Re: bottleneck by java.lang.Class.getAnnotations() - rebased patch

Peter, Many thanks for preparing that patch. As we're leaving annotations behind lets continue any further discussion of this patch in a new email thread specific to JEP-149. I'll run this patch through some basic testing and performance benchmarks. The JEP will also need updating so I'll be

Re: code review request : 8003147 port fix for BCEL bug 39695

Hi Joe! Thank you for looking at this. > You didn't apply the original Apache completely. Was the omission of the > change in toString() method intentional? Yes, the improvement in toString() was not related to the issue and seems to have been included in the apache version of this fix on a wh

hg: jdk8/tl/jdk: 8004357: Implement various methods in SerialBlob/Clob/Array and specify Thread Safety

Changeset: 7a8978a5bb6e Author:lancea Date: 2012-12-12 20:57 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a8978a5bb6e 8004357: Implement various methods in SerialBlob/Clob/Array and specify Thread Safety Reviewed-by: naoto ! src/share/classes/javax/sql/rowset/serial/Seri

hg: jdk8/tl/jdk: 8004235: Disable native JGSS provider on Mac

Changeset: 5a2ab2c3f106 Author:weijun Date: 2012-12-13 08:11 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5a2ab2c3f106 8004235: Disable native JGSS provider on Mac Reviewed-by: erikj, valeriep ! make/sun/security/Makefile ! makefiles/CompileNativeLibraries.gmk ! src/share/

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

On 12/13/2012 03:49 AM, Naoto Sato wrote: Hi Max, Looks like the "$(CD) $$dir;" is unnecessary here. Thanks for the catch. Just wondering why it is failing on solaris-i586 only. I don't use ALT_OUTPUTDIR, but never seen this failure on my environment. I've filed the bug [1] but then noticed

Re: Proposal: Fully Concurrent ClassLoading

On 13/12/2012 1:51 AM, Zhong Yu wrote: If a class loader is declared fully concurrent, yet getClassLoadingLock() is invoked, what's the harm of returning a dedicated lock anyway, exactly like what's done before? The whole point is to get rid of the lockMap and these lock objects. I could retur

hg: jdk8/tl/jdk: 8004651: TEST: java/util/logging/CheckLockLocationTest.java failed to delete file (win)

Changeset: 56fd5479a98f Author:jgish Date: 2012-12-12 15:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56fd5479a98f 8004651: TEST: java/util/logging/CheckLockLocationTest.java failed to delete file (win) Summary: Failure to delete test log file should be a warning instea

Re: bottleneck by java.lang.Class.getAnnotations() - rebased patch

Hi Peter, On 12/12/12 4:31 AM, Peter Levart wrote: Hi all, Ok, no problem. So here's a patch that summarizes what I did in the previous patch, but only for reflective fields (Field[], Method[], Constructor[]) not including annotations: http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149.c/web

hg: jdk8/tl/langtools: 8004504: ListBuffer could reuse List.nil() as the sentinel element

Changeset: 170e486632d9 Author:jlahoda Date: 2012-12-12 20:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/170e486632d9 8004504: ListBuffer could reuse List.nil() as the sentinel element Summary: ListBuffer.last now points to the last elements with client data, or nu

Result: New core-libs Group Member: Mike Duigou

