Re: RFR: JDK-6823527: java.util.logging.Handler has thread safety issues

Daniel, On 8/30/2013 4:50 AM, Daniel Fuchs wrote: Hi, Please find below an updated patch for solution (c) I'm fine with (c) that is a reasonable fix for this bug. The change looks fine with me. Mandy best regards, -- dani

hg: jdk8/tl/jdk: 8008688: Make MethodHandleInfo public

Changeset: 4bdbd1fabea4 Author:rfield Date: 2013-09-03 21:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bdbd1fabea4 8008688: Make MethodHandleInfo public Summary: A major overhaul to MethodHandleInfo and method handles in general. Reviewed-by: vlivanov, twisti Contribute

hg: jdk8/tl/jdk: 8024140: [TESTBUG] Profile based regression test groups for jdk repo

Changeset: 2cdd1078f45b Author:dholmes Date: 2013-09-03 23:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cdd1078f45b 8024140: [TESTBUG] Profile based regression test groups for jdk repo Reviewed-by: alanb, chegar ! test/TEST.groups

Re: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo

With thanks to Alan and Chris for their reviews I will push this initial set of group definitions. David On 3/09/2013 1:02 PM, David Holmes wrote: webrev: http://cr.openjdk.java.net/~dholmes/8024140/webrev/ Similar to what was recently done on the hotspot side, this introduces profile-based

Re: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo

On 3/09/2013 11:12 PM, roger riggs wrote: Hi, There are going to be some gaps in compact1 testing if TestNG tests are omitted. For example, all of java.time uses TestNg exclusively. Yes I noticed. :( The java.time tests do not use the XML input file configuration options so perhaps the depe

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

Just realize that I missed a few words in a sentence that could mislead what I really mean correction below. On 9/3/2013 5:02 PM, Mandy Chung wrote: Nick, I skimmed through the changes. Congratulations for your first patch making changes in both hotspot and jdk code. In my mind, the Lo

Re: Replacement of sun.reflect.Reflection#getCallerClass

On 9/3/13 1:17 AM, Jochen Theodorou wrote: Defining a SE supported @CallerSensitive and also getCallerClass API poses the risk of "encouraging" developers to implement more @CS methods while not fully understand its implication. Again I am curious... what is such an implication? That your metho

Re: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks)

On Sep 3, 2013, at 5:09 PM, Doug Lea wrote: > Only adding isProbablePrime seems to be an OK conservative > move: no existing usages would be affected, but users would > need to somehow be told that they could improve performance > by changing their code to use the new method with > ThreadLocalRan

Re: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks)

On 09/03/2013 07:52 PM, Brian Burkhalter wrote: On Sep 3, 2013, at 4:46 PM, Doug Lea wrote: I assume you mean to change line 898: if (rnd == null) { rnd = ThreadLocalRandom.current();; // was: getSecureRandom(); } Yes. This seems fine in terms of sufficient RNG qua

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

Nick, I skimmed through the changes. Congratulations for your first patch making changes in both hotspot and jdk code. In my mind, the Log4J use case accessing Class instance to obtain additional information for diagnosability is different than the use case of obtaining the caller's class /

Re: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks)

On Sep 3, 2013, at 4:46 PM, Doug Lea wrote: > I assume you mean to change line 898: > >if (rnd == null) { >rnd = ThreadLocalRandom.current();; // was: getSecureRandom(); >} Yes. > This seems fine in terms of sufficient RNG quality and better > performance. Also in te

Re: Still need Reviewer approval: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1

Hi Joe, I will proceed on these two points. Thanks, Brian On Sep 3, 2013, at 4:48 PM, Joe Darcy wrote: > I'd appreciate some additional comments in the body of the code explaining > what is attempted to be implemented. > > On the ccc front, since a behavioral change is presumably being made

Re: Still need Reviewer approval: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1

Hi Brian, I'd appreciate some additional comments in the body of the code explaining what is attempted to be implemented. On the ccc front, since a behavioral change is presumably being made for a few values, a ccc is justified. Thanks, -Joe On 9/3/2013 1:29 PM, Brian Burkhalter wrote: J

Re: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks)

