build failure on solaris-i586 in make/sun/cldr

I haven't build on solaris-i586 for some time and see a failure today in make/sun/cldr. The Makefile [1] has these lines: 75 for dir in $(GENSRCDIR); do \ 76 if [ -d $$dir ] ; then \ 77 ( $(CD) $$dir; \ 78

hg: jdk8/tl/jdk: 8004905: Correct license of test to remove classpath exception

Changeset: 6c795437f212 Author:mduigou Date: 2012-12-11 20:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c795437f212 8004905: Correct license of test to remove classpath exception Reviewed-by: akhil ! test/java/lang/ThreadLocal/ThreadLocalSupplierTest.java

Re: 8004874: (profiles) Reduce dependency on java.beans to only add/removePropertyChangeListener

Hi Alan, This decoupling looks fine to me. David On 12/12/2012 5:55 AM, Alan Bateman wrote: Those tracking the work to get us to a modular JDK will know that the java.beans package is highly problematic. For the "core" modules then j.u.l.LogManager and j.u.jar.Pack200 have support for Proper

Re: RFR: 8004748: clean up @build tags in RMI tests

Looks fine with me. I notice that there are cases that still require @build the main class when it contains the source for other interfaces/classes that another class depends on - not a problem. Mandy On 12/11/2012 3:53 PM, Stuart Marks wrote: Hi all, Please review the following gigantic w

Re: Proposal: Fully Concurrent ClassLoading

Ah, well for our concurrent class loader we just keep simple counters for all that stuff. If we can boost that up to the ClassLoader level that'd be nifty. The stats we track that have been useful are: - Number of defined classes - Number of 'races' i.e. define when already existent - Number

Re: Proposal: Fully Concurrent ClassLoading

On 11/12/2012 9:58 PM, Peter Levart wrote: On 12/11/2012 12:27 PM, David Holmes wrote: Peter, You are convincing me that all superclasses must be fully concurrent too. Otherwise we are just trying to second-guess a whole bunch of what-ifs. :) If you think some more, yes. The superclass might

Re: Proposal: Fully Concurrent ClassLoading

On 12/12/2012 1:10 AM, David M. Lloyd wrote: No problem. What do you mean by "instrumentation"? Any means of "seeing" when parallel define class actually occurred: - -verbose:class logging ? - jvmstat counter ? - -XX:+TraceParallelDefine ? - ??? Thanks, David On 12/10/2012 11:18 PM, David

Re: RFR: 8004748: clean up @build tags in RMI tests

Looks fine; approved, -Joe On 12/11/2012 03:53 PM, Stuart Marks wrote: Hi all, Please review the following gigantic webrev [1] to clean up @build tags in RMI tests. Details underlying this change are in the bug report [2]. Briefly, if test classes listed in @build tags are in the wrong ord

Re: RFR: 8004651 - TEST: java/util/logging/CheckLockLocationTest.java failed to delete file (win)

Looks good! Do you need someone to push this for you? s'marks On 12/11/12 3:04 PM, Jim Gish wrote: A bit more cleanup as suggested: http://cr.openjdk.java.net/~jgish/Bug8004651-CheckLockLocationTest-Windows-delete-file-fix/

RFR: 8004748: clean up @build tags in RMI tests

Hi all, Please review the following gigantic webrev [1] to clean up @build tags in RMI tests. Details underlying this change are in the bug report [2]. Briefly, if test classes listed in @build tags are in the wrong order, this trips over a jtreg problem that in turn causes a cascade of subse

hg: jdk8/tl/jdk: 8003246: Add InitialValue Supplier to ThreadLocal

Changeset: c4bd81de2868 Author:akhil Date: 2012-12-11 15:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4bd81de2868 8003246: Add InitialValue Supplier to ThreadLocal Reviewed-by: mduigou, forax, dl, chegar, briangoetz ! src/share/classes/java/lang/ThreadLocal.java + test

Re: 8004874: (profiles) Reduce dependency on java.beans to only add/removePropertyChangeListener

Alan, Looks good to me. Duplicating the Beans supporting class is fine as they will be removed when the deprecated addPropertyChangeListener and removePropertyChangeListener methods are removed in a future release. Mandy On 12/11/12 11:55 AM, Alan Bateman wrote: Those tracking the work to

