Re: RFR: 8023340 : (xxs) Clarify that unmodifiable List.replaceAll() may not throw UOE if there are no items to be replaced.

Hi Mike, On 6/09/2013 2:58 AM, Mike Duigou wrote: Hello all; A very small spec clarification for review. The spec clarification ensures that the behaviour of the default method can satisfy the needs of unmodifiable implementations. http://cr.openjdk.java.net/~mduigou/JDK-8023340/0/webrev/

Re: @Supported design issues

2013/9/5 12:33 -0700, joe.da...@oracle.com: > IMO, the high order goal here should be getting the "is this API okay to > use" information encoded into the source code and class files. Given > that you've already compiled that information, I think there is great > value in going forward with this

Re: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

On 9/5/2013 11:51 AM, Daniel Fuchs wrote: Logger.java - I like this and much cleaner fix. 251 // because global.manager will become not null somewhen during 252 // the initialization of LogManager. s/somewhen/s

Re: @Supported design issues

On 9/5/2013 2:20 AM, Alan Bateman wrote: On 20/03/2013 01:32, Joseph Darcy wrote: Following up in the same thread, the JEP for this work is now available for your reading pleasure at: JEP 179: Document JDK API Support and Stability http://openjdk.java.net/jeps/179 Joe - do you want t

Re: RFR: 8023447: change specification to allow RMI activation to be optional

Looks fine; cheers, -Joe On 9/5/2013 3:46 PM, Stuart Marks wrote: Hi all, Please review this specification-only change to allow RMI activation to be optional. RMI activation, unlike the rest of RMI, pretty much requires the ability to fork processes at will. This causes difficulties in cert

hg: jdk8/tl/langtools: 8023608: method grouping tabs folding issue

Changeset: e32a8a29643a Author:bpatel Date: 2013-09-05 16:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e32a8a29643a 8023608: method grouping tabs folding issue Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css !

RFR: Faster ZipFile.getEntry()/entries()

Hi, The change proposed here is to bring the zip entry handing code from the native level to the java level. This effectively solves the performance issues of ZipFile.getEntry and entries() that is caused by multiple jni invocation steps to generate one single ZipEntry (see ZipFile.getZipEntry

RFR: 8023447: change specification to allow RMI activation to be optional

Hi all, Please review this specification-only change to allow RMI activation to be optional. RMI activation, unlike the rest of RMI, pretty much requires the ability to fork processes at will. This causes difficulties in certain situations, such as in small embedded configurations. Activation

hg: jdk8/tl/jdk: 8024283: 10 nashorn tests fail with similar stack trace InternalError with cause being NoClassDefFoundError

Changeset: 9cc74675a854 Author:rfield Date: 2013-09-05 14:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9cc74675a854 8024283: 10 nashorn tests fail with similar stack trace InternalError with cause being NoClassDefFoundError Summary: Fix pre-existing 292 bug tickled by c

RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]

Please review my changes for 7199674 (http://bugs.sun.com/view_bug.do?bug_id=7199674). This improves how Java .app bundles work when they've been signed for the Mac App Sandbox. Specifically, it changes how the user.home system property is set. For apps signed for the App Sandbox, user.home

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

On Sep 5, 2013, at 7:50 AM, Paul Sandoz wrote: >> The change to pass in the random number generator appears fine. >> There's probably no need for a strong random number generator in this >> case, though. > If that is the case why not just leave the method as is and replace > SecureRandom with Thr

Re: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type

On 9/4/13 6:55 AM, Joel Borggren-Franck wrote: Hi, Please review fix for: http://bugs.sun.com/view_bug.do?bug_id=4987375 Webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.01/ Specdiff: http://cr.openjdk.java.net/~jfranck/4987375/specdiff/java/lang/Class.html ... Me and Alex have als

Re: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

New webrev. Has Martin's comments + simplified Logger.getGlobal(). Rest left unchanged. Tests are running... cheers, -- daniel On 9/5/13 8:16 PM, Daniel Fuchs wrote: Hi Peter, On 9/5/13 7:15 PM, Peter Levart wrote: On 09/05/20

Re: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

Hi Martin, Thanks for the cheers! :-) I am incorporating your comments. Thanks for spotting these issues! best regards, -- daniel On 9/5/13 6:49 PM, Martin Buchholz wrote: Random review comments: Let me cheerlead your efforts to clean up j.u.logging. It's not easy. Previous efforts (inc

hg: jdk8/tl/jdk: 8023943: Method description fix for String.toLower/UpperCase() methods

Changeset: 4c711ef41bfa Author:naoto Date: 2013-09-05 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c711ef41bfa 8023943: Method description fix for String.toLower/UpperCase() methods Reviewed-by: okutsu ! src/share/classes/java/lang/String.java