On 09/03/2013 03:06 PM, Brian Burkhalter wrote: So it looks like there are two decisions to be made on this topic: On Sep 3, 2013, at 1:21 AM, Paul Sandoz wrote: add the following method to BigInteger public boolean isProbablePrime(int certainty, Random end) , which allows primality testing wi

hg: jdk8/tl/langtools: 8023545: Misleading error message when using diamond operator with private constructor

Changeset: 9be0afbdf244 Author:vromero Date: 2013-09-03 23:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9be0afbdf244 8023545: Misleading error message when using diamond operator with private constructor Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/co

hg: jdk8/tl/langtools: 8023389: Javac fails to infer type for lambda used with intersection type and wildcards

Changeset: fb5a846c4a49 Author:vromero Date: 2013-09-03 23:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fb5a846c4a49 8023389: Javac fails to infer type for lambda used with intersection type and wildcards Reviewed-by: jjg, vromero Contributed-by: maurizio.cimadam.

Re: RFR: 8023997 : j.l.String.join(java.lang.CharSequence, java.lang.Iterable) sample doesn't compile and is incorrect

On 08/30/2013 12:53 AM, Alan Bateman wrote: > On 30/08/2013 07:44, Henry Jen wrote: >> Hi, >> >> Please kindly review a simple webrev that just fixes a sample in the >> javadoc of String.join(). >> >> http://cr.openjdk.java.net/~henryjen/tl/8023997/0/webrev/ >> > This looks okay to me. > Thanks,

Re: RFR: 8024014 : (xs) TEST.groups updates

Hello all; Here is an updated webrev of just 8024014: http://cr.openjdk.java.net/~mduigou/JDK-8024014/0/webrev/ The controversial item here is the definition of the jdk_collections group which, since collections isn't aligned to a directory, is defined by a list of sub-directories. Since the l

hg: jdk8/tl: 8024200: handle hg wrapper with space after #!

Changeset: 6d7f27953da6 Author:mduigou Date: 2013-09-03 15:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6d7f27953da6 8024200: handle hg wrapper with space after #! Reviewed-by: tbell ! common/bin/hgforest.sh

hg: jdk8/tl/jdk: 8023997: j.l.String.join(java.lang.CharSequence, java.lang.Iterable) sample doesn't compile and is incorrect

Changeset: 06b01083ebd7 Author:henryjen Date: 2013-09-03 16:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06b01083ebd7 8023997: j.l.String.join(java.lang.CharSequence, java.lang.Iterable) sample doesn't compile and is incorrect Reviewed-by: alanb ! src/share/classes/jav

hg: jdk8/tl/langtools: 8023549: Compiler emitting spurious errors when constructor reference type is inferred and explicit type arguments are supplied

Changeset: 438547d895dc Author:vromero Date: 2013-09-04 00:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/438547d895dc 8023549: Compiler emitting spurious errors when constructor reference type is inferred and explicit type arguments are supplied Reviewed-by: jjg, v

hg: jdk8/tl/corba: 8017195: Introduce option to setKeepAlive parameter on CORBA sockets

Changeset: af8e5bc3a150 Author:coffeys Date: 2013-09-03 22:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/af8e5bc3a150 8017195: Introduce option to setKeepAlive parameter on CORBA sockets Reviewed-by: chegar, msheppar ! src/share/classes/com/sun/corba/se/impl/transport

Re: RFR: JDK-7186632: NLS t13y issue on jar.properties file

Looks good to me. Naoto On 8/29/13 11:19 AM, Xueming Shen wrote: Hi, Please help review the change for #7186632. http://cr.openjdk.java.net/~sherman/7186632/webrev The proposed change here is to remove the backslash before the word "inflated:". While based on j.u.Properties spec it is absolu

hg: jdk8/tl/jdk: 8017195: Introduce option to setKeepAlive parameter on CORBA sockets