hg: jdk8/tl/langtools: 8004828: refactor init of *DocImpl classes

Changeset: cfde9737131e Author:jjg Date: 2012-12-11 15:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cfde9737131e 8004828: refactor init of *DocImpl classes Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/

Re: RFR: 8004651 - TEST: java/util/logging/CheckLockLocationTest.java failed to delete file (win)

A bit more cleanup as suggested: http://cr.openjdk.java.net/~jgish/Bug8004651-CheckLockLocationTest-Windows-delete-file-fix/ Thanks, Jim On 12/10/2012 07:47 PM, Stuart Marks wrote: Hi Jim, Ca

Re: 8004874: (profiles) Reduce dependency on java.beans to only add/removePropertyChangeListener

Alan, PropMap.java, Nit: typo PropertyChangeListern's similarly in the other. Nice test, but since it is specific to pack200 and all pack200 tests are in jdk/test/tools/pack200, perhaps move it there ? Besides that I could not find anything else wrong, the users of these ProperyChangeListeners

8004874: (profiles) Reduce dependency on java.beans to only add/removePropertyChangeListener

Those tracking the work to get us to a modular JDK will know that the java.beans package is highly problematic. For the "core" modules then j.u.l.LogManager and j.u.jar.Pack200 have support for PropertyChangeListener and that means edges in the module graph that are highly undesirable. As I

Re: Review Request: 8004201: add reducers to primitive type wrappers

http://cr.openjdk.java.net/~akhil/8004201.3/webrev/ - removed these operators on Byte and Short - javadoc improvements based on CCC review On 12/10/2012 03:45 PM, Akhil Arora wrote: http://cr.openjdk.java.net/~akhil/8004201.2/webrev/ - replaced "Suitable for conversion as a method reference to

Re: RFR: Trivial patch for javadoc warnings in Base64

Looks good Chris -- approved! Cheers, -Joe On 12/11/2012 10:10 AM, Chris Hegarty wrote: hg diff Base64.java diff -r d206e52bf8a6 src/share/classes/java/util/Base64.java --- a/src/share/classes/java/util/Base64.java Tue Dec 11 13:14:56 2012 +0800 +++ b/src/share/classes/java/util/Base64.jav

RFR: Trivial patch for javadoc warnings in Base64