Re: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

Hi Peter, On 9/5/13 7:15 PM, Peter Levart wrote: On 09/05/2013 02:43 PM, Daniel Fuchs wrote: On 9/5/13 1:51 PM, Peter Levart wrote: Threads that call ensureLogManagerInitialized() after that will find the flag is true before entering the synchronized block and will return directly. ...and su

Re: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to removeAll(Predicate)

Let me point out that the "xxxIf" form of name for this idea (removing elements of a list that satisfy a predicate, or otherwise operating on the elements of a list that satisfy a predicate) has a history tracing back to the year 1979. That's more than a third of a century. --Guy On Sep 5, 20

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

Hi Joe, Thanks. I will push this myself once the Committer role is finalized for pushes. Brian On Sep 4, 2013, at 8:17 PM, Joe Darcy wrote: > Looks fine; approved to go back.

RFR: 8023340 : (xxs) Clarify that unmodifiable List.replaceAll() may not throw UOE if there are no items to be replaced.

Hello all; A very small spec clarification for review. The spec clarification ensures that the behaviour of the default method can satisfy the needs of unmodifiable implementations. http://cr.openjdk.java.net/~mduigou/JDK-8023340/0/webrev/ Thanks, Mike

Re: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

On 09/05/2013 02:43 PM, Daniel Fuchs wrote: On 9/5/13 1:51 PM, Peter Levart wrote: Threads that call ensureLogManagerInitialized() after that will find the flag is true before entering the synchronized block and will return directly. ...and such threads can see rootLogger field being either s

Re: hg: jdk8/tl/jdk: 8019853: Break logging and AWT circular dependency

- Original Message - > Am 04.09.2013, 16:54 Uhr, schrieb : > > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3d6953b9829 > > 8019853: Break logging and AWT circular dependency > > This looks pretty strange: > > http://hg.openjdk.java.net/jdk8/tl/jdk/file/b3d6953b9829/src/share/cl

Re: hg: jdk8/tl/jdk: 8019853: Break logging and AWT circular dependency

Yes - I'd seen it and intended to fix it and then I forgot. Sorry for that. I will clean that up when I get the chance. -- daniel On 9/5/13 6:46 PM, Andrew Hughes wrote: - Original Message - Am 04.09.2013, 16:54 Uhr, schrieb : URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3

Re: hg: jdk8/tl/jdk: 8019853: Break logging and AWT circular dependency

Am 04.09.2013, 16:54 Uhr, schrieb : URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3d6953b9829 8019853: Break logging and AWT circular dependency This looks pretty strange: http://hg.openjdk.java.net/jdk8/tl/jdk/file/b3d6953b9829/src/share/classes/sun/misc/SharedSecrets.java 173

Re: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to removeAll(Predicate)

I know it's probably too late, but it occurred to me that "removeWhere(Predicate)" seems appropriate: coll.removeWhere(s -> s.size() > 3); On Thu, Sep 5, 2013 at 4:25 AM, Alan Bateman wrote: > On 04/09/2013 22:08, Mike Duigou wrote: > > Hello all; > > > > The naming of the Collection.removeIf(P

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

On Sep 5, 2013, at 7:02 AM, Alan Eliasen wrote: > On 09/04/2013 05:26 PM, Brian Burkhalter wrote: >> I have updated the webrev >> >> http://cr.openjdk.java.net/~bpb/7189139/ >> >> to add the two-parameter version of isProbablePrime() which was >> discussed. Naturally a CCC request would be nee

Re: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

Hi, Here is the new patch. It uses an additional volatile flag to avoid synchronizing once the log manager is fully initialized. I have added some comments to spell out the purpose of the flags, as well as some assertion that should make it clear what is expected, what is possible, and what is no

Re: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type

On 09/05/2013 04:04 PM, Joel Borggren-Franck wrote: I don't think the JLS uses "define". Also I think it is actually ok since clone() isn't public. Perhaps change to: * has a Method object for each of the public methods inherited by the * array type from {@code Object}. It does not contain

Re: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type

Hi Florian, On 2013-09-05, Florian Weimer wrote: > On 09/04/2013 03:55 PM, Joel Borggren-Franck wrote: > >Hi, > > > >Please review fix for: http://bugs.sun.com/view_bug.do?bug_id=4987375 > > > >Webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.01/ > > This: > > + * If this Class ob

Re: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

On 09/05/2013 02:45 AM, Daniel Fuchs wrote: Hi Mandy, On 9/5/13 2:46 AM, Mandy Chung wrote: On 9/4/2013 12:56 PM, Daniel Fuchs wrote: Hi, Please find below a changeset that will fix 8023168: Cleanup LogManager class initialization and LogManager/LoggerContext relationship.