Changeset: 5920155dd080 Author:coffeys Date: 2013-09-03 22:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5920155dd080 8017195: Introduce option to setKeepAlive parameter on CORBA sockets Reviewed-by: chegar, msheppar + test/com/sun/corba/transport/KeepAliveSockets.java

Re: RFR: 8016127 - NLS: logging.properties translatability recommendation

Hi Daniel, Locale.Category was introduced in JDK7 where the user can set the default locales separately for UI display names and Formatting. In your case, the resource bundle seems to contain user visible localizable strings, so I suggested using getDefault() with Locale.Category.DISPLAY spec

Re: RFR: 8016127 - NLS: logging.properties translatability recommendation

On 9/3/13 9:57 PM, Naoto Sato wrote: Hi Daniel, Just one comment. When you are retrieving the default locale, please use Locale.getDefault(Locale.Category.DISPLAY) which returns the default locale for displaying translatable names. Hi Naoto - ResourceBundle.getBundle(String rbName) is document

Still need Reviewer approval: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1

JDK 8 Reviewers: Following up on this thread http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/020421.html an approval from a JDK 8 Reviewer is still needed (assuming of course that the change is acceptable). Also, there is the stated question of CCC request necessity. Thanks,

Re: RFR: 8016127 - NLS: logging.properties translatability recommendation

Hi Daniel, Just one comment. When you are retrieving the default locale, please use Locale.getDefault(Locale.Category.DISPLAY) which returns the default locale for displaying translatable names. Naoto On 9/2/13 6:29 AM, Daniel Fuchs wrote: Hi, Please find below a fix for: 8016127: NLS: lo

Re: Replacement of sun.reflect.Reflection#getCallerClass

In Log4j's case the information we want from each StackTraceFrame is: a) the class name, b) the jar or directory where the class resided. c) the version of the jar. d) the ClassLoader associated with the class. Having the actually Class object allows us to get all of this information but if it i

Re: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets

Sean, yes, that's fine ... no mardy bum from me regards Mark On 03/09/2013 19:15, Seán Coffey wrote: Mark, WRT testing, should we be accessing impl classes from tests, keeping in mind the desire to restrict access to the corba.impl classes in future jdk releases? This then might force this

Re: RFR: 8021591 : (s) Additional explicit null checks

On Sep 3 2013, at 02:03 , Paul Sandoz wrote: > > On Aug 28, 2013, at 12:56 AM, Mike Duigou wrote: > >> Hello all; >> >> Here's an updated version of the patch which incorporates feedback and >> improves the tests (the reason for delay): >> >> http://cr.openjdk.java.net/~mduigou/JDK-8021591/

hg: jdk8/tl/jdk: 8017513: Support for closeable streams; ...

Changeset: 2e8d51a5596b Author:henryjen Date: 2013-09-03 12:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2e8d51a5596b 8017513: Support for closeable streams 8022237: j.u.s.BaseStream.onClose() has an issue in implementation or requires spec clarification 8022572: Same e

Re: Replacement of sun.reflect.Reflection#getCallerClass

On 9/3/13 11:11 AM, Peter Levart wrote: On 09/03/2013 07:41 PM, David M. Lloyd wrote: What about a simple restriction on methods returning such instances that Class objects are only returned when they are resolvable from the ClassLoader of client code. If they are not resolvable, null is return

Re: RFR: 8024718: Difference in Stream.collect(Collector) methods located in jdk8 and jdk8-lambda repos

Looks fine. On Sep 3 2013, at 11:38 , Henry Jen wrote: > Hi, > > Please review a simple webrev at > > http://cr.openjdk.java.net/~henryjen/tl/8024178/0/webrev/ > > The reverted change was included as part of JDK-8015318 fix at late > stage, after more thoughts, it is not needed. > > As a coll

hg: jdk8/tl/jdk: 8022176: Weaken contract of java.lang.AutoCloseable

Changeset: 77a8c4ad516c Author:henryjen Date: 2013-08-28 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77a8c4ad516c 8022176: Weaken contract of java.lang.AutoCloseable Reviewed-by: alanb, martin, mduigou, psandoz Contributed-by: brian.go...@oracle.com ! src/share/clas

