February 2011 - core-libs-dev

hg: jdk7/tl/jdk: 7017493: ConcurrentLinkedDeque: Unexpected initialization order can lead to crash due to use of Unsafe
by chris.hegarty＠oracle.com 23 Feb '11

23 Feb '11

Changeset: 892c3fc7249e Author: dl Date: 2011-02-23 14:56 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/892c3fc7249e 7017493: ConcurrentLinkedDeque: Unexpected initialization order can lead to crash due to use of Unsafe Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java

1 0

java.util.Objects.requireNonNull: an opportunity for NullArgumentException?
by Martin Desruisseaux 23 Feb '11

23 Feb '11

Hello all I apologize if this question was already debated previously. I just wonder: since JDK 7 defines an Object.requireNonNull(…) method for explicit checks of argument value, does the Project-Coin expert group has considered the addition of an explicit NullArgumentException extends NullPointerException for making clear that this exception is the result of an argument check rather than some bug hidden in the middle of a code? Some kind of NullArgumentException seems a common addition in many libraries built on top of JDK. To name just a few from a quick Google search: http://commons.apache.org/lang/api-2.3/org/apache/commons/lang/NullArgument… http://www.croftsoft.com/library/code/javadoc/core/com/croftsoft/core/lang/… http://api.dpml.net/dpml/1.1.0/net/dpml/transit/NullArgumentException.html http://www.geotoolkit.org/apidocs/org/geotoolkit/util/NullArgumentException… A blog: http://closingbraces.net/2007/02/26/nullargumentexception/ Regards, Martin

1 0

hg: jdk7/tl/langtools: 2 new changesets
by maurizio.cimadamore＠oracle.com 23 Feb '11

23 Feb '11

Changeset: 015dc9a63efc Author: mcimadamore Date: 2011-02-23 14:16 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/015dc9a63efc 7020657: Javac rejects a fairly common idiom with raw override and interfaces Summary: name clash should not be reported if subinterface/implementing class resolves the clash by defining common overrider Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/7020657/T7020657neg.java + test/tools/javac/generics/7020657/T7020657neg.out + test/tools/javac/generics/7020657/T7020657pos.java Changeset: 3ab7bb46c5c1 Author: mcimadamore Date: 2011-02-23 14:17 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3ab7bb46c5c1 7019631: issues in test headers in b130 Summary: fix to test headers not containing correct bug ID Reviewed-by: jjg ! test/tools/javac/AnonStaticMember_2.java ! test/tools/javac/InterfaceInInner.java ! test/tools/javac/QualifiedNew.java ! test/tools/javac/generics/6969184/T6969184.java

1 0

Re: Review CR #6611830: UUID thread-safety and performance improvements
by Vitaly Davidovich 23 Feb '11

23 Feb '11

resending as I just realized I replied only to Brian. On Wed, Feb 23, 2011 at 12:19 AM, Vitaly Davidovich <vitalyd(a)gmail.com>wrote: > Hi David/Brian, > > Yes, I meant whether the "entire" string.hashcode technique can be used, > including the default zero values. I agree on the initial -1 assignment > possibly not being visible across cores, leading to incorrect results. > > David, I did not see the actual bug report -- is there a link to it? > > Cheers, > Vitaly > > On Tue, Feb 22, 2011 at 11:53 PM, Brian Goetz <brian.goetz(a)oracle.com>wrote: > >> I think you have a potential visibility problem here. You use -1 as the >> initial value, but observing threads might see instead the default value if >> the initializing write is not visible, and mistakenly think that the zero >> default value represents a computed value. (This is different from the >> trick employed by String.hashCode(), which does not use an initializer. Can >> you get the same result using zero instead?) >> >> The key to making the String.hashCode() trick work is that, while there is >> definitely a data race, it is benign because the field can only ever take on >> one non-default value, and that value is computed deterministically from >> immutable state. >> >> >> On 2/22/2011 7:29 PM, Mike Duigou wrote: >> >>> Daniel Aioanei reported via Josh Bloch a data race issue with the UUID >>> accessor and hashCode() methods. I've prepared a webrev with the suggested >>> changes: >>> >>> http://cr.openjdk.java.net/~mduigou/6611830/webrev.0/webrev/ >>> >>> I've tested the change against the standard UUID tests and did a >>> microbenchmark test of one method, variant(), to see what impact not caching >>> had on performance. Since there was only negligible change in performance >>> vs. the existing UUID implementation I am comfortable with eliminating the >>> cache values. It would appear that a field access plus a shift is not a >>> significant cost over a field access. >>> >>> Mike >>> >> > > > -- > Vitaly > 617-548-7007 (mobile) > -- Vitaly 617-548-7007 (mobile)