The vote for Mike Duigou [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -Alan [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012491.html

Result: New core-libs Group Member: Stuart Marks

The vote for Stuart Marks [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -Alan [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012492.html

Result: New core-libs Group Member: Mandy Chung

The vote for Mandy Chung [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -Alan [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012494.html

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

Hi Max, Looks like the "$(CD) $$dir;" is unnecessary here. Thanks for the catch. Just wondering why it is failing on solaris-i586 only. I don't use ALT_OUTPUTDIR, but never seen this failure on my environment. Can you please file a bug for this? Naoto On 12/11/12 11:33 PM, Weijun Wang wrote

Re: code review request : 8003147 port fix for BCEL bug 39695

Hi David, You didn't apply the original Apache completely. Was the omission of the change in toString() method intentional? I see that you've sent your test to Patrick. Have you run regression test for this patch? Thanks, Joe On 12/9/2012 10:25 PM, David Buck wrote: Hi! I would like to r

Re: Review request: JDK-8004928 TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem.

On 12/12/12 7:41 AM, Alexey Utkin wrote: Bug description: https://jbs.oracle.com/bugs/browse/JDK-8004928 Here is the suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8004928/webrev.01 Looks good in general with some minor comments below. Summary: *test/java/io/Seri

Re: Review request: JDK-8004928 TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem.

On 12/12/2012 15:41, Alexey Utkin wrote: Bug description: https://jbs.oracle.com/bugs/browse/JDK-8004928 Here is the suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8004928/webrev.01 This mostly looks good to me, just a few comments: For java/io/Serializable/resolveProxyClas

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

On 12/12/12 2:43 AM, Alan Bateman wrote: On 11/12/2012 23:53, Stuart Marks wrote: 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

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

On 12/11/12 6:24 PM, Mandy Chung wrote: 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. Right, that's exactly what's going on. To decompress this f

Re: Review request: JDK-8004928 TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem.

On 12/12/12 9:47 AM, Alan Bateman wrote: On 12/12/2012 16:36, Daniel D. Daugherty wrote: For this item: > test/java/util/logging/LoggingDeadlock4.java > Test case was simplified to avoid AWT class loading. Negative test > result was tested on early JDK7 build. if I rememb

Re: Review request: JDK-8004928 TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem.

On 12/12/2012 16:36, Daniel D. Daugherty wrote: For this item: > test/java/util/logging/LoggingDeadlock4.java > Test case was simplified to avoid AWT class loading. Negative test > result was tested on early JDK7 build. if I remember correctly, the whole point of that test

Re: Review request: JDK-8004928 TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem.

For this item: > test/java/util/logging/LoggingDeadlock4.java > Test case was simplified to avoid AWT class loading. Negative test > result was tested on early JDK7 build. if I remember correctly, the whole point of that test was to check for a logging deadlock relative to

Re: Proposal: Fully Concurrent ClassLoading

On Wed, Dec 12, 2012 at 10:05 AM, Peter Levart wrote: > On 12/12/2012 04:51 PM, Zhong Yu wrote: >> >> If a class loader is declared fully concurrent, yet >> getClassLoadingLock() is invoked, what's the harm of returning a >> dedicated lock anyway, exactly like what's done before? > > To encourage

Re: Request for review: 8000525: Java.net.httpcookie api does not support 2-digit year format

Thank you Rob, I'm ok with this change. -Chris. On 12/12/2012 15:44, Rob McKenna wrote: ...the url would be helpful: http://cr.openjdk.java.net/~robm/8000525/webrev.02/ -Rob On 12/12/12 15:43, Rob McKenna wrote: Hi Chris, I guess I figured if the parse failed the cal.set wouldn't happen. Sti

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

Yes, please. Thanks, Jim On 12/11/2012 07:02 PM, Stuart Marks wrote: 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

Re: Proposal: Fully Concurrent ClassLoading

On 12/12/2012 04:51 PM, Zhong Yu wrote: If a class loader is declared fully concurrent, yet getClassLoadingLock() is invoked, what's the harm of returning a dedicated lock anyway, exactly like what's done before? To encourage people to not use locking in the first place ;-) No, seriously, to be

hg: jdk8/tl/jdk: 8004337: java/sql tests aren't run in test/Makefile

Changeset: 68374c6e65c1 Author:robm Date: 2012-12-12 15:57 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68374c6e65c1 8004337: java/sql tests aren't run in test/Makefile Reviewed-by: lancea, alanb ! test/Makefile

Re: Proposal: Fully Concurrent ClassLoading

If a class loader is declared fully concurrent, yet getClassLoadingLock() is invoked, what's the harm of returning a dedicated lock anyway, exactly like what's done before? On Tue, Dec 11, 2012 at 7:40 PM, David Holmes wrote: > On 11/12/2012 9:58 PM, Peter Levart wrote: >> >> On 12/11/2012 12:27

Re: bottleneck by java.lang.Class.getAnnotations() - rebased patch

On 12/12/2012 04:34 PM, Peter Levart wrote: On 12/12/2012 11:59 AM, Joel Borggrén-Franck wrote: Hi all, First, thanks all of you that are involved in this! I agree with David here, lets split this up (for now) and do reflective objects in the context of jep-149 and annotations separately. A

Re: Request for review: 8000525: Java.net.httpcookie api does not support 2-digit year format

..the url would be helpful: http://cr.openjdk.java.net/~robm/8000525/webrev.02/ -Rob On 12/12/12 15:43, Rob McKenna wrote: Hi Chris, I guess I figured if the parse failed the cal.set wouldn't happen. Still, no harm in moving the 1970 into the loop on the off chance something else goes wro

Re: Request for review: 8000525: Java.net.httpcookie api does not support 2-digit year format

Hi Chris, I guess I figured if the parse failed the cal.set wouldn't happen. Still, no harm in moving the 1970 into the loop on the off chance something else goes wrong. I've updated the test too. Thanks for spotting that. -Rob On 10/12/12 16:59, Chris Hegarty wrote: Shouldn't 'cal.set

Review request: JDK-8004928 TEST_BUG: Reduce dependence of CoreLib tests from the AWT subsystem.

Bug description: https://jbs.oracle.com/bugs/browse/JDK-8004928 Here is the suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8004928/webrev.01 Summary: *test/java/io/Serializable/resolveProxyClass/NonPublicInterface.java* *test/java/lang/reflect/Proxy/ClassRestrictions.

Re: bottleneck by java.lang.Class.getAnnotations() - rebased patch

On 12/12/2012 11:59 AM, Joel Borggrén-Franck wrote: Hi all, First, thanks all of you that are involved in this! I agree with David here, lets split this up (for now) and do reflective objects in the context of jep-149 and annotations separately. As you may know there are even more annotation

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

+1 On Dec 12, 2012, at 8:08 AM, Daniel Fuchs wrote: > Hi, > > Please find below a refreshed webrev which adds a bit of cleanup > suggested by Paul. > > Instead of casting the result of newInstance() at several places, > we pass the expected base type to newInstance so that the cast > occurs only

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

Hi, Please find below a refreshed webrev which adds a bit of cleanup suggested by Paul. Instead of casting the result of newInstance() at several places, we pass the expected base type to newInstance so that the cast occurs only once.

hg: jdk8/tl/jdk: 8004874: Reduce dependency on java.beans to only add/removePropertyChangeListener

Changeset: 81640e75c7a7 Author:alanb Date: 2012-12-12 13:03 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81640e75c7a7 8004874: Reduce dependency on java.beans to only add/removePropertyChangeListener Reviewed-by: ksrini, mchung, dholmes ! src/share/classes/com/sun/java/ut

Re: bottleneck by java.lang.Class.getAnnotations() - rebased patch

Hi all, Ok, no problem. So here's a patch that summarizes what I did in the previous patch, but only for reflective fields (Field[], Method[], Constructor[]) not including annotations: http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149.c/webrev/index.html The annotations part is unchanged sem

hg: jdk8/tl/jdk: 8004921: Trivial javadoc warnings in Base64

Changeset: 806cf26e5063 Author:chegar Date: 2012-12-12 11:35 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/806cf26e5063 8004921: Trivial javadoc warnings in Base64 Reviewed-by: darcy ! src/share/classes/java/util/Base64.java

Re: AnnotationType & AnnotationSupport + repeating annotations

Hi, I've filed a bug for this, http://bugs.sun.com/view_bug.do?bug_id=8004919 should hopefully be visible shortly. I won't get around to fixing this just yet, but thanks for both the investigation and the suggested fix! cheers /Joel On Dec 4, 2012, at 10:23 AM, Peter Levart wrote: > Hi aga

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

Looks fine to me. -Chris. On 11/12/2012 19:55, 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 PropertyChangeListener and that

Re: bottleneck by java.lang.Class.getAnnotations() - rebased patch

Hi all, First, thanks all of you that are involved in this! I agree with David here, lets split this up (for now) and do reflective objects in the context of jep-149 and annotations separately. As you may know there are even more annotation coming in with JSR 308 annotations on type (use), so

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

On 11/12/2012 22:18, Kumar Srinivasan wrote: Alan, PropMap.java, Nit: typo PropertyChangeListern's similarly in the other. Thanks, I'll fix that typo in the comment before I push the changes. Nice test, but since it is specific to pack200 and all pack200 tests are in jdk/test/tools/pack200,

hg: jdk8/tl/jdk: 8004904: Makefile for ntlm

Changeset: 12fba0974a9d Author:weijun Date: 2012-12-12 18:39 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12fba0974a9d 8004904: Makefile for ntlm Reviewed-by: erikj, chegar ! make/com/sun/security/Makefile + make/com/sun/security/ntlm/Makefile

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

On 11/12/2012 23:53, 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 order, this trips over a jtreg pro

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

On 12/12/2012 09:31, Paul Sandoz wrote: http://cr.openjdk.java.net/~alanb/8004371/webrev.02/src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java.html Why are the element qualified names compared ignoring case? I'll leave this to Joe, but I agree that it doesn't look right.

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

On Dec 11, 2012, at 1:24 PM, Alan Bateman wrote: > > 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

IdentityHashMap.[keySet|values|entrySet].toArray speed-up

Hi all, I propose a patch to java.util.IdentityHashMap to speed-up toArray methods of it's keySet, values and entrySet views: http://dl.dropbox.com/u/101777488/jdk8-tl/IdentityHashMap/webrev.01/index.html I toyed with the possibility to replace HashMap-s, that are used in java.lang.Class and