Re: Replacement of sun.reflect.Reflection#getCallerClass

Agree. I was just pointing that there are 'sensitive' packages and access to sensitive package classes - both normal linking reference and reflective reference by Class.forName - is security access checked. (i.e., there are Class objects that are security access protected as well - not just Cla

Re: Replacement of sun.reflect.Reflection#getCallerClass

On 09/03/2013 01:11 PM, Peter Levart wrote: On 09/03/2013 07:41 PM, David M. Lloyd wrote: Now for that part, the public API equivalent (StackTraceFrame.getCallerClass() or whatever it is called) need not be restricted to methods annotated with any annotation, but that means that this public API

hg: jdk8/tl/jdk: 8024178: Difference in Stream.collect(Collector) methods located in jdk8 and jdk8-lambda repos

Changeset: 3db3ae4e0853 Author:henryjen Date: 2013-09-03 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3db3ae4e0853 8024178: Difference in Stream.collect(Collector) methods located in jdk8 and jdk8-lambda repos Reviewed-by: mduigou ! src/share/classes/java/util/strea

Re: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks)

So it looks like there are two decisions to be made on this topic: On Sep 3, 2013, at 1:21 AM, Paul Sandoz wrote: >>> add the following method to BigInteger >>> public boolean isProbablePrime(int certainty, Random end) , >>> which allows primality testing with arbitrary Random objects. >>> In man

RFR: 8024718: Difference in Stream.collect(Collector) methods located in jdk8 and jdk8-lambda repos

Hi, Please review a simple webrev at http://cr.openjdk.java.net/~henryjen/tl/8024178/0/webrev/ The reverted change was included as part of JDK-8015318 fix at late stage, after more thoughts, it is not needed. As a collector returns a R can be assigned to ? super R, so we don't really need part

Re: RFR: 8024014 & 8024015 : (xs) TEST.groups updates

FYI, I have pushed 8024015 but not 8024014. I will have an updated (cleaner) patch for 8024014 shortly. Mike On Aug 29 2013, at 17:13 , Mike Duigou wrote: > Hello all; > > This is a review for two changesets. The first change (JDK-8024014) splits up > the jdk_util test group a bit by introdu

hg: jdk8/tl/jdk: 8024015: TEST.groups: move jdk/lambda tests from jdk_other to jdk_lang

Changeset: 4bdbe25b1e04 Author:mduigou Date: 2013-09-03 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bdbe25b1e04 8024015: TEST.groups: move jdk/lambda tests from jdk_other to jdk_lang Reviewed-by: alanb, mchung ! test/TEST.groups

RFR(2nd): 8017513: Support for closeable streams

Updated webrev is at http://cr.openjdk.java.net/~henryjen/ccc/8017513/2/webrev/ Addressed comments from Alan and catch IOExpression when close on exception in Files method. Cheers, Henry On 08/29/2013 02:15 AM, Alan Bateman wrote: > On 29/08/2013 09:51, Paul Sandoz wrote: >> On Aug 29, 2013, a

Re: RFR 8024182 test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes

Looks fine to me as well. Mike On Sep 3 2013, at 09:33 , Paul Sandoz wrote: > Hi, > > Due to recent compiler changes a test is failing to compile. > > The fix is already in lambda and needs to be pushed to tl: > > http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9389 > > Paul. >

Re: Replacement of sun.reflect.Reflection#getCallerClass

Am 03.09.2013 19:16, schrieb Peter Levart: [...] What about a simple restriction on methods returning such instances that Class objects are only returned when they are resolvable from the ClassLoader of client code. If they are not resolvable, null is returned. For example, the equivalent of: pu

Re: Replacement of sun.reflect.Reflection#getCallerClass

On 09/03/2013 12:16 PM, Peter Levart wrote: On 09/03/2013 04:39 PM, Nick Williams wrote: >Do you mean sun.reflect.CallerSensitive can go away? This is very important part of the design that we need to detect which methods are caller-sensitive. I keep seeing you suggest this and it is unclear

Re: Replacement of sun.reflect.Reflection#getCallerClass