Re: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

On 9/5/13 1:51 PM, Peter Levart wrote: Threads that call ensureLogManagerInitialized() after that will find the flag is true before entering the synchronized block and will return directly. ...and such threads can see rootLogger field being either still null or not null but the Logger instance

hg: jdk8/tl/jdk: 8004179: Few of test/java/lang/management/ThreadMXBean/* tests don't clean up the created threads

Changeset: 9522b5e836d3 Author:jbachorik Date: 2013-09-05 14:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9522b5e836d3 8004179: Few of test/java/lang/management/ThreadMXBean/* tests don't clean up the created threads Summary: Just run those tests in "othervm" mode. Revi

Re: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

On 09/05/2013 01:51 PM, Peter Levart wrote: ...almost all of them (except assignment to rootLogger) by themselves ensure that the state mutations they make are published to other threads, so if also *rootLogger* field was made volatile, such double-checked locking would presumably not be broken

Re: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

On 09/05/2013 10:08 AM, Daniel Fuchs wrote: Or, without using yet another class, double-checked locking, like: private volatile boolean initializedCalled; final void ensureLogManagerInitialized() { if (initializedCalled) { return; } synchronized (this) { final LogMan

Re: RFR: 4987375: (reflect) Class.get{Declared}Method{s} does not return clone() for array type

On 09/04/2013 03:55 PM, Joel Borggren-Franck wrote: Hi, Please review fix for: http://bugs.sun.com/view_bug.do?bug_id=4987375 Webrev: http://cr.openjdk.java.net/~jfranck/4987375/webrev.01/ This: + * If this Class object represents an array type, then the returned array + * has a M

hg: jdk8/tl/jdk: 8023464: test/closed/sun/tracing/ProviderProxyTest.java failing

Changeset: af1b08ff48ae Author:jbachorik Date: 2013-09-05 13:04 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af1b08ff48ae 8023464: test/closed/sun/tracing/ProviderProxyTest.java failing Summary: Don't rely on assertions when an Exception suits better Reviewed-by: alanb, dfu

Re: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to removeAll(Predicate)

On 09/04/2013 05:08 PM, Mike Duigou wrote: Hello all; The naming of the Collection.removeIf(Predicate) method has always been an uncertain choice. We've gone back and forth between naming it removeIf and overloading the existing removeAll(Collection) with a removeAll(Predicate). Now that all oth

hg: jdk8/tl/langtools: 8023974: Drop 'implements Completer' and 'implements SourceCompleter' from ClassReader resp. JavaCompiler.

Changeset: a76c663a9cac Author:jfranck Date: 2013-09-05 11:27 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a76c663a9cac 8023974: Drop 'implements Completer' and 'implements SourceCompleter' from ClassReader resp. JavaCompiler. Reviewed-by: jjg, jfranck Contributed-by

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

On 04/09/2013 18:12, Mike Duigou wrote: : Understood. For now the sub-groups boundaries are the same as bug sub-component categories. I personally don't have any plans for the introducing groups which aren't aligned to component or sub-component boundaries. I think we are in agreement that add

Re: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to removeAll(Predicate)

On 04/09/2013 22:08, Mike Duigou wrote: Hello all; The naming of the Collection.removeIf(Predicate) method has always been an uncertain choice. We've gone back and forth between naming it removeIf and overloading the existing removeAll(Collection) with a removeAll(Predicate). Now that all oth

Re: @Supported design issues

On 20/03/2013 01:32, Joseph Darcy wrote: Following up in the same thread, the JEP for this work is now available for your reading pleasure at: JEP 179: Document JDK API Support and Stability http://openjdk.java.net/jeps/179 Joe - do you want to reboot this discussion? With the deadlin

Re: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

On 9/5/13 8:07 AM, Peter Levart wrote: On 09/04/2013 11:36 PM, David M. Lloyd wrote: On 09/04/2013 02:56 PM, Daniel Fuchs wrote: Hi, Please find below a changeset that will fix 8023168: Cleanup LogManager class initialization and LogManager/LoggerContext relationship.

Re: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

Hi David, Thanks a lot for your feedback! On 9/4/13 11:36 PM, David M. Lloyd wrote: As far as calling initialization ("ensureLogManagerInitialized()"), it's a shame that checking for a one-time action has to run through a synchronization block every time. Maybe a "lazy holder" class would be

Re: RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

Hi Mandy, On 9/5/13 2:46 AM, Mandy Chung wrote: On 9/4/2013 12:56 PM, Daniel Fuchs wrote: Hi, Please find below a changeset that will fix 8023168: Cleanup LogManager class initialization and LogManager/LoggerContext relationship.