hg diff Base64.java diff -r d206e52bf8a6 src/share/classes/java/util/Base64.java --- a/src/share/classes/java/util/Base64.java Tue Dec 11 13:14:56 2012 +0800 +++ b/src/share/classes/java/util/Base64.java Tue Dec 11 18:05:30 2012 + @@ -289,8 +289,8 @@ public class Base64 { *

RFR: javax.xml.datatype: Using ServiceLoader to load JAXP datatype factories (7169894: JAXP Plugability Layer: using service loader)

Hi, Here is a new webrev in the series that addresses using ServiceLoader in JAXP for JDK 8. 7169894: JAXP Plugability Layer: using service loader This changeset addresses modification in the javax.xml.datatype package. It is similar to changes proposed for the javax.xml.parsers package [1], wi

Re: Proposal: Fully Concurrent ClassLoading

On 12/11/2012 02:12 AM, Peter Levart wrote: On 12/11/2012 04:41 AM, David M. Lloyd wrote: On JDK 8 with your patches, we are loading around 4750 classes and there are, as expected, 0 define races (I believe, however, that we're getting a false count though whenever defineClass() returns an alrea

Re: Proposal: Fully Concurrent ClassLoading

No problem. What do you mean by "instrumentation"? On 12/10/2012 11:18 PM, David Holmes wrote: David, Many thanks for trialling this so promptly! Do you have any suggestions for what instrumentation you would like to see accompany this? David On 11/12/2012 1:41 PM, David M. Lloyd wrote: On

Review request 8004357: Implement various methods in SerialBlob/Clob/Array and specify Thread Safety

Need a reviewer for 8004357:Implement various methods in SerialBlob/Clob/Array and specify Thread Safety This defines thread safety adds missing methods to SerialBlob/Clob/Array The CCC request has been reviewed. The changes uncovered a couple of bugs in the JCK which the JCK team is goi

Re: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser factories (7169894: JAXP Plugability Layer: using service loader)

On 12/11/12 2:01 PM, Alan Bateman wrote: On 10/12/2012 17:12, Daniel Fuchs wrote: [...] So here is a new - and hopefully simpler webrev: best regards, -- daniel This looks fine to me, just a stray at L64. Righ

Re: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser factories (7169894: JAXP Plugability Layer: using service loader)

On 10/12/2012 17:12, Daniel Fuchs wrote: Hi, After further discussion with Joe & Alan, I changed the call to ServiceLoader to simply return the first provider it finds, or null. This is closer to what was present in JDK 7 - and looping is not necessary in JDK 8 since the default implementation

Re: RFR: 8001647: In-place methods on Collection/List

On 10/12/2012 21:59, Mike Duigou wrote: : Adding "public" was at my suggestion. It seems inconsistent to me to have it on the default methods. Perhaps this has been discussed before, in which case ignore this. BTW: The only reason I'm bringing this up is because there are lots of default met

Re: 8004371: (props) Properties.loadFromXML needs small footprint XML parser as fallback when JAXP is not present

Joe sent me an update with changes to address issues discussed so far, I've put the webrev here: http://cr.openjdk.java.net/~alanb/8004371/webrev.02/ Joe - the classes you sent me were in different packages, also the formatting was a bit messed up in several classes, I've fixed up those iss

Re: Proposal: Fully Concurrent ClassLoading

On 12/11/2012 12:27 PM, David Holmes wrote: Peter, You are convincing me that all superclasses must be fully concurrent too. Otherwise we are just trying to second-guess a whole bunch of what-ifs. :) If you think some more, yes. The superclass might not use getClassLoadingLock() but rely on

Re: RFR: 8001647: In-place methods on Collection/List

On 11/12/2012 7:59 AM, Mike Duigou wrote: On Dec 10 2012, at 05:28 , Alan Bateman wrote: On 08/12/2012 01:42, Akhil Arora wrote: As part of the Library Lambdafication, this patch adds the following default methods to Collections - This may be bikeshed territory but we usually don't use the

Re: Proposal: Fully Concurrent ClassLoading

Peter, You are convincing me that all superclasses must be fully concurrent too. Otherwise we are just trying to second-guess a whole bunch of what-ifs. :) Thanks, David On 11/12/2012 7:44 PM, Peter Levart wrote: On 12/11/2012 10:29 AM, David Holmes wrote: On 11/12/2012 7:20 PM, Peter Leva

Re: Proposal: Fully Concurrent ClassLoading

On 12/11/2012 10:29 AM, David Holmes wrote: On 11/12/2012 7:20 PM, Peter Levart wrote: On 12/11/2012 03:55 AM, David Holmes wrote: Question on the source code: registerAsFullyConcurrent has confusing comment - do the super classes all need to be parallel capable? Or do the super classes all nee

Re: Proposal: Fully Concurrent ClassLoading

Hi again, There might be a middle-ground variant. No registration API changes as described below. When ClassLoader X declares that it is fully-concurrent make it fully-concurrent. But if any superclass registered as only parallel-capable, provide getClassLoadingLock() locks nevertheless. Only

Re: Proposal: Fully Concurrent ClassLoading

On 11/12/2012 7:20 PM, Peter Levart wrote: On 12/11/2012 03:55 AM, David Holmes wrote: Question on the source code: registerAsFullyConcurrent has confusing comment - do the super classes all need to be parallel capable? Or do the super classes all need to be FullyConcurrent? I assume the latter,

Re: Proposal: Fully Concurrent ClassLoading

On 12/11/2012 03:55 AM, David Holmes wrote: Question on the source code: registerAsFullyConcurrent has confusing comment - do the super classes all need to be parallel capable? Or do the super classes all need to be FullyConcurrent? I assume the latter, so just fix the comments. Actually it i

Re: Proposal: Fully Concurrent ClassLoading

On 12/11/2012 04:41 AM, David M. Lloyd wrote: On JDK 8 with your patches, we are loading around 4750 classes and there are, as expected, 0 define races (I believe, however, that we're getting a false count though whenever defineClass() returns an already-defined class - it would be nice if ther