Am 03.09.2013 16:12, schrieb A. Sundararajan: [...] If Groovy or any third-party framework gets away with that -- that is because you need to use modified security policy that gives those necessary permissions to groovy.jar or whatever third-party jar in question. just think of us needing to bu

Re: Replacement of sun.reflect.Reflection#getCallerClass

On 09/03/2013 07:26 PM, Nick Williams wrote: On Sep 3, 2013, at 12:16 PM, Peter Levart wrote: On 09/03/2013 04:39 PM, Nick Williams wrote: Do you mean sun.reflect.CallerSensitive can go away? This is very important part of the design that we need to detect which methods are caller-sensitive.

Re: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets

Mark, WRT testing, should we be accessing impl classes from tests, keeping in mind the desire to restrict access to the corba.impl classes in future jdk releases? This then might force this to be a packet level test? Missed this comment. With respect to using the impl classes, I don't see a p

Re: Replacement of sun.reflect.Reflection#getCallerClass

On 09/03/2013 07:41 PM, David M. Lloyd wrote: Now for that part, the public API equivalent (StackTraceFrame.getCallerClass() or whatever it is called) need not be restricted to methods annotated with any annotation, but that means that this public API should not be used to implement security deci

Re: Replacement of sun.reflect.Reflection#getCallerClass

On Sep 3, 2013, at 12:16 PM, Peter Levart wrote: > On 09/03/2013 04:39 PM, Nick Williams wrote: >>> > >>> Do you mean sun.reflect.CallerSensitive can go away? This is very >>> important part of the design that we need to detect which methods are >>> caller-sensitive. I keep seeing you sugge

Re: RFR 8024182 test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes

On 03/09/2013 17:33, Paul Sandoz wrote: Hi, Due to recent compiler changes a test is failing to compile. The fix is already in lambda and needs to be pushed to tl: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9389 Paul. Looks good, thanks for sorting this out. The other thing that t

Re: Replacement of sun.reflect.Reflection#getCallerClass

On 09/03/2013 04:39 PM, Nick Williams wrote: >Do you mean sun.reflect.CallerSensitive can go away? This is very important part of the design that we need to detect which methods are caller-sensitive. I keep seeing you suggest this and it is unclear to me if you only mean to remove java.lang

Re: Replacement of sun.reflect.Reflection#getCallerClass

On 9/3/13 7:40 AM, David M. Lloyd wrote: On 09/03/2013 09:30 AM, Mandy Chung wrote: On 9/3/2013 5:52 AM, Nick Williams wrote: Do, I don't understand the rationale. Alan said the security issues couldn't be discussed openly. I can get a Class object MANY different ways without a security check.

RFR 8024182 test/java/util/Arrays/SetAllTest.java fails to compile due to recent compiler changes

Hi, Due to recent compiler changes a test is failing to compile. The fix is already in lambda and needs to be pushed to tl: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9389 Paul.

Re: Replacement of sun.reflect.Reflection#getCallerClass

Am 03.09.2013 11:04, schrieb Remi Forax: [...] So there is a need for an API to get the caller classes which is not getCallerClass (or any methods in a package sun.*) that will hide you the method handle API impementation and allow you choose to filter caller methods using a user defined API. n

Re: Replacement of sun.reflect.Reflection#getCallerClass

I'd just like to add to this thread that Log4j is copying behavior that has been in Logback for years. The default behavior for both is to print a stack trace that includes the jar or directory where the class was located and its version. User's find this extremely helpful when diagnosing probl

Re: Replacement of sun.reflect.Reflection#getCallerClass

On 09/03/2013 09:30 AM, Mandy Chung wrote: On 9/3/2013 5:52 AM, Nick Williams wrote: Do, I don't understand the rationale. Alan said the security issues couldn't be discussed openly. I can get a Class object MANY different ways without a security check. I don't see or understand any vulnerabili

Re: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets

On 3 Sep 2013, at 16:10, Seán Coffey wrote: > I'd like to keep the same property behaviour as that used in JDK 6. It's also > the one agreed on for CCC request. I've seen the same pattern used in other > parts of corelibs code. > > Taken Chris's feedback on board : > http://cr.openjdk.java.ne