1 0

Zlib level in JDK7
by Steve Poole 23 Feb '11

23 Feb '11

Hi all, JDK7 is using zlib 1.2.3 (which was added to JDK7 back in 2009.) Zlib's latest version is 1.2.5 - is there any expectation to move to 1.2.5 in JDK7? It seems a real shame to ship JDK7 with a version of zlib that is so out of date. More than happy to help contribute towards making this happen. I would like to know if its already on someone's radar though or to understand why this is a mad idea :-) Cheers Steve

7 16

hg: jdk7/tl/jdk: 7021209: convert lang, math, util to use try-with-resources
by stuart.marks＠oracle.com 22 Feb '11

22 Feb '11

Changeset: 84e339f1033b Author: smarks Date: 2011-02-22 15:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/84e339f1033b 7021209: convert lang, math, util to use try-with-resources Reviewed-by: alanb, darcy, naoto ! src/share/classes/java/lang/Package.java ! src/share/classes/java/util/Currency.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! src/solaris/classes/java/util/prefs/FileSystemPreferences.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/Runtime/shutdown/ShutdownHooks.java ! test/java/lang/instrument/BootClassPath/Setup.java ! test/java/lang/instrument/ilib/Inject.java ! test/java/math/BigInteger/BigIntegerTest.java ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Formatter/FailingConstructors.java ! test/java/util/Locale/LocaleEnhanceTest.java ! test/java/util/ResourceBundle/Bug6204853.java ! test/java/util/Scanner/FailingConstructors.java

1 0

Re: review request for 7021209, use try-with-resources in lang, math, util
by Stuart Marks 22 Feb '11

22 Feb '11

On 2/22/11 12:44 AM, Alan Bateman wrote: > Minor comment on test/java/util/Formatter/FailingConstructors.java is that an > alternative to using try-with-resources is to just replace it with > Files.write(file.toPath(), FILE_CONTENTS.getBytes()). Same thing in > test/java/util/Scanner/FailingConstructors.java. Ah, good point. It's not directly related to try-with-resources but it's good cleanup nonetheless. I'll integrate this change. Thanks. s'marks

1 0

review request for 7021209, use try-with-resources in lang, math, util
by Stuart Marks 22 Feb '11

22 Feb '11

Hi all, The following webrev changes a variety of files in java.lang, math, and util, and their corresponding tests, to use the new Java 7 try-with-resources construct. I think most of the changes should be straightforward. In a few cases (e.g., Currency.java and LocalGregorianCalendar.java) there was no close() call in the original code so the open file was always leaked. Naoto, several of the util changes look like they're in the internationalization area. I don't know if you're the right person to review them; if not, please forward or cc this to the right person. Or, should I forward this to something like i18n-dev? Webrev is here: http://cr.openjdk.java.net/~smarks/reviews/7021209/webrev.0/ Thanks! s'marks

5 6

hg: jdk7/tl/jdk: 6604496: Support for CKM_AES_CTR (counter mode)
by valerie.peng＠oracle.com 22 Feb '11

22 Feb '11

Changeset: 75216854fb53 Author: valeriep Date: 2011-02-22 12:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/75216854fb53 6604496: Support for CKM_AES_CTR (counter mode) Summary: Enhanced SunPKCS11 provider to support AES/CTR/NoPadding transformation. Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java + src/share/classes/sun/security/pkcs11/wrapper/CK_AES_CTR_PARAMS.java ! src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c + src/share/native/sun/security/pkcs11/wrapper/pkcs-11v2-20a3.h ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h ! test/sun/security/pkcs11/Cipher/TestSymmCiphers.java ! test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java

1 0

java.awt.Graphics: not a candidate for AutoCloseable?
by assembling signals 22 Feb '11

22 Feb '11

Hello, community! Is java.awt.Graphics not a candidate for AutoCloseable? In most cases, a Graphics object has to be dispose()'d at the end. Couldn't it be extended with close() which would be a delegate to dispose()? Best regards, Ivan G Shevchenko

2 2