Re: Replacement of sun.reflect.Reflection#getCallerClass

On Sep 3, 2013, at 9:30 AM, Mandy Chung wrote: > > On 9/3/2013 5:52 AM, Nick Williams wrote: >> Do, I don't understand the rationale. Alan said the security issues couldn't >> be discussed openly. I can get a Class object MANY different ways without a >> security check. I don't see or understa

Re: Replacement of sun.reflect.Reflection#getCallerClass

On Sep 3, 2013, at 9:39 AM, Nick Williams wrote: > > On Sep 3, 2013, at 9:30 AM, Mandy Chung wrote: > >> >> On 9/3/2013 5:52 AM, Nick Williams wrote: >>> Do, I don't understand the rationale. Alan said the security issues >>> couldn't be discussed openly. I can get a Class object MANY differe

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

On 03/09/2013 13:24, Nick Williams wrote: : As regards frameworks using sun.reflect.Reflection.getCallerClass directly then it's as I said previously, they are probably not run with a security manager very often (at least not unless the policy is configured to allow direct access to sun.*).

Re: Replacement of sun.reflect.Reflection#getCallerClass

On Sep 3, 2013, at 9:40 AM, David M. Lloyd wrote: > On 09/03/2013 09:30 AM, Mandy Chung wrote: >> >> On 9/3/2013 5:52 AM, Nick Williams wrote: >>> Do, I don't understand the rationale. Alan said the security issues >>> couldn't be discussed openly. I can get a Class object MANY different >>> way

Re: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets

It appears to be negative logic. If it's not false then its true. As the default value is false, would it be less ambiguous if only a property value of true sets the keepAlive variable to true? if ((value != null) && ("true".equalsIgnoreCase(value)) keepAlive = true; WRT testing, shou

Re: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets

I'd like to keep the same property behaviour as that used in JDK 6. It's also the one agreed on for CCC request. I've seen the same pattern used in other parts of corelibs code. Taken Chris's feedback on board : http://cr.openjdk.java.net/~coffeys/webrev.8017195.2/webrev/ regards, Sean. On 03

Re: RFR: 8019853 - Break logging and AWT circular dependency

Hi, Daniel, I only looked at AppContext.java changes, and they look fine. Line 870 looks redundant, indeed, on the other hand it shouldn't hurt as well. Leaving it up to you. Thanks, Artem On 8/30/2013 7:14 AM, Mandy Chung wrote: Hi Daniel, Thanks for getting this fixed. The change looks

Re: Replacement of sun.reflect.Reflection#getCallerClass

On 9/3/2013 5:52 AM, Nick Williams wrote: Do, I don't understand the rationale. Alan said the security issues couldn't be discussed openly. I can get a Class object MANY different ways without a security check. I don't see or understand any vulnerabilities here. I'm going to need much more in

Re: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets

There is always debate over this, but I suspect, given the property name com.sun.CORBA.transport.enableTcpKeepAlive, that if it is set ( -Dcom.sun.CORBA.transport.enableTcpKeepAlive ) then Sean is proposing that keepAlive should be true. It if has a value, then it must not be false. -Chris. O

Re: Replacement of sun.reflect.Reflection#getCallerClass

I don't think it is possible to get every Class object in the system. Either you should have a reference to an object (in which case you can call Object.getClass method) or the classloader that loaded your class should be able to resolve the referred class. For example, Class.forName("sun

Re: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo

Hi, There are going to be some gaps in compact1 testing if TestNG tests are omitted. For example, all of java.time uses TestNg exclusively. The java.time tests do not use the XML input file configuration options so perhaps the dependency on XML can be broken. Roger On 9/3/2013 4:26 AM, David

Re: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\'

On 09/03/2013 01:53 PM, Seán Coffey wrote: First option sounds good to me too Miran. Sounds like we can expect this fix to be sync'ed into JDK8 from JAXWS team over next week or two then. Hopefully you can do the same for jdk7u-dev. Since this is destined for 7u too. I would suggest that the JA

Re: RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets

Sean, I remember discussing this (offlist) with you a while back, and I agree with the proposed solution. The logic for checking the system property looks a little odd. But I will admit views differ on exactly what values should be accepted. So, trivially I would suggest making keepAlive fin

Re: Replacement of sun.reflect.Reflection#getCallerClass

On Sep 2, 2013, at 10:04 PM, Mandy Chung wrote: > Hi Nick, > > Thanks for the patch. > > JEP 176 [1] describes the caller-sensitive method and the need for a > mechanical checking of caller-sensitive methods. Also Peter Levart in [2] > explained the change in MethodHandles.Lookup related to

Re: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\'

First option sounds good to me too Miran. Sounds like we can expect this fix to be sync'ed into JDK8 from JAXWS team over next week or two then. Hopefully you can do the same for jdk7u-dev. regards, Sean. On 03/09/2013 13:32, Miroslav Kos wrote: Hi Sean, up to now, integrations JAX-WS > JDK h

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

It's simple enough to just create an accessor object and add a security check on creation. There does not need to be a significant jam-up over this issue afaict. On 09/03/2013 07:24 AM, Nick Williams wrote: On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote: On 02/09/2013 18:45, Nick Williams

Re: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\'

Hi Sean, up to now, integrations JAX-WS > JDK haven't been done on regular basis, just when bug fixes were required, for current JDK development version it was time to time - 2x or 3x during a year (?) ... For future, we would like make it on regular basis for development version JAX-WS trunk

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote: > On 02/09/2013 18:45, Nick Williams wrote: >> : >> >> I didn't decide to ignore the security concerns, I just don't see any >> security concerns. As has been /clearly/ established in the last three >> months, frameworks have been using getCaller

RFR: 8017195 : Introduce option to setKeepAlive parameter on CORBA sockets

Sockets created by the com.sun.corba.se.impl.transport.DefaultSocketFactoryImpl factory can be affected by firewalls if that connection is left idle for long periods of time. (closed out). A workaround for such an issue could be to have a simple corba thread send some simple ping traffic on the

Re: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\'

Miran, can you clarify how we get this fix in then. Will you patch into JAX-WS and port to the jdk/jaxws repo or do can we push it to both repos independently? How often does JAX-WS team sync with openJDK ? I need to get this ported to jdk7u also. regards, Sean. On 03/09/2013 11:11, Mirosla

Re: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\'

Hi Alan, good catch! Yes, we need to apply the fix on our side too, otherwise it would be reverted with a new integration JAX-WS > JDK. Miran On 09/03/2013 12:03 PM, Alan Bateman wrote: On 03/09/2013 10:49, Seán Coffey wrote: Bug report not public at moment. (should appear shortly) Issue

Re: RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\'

On 03/09/2013 10:49, Seán Coffey wrote: Bug report not public at moment. (should appear shortly) Issue with wsimport tool. Use of jar files created from wsimport on windows don't work on unix systems. Portability issue. Simple fix. wsimport testcase to accompany it. http://cr.openjdk.java.net

Re: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo

On 3/09/2013 7:22 PM, Chris Hegarty wrote: David, I share Alan's concerns about the maintainability of this, but I don't have a better answer ( without much reorganizing/tagging ). Out of interest, how did you come up with the lists? For example, java/net/URLClassLoader/closetest/GetResourceAsS

RFR: 8016271: wsimport -clientjar does not create portable jar on windows due to hardcoded '\'

Bug report not public at moment. (should appear shortly) Issue with wsimport tool. Use of jar files created from wsimport on windows don't work on unix systems. Portability issue. Simple fix. wsimport testcase to accompany it. http://cr.openjdk.java.net/~coffeys/webrev.8016271/ regards, Sean.

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

On 09/03/2013 11:07 AM, Alan Bateman wrote: On 02/09/2013 18:45, Nick Williams wrote: : I didn't decide to ignore the security concerns, I just don't see any security concerns. As has been /clearly/ established in the last three months, frameworks have been using getCallerClass for years, if

Re: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo

David, I share Alan's concerns about the maintainability of this, but I don't have a better answer ( without much reorganizing/tagging ). Out of interest, how did you come up with the lists? For example, java/net/URLClassLoader/closetest/GetResourceAsStream.java is in needs_jdk. I presume be

Re: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets or trees (red/black)

On 02/09/2013 15:12, Paul Sandoz wrote: FYI: this has been soaking in the lambda repo for over a weak now. AFAICT there have been no issues. Paul. If you can pull into a clone of jdk8/tl, run the tests to make sure that all is okay then I think we should just get it in. -Alan.

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

On 02/09/2013 18:45, Nick Williams wrote: : I didn't decide to ignore the security concerns, I just don't see any security concerns. As has been /clearly/ established in the last three months, frameworks have been using getCallerClass for years, if not a decade. It has never caused a security

Re: Replacement of sun.reflect.Reflection#getCallerClass

On 09/03/2013 10:17 AM, Jochen Theodorou wrote: Am 03.09.2013 05:04, schrieb Mandy Chung: Hi Nick, Thanks for the patch. JEP 176 [1] describes the caller-sensitive method and the need for a mechanical checking of caller-sensitive methods. Also Peter Levart in [2] explained the change in Metho

Re: RFR: 8021591 : (s) Additional explicit null checks

On Aug 28, 2013, at 12:56 AM, Mike Duigou wrote: > Hello all; > > Here's an updated version of the patch which incorporates feedback and > improves the tests (the reason for delay): > > http://cr.openjdk.java.net/~mduigou/JDK-8021591/1/webrev/ > > The substance of the patch is largely to add

Re: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo

Hi Alan, On 3/09/2013 5:55 PM, Alan Bateman wrote: On 03/09/2013 04:02, David Holmes wrote: webrev: http://cr.openjdk.java.net/~dholmes/8024140/webrev/ : Note: once this is in place, anyone writing regression tests will need to be aware of whether that test is limited to certain profiles and

Re: RFR: 8024014 & 8024015 : (xs) TEST.groups updates

On 03/09/2013 00:23, David Holmes wrote: On 3/09/2013 2:05 AM, Alan Bateman wrote: On 30/08/2013 21:30, Mike Duigou wrote: : Did you see David Holmes' suggestion? Do you think it's adequate? I agree about the maintainability aspect as I really felt guilty re-creating FILES_JAVA.gmk... Sorry Mi

Re: Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks)

On Sep 3, 2013, at 7:14 AM, Bradford Wetmore wrote: > Bill also wrote in that email: > > > add the following method to BigInteger > > public boolean isProbablePrime(int certainty, Random end) , > > which allows primality testing with arbitrary Random objects. > > In many cases, using a well seed

Re: Replacement of sun.reflect.Reflection#getCallerClass

Am 03.09.2013 05:04, schrieb Mandy Chung: Hi Nick, Thanks for the patch. JEP 176 [1] describes the caller-sensitive method and the need for a mechanical checking of caller-sensitive methods. Also Peter Levart in [2] explained the change in MethodHandles.Lookup related to @CS. I assume you und

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

On 02/09/2013 22:58, Seán Coffey wrote: Some minor modification (and further simplifying of conditions) : http://cr.openjdk.java.net/~coffeys/webrev.8023563.3/webrev/ This looks much better. -Alan.

Re: RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo

On 03/09/2013 04:02, David Holmes wrote: webrev: http://cr.openjdk.java.net/~dholmes/8024140/webrev/ : Note: once this is in place, anyone writing regression tests will need to be aware of whether that test is limited to certain profiles and update the group file accordingly. Sometimes it is

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

On 2 Sep 2013, at 22:58, Seán Coffey wrote: > Some minor modification (and further simplifying of conditions) : > > http://cr.openjdk.java.net/~coffeys/webrev.8023563.3/webrev/ Looks good to me. -Chris. > > regards, > Sean. > > On 02/09/13 21:07, Alan Bateman wrote: >> On 02/09/2013 19:06,