From irisg at alum.mit.edu Tue Apr 1 01:52:43 2008 From: irisg at alum.mit.edu (Iris Clark) Date: Mon, 31 Mar 2008 21:52:43 -0400 (EDT) Subject: CFV: Doug Lea to Membership in the Core Libraries Group Message-ID: <15305053.751207014763728.JavaMail.joexu@brunch.mit.edu> The CVF for Doug Lea's membership[1] has now closed, and the results have been tallied. Valid votes were received from the following Members of the Core Libraries Group: David Bristor vote: yes Iris Clark vote: yes Mark Reinhold vote: yes Martin Buchholz vote: yes Peter Jones vote: yes According to the rules describing group expansion[2], this is sufficient to approve the proposal for Doug Lea to become a Member of the Core Libraries Group. Congratulations and Welcome Doug! iris [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-March/000294.html [2] http://openjdk.java.net/groups/ From eamonn.mcmanus at sun.com Tue Apr 1 12:46:43 2008 From: eamonn.mcmanus at sun.com (eamonn.mcmanus at sun.com) Date: Tue, 01 Apr 2008 12:46:43 +0000 Subject: hg: jdk7/tl/jdk: 6610917: Define a generic NotificationFilter Message-ID: <20080401124655.CCAC0273F4@hg.openjdk.java.net> Changeset: 2965459a8ee7 Author: emcmanus Date: 2008-04-01 14:45 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2965459a8ee7 6610917: Define a generic NotificationFilter Summary: Adds javax.management.QueryNotificationFilter Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java + src/share/classes/com/sun/jmx/mbeanserver/NotificationMBeanSupport.java ! src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java ! src/share/classes/com/sun/jmx/mbeanserver/Repository.java ! src/share/classes/com/sun/jmx/mbeanserver/Util.java ! src/share/classes/javax/management/ObjectName.java + src/share/classes/javax/management/QueryNotificationFilter.java + test/javax/management/query/QueryNotifFilterTest.java From Pete.Soper at Sun.COM Tue Apr 1 18:45:52 2008 From: Pete.Soper at Sun.COM (Pete Soper) Date: Tue, 01 Apr 2008 14:45:52 -0400 Subject: CFV: Doug Lea to Membership in the Core Libraries Group In-Reply-To: <15305053.751207014763728.JavaMail.joexu@brunch.mit.edu> References: <15305053.751207014763728.JavaMail.joexu@brunch.mit.edu> Message-ID: <47F282E0.2070808@sun.com> Hi Iris, It's nice to see this vote finished. It might be useful for us to understand if Alan, Martin, and I did something wrong wrt this vote and how to avoid the mistake in the future. I sent a "yes" at 10:19EDT on 3/25 and I saw Martin's "yes" at 11:36 that same day. I saw a "yes" from Alan Bateman on 3/28 at 7:08EDT. All three msgs seem to have the right format and be to the right addresses. -Pete Iris Clark wrote: > The CVF for Doug Lea's membership[1] has now closed, and the results have been tallied. > > Valid votes were received from the following Members of the Core Libraries Group: > > David Bristor vote: yes > Iris Clark vote: yes > Mark Reinhold vote: yes > Martin Buchholz vote: yes > Peter Jones vote: yes > > According to the rules describing group expansion[2], this is sufficient to approve the > proposal for Doug Lea to become a Member of the Core Libraries Group. > > Congratulations and Welcome Doug! > > iris > > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-March/000294.html > [2] http://openjdk.java.net/groups/ > From dl at cs.oswego.edu Wed Apr 2 11:06:29 2008 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 02 Apr 2008 07:06:29 -0400 Subject: CFV: Doug Lea to Membership in the Core Libraries Group In-Reply-To: <15305053.751207014763728.JavaMail.joexu@brunch.mit.edu> References: <15305053.751207014763728.JavaMail.joexu@brunch.mit.edu> Message-ID: <47F368B5.8000108@cs.oswego.edu> Iris Clark wrote: > According to the rules describing group expansion[2], this is sufficient to approve the > proposal for Doug Lea to become a Member of the Core Libraries Group. > > Congratulations and Welcome Doug! > Thanks! I might need some hg training. Are there reliable guides for this out yet? -Doug From Alan.Bateman at Sun.COM Wed Apr 2 11:42:32 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 02 Apr 2008 12:42:32 +0100 Subject: CFV: Doug Lea to Membership in the Core Libraries Group In-Reply-To: <47F368B5.8000108@cs.oswego.edu> References: <15305053.751207014763728.JavaMail.joexu@brunch.mit.edu> <47F368B5.8000108@cs.oswego.edu> Message-ID: <47F37128.60700@sun.com> Doug Lea wrote: > Iris Clark wrote: > >> According to the rules describing group expansion[2], this is >> sufficient to approve the >> proposal for Doug Lea to become a Member of the Core Libraries Group. >> >> Congratulations and Welcome Doug! >> > > Thanks! > > I might need some hg training. Are there reliable guides for this > out yet? Good to have you on board! I think Iris is away for a few days but she has been working on the OpenJDK Developers Guide [1]. This has a section on repositories that includes information on the installation and configuration of Mercurial. Another important section is the "Producing a Changeset" section that details the procedures needed to produce a changeset and how to getting your ssh key setup. In addition to the developers guide, a real must is Bryan O'Sullivan's online book "Distributed revision control with Mercurial" [2]. The first two chapters are sufficient to get a basic working knowledge. OpenJDK uses the Mercurial forest. This isn't covered in the book but there links in the developers guide on how to set that up. -Alan. [1] http://openjdk.java.net/guide/ [2] http://hgbook.red-bean.com From kumar.srinivasan at sun.com Fri Apr 4 01:10:20 2008 From: kumar.srinivasan at sun.com (kumar.srinivasan at sun.com) Date: Fri, 04 Apr 2008 01:10:20 +0000 Subject: hg: jdk7/tl/langtools: 6570242: Regression test failures with Javac on win32. Message-ID: <20080404011022.14FE02754E@hg.openjdk.java.net> Changeset: ddd77d1c1b49 Author: ksrini Date: 2008-04-03 18:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ddd77d1c1b49 6570242: Regression test failures with Javac on win32. Summary: takes this test out of service until the reall bug is fixed Reviewed-by: jjg ! test/tools/javac/api/6431257/T6431257.java From eliasen at mindspring.com Fri Apr 4 09:29:53 2008 From: eliasen at mindspring.com (Alan Eliasen) Date: Fri, 04 Apr 2008 03:29:53 -0600 Subject: [UPDATED PATCH] 4837946: Implement Karatsuba multiplication algorithm in BigInteger In-Reply-To: <47EC9ADB.5000301@mindspring.com> References: <47A14D21.8020807@mindspring.com> <47BB539B.8090901@mindspring.com> <47EC9ADB.5000301@mindspring.com> Message-ID: <47F5F511.60204@mindspring.com> Attached is an UPDATED patch for bug 4837946, for implementing asymptotically faster algorithms for multiplication of large numbers in the BigInteger class: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4837946 This patch supersedes all previous patches, and contains all of their changes. The difference between this patch and the one posted previously are small, and consist of the following: * Changed a line in getToomSlice() to fix a problem that will affect the future work I'm doing on the pow() function (which I have not yet released.) * Changed threshhold constants from public to private final. These had been made public for tuning of threshholds, and they were accidentally left as public in the last patch. For those who'd rather just replace their BigInteger with my much faster version, that also contains my patches for pow(), it's available at: http://futureboy.us/temp/BigInteger.java -- Alan Eliasen | "Furious activity is no substitute eliasen at mindspring.com | for understanding." http://futureboy.us/ | --H.H. Williams -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: BigInteger.diff URL: From martinrb at google.com Sat Apr 5 20:03:41 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 5 Apr 2008 13:03:41 -0700 Subject: sun.nio.ch.NativeThread.current Message-ID: <1ccfd1c10804051303l27cffbd0s7492f239330f56ae@mail.gmail.com> There is a mismatch between the spec and implementation of sun.nio.ch.NativeThread.current // Returns an opaque token representing the native thread underlying the // invoking Java thread. On systems that do not require signalling, this // method always returns zero. // static native long current(); ... Java_sun_nio_ch_NativeThread_current(JNIEnv *env, jclass cl) { #ifdef __linux__ return (long)pthread_self(); #else return -1; #endif ... Which is it, zero or -1? Please file a bug. Thanks, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at Sun.COM Sun Apr 6 07:40:49 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 06 Apr 2008 08:40:49 +0100 Subject: sun.nio.ch.NativeThread.current In-Reply-To: <1ccfd1c10804051303l27cffbd0s7492f239330f56ae@mail.gmail.com> References: <1ccfd1c10804051303l27cffbd0s7492f239330f56ae@mail.gmail.com> Message-ID: <47F87E81.7020707@sun.com> Martin Buchholz wrote: > There is a mismatch between the spec and implementation of > sun.nio.ch.NativeThread.current > > // Returns an opaque token representing the native thread > underlying the > // invoking Java thread. On systems that do not require > signalling, this > // method always returns zero. > // > static native long current(); > > ... > > Java_sun_nio_ch_NativeThread_current(JNIEnv *env, jclass cl) > { > #ifdef __linux__ > return (long)pthread_self(); > #else > return -1; > #endif > > ... > > Which is it, zero or -1? > > Please file a bug. A good observation. It should be 0L but as we only need to signal threads on Linux, it doesn't cause any problems. I've added your mail to 6596323 so that it cna be fixed as part of that bug. Also, I've assigned myself as RE as it was supposed to have been fixed ages ago. -Alan. From maurizio.cimadamore at sun.com Wed Apr 2 10:24:10 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 02 Apr 2008 10:24:10 +0000 Subject: hg: jdk7/tl/langtools: 6569789: Compiler test lang/TYPE/type153/type15304/type15304.html fails since jdk7 b05 Message-ID: <20080402102412.78BED27447@hg.openjdk.java.net> Changeset: 6e4cefcce80a Author: mcimadamore Date: 2008-04-02 11:20 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6e4cefcce80a 6569789: Compiler test lang/TYPE/type153/type15304/type15304.html fails since jdk7 b05 Summary: improved glb on type-inference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6569789/T6569789.java From maurizio.cimadamore at sun.com Wed Apr 2 10:39:05 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 02 Apr 2008 10:39:05 +0000 Subject: hg: jdk7/tl/langtools: 6509042: javac rejects class literals in enum constructors Message-ID: <20080402103907.1C6302744C@hg.openjdk.java.net> Changeset: aeaa0f482b28 Author: mcimadamore Date: 2008-04-02 11:38 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/aeaa0f482b28 6509042: javac rejects class literals in enum constructors Summary: javac now distinguish between enum class literals and static fields Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/enum/T6509042.java From maurizio.cimadamore at sun.com Wed Apr 2 10:44:57 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 02 Apr 2008 10:44:57 +0000 Subject: hg: jdk7/tl/langtools: 6531090: Cannot access methods/fields of a captured type belonging to an intersection type Message-ID: <20080402104459.333CB27451@hg.openjdk.java.net> Changeset: adaa3fc51b60 Author: mcimadamore Date: 2008-04-02 11:44 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/adaa3fc51b60 6531090: Cannot access methods/fields of a captured type belonging to an intersection type Summary: fixed lookup of field/methods on intersection types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/6531090/T6531090a.java + test/tools/javac/generics/6531090/T6531090b.java From bradford.wetmore at sun.com Mon Apr 7 21:38:37 2008 From: bradford.wetmore at sun.com (bradford.wetmore at sun.com) Date: Mon, 07 Apr 2008 21:38:37 +0000 Subject: hg: jdk7/tl/jdk: 14 new changesets Message-ID: <20080407214126.D82112765A@hg.openjdk.java.net> Changeset: a8d6215fa863 Author: weijun Date: 2008-03-20 11:57 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a8d6215fa863 6670362: HTTP/SPNEGO should work across realms Reviewed-by: valeriep ! src/share/classes/sun/net/www/protocol/http/NegotiatorImpl.java Changeset: 74bc85c0f2a9 Author: valeriep Date: 2008-03-20 16:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74bc85c0f2a9 4898461: Support for ECB and CBC/PKCS5Padding Summary: Add support for ECB mode and PKCS5Padding Reviewed-by: andreas ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java + test/sun/security/pkcs11/Cipher/TestSymmCiphers.java Changeset: 66c2b0cfc896 Author: valeriep Date: 2008-03-20 17:17 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/66c2b0cfc896 6572331: regression: cipher.wrap operation fails with CKR_ATTRIBUTE_VALUE_INVALID Summary: Check supported key size range and use encryption if needed Reviewed-by: andreas ! src/share/classes/sun/security/pkcs11/P11KeyGenerator.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java + test/sun/security/pkcs11/Cipher/TestRSACipherWrap.java Changeset: 84aced25a346 Author: valeriep Date: 2008-03-20 18:41 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/84aced25a346 6599979: KeyStore.setEntry/setKeyEntry() do not override existing entry for secret key objects Summary: Override existing secret key entry when setEntry/setKeyEntry() is called Reviewed-by: andreas ! src/share/classes/sun/security/pkcs11/P11KeyStore.java ! src/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java + test/sun/security/pkcs11/KeyStore/SecretKeysBasic.java + test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh Changeset: 05afbed1dc4f Author: valeriep Date: 2008-03-21 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/05afbed1dc4f Merge Changeset: b22cbc65a360 Author: wetmore Date: 2008-03-28 12:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b22cbc65a360 Merge Changeset: 8805ae9d160c Author: valeriep Date: 2008-03-31 11:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8805ae9d160c 6681652: Two new regression test failures in pkcs11 code Summary: Fixed the test to not assume SunJCE provider being the provider for DES Reviewed-by: wetmore ! test/javax/crypto/Cipher/TestGetInstance.java Changeset: e1bf7407c933 Author: wetmore Date: 2008-03-31 13:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e1bf7407c933 6469580: 1.5.0_08 JVM crashes in SignatureHandlerLibrary::add on Fujitsu Primepower platform Reviewed-by: andreas, valeriep, wetmore Contributed-by: chris.phillips at sun.com ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c Changeset: 17e93b7fb97d Author: valeriep Date: 2008-03-31 16:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/17e93b7fb97d 6682411: JCK test failed w/ ArrayIndexOutOfBoundException (-1) when decrypting with no data Summary: Fixed PKCS5Padding class with additional check and throw BadPaddingException if the check failed Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: c063b7fb55f7 Author: valeriep Date: 2008-03-31 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c063b7fb55f7 6682417: JCK test failed w/ ProviderException when decrypted data is not multiple of blocks Summary: Check for CKR_ENCRYPTED_DATA_LEN_RANGE and throw IllegalBlockSizeException Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: 99b3301fc27c Author: valeriep Date: 2008-03-31 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/99b3301fc27c Merge Changeset: df5d7e6ac15e Author: xuelei Date: 2008-04-02 22:44 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/df5d7e6ac15e 6668231: Presence of a critical subjectAltName causes JSSE's SunX509 to fail trusted checks Summary: make the critical extension known to end entity checker. Reviewed-by: wetmore, mullan ! src/share/classes/sun/security/validator/EndEntityChecker.java + test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java + test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/crisubn.jks + test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/trusted.jks Changeset: b70fc43afb8c Author: wetmore Date: 2008-04-06 10:15 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b70fc43afb8c 6683078: Update JCE framework and provider builds to work on read-only filesystems 6644659: Error in default target of make/javax/crypto in OpenJDK build Reviewed-by: valeriep, ohair ! make/com/sun/crypto/provider/Makefile ! make/common/shared/Defs.gmk ! make/javax/crypto/Defs-jce.gmk ! make/javax/crypto/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile Changeset: f4205a7bdfd4 Author: wetmore Date: 2008-04-07 14:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f4205a7bdfd4 Merge From maurizio.cimadamore at sun.com Wed Apr 9 13:06:27 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 09 Apr 2008 13:06:27 +0000 Subject: hg: jdk7/tl/langtools: 4 new changesets Message-ID: <20080409130634.DC303276F6@hg.openjdk.java.net> Changeset: 961ae2608114 Author: mcimadamore Date: 2008-04-09 13:19 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/961ae2608114 6531075: Missing synthetic casts when accessing fields/methods of intersection types including type variables Summary: bug when javac generates code involving intersection types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/generics/6531075/T6531075.java Changeset: d032d5090fd5 Author: mcimadamore Date: 2008-04-09 13:41 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d032d5090fd5 5009937: hiding versus generics versus binary compatibility Summary: missing implementation of JLS 8.4.8.3 (different arguments with same erasure not always triggering a compiler error) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/5009937/T5009937.java + test/tools/javac/generics/5009937/T5009937.out ! test/tools/javac/generics/InheritanceConflict.java ! test/tools/javac/generics/InheritanceConflict2.java Changeset: 57ba4f70f0d8 Author: mcimadamore Date: 2008-04-09 13:53 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/57ba4f70f0d8 6365166: javac (generic) unable to resolve methods Summary: Unignore regression test as this bug has been fixed by CR 6278587 Reviewed-by: jjg + test/tools/javac/generics/inference/6356673/T6365166.java Changeset: 25338c55e458 Author: mcimadamore Date: 2008-04-09 14:05 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/25338c55e458 6481655: Parser confused by combination of parens and explicit type args Summary: Bug in the parser caused by the fact that explicit type arguments are disabled when parsing parenthesized expressions Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/Parser.java + test/tools/javac/generics/T6481655.java From maurizio.cimadamore at sun.com Wed Apr 9 14:33:19 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 09 Apr 2008 14:33:19 +0000 Subject: hg: jdk7/tl/langtools: 4 new changesets Message-ID: <20080409143326.2AB00276FB@hg.openjdk.java.net> Changeset: 447c300a24e7 Author: mcimadamore Date: 2008-04-09 14:45 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/447c300a24e7 6450290: Capture of nested wildcards causes type error Summary: A missing capture conversion makes javac to think that some expressions are well-formed even when they aren't Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/wildcards/T6450290.java Changeset: e7bf2e39b8fe Author: mcimadamore Date: 2008-04-09 14:57 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e7bf2e39b8fe 6657499: javac 1.6.0 fails to compile class with inner class Summary: Lookup of member inner classes silently fails leading to an unwanted erasure to take place Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/T6657499.java Changeset: 6522ea413d23 Author: mcimadamore Date: 2008-04-09 15:04 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6522ea413d23 6683438: Bad regression test for CR 6611449 Summary: The regression test for CR 6611449 contains some inconstistencies Reviewed-by: jjg ! test/tools/javac/generics/inference/6611449/T6611449.java ! test/tools/javac/generics/inference/6611449/T6611449.out Changeset: a1d1f335633f Author: mcimadamore Date: 2008-04-09 15:30 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a1d1f335633f 6559182: Cast from a raw type with non-generic supertype to a raw type fails unexpectedly Summary: Javac doesn't conform to JLS 4.8 - all the supertypes of a raw type must be erased Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/Casting5.java From Alan.Bateman at Sun.COM Thu Apr 10 13:37:00 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 10 Apr 2008 14:37:00 +0100 Subject: 4939819: File.canWrite() returns false for the "My Documents" directory (win) Message-ID: <47FE17FC.1010205@sun.com> I need a reviewer for 4939819. This is one that the desktop folks have been asking to be fixed for some time. On Windows the DOS read-only attribute doesn't make a directory read-only. Instead this attribute just prevents a directory from being deleted. The bug is that java.io.File's canWrite method returns false when this attribute is set whereas it should be ignored when checking access to directories. The attached patch fixes this by ignoring the attribute on directories. There shouldn't be any side effects moving from _waccess to GetFileAttributes because the Microsoft CRT has always implemented _waccess as a call to GetFileAttributesW. Thanks, Alan. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: canWrite.patch URL: From Alan.Bateman at Sun.COM Thu Apr 10 14:07:19 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 10 Apr 2008 15:07:19 +0100 Subject: 6652379: File.setLastModified fails on large files (lnx only) Message-ID: <47FE1F17.5050900@sun.com> I need a reviewer for 6652379. A recent change in the Linux kernel means utimes(2) fails for invalid argument cases where it didn't fail previously. This exposes a long standing bug in java.io.File's setLastModified implementation when setting the last modified time on large files. The attached patch fixes the bug by mostly eliminating the crud left over from the addition of large file support in JDK1.2. Thanks, Alan. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: setLastModified.patch URL: From kumar.srinivasan at sun.com Thu Apr 10 16:06:19 2008 From: kumar.srinivasan at sun.com (kumar.srinivasan at sun.com) Date: Thu, 10 Apr 2008 16:06:19 +0000 Subject: hg: jdk7/tl/jdk: 6684582: Launcher needs improved error reporting Message-ID: <20080410160631.189EB2776C@hg.openjdk.java.net> Changeset: c2019d1360ef Author: ksrini Date: 2008-04-10 09:02 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2019d1360ef 6684582: Launcher needs improved error reporting Summary: indicate the missing main class in the error message Reviewed-by: darcy, kbr ! src/share/bin/emessages.h ! src/share/bin/java.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/Arrrghs.sh From xueming.shen at sun.com Thu Apr 10 21:52:14 2008 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Thu, 10 Apr 2008 21:52:14 +0000 Subject: hg: jdk7/tl/jdk: 6529796: Support JIS X 0213:2004 in existing JDK versions, especially for Windows Vista Message-ID: <20080410215236.1998C27805@hg.openjdk.java.net> Changeset: cb934dd5e073 Author: sherman Date: 2008-04-10 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb934dd5e073 6529796: Support JIS X 0213:2004 in existing JDK versions, especially for Windows Vista Summary: SJIS0213 support Reviewed-by: naoto ! make/java/sun_nio/FILES_java.gmk ! make/sun/nio/Makefile + make/tools/CharsetMapping/Makefile + make/tools/CharsetMapping/sjis0213.map ! make/tools/Makefile + make/tools/src/build/tools/charsetmapping/CharsetMapping.java + make/tools/src/build/tools/charsetmapping/GenerateMapping.java + src/share/classes/sun/nio/cs/CharsetMapping.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java + src/share/classes/sun/nio/cs/ext/MS932_0213.java + src/share/classes/sun/nio/cs/ext/SJIS_0213.java From mandy.chung at sun.com Thu Apr 10 23:16:30 2008 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Thu, 10 Apr 2008 23:16:30 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20080410231656.846562780A@hg.openjdk.java.net> Changeset: fd563c5dd750 Author: mchung Date: 2008-04-10 10:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fd563c5dd750 6610094: Add generic support for platform MXBeans of any type (also fixed 6681031) Summary: Add new methods in ManagementFactory class to obtain platform MXBeans Reviewed-by: alanb, dfuchs, emcmanus ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/java/lang/management/ClassLoadingMXBean.java ! src/share/classes/java/lang/management/CompilationMXBean.java ! src/share/classes/java/lang/management/GarbageCollectorMXBean.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/MemoryMXBean.java ! src/share/classes/java/lang/management/MemoryManagerMXBean.java ! src/share/classes/java/lang/management/MemoryPoolMXBean.java ! src/share/classes/java/lang/management/OperatingSystemMXBean.java + src/share/classes/java/lang/management/PlatformComponent.java + src/share/classes/java/lang/management/PlatformManagedObject.java ! src/share/classes/java/lang/management/RuntimeMXBean.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/ThreadMXBean.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingMXBean.java ! src/share/classes/sun/management/ClassLoadingImpl.java ! src/share/classes/sun/management/CompilationImpl.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotInternal.java ! src/share/classes/sun/management/LockDataConverter.java ! src/share/classes/sun/management/ManagementFactory.java + src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MemoryImpl.java ! src/share/classes/sun/management/MemoryManagerImpl.java ! src/share/classes/sun/management/MemoryNotifInfoCompositeData.java ! src/share/classes/sun/management/MemoryPoolImpl.java ! src/share/classes/sun/management/MemoryUsageCompositeData.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/OperatingSystemImpl.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/StackTraceElementCompositeData.java ! src/share/classes/sun/management/ThreadImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/Util.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/classes/sun/management/VMOptionCompositeData.java ! test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticOptions.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetVMOption.java ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java + test/java/lang/management/ManagementFactory/GetPlatformMXBeans.java + test/java/lang/management/OperatingSystemMXBean/PlatformMXBeanTest.java Changeset: bcf689d26c1c Author: mchung Date: 2008-04-10 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bcf689d26c1c Merge From mandy.chung at sun.com Fri Apr 11 17:31:43 2008 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Fri, 11 Apr 2008 17:31:43 +0000 Subject: hg: jdk7/tl/jdk: 6687508: Update test/sun/management jtreg tests due to sun.management.ManagementFactory class rename Message-ID: <20080411173155.3FCC9278E0@hg.openjdk.java.net> Changeset: 18eed13fe9f6 Author: mchung Date: 2008-04-11 10:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/18eed13fe9f6 6687508: Update test/sun/management jtreg tests due to sun.management.ManagementFactory class rename Summary: Modified the jtreg tests to use ManagementFactoryHelper instead Reviewed-by: emcmanus ! test/sun/management/HotspotClassLoadingMBean/GetClassInitializationTime.java ! test/sun/management/HotspotClassLoadingMBean/GetClassLoadingTime.java ! test/sun/management/HotspotClassLoadingMBean/GetInitializedClassCount.java ! test/sun/management/HotspotClassLoadingMBean/GetLoadedClassSize.java ! test/sun/management/HotspotClassLoadingMBean/GetMethodDataSize.java ! test/sun/management/HotspotClassLoadingMBean/GetUnloadedClassSize.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointCount.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java ! test/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java ! test/sun/management/HotspotThreadMBean/GetInternalThreads.java From xueming.shen at sun.com Tue Apr 15 04:50:38 2008 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Tue, 15 Apr 2008 04:50:38 +0000 Subject: hg: jdk7/tl/jdk: 6635133: Exception thrown when using a Unicode escape Message-ID: <20080415045057.E6F5F27D44@hg.openjdk.java.net> Changeset: dd212ba9a0c6 Author: sherman Date: 2008-04-14 21:45 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd212ba9a0c6 6635133: Exception thrown when using a Unicode escape Summary: Update regex engine to handle unicode escape correctly in character class Reviewed-by: okutsu ! src/share/classes/java/util/regex/Pattern.java From iris at sun.com Tue Apr 15 17:24:26 2008 From: iris at sun.com (iris clark) Date: Tue, 15 Apr 2008 10:24:26 -0700 (PDT) Subject: CFV: Project sponsorship: More New I/0 APIs for te Java Platform (JSR-203) Message-ID: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> Greetings, voting members of the Core Libraries Group! Question: Should the Core Libraries Group sponsor the "More New I/O APIs for the Java Platform (JSR-203) Project[1]? Please cast your vote by replying, publicly, to this message with either Vote: yes or Vote: no as the first line of the message body. You may, at your option, indicate the reason for your decision on subsequent lines. Votes must be cast in the open; votes sent as private replies will not be counted. The sponsorship decision will be made by a simple majority vote of the Group's Members. Votes are due by midnight UTC next Wednesday, 22 April. As an optimization, if an absolute majority of the Group's Members votes one way or the other prior to that time then the decision may be rendered earlier. Once a decision has been made the votes will be tallied and reported to this list and also to discuss at openjdk.java.net. Only Members of the Core Libraries Group are eligible to vote on this decision. The current Members are: Alan Bateman Christopher Hegarty David Bristor Iris Clark Doug Lea Jeff Nisewanger Joe Darcy Mark Reinhold Martin Buchholz Pete Soper Peter Jones Xueming Shen Thanks, iris [1] http://mail.openjdk.java.net/pipermail/announce/2008-April/000063.html From Joe.Darcy at Sun.COM Tue Apr 15 17:53:28 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 15 Apr 2008 10:53:28 -0700 Subject: CFV: Project sponsorship: More New I/0 APIs for te Java Platform (JSR-203) In-Reply-To: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> References: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> Message-ID: <4804EB98.8020909@sun.com> Vote: yes iris clark wrote: > Greetings, voting members of the Core Libraries Group! > > Question: Should the Core Libraries Group sponsor the "More New I/O APIs > for the Java Platform (JSR-203) Project[1]? > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not be > counted. > > The sponsorship decision will be made by a simple majority vote of the > Group's Members. Votes are due by midnight UTC next Wednesday, 22 April. > As an optimization, if an absolute majority of the Group's Members votes > one way or the other prior to that time then the decision may be rendered > earlier. Once a decision has been made the votes will be tallied and > reported to this list and also to discuss at openjdk.java.net. > > Only Members of the Core Libraries Group are eligible to vote on this > decision. The current Members are: > > Alan Bateman > Christopher Hegarty > David Bristor > Iris Clark > Doug Lea > Jeff Nisewanger > Joe Darcy > Mark Reinhold > Martin Buchholz > Pete Soper > Peter Jones > Xueming Shen > > Thanks, > iris > > [1] http://mail.openjdk.java.net/pipermail/announce/2008-April/000063.html From iris at sun.com Tue Apr 15 18:06:34 2008 From: iris at sun.com (iris clark) Date: Tue, 15 Apr 2008 11:06:34 -0700 (PDT) Subject: CFV: Project sponsorship: More New I/0 APIs for te Java Platform (JSR-203) In-Reply-To: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> (message from iris clark on Tue, 15 Apr 2008 10:24:26 -0700 (PDT)) Message-ID: <200804151806.m3FI6YA5017847@ribbit.SFBay.Sun.COM> Vote: yes iris CVF e-mail: http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-April/000332.html From David.Bristor at Sun.COM Tue Apr 15 19:05:47 2008 From: David.Bristor at Sun.COM (Dave Bristor) Date: Tue, 15 Apr 2008 12:05:47 -0700 Subject: CFV: Project sponsorship: More New I/0 APIs for te Java Platform (JSR-203) In-Reply-To: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> References: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> Message-ID: <4804FC8B.4090501@sun.com> Vote: yes iris clark wrote: > Greetings, voting members of the Core Libraries Group! > > Question: Should the Core Libraries Group sponsor the "More New I/O APIs > for the Java Platform (JSR-203) Project[1]? > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not be > counted. > > The sponsorship decision will be made by a simple majority vote of the > Group's Members. Votes are due by midnight UTC next Wednesday, 22 April. > As an optimization, if an absolute majority of the Group's Members votes > one way or the other prior to that time then the decision may be rendered > earlier. Once a decision has been made the votes will be tallied and > reported to this list and also to discuss at openjdk.java.net. > > Only Members of the Core Libraries Group are eligible to vote on this > decision. The current Members are: > > Alan Bateman > Christopher Hegarty > David Bristor > Iris Clark > Doug Lea > Jeff Nisewanger > Joe Darcy > Mark Reinhold > Martin Buchholz > Pete Soper > Peter Jones > Xueming Shen > > Thanks, > iris > > [1] http://mail.openjdk.java.net/pipermail/announce/2008-April/000063.html From Christopher.Hegarty at Sun.COM Tue Apr 15 20:55:41 2008 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Tue, 15 Apr 2008 21:55:41 +0100 Subject: CFV: Project sponsorship: More New I/0 APIs for te Java Platform (JSR-203) In-Reply-To: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> References: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> Message-ID: <4805164D.806@sun.com> Vote: yes -Chris. iris clark wrote: > Greetings, voting members of the Core Libraries Group! > > Question: Should the Core Libraries Group sponsor the "More New I/O APIs > for the Java Platform (JSR-203) Project[1]? > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not be > counted. > > The sponsorship decision will be made by a simple majority vote of the > Group's Members. Votes are due by midnight UTC next Wednesday, 22 April. > As an optimization, if an absolute majority of the Group's Members votes > one way or the other prior to that time then the decision may be rendered > earlier. Once a decision has been made the votes will be tallied and > reported to this list and also to discuss at openjdk.java.net. > > Only Members of the Core Libraries Group are eligible to vote on this > decision. The current Members are: > > Alan Bateman > Christopher Hegarty > David Bristor > Iris Clark > Doug Lea > Jeff Nisewanger > Joe Darcy > Mark Reinhold > Martin Buchholz > Pete Soper > Peter Jones > Xueming Shen > > Thanks, > iris > > [1] http://mail.openjdk.java.net/pipermail/announce/2008-April/000063.html From martinrb at google.com Tue Apr 15 22:08:45 2008 From: martinrb at google.com (Martin Buchholz) Date: Tue, 15 Apr 2008 15:08:45 -0700 Subject: CFV: Project sponsorship: More New I/0 APIs for te Java Platform (JSR-203) In-Reply-To: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> References: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> Message-ID: <1ccfd1c10804151508r7e201e9fs59f9f6aa196f52c4@mail.gmail.com> Vote: yes -------------- next part -------------- An HTML attachment was scrubbed... URL: From dl at cs.oswego.edu Tue Apr 15 22:55:43 2008 From: dl at cs.oswego.edu (Doug Lea) Date: Tue, 15 Apr 2008 18:55:43 -0400 Subject: CFV: Project sponsorship: More New I/0 APIs for te Java Platform (JSR-203) In-Reply-To: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> References: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> Message-ID: <4805326F.2080604@cs.oswego.edu> Vote: yes. (The world is waiting for these! I hope they get in soon.) -Doug iris clark wrote: > Greetings, voting members of the Core Libraries Group! > > Question: Should the Core Libraries Group sponsor the "More New I/O APIs > for the Java Platform (JSR-203) Project[1]? > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not be > counted. > > The sponsorship decision will be made by a simple majority vote of the > Group's Members. Votes are due by midnight UTC next Wednesday, 22 April. > As an optimization, if an absolute majority of the Group's Members votes > one way or the other prior to that time then the decision may be rendered > earlier. Once a decision has been made the votes will be tallied and > reported to this list and also to discuss at openjdk.java.net. > > Only Members of the Core Libraries Group are eligible to vote on this > decision. The current Members are: > > Alan Bateman > Christopher Hegarty > David Bristor > Iris Clark > Doug Lea > Jeff Nisewanger > Joe Darcy > Mark Reinhold > Martin Buchholz > Pete Soper > Peter Jones > Xueming Shen > > Thanks, > iris > > [1] http://mail.openjdk.java.net/pipermail/announce/2008-April/000063.html > From mr at sun.com Wed Apr 16 03:11:24 2008 From: mr at sun.com (Mark Reinhold) Date: Tue, 15 Apr 2008 20:11:24 -0700 Subject: CFV: Project sponsorship: More New I/0 APIs for te Java Platform (JSR-203) In-Reply-To: iris@sun.com; Tue, 15 Apr 2008 10:24:26 PDT; <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> Message-ID: <20080416031124.1FFD42C57A@callebaut.niobe.net> Vote: yes (As the original submitter of JSR 203, how could I possibly vote otherwise?) - Mark From Alan.Bateman at Sun.COM Wed Apr 16 15:11:01 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 16 Apr 2008 16:11:01 +0100 Subject: 6682020: (bf) Support monitoring of direct and mapped buffer usage Message-ID: <48061705.7050908@sun.com> Iris - can you review 6682020? This adds instrumentation so that the resources for direct and mapped buffers can be monitored by jconsole and other JMX based tools. It builds on the generic support that Mandy added last week [1]. Thanks, -Alan [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fd563c5dd750 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: BufferPoolMXBean.patch URL: From Pete.Soper at Sun.COM Wed Apr 16 17:55:06 2008 From: Pete.Soper at Sun.COM (Pete Soper) Date: Wed, 16 Apr 2008 13:55:06 -0400 Subject: CFV: Project sponsorship: More New I/0 APIs for te Java Platform (JSR-203) In-Reply-To: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> References: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> Message-ID: <48063D7A.2040101@sun.com> Vote: yes -Pete From Xueming.Shen at Sun.COM Thu Apr 17 02:29:27 2008 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Wed, 16 Apr 2008 19:29:27 -0700 Subject: CFV: Project sponsorship: More New I/0 APIs for te Java Platform (JSR-203) In-Reply-To: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> References: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> Message-ID: <4806B607.30905@sun.com> Vote: yes iris clark wrote: > Greetings, voting members of the Core Libraries Group! > > Question: Should the Core Libraries Group sponsor the "More New I/O APIs > for the Java Platform (JSR-203) Project[1]? > > Please cast your vote by replying, publicly, to this message with either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will not be > counted. > > The sponsorship decision will be made by a simple majority vote of the > Group's Members. Votes are due by midnight UTC next Wednesday, 22 April. > As an optimization, if an absolute majority of the Group's Members votes > one way or the other prior to that time then the decision may be rendered > earlier. Once a decision has been made the votes will be tallied and > reported to this list and also to discuss at openjdk.java.net. > > Only Members of the Core Libraries Group are eligible to vote on this > decision. The current Members are: > > Alan Bateman > Christopher Hegarty > David Bristor > Iris Clark > Doug Lea > Jeff Nisewanger > Joe Darcy > Mark Reinhold > Martin Buchholz > Pete Soper > Peter Jones > Xueming Shen > > Thanks, > iris > > [1] http://mail.openjdk.java.net/pipermail/announce/2008-April/000063.html > From tim.bell at sun.com Fri Apr 18 02:34:00 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:34:00 +0000 Subject: hg: jdk7/tl: 3 new changesets Message-ID: <20080418023400.9679227F16@hg.openjdk.java.net> Changeset: 05809a7eb190 Author: ohair Date: 2008-03-18 11:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/05809a7eb190 6674232: OPENJDK=false is same as OPENJDK=true Summary: If OPENJDK has a value, that value must be "true", empty value == undefined with GNU make. Reviewed-by: tbell ! make/Defs-internal.gmk Changeset: cbc8ad9dd0e0 Author: ohair Date: 2008-03-25 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/cbc8ad9dd0e0 6623832: Cleanup old j2se makefile targets Summary: Just removing unneeded makefile rules and 'control' logic. Reviewed-by: xdono ! Makefile ! make/jdk-rules.gmk Changeset: 9410f77cc30c Author: xdono Date: 2008-04-09 11:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/rev/9410f77cc30c Added tag jdk7-b25 for changeset cbc8ad9dd0e0 ! .hgtags From tim.bell at sun.com Fri Apr 18 02:34:31 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:34:31 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20080418023433.AE7E427F1B@hg.openjdk.java.net> Changeset: 5e61d5df6258 Author: ohair Date: 2008-03-25 14:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/5e61d5df6258 6627817: Remove ^M characters in all files (Makefiles too) Summary: Some files included the use of the ^M character, which has been deleted Reviewed-by: xdono ! src/share/classes/com/sun/corba/se/impl/corba/orb_config_design.txt ! src/share/classes/org/omg/CORBA/ir.idl ! src/share/classes/org/omg/DynamicAny/DynamicAny.idl Changeset: 0043eb3d4e62 Author: xdono Date: 2008-04-09 11:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/0043eb3d4e62 Added tag jdk7-b25 for changeset 5e61d5df6258 ! .hgtags From tim.bell at sun.com Fri Apr 18 02:35:48 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:35:48 +0000 Subject: hg: jdk7/tl/hotspot: Added tag jdk7-b25 for changeset 7836be3e92d0 Message-ID: <20080418023551.EA96E27F22@hg.openjdk.java.net> Changeset: 8b0b3490194f Author: xdono Date: 2008-04-09 11:18 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8b0b3490194f Added tag jdk7-b25 for changeset 7836be3e92d0 ! .hgtags From tim.bell at sun.com Fri Apr 18 02:37:28 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:37:28 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b25 for changeset a3b3ba7d6034 Message-ID: <20080418023730.5E1FC27F29@hg.openjdk.java.net> Changeset: da43cb85fac1 Author: xdono Date: 2008-04-09 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/da43cb85fac1 Added tag jdk7-b25 for changeset a3b3ba7d6034 ! .hgtags From tim.bell at sun.com Fri Apr 18 02:38:01 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:38:01 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b25 for changeset 59fd8224ba2d Message-ID: <20080418023803.E442C27F32@hg.openjdk.java.net> Changeset: debd37e1a422 Author: xdono Date: 2008-04-09 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/debd37e1a422 Added tag jdk7-b25 for changeset 59fd8224ba2d ! .hgtags From tim.bell at sun.com Fri Apr 18 02:39:08 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:39:08 +0000 Subject: hg: jdk7/tl/jdk: 12 new changesets Message-ID: <20080418024141.1488F27F37@hg.openjdk.java.net> Changeset: f1c168caf94f Author: ohair Date: 2008-03-18 11:03 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f1c168caf94f 6674226: Warning errors in freetypecheck Summary: Just corrected some C code to remove warning errors from gcc. Reviewed-by: tbell ! make/tools/freetypecheck/freetypecheck.c Changeset: e564dc9241e5 Author: ohair Date: 2008-03-18 11:04 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e564dc9241e5 6611788: chmod a+x bin/winver.exe in make/tools/winver/Makefile fails on a read only file system Summary: Tell Mercurial this file has execute permission. Reviewed-by: tbell Changeset: ea98209ac149 Author: ohair Date: 2008-03-18 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ea98209ac149 6674232: OPENJDK=false is same as OPENJDK=true Summary: OPENJDK should be empty (undefined) or "true". Reviewed-by: tbell ! make/common/Defs.gmk Changeset: e98ce66d7630 Author: ohair Date: 2008-03-18 11:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e98ce66d7630 6654458: /java/devtools findbugs doesn't work on windows Summary: Changes to both ant and findbugs version checking. Reviewed-by: tbell ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity.gmk Changeset: 9ae5ccf6891c Author: ohair Date: 2008-03-19 13:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9ae5ccf6891c 6611629: Avoid hardcoded cygwin paths for memory detection Summary: Use free with sygwin, mem or systeminfo otherwise, to get MB_OF_MEMORY on windows. Reviewed-by: tbell ! make/common/shared/Platform.gmk Changeset: 9b0d53aa8549 Author: ohair Date: 2008-03-25 14:40 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9b0d53aa8549 6627817: Remove ^M characters in all files (Makefiles too) Summary: Some files included the use of the ^M character, which has been deleted. Reviewed-by: xdono ! make/common/shared/Sanity.gmk ! make/docs/CORE_PKGS.gmk ! src/share/classes/com/sun/inputmethods/internal/indicim/resources/DisplayNames.properties ! src/share/classes/com/sun/inputmethods/internal/thaiim/resources/DisplayNames.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.dtd ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.xml ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/schema/etsi.xsd ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_en.properties ! src/share/classes/javax/swing/plaf/synth/doc-files/synth.dtd ! src/share/classes/javax/swing/plaf/synth/package.html ! src/share/demo/jfc/Notepad/resources/Notepad.properties ! src/share/sample/vm/clr-jvm/Makefile ! src/share/sample/vm/clr-jvm/README.txt ! src/share/sample/vm/clr-jvm/invoker.cs ! src/share/sample/vm/jvm-clr/README.txt ! src/share/sample/vm/jvm-clr/invoked.cs Changeset: 40b6f7fcac38 Author: ohair Date: 2008-03-26 17:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/40b6f7fcac38 Merge Changeset: 75fca0b0ab83 Author: xdono Date: 2008-03-27 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/75fca0b0ab83 Merge Changeset: 6e25a8a3f8c6 Author: xdono Date: 2008-04-09 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6e25a8a3f8c6 Added tag jdk7-b25 for changeset 75fca0b0ab83 ! .hgtags Changeset: e6da580585e9 Author: tbell Date: 2008-04-07 23:27 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e6da580585e9 Merge ! make/common/shared/Defs.gmk Changeset: 4708b9a13f24 Author: tbell Date: 2008-04-11 15:06 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4708b9a13f24 Merge Changeset: 74a42d77106b Author: tbell Date: 2008-04-15 17:46 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74a42d77106b Merge From tim.bell at sun.com Fri Apr 18 02:44:34 2008 From: tim.bell at sun.com (tim.bell at sun.com) Date: Fri, 18 Apr 2008 02:44:34 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20080418024440.5980927F3C@hg.openjdk.java.net> Changeset: 18f0b1b5ffd6 Author: xdono Date: 2008-04-09 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/18f0b1b5ffd6 Added tag jdk7-b25 for changeset 58039502942e ! .hgtags Changeset: c46d25a2350a Author: tbell Date: 2008-04-11 15:08 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c46d25a2350a Merge Changeset: 627deea1ea4f Author: tbell Date: 2008-04-15 17:48 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/627deea1ea4f Merge From iris at sun.com Fri Apr 18 19:49:29 2008 From: iris at sun.com (iris clark) Date: Fri, 18 Apr 2008 12:49:29 -0700 (PDT) Subject: CFV: Project sponsorship: More New I/0 APIs for te Java Platform (JSR-203) In-Reply-To: <200804151724.m3FHOQPK017797@ribbit.SFBay.Sun.COM> (message from iris clark on Tue, 15 Apr 2008 10:24:26 -0700 (PDT)) Message-ID: <200804181949.m3IJnTc8019451@ribbit.SFBay.Sun.COM> Regarding the CFV on the following question[1]: Should the Core Libraries Group sponsor the "More New I/O APIs for the Java Platform (JSR-203) Project? Voting has now concluded. I have received "Yes" votes from the following 9 members of the Core Libraries Group: Christopher Hegarty David Bristor Doug Lea Iris Clark Joe Darcy Mark Reinhold Martin Buchholz Pete Soper Xueming Shen This constitues an absolute majority of the eligible voting members. Thus I am able to immediately render a decision. The Core Libraries Group has decided to sponsor the JSR-203 project. Thank you. iris [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-April/000332.html From charlie.hunt at sun.com Thu Apr 17 21:54:18 2008 From: charlie.hunt at sun.com (charlie hunt) Date: Thu, 17 Apr 2008 16:54:18 -0500 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? Message-ID: <4807C70A.10508@sun.com> Been looking at TreeMap's implementation rather closely and observed something I don't understand. %-) TreeMap (as of JDK 6 and later) implements NavigableMap. NavigableMap requires an implementation of a navigableKeySet() method which returns a NavigableSet. So, in TreeMap I see: public NavigableSet navigableKeySet() Then, the NavigableSet interface has an Iterator descendingIterator() and Iteratoriterator(). The former returns an iterator over the elements in descending order. The latter in ascending order. I also noticed in TreeMap, NavigableMap requires an implementation of a descendingKeySet(), i.e. public NavigableSet descendingKeySet(). Again, the NavigableSet interface has an Iterator descendingIterator() and iterator() as described above. When I populate a TreeMap with some dummy data, let's say I populate it with 15 Integer keys and String's representing those Integer keys as values, I observe something I don't understand when using the navigableKeySet().descendingIterator(). When, I try to iterate over the returned NavigableKeySet, I see the lowest key printed and that's it. Nothing else prints. From looking at the JavaDoc for TreeMap and NavigableSet, this doesn't seem right. Shouldn't it iterate over the entire set in descending order? I looked at the source and it creates an Iterator that starts at the lowest key and then tries to find the next lowest key (which obviously doesn't exist). Am I not reading something right in the JavaDoc? When iterating using navigableKeySet().iterator() I see all 15 keys printed in ascending order, (as expected). When I iterate with descendingKeySet().descendingIterator() I see the 15 keys printed in ascending order, (as expected since descending set followed by a descending iterator should give me ascending order). When iterating using descendingKeySet().iterator, I see the 15 keys printed in descending order, (as expected). I've attached a very simple program that illustrates what I'm describing. Could someone clarify this behavior? thanks, charlie ... -------------- next part -------------- A non-text attachment was scrubbed... Name: TestTreeMap.java Type: text/x-java Size: 2808 bytes Desc: not available URL: From keith.mcguigan at sun.com Fri Apr 18 04:22:54 2008 From: keith.mcguigan at sun.com (keith.mcguigan at sun.com) Date: Fri, 18 Apr 2008 04:22:54 +0000 Subject: hg: jdk7/tl/jdk: 6690122: Provide a mechanism for specifying Java-level USDT-like dtrace probes Message-ID: <20080418042306.9898F27F49@hg.openjdk.java.net> Changeset: 2bfddc119eea Author: kamg Date: 2008-04-17 22:00 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2bfddc119eea 6690122: Provide a mechanism for specifying Java-level USDT-like dtrace probes Summary: Initial checkin of JSDT code Reviewed-by: sspitsyn, sbohne ! make/com/sun/Makefile + make/com/sun/tracing/Makefile + make/com/sun/tracing/dtrace/Makefile ! make/docs/Makefile ! make/docs/NON_CORE_PKGS.gmk ! make/sun/Makefile + make/sun/tracing/Makefile + make/sun/tracing/dtrace/Makefile + make/sun/tracing/dtrace/mapfile-vers + src/share/classes/com/sun/tracing/Probe.java + src/share/classes/com/sun/tracing/ProbeName.java + src/share/classes/com/sun/tracing/Provider.java + src/share/classes/com/sun/tracing/ProviderFactory.java + src/share/classes/com/sun/tracing/ProviderName.java + src/share/classes/com/sun/tracing/dtrace/ArgsAttributes.java + src/share/classes/com/sun/tracing/dtrace/Attributes.java + src/share/classes/com/sun/tracing/dtrace/DependencyClass.java + src/share/classes/com/sun/tracing/dtrace/FunctionAttributes.java + src/share/classes/com/sun/tracing/dtrace/FunctionName.java + src/share/classes/com/sun/tracing/dtrace/ModuleAttributes.java + src/share/classes/com/sun/tracing/dtrace/ModuleName.java + src/share/classes/com/sun/tracing/dtrace/NameAttributes.java + src/share/classes/com/sun/tracing/dtrace/ProviderAttributes.java + src/share/classes/com/sun/tracing/dtrace/StabilityLevel.java + src/share/classes/com/sun/tracing/dtrace/package-info.java + src/share/classes/com/sun/tracing/package-info.java + src/share/classes/sun/tracing/MultiplexProviderFactory.java + src/share/classes/sun/tracing/NullProviderFactory.java + src/share/classes/sun/tracing/PrintStreamProviderFactory.java + src/share/classes/sun/tracing/ProbeSkeleton.java + src/share/classes/sun/tracing/ProviderSkeleton.java + src/share/classes/sun/tracing/dtrace/Activation.java + src/share/classes/sun/tracing/dtrace/DTraceProbe.java + src/share/classes/sun/tracing/dtrace/DTraceProvider.java + src/share/classes/sun/tracing/dtrace/DTraceProviderFactory.java + src/share/classes/sun/tracing/dtrace/JVM.java + src/share/classes/sun/tracing/package-info.java ! src/share/javavm/export/jvm.h + src/share/native/sun/tracing/dtrace/JVM.c + src/share/native/sun/tracing/dtrace/jvm_symbols.h + src/solaris/native/sun/tracing/dtrace/jvm_symbols_md.c + src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c + test/com/sun/tracing/BasicFunctionality.java From kevinb at google.com Fri Apr 18 21:39:05 2008 From: kevinb at google.com (kevin bourrillion) Date: Fri, 18 Apr 2008 14:39:05 -0700 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <4807C70A.10508@sun.com> References: <4807C70A.10508@sun.com> Message-ID: <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> Wow. TreeMap.java line 1024: return new DescendingKeyIterator(getFirstEntry()); Sure does look fishy. On Thu, Apr 17, 2008 at 2:54 PM, charlie hunt wrote: > Been looking at TreeMap's implementation rather closely and observed > something I don't understand. %-) > > TreeMap (as of JDK 6 and later) implements NavigableMap. NavigableMap > requires an implementation of a navigableKeySet() method which returns a > NavigableSet. So, in TreeMap I see: > > public NavigableSet navigableKeySet() > > Then, the NavigableSet interface has an Iterator descendingIterator() > and Iteratoriterator(). The former returns an iterator over the elements > in descending order. The latter in ascending order. > > I also noticed in TreeMap, NavigableMap requires an implementation of a > descendingKeySet(), i.e. public NavigableSet descendingKeySet(). Again, > the NavigableSet interface has an Iterator descendingIterator() and > iterator() as described above. > > When I populate a TreeMap with some dummy data, let's say I populate it > with 15 Integer keys and String's representing those Integer keys as values, > I observe something I don't understand when using the > navigableKeySet().descendingIterator(). > > When, I try to iterate over the returned NavigableKeySet, I see the lowest > key printed and that's it. Nothing else prints. From looking at the JavaDoc > for TreeMap and NavigableSet, this doesn't seem right. Shouldn't it iterate > over the entire set in descending order? I looked at the source and it > creates an Iterator that starts at the lowest key and then tries to find the > next lowest key (which obviously doesn't exist). Am I not reading something > right in the JavaDoc? > > When iterating using navigableKeySet().iterator() I see all 15 keys printed > in ascending order, (as expected). > > When I iterate with descendingKeySet().descendingIterator() I see the 15 > keys printed in ascending order, (as expected since descending set followed > by a descending iterator should give me ascending order). > > When iterating using descendingKeySet().iterator, I see the 15 keys printed > in descending order, (as expected). > > I've attached a very simple program that illustrates what I'm describing. > > Could someone clarify this behavior? > > thanks, > > charlie ... > > -- Kevin Bourrillion @ Google internal: go/javalibraries google-collections.googlecode.com google-guice.googlecode.com From martinrb at google.com Sat Apr 19 08:37:49 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 19 Apr 2008 01:37:49 -0700 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> Message-ID: <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> Yes, sad to say, looks like a serious and embarrassing bug. This bit of code has no existing test case. More tests should be added to MOAT.java. Charlie, please file a bug. In our defense, there are very many methods in the NavigableFoo interfaces, and for completeness they have to be tested on subsets and submaps, and Sun engineers have not historically had good code coverage tool support. Martin On Fri, Apr 18, 2008 at 2:39 PM, kevin bourrillion wrote: > Wow. TreeMap.java line 1024: > > return new DescendingKeyIterator(getFirstEntry()); > > Sure does look fishy. > > > > On Thu, Apr 17, 2008 at 2:54 PM, charlie hunt > wrote: > > Been looking at TreeMap's implementation rather closely and observed > > something I don't understand. %-) > > > > TreeMap (as of JDK 6 and later) implements NavigableMap. NavigableMap > > requires an implementation of a navigableKeySet() method which returns a > > NavigableSet. So, in TreeMap I see: > > > > public NavigableSet navigableKeySet() > > > > Then, the NavigableSet interface has an Iterator > descendingIterator() > > and Iteratoriterator(). The former returns an iterator over the > elements > > in descending order. The latter in ascending order. > > > > I also noticed in TreeMap, NavigableMap requires an implementation of a > > descendingKeySet(), i.e. public NavigableSet descendingKeySet(). > Again, > > the NavigableSet interface has an Iterator descendingIterator() and > > iterator() as described above. > > > > When I populate a TreeMap with some dummy data, let's say I populate it > > with 15 Integer keys and String's representing those Integer keys as > values, > > I observe something I don't understand when using the > > navigableKeySet().descendingIterator(). > > > > When, I try to iterate over the returned NavigableKeySet, I see the > lowest > > key printed and that's it. Nothing else prints. From looking at the > JavaDoc > > for TreeMap and NavigableSet, this doesn't seem right. Shouldn't it > iterate > > over the entire set in descending order? I looked at the source and it > > creates an Iterator that starts at the lowest key and then tries to find > the > > next lowest key (which obviously doesn't exist). Am I not reading > something > > right in the JavaDoc? > > > > When iterating using navigableKeySet().iterator() I see all 15 keys > printed > > in ascending order, (as expected). > > > > When I iterate with descendingKeySet().descendingIterator() I see the > 15 > > keys printed in ascending order, (as expected since descending set > followed > > by a descending iterator should give me ascending order). > > > > When iterating using descendingKeySet().iterator, I see the 15 keys > printed > > in descending order, (as expected). > > > > I've attached a very simple program that illustrates what I'm > describing. > > > > Could someone clarify this behavior? > > > > thanks, > > > > charlie ... > > > > > > > > -- > Kevin Bourrillion @ Google > internal: go/javalibraries > google-collections.googlecode.com > google-guice.googlecode.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dl at cs.oswego.edu Sat Apr 19 15:12:34 2008 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 19 Apr 2008 11:12:34 -0400 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> Message-ID: <480A0BE2.4070209@cs.oswego.edu> Martin Buchholz wrote: > Yes, sad to say, looks like a serious and embarrassing bug. And dumb! "First" => "Last" on line 1024. Ugh. > This bit of code has no existing test case. Well, it did, but that TCK test only checked that elements were in order, not that #elements == size. Now it does. > Charlie, please file a bug. We can use this as a good test case to find out if we can quickly get a one line fix committed. Martin? -Doug From martinrb at google.com Sat Apr 19 15:54:09 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 19 Apr 2008 08:54:09 -0700 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <480A0BE2.4070209@cs.oswego.edu> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> <480A0BE2.4070209@cs.oswego.edu> Message-ID: <1ccfd1c10804190854m3790e07cub7ca988c7286f54d@mail.gmail.com> I'll take care of making a fix. Patch to follow. Martin On Sat, Apr 19, 2008 at 8:12 AM, Doug Lea
wrote: > Martin Buchholz wrote: > > > Yes, sad to say, looks like a serious and embarrassing bug. > > > > And dumb! "First" => "Last" on line 1024. Ugh. > > This bit of code has no existing test case. > > > > Well, it did, but that TCK test only checked that elements > were in order, not that #elements == size. Now it does. > > Charlie, please file a bug. > > > > We can use this as a good test case to find out if we can quickly > get a one line fix committed. Martin? > > -Doug > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Sat Apr 19 18:53:48 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 19 Apr 2008 11:53:48 -0700 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <1ccfd1c10804190854m3790e07cub7ca988c7286f54d@mail.gmail.com> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> <480A0BE2.4070209@cs.oswego.edu> <1ccfd1c10804190854m3790e07cub7ca988c7286f54d@mail.gmail.com> Message-ID: <1ccfd1c10804191153v2be0fe87tc7388f07d52eec6b@mail.gmail.com> Below is the proposed patch. We had alredy been testing m.descendingKeySet().iterator() but not the equivalent m.navigableKeySet().descendingIterator() which goes down a different code path. To get this into the JDK, we will need: 1. Review from Doug (or some other person empowered to do so) 2. Bug creation from Charlie (or some other person empowered to do so) I suggest making this bug P2-S2. I will need the bug id and synopsis to create the proper mercurial comment. 3. Someone at Sun will need to backport this to JDK 6. It's time to appoint a Sun engineer to the Collections/Concurrency area for tasks such as this. (I would have used webrev if that was publically available, and there was a place to store it) The added tests are rather more than strictly necessary to expose the bug, but that's no defect. diff --git a/src/share/classes/java/util/TreeMap.java b/src/share/classes/java/util/TreeMap.java --- a/src/share/classes/java/util/TreeMap.java +++ b/src/share/classes/java/util/TreeMap.java @@ -1021,7 +1021,7 @@ public class TreeMap } Iterator descendingKeyIterator() { - return new DescendingKeyIterator(getFirstEntry()); + return new DescendingKeyIterator(getLastEntry()); } static final class KeySet extends AbstractSet implements NavigableSet { diff --git a/test/java/util/Collection/MOAT.java b/test/java/util/Collection/MOAT.java --- a/test/java/util/Collection/MOAT.java +++ b/test/java/util/Collection/MOAT.java @@ -155,7 +155,7 @@ public class MOAT { check(c.containsAll(new ArrayList())); } - private static void testEmptyCollection(Collection c) { + private static void testEmptyCollection(Collection c) { check(c.isEmpty()); equal(c.size(), 0); equal(c.toString(),"[]"); @@ -165,6 +165,23 @@ public class MOAT { Object[] a = new Object[1]; a[0] = Boolean.TRUE; equal(c.toArray(a), a); equal(a[0], null); + testEmptyIterator(c.iterator()); + } + + static void testEmptyIterator(final Iterator it) { + if (rnd.nextBoolean()) + check(! it.hasNext()); + + THROWS(NoSuchElementException.class, + new Fun(){void f(){ it.next(); }}); + + try { it.remove(); } + catch (IllegalStateException _) { pass(); } + catch (UnsupportedOperationException _) { pass(); } + catch (Throwable t) { unexpected(t); } + + if (rnd.nextBoolean()) + check(! it.hasNext()); } private static void testEmptyList(List c) { @@ -173,10 +190,12 @@ public class MOAT { equal2(c, Collections.emptyList()); } - private static void testEmptySet(Set c) { + private static void testEmptySet(Set c) { testEmptyCollection(c); equal(c.hashCode(), 0); equal2(c, Collections.emptySet()); + if (c instanceof NavigableSet) + testEmptyIterator(((NavigableSet)c).descendingIterator()); } private static void testImmutableCollection(final Collection c) { @@ -221,7 +240,7 @@ public class MOAT { testEmptyCollection(c); } - private static void testEmptyMap(final Map m) { + private static void testEmptyMap(final Map m) { check(m.isEmpty()); equal(m.size(), 0); equal(m.toString(),"{}"); @@ -433,8 +452,18 @@ public class MOAT { if (! supportsAdd(c)) return; //System.out.println("add() supported"); - if (c instanceof NavigableSet) - testNavigableSet((NavigableSet)c); + if (c instanceof NavigableSet) { + System.out.println("NavigableSet tests..."); + + NavigableSet ns = (NavigableSet)c; + testNavigableSet(ns); + testNavigableSet(ns.headSet(6, false)); + testNavigableSet(ns.headSet(5, true)); + testNavigableSet(ns.tailSet(0, false)); + testNavigableSet(ns.tailSet(1, true)); + testNavigableSet(ns.subSet(0, false, 5, true)); + testNavigableSet(ns.subSet(1, true, 6, false)); + } if (c instanceof Queue) testQueue((Queue)c); @@ -514,8 +543,19 @@ public class MOAT { if (m instanceof ConcurrentMap) testConcurrentMap((ConcurrentMap) m); - if (m instanceof NavigableMap) - testNavigableMap((NavigableMap) m); + if (m instanceof NavigableMap) { + System.out.println("NavigableMap tests..."); + + NavigableMap nm = + (NavigableMap) m; + testNavigableMap(nm); + testNavigableMap(nm.headMap(6, false)); + testNavigableMap(nm.headMap(5, true)); + testNavigableMap(nm.tailMap(0, false)); + testNavigableMap(nm.tailMap(1, true)); + testNavigableMap(nm.subMap(1, true, 6, false)); + testNavigableMap(nm.subMap(0, false, 5, true)); + } checkFunctionalInvariants(m); @@ -697,8 +737,6 @@ public class MOAT { private static void testNavigableMap(NavigableMap m) { - System.out.println("NavigableMap tests..."); - clear(m); checkNavigableMapKeys(m, 1, null, null, null, null); @@ -717,9 +755,11 @@ public class MOAT { checkNavigableMapKeys(m, 5, 3, 5, 5, null); checkNavigableMapKeys(m, 6, 5, 5, null, null); - { - final Iterator it - = m.descendingKeySet().iterator(); + for (final Iterator it : + (Iterator[]) + new Iterator[] { + m.descendingKeySet().iterator(), + m.navigableKeySet().descendingIterator()}) { equalNext(it, 5); equalNext(it, 3); equalNext(it, 1); @@ -742,8 +782,6 @@ public class MOAT { private static void testNavigableSet(NavigableSet s) { - System.out.println("NavigableSet tests..."); - clear(s); checkNavigableSetKeys(s, 1, null, null, null, null); @@ -762,8 +800,11 @@ public class MOAT { checkNavigableSetKeys(s, 5, 3, 5, 5, null); checkNavigableSetKeys(s, 6, 5, 5, null, null); - { - final Iterator it = s.descendingIterator(); + for (final Iterator it : + (Iterator[]) + new Iterator[] { + s.descendingIterator(), + s.descendingSet().iterator()}) { equalNext(it, 5); equalNext(it, 3); equalNext(it, 1); From dl at cs.oswego.edu Sat Apr 19 19:01:09 2008 From: dl at cs.oswego.edu (Doug Lea) Date: Sat, 19 Apr 2008 15:01:09 -0400 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <1ccfd1c10804191153v2be0fe87tc7388f07d52eec6b@mail.gmail.com> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> <480A0BE2.4070209@cs.oswego.edu> <1ccfd1c10804190854m3790e07cub7ca988c7286f54d@mail.gmail.com> <1ccfd1c10804191153v2be0fe87tc7388f07d52eec6b@mail.gmail.com> Message-ID: <480A4175.3070907@cs.oswego.edu> Martin Buchholz wrote: > Below is the proposed patch. > I also checked in the JSR166 TCK improvements I mentioned. (These aren't yet part of openjdk.) And also applied to ConcurrentSkipListMapTest. See http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/TreeMapTest.java?view=log http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ConcurrentSkipListMapTest.java?view=log -Doug From Alan.Bateman at Sun.COM Sat Apr 19 20:26:12 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sat, 19 Apr 2008 21:26:12 +0100 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <1ccfd1c10804191153v2be0fe87tc7388f07d52eec6b@mail.gmail.com> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> <480A0BE2.4070209@cs.oswego.edu> <1ccfd1c10804190854m3790e07cub7ca988c7286f54d@mail.gmail.com> <1ccfd1c10804191153v2be0fe87tc7388f07d52eec6b@mail.gmail.com> Message-ID: <480A5564.4010405@sun.com> Martin Buchholz wrote: > : > > 2. Bug creation from Charlie (or some other person empowered to do so) > I suggest making this bug P2-S2. > > I will need the bug id and synopsis to create the proper mercurial comment. > I don't know if Charlie is online today, but as you seem to be ready to create the change-set, I've created java/classes_util bug: 6691185: (coll) TreeMap.navigableKeySet's descendingIterator method starts at first instead of last entry with a link to this thread. The synopsis can be changed if you want something different. -Alan. From martinrb at google.com Sun Apr 20 00:56:09 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 19 Apr 2008 17:56:09 -0700 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <480A5EFE.5090005@sun.com> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> <480A0BE2.4070209@cs.oswego.edu> <1ccfd1c10804190854m3790e07cub7ca988c7286f54d@mail.gmail.com> <1ccfd1c10804191153v2be0fe87tc7388f07d52eec6b@mail.gmail.com> <480A5564.4010405@sun.com> <480A5EFE.5090005@sun.com> Message-ID: <1ccfd1c10804191756y3f6186f8h59cb0d779862a695@mail.gmail.com> Alan, thanks for filing the bug. Charlie, thanks for the review. However, since you are not (yet?) an OpenJDK committer, I will still need an official review from Doug (or Alan?) I noticed there was another test case, NavigableMap/LockStep.java, that "almost" tested the faulty code. I include a change to that test case as well, below (as well as making the test case a little more maintainble). diff --git a/test/java/util/NavigableMap/LockStep.java b/test/java/util/NavigableMap/LockStep.java --- a/test/java/util/NavigableMap/LockStep.java +++ b/test/java/util/NavigableMap/LockStep.java @@ -159,6 +159,7 @@ public class LockStep { Object[] a = new Object[1]; a[0] = Boolean.TRUE; equal(c.toArray(a), a); equal(a[0], null); + check(! c.iterator().hasNext()); } static void testEmptySet(Set c) { @@ -262,6 +263,16 @@ public class LockStep { } } + static void equalIterators(final Iterator it1, + final Iterator it2) { + while (it1.hasNext()) { + if (maybe(2)) + check(it2.hasNext()); + equal(it1.next(), it2.next()); + } + check(! it2.hasNext()); + } + static void equalNavigableSetsLeaf(final NavigableSet s1, final NavigableSet s2) { equal2(s1, s2); @@ -273,6 +284,8 @@ public class LockStep { equal(s1.first(), s2.first()); equal(s1.last(), s2.last()); } + equalIterators(s1.iterator(), s2.iterator()); + equalIterators(s1.descendingIterator(), s2.descendingIterator()); checkNavigableSet(s1); checkNavigableSet(s2); } @@ -493,30 +506,23 @@ public class LockStep { static MapFrobber randomAdder(NavigableMap m) { final Integer k = unusedKey(m); - MapFrobber f; - switch (rnd.nextInt(4)) { - case 0: f = new MapFrobber() {void frob(NavigableMap m) { - equal(m.put(k, k+1), null); - equal(m.get(k), k+1); - if (maybe(4)) { - equal(m.put(k, k+1), k+1); - equal(m.get(k), k+1);}}}; - break; - case 1: f = new MapFrobber() {void frob(NavigableMap m) { - m.descendingMap().put(k, k+1); - equal(m.get(k), k+1);}}; - break; - case 2: f = new MapFrobber() {void frob(NavigableMap m) { - m.tailMap(k,true).headMap(k,true).put(k,k+1);}}; - break; - case 3: f = new MapFrobber() {void frob(NavigableMap m) { - m.tailMap(k,true).headMap(k,true).descendingMap().put(k,k+1);}}; - break; - default: throw new Error(); - } - final MapFrobber ff = f; + final MapFrobber[] randomAdders = { + new MapFrobber() {void frob(NavigableMap m) { + equal(m.put(k, k+1), null); + equal(m.get(k), k+1); + if (maybe(4)) { + equal(m.put(k, k+1), k+1); + equal(m.get(k), k+1);}}}, + new MapFrobber() {void frob(NavigableMap m) { + m.descendingMap().put(k, k+1); + equal(m.get(k), k+1);}}, + new MapFrobber() {void frob(NavigableMap m) { + m.tailMap(k,true).headMap(k,true).put(k,k+1);}}, + new MapFrobber() {void frob(NavigableMap m) { + m.tailMap(k,true).headMap(k,true).descendingMap().put(k,k+1);}} + }; return new MapFrobber() {void frob(NavigableMap m) { - ff.frob(m); + randomAdders[rnd.nextInt(randomAdders.length)].frob(m); if (maybe(2)) equal(m.get(k), k+1); if (maybe(4)) { equal(m.put(k, k+1), k+1); @@ -525,26 +531,19 @@ public class LockStep { static SetFrobber randomAdder(NavigableSet s) { final Integer e = unusedElt(s); - SetFrobber f; - switch (rnd.nextInt(4)) { - case 0: f = new SetFrobber() {void frob(NavigableSet s) { - check(s.add(e));}}; - break; - case 1: f = new SetFrobber() {void frob(NavigableSet s) { - s.descendingSet().add(e);}}; - break; - case 2: f = new SetFrobber() {void frob(NavigableSet s) { - s.tailSet(e,true).headSet(e,true).add(e);}}; - break; - case 3: f = new SetFrobber() {void frob(NavigableSet s) { - s.descendingSet().tailSet(e,true).headSet(e,true).add(e);}}; - break; - default: throw new Error(); - } - final SetFrobber ff = f; + final SetFrobber[] randomAdders = { + new SetFrobber() {void frob(NavigableSet s) { + check(s.add(e));}}, + new SetFrobber() {void frob(NavigableSet s) { + s.descendingSet().add(e);}}, + new SetFrobber() {void frob(NavigableSet s) { + s.tailSet(e,true).headSet(e,true).add(e);}}, + new SetFrobber() {void frob(NavigableSet s) { + s.descendingSet().tailSet(e,true).headSet(e,true).add(e);}} + }; return new SetFrobber() {void frob(NavigableSet s) { if (maybe(2)) check(! s.contains(e)); - ff.frob(s); + randomAdders[rnd.nextInt(randomAdders.length)].frob(s); if (maybe(2)) check(! s.add(e)); if (maybe(2)) check(s.contains(e));}}; } @@ -605,89 +604,112 @@ public class LockStep { static MapFrobber randomRemover(NavigableMap m) { final Integer k = usedKey(m); - switch (rnd.nextInt(7)) { - default: throw new Error(); - case 0: return new MapFrobber() {void frob(NavigableMap m) { - Map.Entry e = m.firstEntry(); - equal(m.pollFirstEntry(), e); - checkUnusedKey(m, e.getKey());}}; - case 1: return new MapFrobber() {void frob(NavigableMap m) { - Map.Entry e = m.lastEntry(); - equal(m.pollLastEntry(), e); - checkUnusedKey(m, e.getKey());}}; - case 2: return new MapFrobber() {void frob(NavigableMap m) { - check(m.remove(k) != null); - checkUnusedKey(m, k);}}; - case 3: return new MapFrobber() {void frob(NavigableMap m) { - m.subMap(k, true, k, true).clear(); - checkUnusedKey(m, k);}}; - case 4: return new MapFrobber() {void frob(NavigableMap m) { - m.descendingMap().subMap(k, true, k, true).clear(); - checkUnusedKey(m, k);}}; - case 5: return new MapFrobber() {void frob(NavigableMap m) { - final Iterator it = m.keySet().iterator(); - while (it.hasNext()) - if (it.next().equals(k)) { - it.remove(); - if (maybe(2)) - THROWS(IllegalStateException.class, - new Fun(){void f(){ it.remove(); }}); - } - checkUnusedKey(m, k);}}; - case 6: return new MapFrobber() {void frob(NavigableMap m) { - final Iterator it = m.entrySet().iterator(); - while (it.hasNext()) - if (it.next().getKey().equals(k)) { - it.remove(); - if (maybe(2)) - THROWS(IllegalStateException.class, remover(it)); - } - checkUnusedKey(m, k);}}; - } + final MapFrobber[] randomRemovers = { + new MapFrobber() {void frob(NavigableMap m) { + Map.Entry e = m.firstEntry(); + equal(m.pollFirstEntry(), e); + checkUnusedKey(m, e.getKey());}}, + new MapFrobber() {void frob(NavigableMap m) { + Map.Entry e = m.lastEntry(); + equal(m.pollLastEntry(), e); + checkUnusedKey(m, e.getKey());}}, + new MapFrobber() {void frob(NavigableMap m) { + check(m.remove(k) != null); + checkUnusedKey(m, k);}}, + new MapFrobber() {void frob(NavigableMap m) { + m.subMap(k, true, k, true).clear(); + checkUnusedKey(m, k);}}, + new MapFrobber() {void frob(NavigableMap m) { + m.descendingMap().subMap(k, true, k, true).clear(); + checkUnusedKey(m, k);}}, + new MapFrobber() {void frob(NavigableMap m) { + final Iterator it = m.keySet().iterator(); + while (it.hasNext()) + if (it.next().equals(k)) { + it.remove(); + if (maybe(2)) + THROWS(IllegalStateException.class, + new Fun(){void f(){ it.remove(); }}); + } + checkUnusedKey(m, k);}}, + new MapFrobber() {void frob(NavigableMap m) { + final Iterator it = m.navigableKeySet().descendingIterator(); + while (it.hasNext()) + if (it.next().equals(k)) { + it.remove(); + if (maybe(2)) + THROWS(IllegalStateException.class, + new Fun(){void f(){ it.remove(); }}); + } + checkUnusedKey(m, k);}}, + new MapFrobber() {void frob(NavigableMap m) { + final Iterator it = m.entrySet().iterator(); + while (it.hasNext()) + if (it.next().getKey().equals(k)) { + it.remove(); + if (maybe(2)) + THROWS(IllegalStateException.class, remover(it)); + } + checkUnusedKey(m, k);}}, + }; + + return randomRemovers[rnd.nextInt(randomRemovers.length)]; } static SetFrobber randomRemover(NavigableSet s) { final Integer e = usedElt(s); - switch (rnd.nextInt(7)) { - default: throw new Error(); - case 0: return new SetFrobber() {void frob(NavigableSet s) { - Object e = s.first(); - equal(s.pollFirst(), e); - checkUnusedElt(s, e);}}; - case 1: return new SetFrobber() {void frob(NavigableSet s) { - Object e = s.last(); - equal(s.pollLast(), e); - checkUnusedElt(s, e);}}; - case 2: return new SetFrobber() {void frob(NavigableSet s) { - check(s.remove(e)); - checkUnusedElt(s, e);}}; - case 3: return new SetFrobber() {void frob(NavigableSet s) { - s.subSet(e, true, e, true).clear(); - checkUnusedElt(s, e);}}; - case 4: return new SetFrobber() {void frob(NavigableSet s) { - s.descendingSet().subSet(e, true, e, true).clear(); - checkUnusedElt(s, e);}}; - case 5: return new SetFrobber() {void frob(NavigableSet s) { - final Iterator it = s.iterator(); - while (it.hasNext()) - if (it.next().equals(e)) { - it.remove(); - if (maybe(2)) - THROWS(IllegalStateException.class, - new Fun(){void f(){ it.remove(); }}); - } - checkUnusedElt(s, e);}}; - case 6: return new SetFrobber() {void frob(NavigableSet s) { - final Iterator it = s.descendingSet().iterator(); - while (it.hasNext()) - if (it.next().equals(e)) { - it.remove(); - if (maybe(2)) - THROWS(IllegalStateException.class, - new Fun(){void f(){ it.remove(); }}); - } - checkUnusedElt(s, e);}}; - } + + final SetFrobber[] randomRemovers = { + new SetFrobber() {void frob(NavigableSet s) { + Object e = s.first(); + equal(s.pollFirst(), e); + checkUnusedElt(s, e);}}, + new SetFrobber() {void frob(NavigableSet s) { + Object e = s.last(); + equal(s.pollLast(), e); + checkUnusedElt(s, e);}}, + new SetFrobber() {void frob(NavigableSet s) { + check(s.remove(e)); + checkUnusedElt(s, e);}}, + new SetFrobber() {void frob(NavigableSet s) { + s.subSet(e, true, e, true).clear(); + checkUnusedElt(s, e);}}, + new SetFrobber() {void frob(NavigableSet s) { + s.descendingSet().subSet(e, true, e, true).clear(); + checkUnusedElt(s, e);}}, + new SetFrobber() {void frob(NavigableSet s) { + final Iterator it = s.iterator(); + while (it.hasNext()) + if (it.next().equals(e)) { + it.remove(); + if (maybe(2)) + THROWS(IllegalStateException.class, + new Fun(){void f(){ it.remove(); }}); + } + checkUnusedElt(s, e);}}, + new SetFrobber() {void frob(NavigableSet s) { + final Iterator it = s.descendingSet().iterator(); + while (it.hasNext()) + if (it.next().equals(e)) { + it.remove(); + if (maybe(2)) + THROWS(IllegalStateException.class, + new Fun(){void f(){ it.remove(); }}); + } + checkUnusedElt(s, e);}}, + new SetFrobber() {void frob(NavigableSet s) { + final Iterator it = s.descendingIterator(); + while (it.hasNext()) + if (it.next().equals(e)) { + it.remove(); + if (maybe(2)) + THROWS(IllegalStateException.class, + new Fun(){void f(){ it.remove(); }}); + } + checkUnusedElt(s, e);}} + }; + + return randomRemovers[rnd.nextInt(randomRemovers.length)]; } static void lockStep(NavigableMap m1, Martin On Sat, Apr 19, 2008 at 2:07 PM, charlie hunt wrote: > > Alan Bateman wrote: > > > Martin Buchholz wrote: > > > > > : > > > > > > 2. Bug creation from Charlie (or some other person empowered to do so) > > > I suggest making this bug P2-S2. > > > > > > I will need the bug id and synopsis to create the proper mercurial > comment. > > > > > > > > I don't know if Charlie is online today, but as you seem to be ready to > create the change-set, I've created java/classes_util bug: > > > > 6691185: (coll) TreeMap.navigableKeySet's descendingIterator method > starts at first instead of last entry > > > > with a link to this thread. The synopsis can be changed if you want > something different. > > > > -Alan. > > > > Alan, thanks for filing the bug. One less item on my list of things to do. > :-) > > Fwiw, I've looked at Martin's proposed changes. From the familiarity I've > gotten with TreeMap over the past week or two, the changes look good to me. > > charlie ... > > > From martinrb at google.com Sun Apr 20 02:32:43 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 19 Apr 2008 19:32:43 -0700 Subject: 6636363: BufferUnderflowException decoding length 6 UTF-8 sequences with direct buffers Message-ID: <1ccfd1c10804191932y59186c49q4119a10f2b42307b@mail.gmail.com> Xueming and/or Iris: Here's a fix for 6636363: BufferUnderflowException decoding length 6 UTF-8 sequences with direct buffers This is a very obscure bug, but I like very much real bug fixes that are smallest possible i.e. change only one bit of the source code. A regression test will be forthcoming once FindDecodingBugs.java and friends are opened. diff --git a/src/share/classes/sun/nio/cs/UTF_8.java b/src/share/classes/sun/nio/cs/UTF_8.java --- a/src/share/classes/sun/nio/cs/UTF_8.java +++ b/src/share/classes/sun/nio/cs/UTF_8.java @@ -326,7 +326,7 @@ class UTF_8 extends Unicode case 12: case 13: // 6 bytes, 31 bits - if (src.remaining() < 4) + if (src.remaining() < 5) return CoderResult.UNDERFLOW; if (!isContinuation(b2 = src.get())) return CoderResult.malformedForLength(1); From Christopher.Hegarty at Sun.COM Sun Apr 20 09:50:15 2008 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Sun, 20 Apr 2008 10:50:15 +0100 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <1ccfd1c10804191756y3f6186f8h59cb0d779862a695@mail.gmail.com> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> <480A0BE2.4070209@cs.oswego.edu> <1ccfd1c10804190854m3790e07cub7ca988c7286f54d@mail.gmail.com> <1ccfd1c10804191153v2be0fe87tc7388f07d52eec6b@mail.gmail.com> <480A5564.4010405@sun.com> <480A5EFE.5090005@sun.com> <1ccfd1c10804191756y3f6186f8h59cb0d779862a695@mail.gmail.com> Message-ID: <480B11D7.3000706@sun.com> Hi Martin, I (OpenJDK user chegar) approve the changes that you made to: src/share/classes/java/util/TreeMap.java test/java/util/Collection/MOAT.java test/java/util/NavigableMap/LockStep.java The only comment I have is that you may want to add the bug number, CR 6691185, to the @bug tag in the testcases. Do you still have integration access? I can take care of the JDK 6 integration. -Chris. Martin Buchholz wrote: > Alan, thanks for filing the bug. > > Charlie, thanks for the review. However, since you are not (yet?) > an OpenJDK committer, I will still need an official review from Doug > (or Alan?) > > I noticed there was another test case, NavigableMap/LockStep.java, > that "almost" tested the faulty code. > > I include a change to that test case as well, below > (as well as making the test case a little more maintainble). > > diff --git a/test/java/util/NavigableMap/LockStep.java > b/test/java/util/NavigableMap/LockStep.java > --- a/test/java/util/NavigableMap/LockStep.java > +++ b/test/java/util/NavigableMap/LockStep.java > @@ -159,6 +159,7 @@ public class LockStep { > Object[] a = new Object[1]; a[0] = Boolean.TRUE; > equal(c.toArray(a), a); > equal(a[0], null); > + check(! c.iterator().hasNext()); > } > > static void testEmptySet(Set c) { > @@ -262,6 +263,16 @@ public class LockStep { > } > } > > + static void equalIterators(final Iterator it1, > + final Iterator it2) { > + while (it1.hasNext()) { > + if (maybe(2)) > + check(it2.hasNext()); > + equal(it1.next(), it2.next()); > + } > + check(! it2.hasNext()); > + } > + > static void equalNavigableSetsLeaf(final NavigableSet s1, > final NavigableSet s2) { > equal2(s1, s2); > @@ -273,6 +284,8 @@ public class LockStep { > equal(s1.first(), s2.first()); > equal(s1.last(), s2.last()); > } > + equalIterators(s1.iterator(), s2.iterator()); > + equalIterators(s1.descendingIterator(), s2.descendingIterator()); > checkNavigableSet(s1); > checkNavigableSet(s2); > } > @@ -493,30 +506,23 @@ public class LockStep { > > static MapFrobber randomAdder(NavigableMap m) { > final Integer k = unusedKey(m); > - MapFrobber f; > - switch (rnd.nextInt(4)) { > - case 0: f = new MapFrobber() {void frob(NavigableMap m) { > - equal(m.put(k, k+1), null); > - equal(m.get(k), k+1); > - if (maybe(4)) { > - equal(m.put(k, k+1), k+1); > - equal(m.get(k), k+1);}}}; > - break; > - case 1: f = new MapFrobber() {void frob(NavigableMap m) { > - m.descendingMap().put(k, k+1); > - equal(m.get(k), k+1);}}; > - break; > - case 2: f = new MapFrobber() {void frob(NavigableMap m) { > - m.tailMap(k,true).headMap(k,true).put(k,k+1);}}; > - break; > - case 3: f = new MapFrobber() {void frob(NavigableMap m) { > - m.tailMap(k,true).headMap(k,true).descendingMap().put(k,k+1);}}; > - break; > - default: throw new Error(); > - } > - final MapFrobber ff = f; > + final MapFrobber[] randomAdders = { > + new MapFrobber() {void frob(NavigableMap m) { > + equal(m.put(k, k+1), null); > + equal(m.get(k), k+1); > + if (maybe(4)) { > + equal(m.put(k, k+1), k+1); > + equal(m.get(k), k+1);}}}, > + new MapFrobber() {void frob(NavigableMap m) { > + m.descendingMap().put(k, k+1); > + equal(m.get(k), k+1);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + m.tailMap(k,true).headMap(k,true).put(k,k+1);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + m.tailMap(k,true).headMap(k,true).descendingMap().put(k,k+1);}} > + }; > return new MapFrobber() {void frob(NavigableMap m) { > - ff.frob(m); > + randomAdders[rnd.nextInt(randomAdders.length)].frob(m); > if (maybe(2)) equal(m.get(k), k+1); > if (maybe(4)) { > equal(m.put(k, k+1), k+1); > @@ -525,26 +531,19 @@ public class LockStep { > > static SetFrobber randomAdder(NavigableSet s) { > final Integer e = unusedElt(s); > - SetFrobber f; > - switch (rnd.nextInt(4)) { > - case 0: f = new SetFrobber() {void frob(NavigableSet s) { > - check(s.add(e));}}; > - break; > - case 1: f = new SetFrobber() {void frob(NavigableSet s) { > - s.descendingSet().add(e);}}; > - break; > - case 2: f = new SetFrobber() {void frob(NavigableSet s) { > - s.tailSet(e,true).headSet(e,true).add(e);}}; > - break; > - case 3: f = new SetFrobber() {void frob(NavigableSet s) { > - s.descendingSet().tailSet(e,true).headSet(e,true).add(e);}}; > - break; > - default: throw new Error(); > - } > - final SetFrobber ff = f; > + final SetFrobber[] randomAdders = { > + new SetFrobber() {void frob(NavigableSet s) { > + check(s.add(e));}}, > + new SetFrobber() {void frob(NavigableSet s) { > + s.descendingSet().add(e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + s.tailSet(e,true).headSet(e,true).add(e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + s.descendingSet().tailSet(e,true).headSet(e,true).add(e);}} > + }; > return new SetFrobber() {void frob(NavigableSet s) { > if (maybe(2)) check(! s.contains(e)); > - ff.frob(s); > + randomAdders[rnd.nextInt(randomAdders.length)].frob(s); > if (maybe(2)) check(! s.add(e)); > if (maybe(2)) check(s.contains(e));}}; > } > @@ -605,89 +604,112 @@ public class LockStep { > > static MapFrobber randomRemover(NavigableMap m) { > final Integer k = usedKey(m); > - switch (rnd.nextInt(7)) { > - default: throw new Error(); > - case 0: return new MapFrobber() {void frob(NavigableMap m) { > - Map.Entry e = m.firstEntry(); > - equal(m.pollFirstEntry(), e); > - checkUnusedKey(m, e.getKey());}}; > - case 1: return new MapFrobber() {void frob(NavigableMap m) { > - Map.Entry e = m.lastEntry(); > - equal(m.pollLastEntry(), e); > - checkUnusedKey(m, e.getKey());}}; > - case 2: return new MapFrobber() {void frob(NavigableMap m) { > - check(m.remove(k) != null); > - checkUnusedKey(m, k);}}; > - case 3: return new MapFrobber() {void frob(NavigableMap m) { > - m.subMap(k, true, k, true).clear(); > - checkUnusedKey(m, k);}}; > - case 4: return new MapFrobber() {void frob(NavigableMap m) { > - m.descendingMap().subMap(k, true, k, true).clear(); > - checkUnusedKey(m, k);}}; > - case 5: return new MapFrobber() {void frob(NavigableMap m) { > - final Iterator it = m.keySet().iterator(); > - while (it.hasNext()) > - if (it.next().equals(k)) { > - it.remove(); > - if (maybe(2)) > - THROWS(IllegalStateException.class, > - new Fun(){void f(){ it.remove(); }}); > - } > - checkUnusedKey(m, k);}}; > - case 6: return new MapFrobber() {void frob(NavigableMap m) { > - final Iterator it = m.entrySet().iterator(); > - while (it.hasNext()) > - if (it.next().getKey().equals(k)) { > - it.remove(); > - if (maybe(2)) > - THROWS(IllegalStateException.class, remover(it)); > - } > - checkUnusedKey(m, k);}}; > - } > + final MapFrobber[] randomRemovers = { > + new MapFrobber() {void frob(NavigableMap m) { > + Map.Entry e = m.firstEntry(); > + equal(m.pollFirstEntry(), e); > + checkUnusedKey(m, e.getKey());}}, > + new MapFrobber() {void frob(NavigableMap m) { > + Map.Entry e = m.lastEntry(); > + equal(m.pollLastEntry(), e); > + checkUnusedKey(m, e.getKey());}}, > + new MapFrobber() {void frob(NavigableMap m) { > + check(m.remove(k) != null); > + checkUnusedKey(m, k);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + m.subMap(k, true, k, true).clear(); > + checkUnusedKey(m, k);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + m.descendingMap().subMap(k, true, k, true).clear(); > + checkUnusedKey(m, k);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + final Iterator it = m.keySet().iterator(); > + while (it.hasNext()) > + if (it.next().equals(k)) { > + it.remove(); > + if (maybe(2)) > + THROWS(IllegalStateException.class, > + new Fun(){void f(){ it.remove(); }}); > + } > + checkUnusedKey(m, k);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + final Iterator it = m.navigableKeySet().descendingIterator(); > + while (it.hasNext()) > + if (it.next().equals(k)) { > + it.remove(); > + if (maybe(2)) > + THROWS(IllegalStateException.class, > + new Fun(){void f(){ it.remove(); }}); > + } > + checkUnusedKey(m, k);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + final Iterator it = m.entrySet().iterator(); > + while (it.hasNext()) > + if (it.next().getKey().equals(k)) { > + it.remove(); > + if (maybe(2)) > + THROWS(IllegalStateException.class, remover(it)); > + } > + checkUnusedKey(m, k);}}, > + }; > + > + return randomRemovers[rnd.nextInt(randomRemovers.length)]; > } > > static SetFrobber randomRemover(NavigableSet s) { > final Integer e = usedElt(s); > - switch (rnd.nextInt(7)) { > - default: throw new Error(); > - case 0: return new SetFrobber() {void frob(NavigableSet s) { > - Object e = s.first(); > - equal(s.pollFirst(), e); > - checkUnusedElt(s, e);}}; > - case 1: return new SetFrobber() {void frob(NavigableSet s) { > - Object e = s.last(); > - equal(s.pollLast(), e); > - checkUnusedElt(s, e);}}; > - case 2: return new SetFrobber() {void frob(NavigableSet s) { > - check(s.remove(e)); > - checkUnusedElt(s, e);}}; > - case 3: return new SetFrobber() {void frob(NavigableSet s) { > - s.subSet(e, true, e, true).clear(); > - checkUnusedElt(s, e);}}; > - case 4: return new SetFrobber() {void frob(NavigableSet s) { > - s.descendingSet().subSet(e, true, e, true).clear(); > - checkUnusedElt(s, e);}}; > - case 5: return new SetFrobber() {void frob(NavigableSet s) { > - final Iterator it = s.iterator(); > - while (it.hasNext()) > - if (it.next().equals(e)) { > - it.remove(); > - if (maybe(2)) > - THROWS(IllegalStateException.class, > - new Fun(){void f(){ it.remove(); }}); > - } > - checkUnusedElt(s, e);}}; > - case 6: return new SetFrobber() {void frob(NavigableSet s) { > - final Iterator it = s.descendingSet().iterator(); > - while (it.hasNext()) > - if (it.next().equals(e)) { > - it.remove(); > - if (maybe(2)) > - THROWS(IllegalStateException.class, > - new Fun(){void f(){ it.remove(); }}); > - } > - checkUnusedElt(s, e);}}; > - } > + > + final SetFrobber[] randomRemovers = { > + new SetFrobber() {void frob(NavigableSet s) { > + Object e = s.first(); > + equal(s.pollFirst(), e); > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + Object e = s.last(); > + equal(s.pollLast(), e); > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + check(s.remove(e)); > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + s.subSet(e, true, e, true).clear(); > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + s.descendingSet().subSet(e, true, e, true).clear(); > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + final Iterator it = s.iterator(); > + while (it.hasNext()) > + if (it.next().equals(e)) { > + it.remove(); > + if (maybe(2)) > + THROWS(IllegalStateException.class, > + new Fun(){void f(){ it.remove(); }}); > + } > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + final Iterator it = s.descendingSet().iterator(); > + while (it.hasNext()) > + if (it.next().equals(e)) { > + it.remove(); > + if (maybe(2)) > + THROWS(IllegalStateException.class, > + new Fun(){void f(){ it.remove(); }}); > + } > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + final Iterator it = s.descendingIterator(); > + while (it.hasNext()) > + if (it.next().equals(e)) { > + it.remove(); > + if (maybe(2)) > + THROWS(IllegalStateException.class, > + new Fun(){void f(){ it.remove(); }}); > + } > + checkUnusedElt(s, e);}} > + }; > + > + return randomRemovers[rnd.nextInt(randomRemovers.length)]; > } > > static void lockStep(NavigableMap m1, > > > Martin > > On Sat, Apr 19, 2008 at 2:07 PM, charlie hunt wrote: >> Alan Bateman wrote: >> >>> Martin Buchholz wrote: >>> >>>> : >>>> >>>> 2. Bug creation from Charlie (or some other person empowered to do so) >>>> I suggest making this bug P2-S2. >>>> >>>> I will need the bug id and synopsis to create the proper mercurial >> comment. >>>> >>> I don't know if Charlie is online today, but as you seem to be ready to >> create the change-set, I've created java/classes_util bug: >>> 6691185: (coll) TreeMap.navigableKeySet's descendingIterator method >> starts at first instead of last entry >>> with a link to this thread. The synopsis can be changed if you want >> something different. >>> -Alan. >>> >> Alan, thanks for filing the bug. One less item on my list of things to do. >> :-) >> >> Fwiw, I've looked at Martin's proposed changes. From the familiarity I've >> gotten with TreeMap over the past week or two, the changes look good to me. >> >> charlie ... >> >> >> From Alan.Bateman at Sun.COM Sun Apr 20 10:07:36 2008 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Sun, 20 Apr 2008 11:07:36 +0100 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <17b2302a0804200026j27bef26fsa17471fe9e5c3088@mail.gmail.com> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> <480A0BE2.4070209@cs.oswego.edu> <1ccfd1c10804190854m3790e07cub7ca988c7286f54d@mail.gmail.com> <1ccfd1c10804191153v2be0fe87tc7388f07d52eec6b@mail.gmail.com> <480A5564.4010405@sun.com> <480A5EFE.5090005@sun.com> <1ccfd1c10804191756y3f6186f8h59cb0d779862a695@mail.gmail.com> <17b2302a0804200007g17a194aaofbf0eb001f4fc403@mail.gmail.com> <17b2302a0804200026j27bef26fsa17471fe9e5c3088@mail.gmail.com> Message-ID: <480B15E8.8000508@sun.com> Joshua Bloch wrote: > > Folks, > > While we're at it, here's another Collections bug discovered recently > by a Googler (Scott Blum). The value of this expression should be false: > > new IdentityHashMap().containsValue(null) > > Unfortunately, it's true. Looking at the code for containsValue, it's > obvious what's wrong: > > /** > * Tests whether the specified object reference is a value in this > identity > * hash map. > * > * @param value value whose presence in this map is to be tested > * @return true if this map maps one or more keys to the > * specified object reference > * @see #containsKey(Object) > */ > public boolean containsValue(Object value) { > Object[] tab = table; > for (int i = 1; i < tab.length; i+= 2) > if (tab[i] == value) > return true; > > return false; > } > > Empty entries are masquerading as entries mapping to null. The fix is > easy: > > if (tab[i] == value) > > becomes: > > if (tab[i] == value && tab[i -1] != null) > > (Recall that the null key (but not value) is proxied by NULL_KEY.) > > Josh > I don't see this in the bug database so I've created the following so that it doesn't get lost: 6691215: (coll) IdentityHashMap.containsValue(null) returns true when null value not present -Alan. From martinrb at google.com Sun Apr 20 17:46:10 2008 From: martinrb at google.com (Martin Buchholz) Date: Sun, 20 Apr 2008 10:46:10 -0700 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <480B11D7.3000706@sun.com> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> <480A0BE2.4070209@cs.oswego.edu> <1ccfd1c10804190854m3790e07cub7ca988c7286f54d@mail.gmail.com> <1ccfd1c10804191153v2be0fe87tc7388f07d52eec6b@mail.gmail.com> <480A5564.4010405@sun.com> <480A5EFE.5090005@sun.com> <1ccfd1c10804191756y3f6186f8h59cb0d779862a695@mail.gmail.com> <480B11D7.3000706@sun.com> Message-ID: <1ccfd1c10804201046i4db6c843qcd581d29902f33ca@mail.gmail.com> On Sun, Apr 20, 2008 at 2:50 AM, Christopher Hegarty - Sun Microsystems Ireland wrote: > Hi Martin, > > I (OpenJDK user chegar) approve the changes that you made to: > > src/share/classes/java/util/TreeMap.java > test/java/util/Collection/MOAT.java > test/java/util/NavigableMap/LockStep.java Thanks, Chris. > The only comment I have is that you may want to add the bug number, CR > 6691185, to the @bug tag in the testcases. Quite right. Updated. Do you still have integration > access? Yes, in theory. We'll see how it works in practice. > I can take care of the JDK 6 integration. Thanks. Martin From martinrb at google.com Sun Apr 20 23:35:45 2008 From: martinrb at google.com (Martin Buchholz) Date: Sun, 20 Apr 2008 16:35:45 -0700 Subject: 6691215: (coll) IdentityHashMap.containsValue(null) returns true when null value not present Message-ID: <1ccfd1c10804201635hd266fd3y2fdbf5de50d9518a@mail.gmail.com> It's a little disconcerting to still keep finding basic correctness bugs in core Collections classes. Here's a fix (again demonstrating that the Mother Of All Collections Tests is not thorough enough): Review requested from Chris Hegarty, Doug Lea # HG changeset patch # User martin # Date 1208733844 25200 # Node ID fd80580439549ed34473cfa973f34d29f9efd7a6 # Parent 8513593a57f180641d06cf535f1647cb9160f9e0 6691215: (coll) IdentityHashMap.containsValue(null) returns true when null value not present Reviewed-by: Contributed-by: Scott Blum diff --git a/src/share/classes/java/util/IdentityHashMap.java b/src/share/classes/java/util/IdentityHashMap.java --- a/src/share/classes/java/util/IdentityHashMap.java +++ b/src/share/classes/java/util/IdentityHashMap.java @@ -188,7 +188,6 @@ public class IdentityHashMap /** * Use NULL_KEY for key if it is null. */ - private static Object maskNull(Object key) { return (key == null ? NULL_KEY : key); } @@ -378,8 +377,8 @@ public class IdentityHashMap */ public boolean containsValue(Object value) { Object[] tab = table; - for (int i = 1; i < tab.length; i+= 2) - if (tab[i] == value) + for (int i = 1; i < tab.length; i += 2) + if (tab[i] == value && tab[i - 1] != null) return true; return false; @@ -905,7 +904,6 @@ public class IdentityHashMap * view the first time this view is requested. The view is stateless, * so there's no reason to create more than one. */ - private transient Set> entrySet = null; /** diff --git a/test/java/util/Collection/MOAT.java b/test/java/util/Collection/MOAT.java --- a/test/java/util/Collection/MOAT.java +++ b/test/java/util/Collection/MOAT.java @@ -25,7 +25,7 @@ * @test * @bug 6207984 6272521 6192552 6269713 6197726 6260652 5073546 4137464 * 4155650 4216399 4294891 6282555 6318622 6355327 6383475 6420753 - * 6431845 4802633 6570566 6570575 6570631 6570924 6691185 + * 6431845 4802633 6570566 6570575 6570631 6570924 6691185 6691215 * @summary Run many tests on many Collection and Map implementations * @author Martin Buchholz */ @@ -247,6 +247,13 @@ public class MOAT { testEmptySet(m.keySet()); testEmptySet(m.entrySet()); testEmptyCollection(m.values()); + + try { check(! m.containsValue(null)); } + catch (NullPointerException _) { /* OK */ } + try { check(! m.containsKey(null)); } + catch (NullPointerException _) { /* OK */ } + check(! m.containsValue(1)); + check(! m.containsKey(1)); } private static void testImmutableMap(final Map m) { Martin On Sun, Apr 20, 2008 at 3:07 AM, Alan Bateman wrote: > Joshua Bloch wrote: > > > > > Folks, > > > > While we're at it, here's another Collections bug discovered recently by a > Googler (Scott Blum). The value of this expression should be false: > > > > new IdentityHashMap().containsValue(null) > > > > Unfortunately, it's true. Looking at the code for containsValue, it's > obvious what's wrong: > > > > /** > > * Tests whether the specified object reference is a value in this > identity > > * hash map. > > * > > * @param value value whose presence in this map is to be tested > > * @return true if this map maps one or more keys to the > > * specified object reference > > * @see #containsKey(Object) > > */ > > public boolean containsValue(Object value) { > > Object[] tab = table; > > for (int i = 1; i < tab.length; i+= 2) > > if (tab[i] == value) > > return true; > > > > return false; > > } > > > > Empty entries are masquerading as entries mapping to null. The fix is > easy: > > > > if (tab[i] == value) > > > > becomes: > > > > if (tab[i] == value && tab[i -1] != null) > > > > (Recall that the null key (but not value) is proxied by NULL_KEY.) > > > > Josh > > > > > I don't see this in the bug database so I've created the following so that > it doesn't get lost: > 6691215: (coll) IdentityHashMap.containsValue(null) returns true when null > value not present > > -Alan. > From dl at cs.oswego.edu Mon Apr 21 11:00:25 2008 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 21 Apr 2008 07:00:25 -0400 Subject: 6691215: (coll) IdentityHashMap.containsValue(null) returns true when null value not present In-Reply-To: <1ccfd1c10804201635hd266fd3y2fdbf5de50d9518a@mail.gmail.com> References: <1ccfd1c10804201635hd266fd3y2fdbf5de50d9518a@mail.gmail.com> Message-ID: <480C73C9.3050604@cs.oswego.edu> Martin Buchholz wrote: > It's a little disconcerting to still keep finding basic correctness bugs in > core Collections classes. > > Here's a fix (again demonstrating that the Mother Of All Collections Tests > is not thorough enough): Further aside: MOAT ought to be rolled into TCK someday. It solely covers basic specified functionality. > > Review requested from Chris Hegarty, Doug Lea Yes, this looks OK to me. > > # HG changeset patch > # User martin > # Date 1208733844 25200 > # Node ID fd80580439549ed34473cfa973f34d29f9efd7a6 > # Parent 8513593a57f180641d06cf535f1647cb9160f9e0 > 6691215: (coll) IdentityHashMap.containsValue(null) returns true when > null value not present > Reviewed-by: > Contributed-by: Scott Blum > > diff --git a/src/share/classes/java/util/IdentityHashMap.java > b/src/share/classes/java/util/IdentityHashMap.java > --- a/src/share/classes/java/util/IdentityHashMap.java > +++ b/src/share/classes/java/util/IdentityHashMap.java > @@ -188,7 +188,6 @@ public class IdentityHashMap > /** > * Use NULL_KEY for key if it is null. > */ > - > private static Object maskNull(Object key) { > return (key == null ? NULL_KEY : key); > } > @@ -378,8 +377,8 @@ public class IdentityHashMap > */ > public boolean containsValue(Object value) { > Object[] tab = table; > - for (int i = 1; i < tab.length; i+= 2) > - if (tab[i] == value) > + for (int i = 1; i < tab.length; i += 2) > + if (tab[i] == value && tab[i - 1] != null) > return true; > > return false; > @@ -905,7 +904,6 @@ public class IdentityHashMap > * view the first time this view is requested. The view is stateless, > * so there's no reason to create more than one. > */ > - > private transient Set> entrySet = null; > > /** > diff --git a/test/java/util/Collection/MOAT.java > b/test/java/util/Collection/MOAT.java > --- a/test/java/util/Collection/MOAT.java > +++ b/test/java/util/Collection/MOAT.java > @@ -25,7 +25,7 @@ > * @test > * @bug 6207984 6272521 6192552 6269713 6197726 6260652 5073546 4137464 > * 4155650 4216399 4294891 6282555 6318622 6355327 6383475 6420753 > - * 6431845 4802633 6570566 6570575 6570631 6570924 6691185 > + * 6431845 4802633 6570566 6570575 6570631 6570924 6691185 6691215 > * @summary Run many tests on many Collection and Map implementations > * @author Martin Buchholz > */ > @@ -247,6 +247,13 @@ public class MOAT { > testEmptySet(m.keySet()); > testEmptySet(m.entrySet()); > testEmptyCollection(m.values()); > + > + try { check(! m.containsValue(null)); } > + catch (NullPointerException _) { /* OK */ } > + try { check(! m.containsKey(null)); } > + catch (NullPointerException _) { /* OK */ } > + check(! m.containsValue(1)); > + check(! m.containsKey(1)); > } > > private static void testImmutableMap(final Map m) { > > Martin > > On Sun, Apr 20, 2008 at 3:07 AM, Alan Bateman wrote: >> Joshua Bloch wrote: >> >>> Folks, >>> >>> While we're at it, here's another Collections bug discovered recently by a >> Googler (Scott Blum). The value of this expression should be false: >>> new IdentityHashMap().containsValue(null) >>> >>> Unfortunately, it's true. Looking at the code for containsValue, it's >> obvious what's wrong: >>> /** >>> * Tests whether the specified object reference is a value in this >> identity >>> * hash map. >>> * >>> * @param value value whose presence in this map is to be tested >>> * @return true if this map maps one or more keys to the >>> * specified object reference >>> * @see #containsKey(Object) >>> */ >>> public boolean containsValue(Object value) { >>> Object[] tab = table; >>> for (int i = 1; i < tab.length; i+= 2) >>> if (tab[i] == value) >>> return true; >>> >>> return false; >>> } >>> >>> Empty entries are masquerading as entries mapping to null. The fix is >> easy: >>> if (tab[i] == value) >>> >>> becomes: >>> >>> if (tab[i] == value && tab[i -1] != null) >>> >>> (Recall that the null key (but not value) is proxied by NULL_KEY.) >>> >>> Josh >>> >>> >> I don't see this in the bug database so I've created the following so that >> it doesn't get lost: >> 6691215: (coll) IdentityHashMap.containsValue(null) returns true when null >> value not present >> >> -Alan. >> > From forax at univ-mlv.fr Mon Apr 21 12:39:40 2008 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 21 Apr 2008 14:39:40 +0200 Subject: sun.reflect.generics.* Message-ID: <480C8B0C.5000304@univ-mlv.fr> Hi all, Is someone knows why package sun.reflect.generics is so complex ? This package (and subpackage) it used to reify a generics signatures to a java.lang.reflect.Type tree. It creates a parser, parse the signature to create an AST, and use a visitor to create the tree. This package, contains in my opinion, lot of unecessary garbage. - It creates an AST even if the Type tree can be created in one pass. - A bunch of interfaces has only one implementation like Visitor. - Use a visitor even if there is only one operation. - Use lots of generics can be removed because only one instanciation is used. cheers, R?mi From martinrb at google.com Mon Apr 21 12:43:14 2008 From: martinrb at google.com (Martin Buchholz) Date: Mon, 21 Apr 2008 05:43:14 -0700 Subject: 6691215: (coll) IdentityHashMap.containsValue(null) returns true when null value not present In-Reply-To: <480C73C9.3050604@cs.oswego.edu> References: <1ccfd1c10804201635hd266fd3y2fdbf5de50d9518a@mail.gmail.com> <480C73C9.3050604@cs.oswego.edu> Message-ID: <1ccfd1c10804210543x52f80dcbqff166032d8fd610c@mail.gmail.com> [+dmitry.miltsov] On Mon, Apr 21, 2008 at 4:00 AM, Doug Lea
wrote: > Martin Buchholz wrote: > > > It's a little disconcerting to still keep finding basic correctness bugs > in > > core Collections classes. > > > > Here's a fix (again demonstrating that the Mother Of All Collections Tests > > is not thorough enough): > > > > Further aside: MOAT ought to be rolled into TCK someday. > It solely covers basic specified functionality. Yes, but.... This kind of cooperation has been inhibited in the past by geographic, organizational, and cultural divides between the TCK and JDK engineering teams. Dmitry, consider adding yourself to core-libs-dev and perhaps other relevant OpenJDK mailing lists. One cultural impediment appears to be the practice of dividing the functionality to be tested by class and method, making the testing effort for collection classes of order C*M, while MOAT's approach aims for an engineering effort of C+M. I'm sure we can find more bugs by extending MOAT to test more collection class implementations and more operations. Perhaps some refactoring to allow MOAT to be used to test 3rd party implementations? There's a career path in there somewhere. Martin > > > > > > Review requested from Chris Hegarty, Doug Lea > > > > Yes, this looks OK to me. > > > > > > > > # HG changeset patch > > # User martin > > # Date 1208733844 25200 > > # Node ID fd80580439549ed34473cfa973f34d29f9efd7a6 > > # Parent 8513593a57f180641d06cf535f1647cb9160f9e0 > > 6691215: (coll) IdentityHashMap.containsValue(null) returns true when > > null value not present > > Reviewed-by: > > Contributed-by: Scott Blum > > > > diff --git a/src/share/classes/java/util/IdentityHashMap.java > > b/src/share/classes/java/util/IdentityHashMap.java > > --- a/src/share/classes/java/util/IdentityHashMap.java > > +++ b/src/share/classes/java/util/IdentityHashMap.java > > @@ -188,7 +188,6 @@ public class IdentityHashMap > > /** > > * Use NULL_KEY for key if it is null. > > */ > > - > > private static Object maskNull(Object key) { > > return (key == null ? NULL_KEY : key); > > } > > @@ -378,8 +377,8 @@ public class IdentityHashMap > > */ > > public boolean containsValue(Object value) { > > Object[] tab = table; > > - for (int i = 1; i < tab.length; i+= 2) > > - if (tab[i] == value) > > + for (int i = 1; i < tab.length; i += 2) > > + if (tab[i] == value && tab[i - 1] != null) > > return true; > > > > return false; > > @@ -905,7 +904,6 @@ public class IdentityHashMap > > * view the first time this view is requested. The view is stateless, > > * so there's no reason to create more than one. > > */ > > - > > private transient Set> entrySet = null; > > > > /** > > diff --git a/test/java/util/Collection/MOAT.java > > b/test/java/util/Collection/MOAT.java > > --- a/test/java/util/Collection/MOAT.java > > +++ b/test/java/util/Collection/MOAT.java > > @@ -25,7 +25,7 @@ > > * @test > > * @bug 6207984 6272521 6192552 6269713 6197726 6260652 5073546 > 4137464 > > * 4155650 4216399 4294891 6282555 6318622 6355327 6383475 > 6420753 > > - * 6431845 4802633 6570566 6570575 6570631 6570924 6691185 > > + * 6431845 4802633 6570566 6570575 6570631 6570924 6691185 > 6691215 > > * @summary Run many tests on many Collection and Map implementations > > * @author Martin Buchholz > > */ > > @@ -247,6 +247,13 @@ public class MOAT { > > testEmptySet(m.keySet()); > > testEmptySet(m.entrySet()); > > testEmptyCollection(m.values()); > > + > > + try { check(! m.containsValue(null)); } > > + catch (NullPointerException _) { /* OK */ } > > + try { check(! m.containsKey(null)); } > > + catch (NullPointerException _) { /* OK */ } > > + check(! m.containsValue(1)); > > + check(! m.containsKey(1)); > > } > > > > private static void testImmutableMap(final Map m) { > > > > Martin > > > > On Sun, Apr 20, 2008 at 3:07 AM, Alan Bateman > wrote: > > > > > Joshua Bloch wrote: > > > > > > > > > > Folks, > > > > > > > > While we're at it, here's another Collections bug discovered recently > by a > > > > > > > Googler (Scott Blum). The value of this expression should be false: > > > > > > > new IdentityHashMap().containsValue(null) > > > > > > > > Unfortunately, it's true. Looking at the code for containsValue, it's > > > > > > > obvious what's wrong: > > > > > > > /** > > > > * Tests whether the specified object reference is a value in this > > > > > > > identity > > > > > > > * hash map. > > > > * > > > > * @param value value whose presence in this map is to be tested > > > > * @return true if this map maps one or more keys to the > > > > * specified object reference > > > > * @see #containsKey(Object) > > > > */ > > > > public boolean containsValue(Object value) { > > > > Object[] tab = table; > > > > for (int i = 1; i < tab.length; i+= 2) > > > > if (tab[i] == value) > > > > return true; > > > > > > > > return false; > > > > } > > > > > > > > Empty entries are masquerading as entries mapping to null. The fix is > > > > > > > easy: > > > > > > > if (tab[i] == value) > > > > > > > > becomes: > > > > > > > > if (tab[i] == value && tab[i -1] != null) > > > > > > > > (Recall that the null key (but not value) is proxied by NULL_KEY.) > > > > > > > > Josh > > > > > > > > > > > > > > > I don't see this in the bug database so I've created the following so > that > > > it doesn't get lost: > > > 6691215: (coll) IdentityHashMap.containsValue(null) returns true when > null > > > value not present > > > > > > -Alan. > > > > > > > > > > > > From charlie.hunt at sun.com Sat Apr 19 11:45:45 2008 From: charlie.hunt at sun.com (charlie hunt) Date: Sat, 19 Apr 2008 06:45:45 -0500 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> Message-ID: <4809DB69.4030706@sun.com> I'll file a bug. I'll also suggest in the bug report additional tests be added to MOAT.java. You are right, there are very many Navigable* interface methods ("very many" doesn't seem to do justice to describe the number of methods). TreeMap is rather complex beast! It's complexity really increased between Java 5 and Java 6. In looking at TreeMap closely over the last week, writing a complete suite of tests for TreeMap would be lengthy and difficult task. It's easy to see how this bug could have slipped through. Looks like the fix is changing TreeMap line 1024, from "return DescendingKeyIterator(getFirstEntry())" to "return DescendingKeyIterator(getLastEntry())". thanks, charlie ... Martin Buchholz wrote: > Yes, sad to say, looks like a serious and embarrassing bug. > This bit of code has no existing test case. > More tests should be added to MOAT.java. > Charlie, please file a bug. > > In our defense, there are very many methods in the NavigableFoo > interfaces, > and for completeness they have to be tested on subsets and submaps, > and Sun engineers have not historically had good code coverage tool > support. > > Martin > > On Fri, Apr 18, 2008 at 2:39 PM, kevin bourrillion > wrote: > > Wow. TreeMap.java line 1024: > > return new DescendingKeyIterator(getFirstEntry()); > > Sure does look fishy. > > > > On Thu, Apr 17, 2008 at 2:54 PM, charlie hunt > > wrote: > > Been looking at TreeMap's implementation rather closely and observed > > something I don't understand. %-) > > > > TreeMap (as of JDK 6 and later) implements NavigableMap. > NavigableMap > > requires an implementation of a navigableKeySet() method which > returns a > > NavigableSet. So, in TreeMap I see: > > > > public NavigableSet navigableKeySet() > > > > Then, the NavigableSet interface has an Iterator > descendingIterator() > > and Iteratoriterator(). The former returns an iterator over > the elements > > in descending order. The latter in ascending order. > > > > I also noticed in TreeMap, NavigableMap requires an > implementation of a > > descendingKeySet(), i.e. public NavigableSet > descendingKeySet(). Again, > > the NavigableSet interface has an Iterator > descendingIterator() and > > iterator() as described above. > > > > When I populate a TreeMap with some dummy data, let's say I > populate it > > with 15 Integer keys and String's representing those Integer > keys as values, > > I observe something I don't understand when using the > > navigableKeySet().descendingIterator(). > > > > When, I try to iterate over the returned NavigableKeySet, I see > the lowest > > key printed and that's it. Nothing else prints. From looking at > the JavaDoc > > for TreeMap and NavigableSet, this doesn't seem right. > Shouldn't it iterate > > over the entire set in descending order? I looked at the source > and it > > creates an Iterator that starts at the lowest key and then tries > to find the > > next lowest key (which obviously doesn't exist). Am I not > reading something > > right in the JavaDoc? > > > > When iterating using navigableKeySet().iterator() I see all 15 > keys printed > > in ascending order, (as expected). > > > > When I iterate with descendingKeySet().descendingIterator() I > see the 15 > > keys printed in ascending order, (as expected since descending > set followed > > by a descending iterator should give me ascending order). > > > > When iterating using descendingKeySet().iterator, I see the 15 > keys printed > > in descending order, (as expected). > > > > I've attached a very simple program that illustrates what I'm > describing. > > > > Could someone clarify this behavior? > > > > thanks, > > > > charlie ... > > > > > > > > -- > Kevin Bourrillion @ Google > internal: go/javalibraries > google-collections.googlecode.com > > google-guice.googlecode.com > > -- Charlie Hunt Java Performance Engineer From charlie.hunt at sun.com Sat Apr 19 21:07:10 2008 From: charlie.hunt at sun.com (charlie hunt) Date: Sat, 19 Apr 2008 16:07:10 -0500 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <480A5564.4010405@sun.com> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> <480A0BE2.4070209@cs.oswego.edu> <1ccfd1c10804190854m3790e07cub7ca988c7286f54d@mail.gmail.com> <1ccfd1c10804191153v2be0fe87tc7388f07d52eec6b@mail.gmail.com> <480A5564.4010405@sun.com> Message-ID: <480A5EFE.5090005@sun.com> Alan Bateman wrote: > Martin Buchholz wrote: >> : >> >> 2. Bug creation from Charlie (or some other person empowered to do so) >> I suggest making this bug P2-S2. >> >> I will need the bug id and synopsis to create the proper mercurial >> comment. >> > I don't know if Charlie is online today, but as you seem to be ready > to create the change-set, I've created java/classes_util bug: > > 6691185: (coll) TreeMap.navigableKeySet's descendingIterator method > starts at first instead of last entry > > with a link to this thread. The synopsis can be changed if you want > something different. > > -Alan. Alan, thanks for filing the bug. One less item on my list of things to do. :-) Fwiw, I've looked at Martin's proposed changes. From the familiarity I've gotten with TreeMap over the past week or two, the changes look good to me. charlie ... From jjb at google.com Sun Apr 20 07:07:03 2008 From: jjb at google.com (Joshua Bloch) Date: Sun, 20 Apr 2008 00:07:03 -0700 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <1ccfd1c10804191756y3f6186f8h59cb0d779862a695@mail.gmail.com> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> <480A0BE2.4070209@cs.oswego.edu> <1ccfd1c10804190854m3790e07cub7ca988c7286f54d@mail.gmail.com> <1ccfd1c10804191153v2be0fe87tc7388f07d52eec6b@mail.gmail.com> <480A5564.4010405@sun.com> <480A5EFE.5090005@sun.com> <1ccfd1c10804191756y3f6186f8h59cb0d779862a695@mail.gmail.com> Message-ID: <17b2302a0804200007g17a194aaofbf0eb001f4fc403@mail.gmail.com> FWIW, I probably wrote the broken code. I wrote NavigableMap and retrofitted TreeMap. Doug wrote ConcurrentSkipListMap. Sorry 'bout that. Josh On Sat, Apr 19, 2008 at 5:56 PM, Martin Buchholz wrote: > Alan, thanks for filing the bug. > > Charlie, thanks for the review. However, since you are not (yet?) > an OpenJDK committer, I will still need an official review from Doug > (or Alan?) > > I noticed there was another test case, NavigableMap/LockStep.java, > that "almost" tested the faulty code. > > I include a change to that test case as well, below > (as well as making the test case a little more maintainble). > > diff --git a/test/java/util/NavigableMap/LockStep.java > b/test/java/util/NavigableMap/LockStep.java > --- a/test/java/util/NavigableMap/LockStep.java > +++ b/test/java/util/NavigableMap/LockStep.java > @@ -159,6 +159,7 @@ public class LockStep { > Object[] a = new Object[1]; a[0] = Boolean.TRUE; > equal(c.toArray(a), a); > equal(a[0], null); > + check(! c.iterator().hasNext()); > } > > static void testEmptySet(Set c) { > @@ -262,6 +263,16 @@ public class LockStep { > } > } > > + static void equalIterators(final Iterator it1, > + final Iterator it2) { > + while (it1.hasNext()) { > + if (maybe(2)) > + check(it2.hasNext()); > + equal(it1.next(), it2.next()); > + } > + check(! it2.hasNext()); > + } > + > static void equalNavigableSetsLeaf(final NavigableSet s1, > final NavigableSet s2) { > equal2(s1, s2); > @@ -273,6 +284,8 @@ public class LockStep { > equal(s1.first(), s2.first()); > equal(s1.last(), s2.last()); > } > + equalIterators(s1.iterator(), s2.iterator()); > + equalIterators(s1.descendingIterator(), s2.descendingIterator()); > checkNavigableSet(s1); > checkNavigableSet(s2); > } > @@ -493,30 +506,23 @@ public class LockStep { > > static MapFrobber randomAdder(NavigableMap m) { > final Integer k = unusedKey(m); > - MapFrobber f; > - switch (rnd.nextInt(4)) { > - case 0: f = new MapFrobber() {void frob(NavigableMap m) { > - equal(m.put(k, k+1), null); > - equal(m.get(k), k+1); > - if (maybe(4)) { > - equal(m.put(k, k+1), k+1); > - equal(m.get(k), k+1);}}}; > - break; > - case 1: f = new MapFrobber() {void frob(NavigableMap m) { > - m.descendingMap().put(k, k+1); > - equal(m.get(k), k+1);}}; > - break; > - case 2: f = new MapFrobber() {void frob(NavigableMap m) { > - m.tailMap(k,true).headMap(k,true).put(k,k+1);}}; > - break; > - case 3: f = new MapFrobber() {void frob(NavigableMap m) { > - > m.tailMap(k,true).headMap(k,true).descendingMap().put(k,k+1);}}; > - break; > - default: throw new Error(); > - } > - final MapFrobber ff = f; > + final MapFrobber[] randomAdders = { > + new MapFrobber() {void frob(NavigableMap m) { > + equal(m.put(k, k+1), null); > + equal(m.get(k), k+1); > + if (maybe(4)) { > + equal(m.put(k, k+1), k+1); > + equal(m.get(k), k+1);}}}, > + new MapFrobber() {void frob(NavigableMap m) { > + m.descendingMap().put(k, k+1); > + equal(m.get(k), k+1);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + m.tailMap(k,true).headMap(k,true).put(k,k+1);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + > m.tailMap(k,true).headMap(k,true).descendingMap().put(k,k+1);}} > + }; > return new MapFrobber() {void frob(NavigableMap m) { > - ff.frob(m); > + randomAdders[rnd.nextInt(randomAdders.length)].frob(m); > if (maybe(2)) equal(m.get(k), k+1); > if (maybe(4)) { > equal(m.put(k, k+1), k+1); > @@ -525,26 +531,19 @@ public class LockStep { > > static SetFrobber randomAdder(NavigableSet s) { > final Integer e = unusedElt(s); > - SetFrobber f; > - switch (rnd.nextInt(4)) { > - case 0: f = new SetFrobber() {void frob(NavigableSet s) { > - check(s.add(e));}}; > - break; > - case 1: f = new SetFrobber() {void frob(NavigableSet s) { > - s.descendingSet().add(e);}}; > - break; > - case 2: f = new SetFrobber() {void frob(NavigableSet s) { > - s.tailSet(e,true).headSet(e,true).add(e);}}; > - break; > - case 3: f = new SetFrobber() {void frob(NavigableSet s) { > - s.descendingSet().tailSet(e,true).headSet(e,true).add(e);}}; > - break; > - default: throw new Error(); > - } > - final SetFrobber ff = f; > + final SetFrobber[] randomAdders = { > + new SetFrobber() {void frob(NavigableSet s) { > + check(s.add(e));}}, > + new SetFrobber() {void frob(NavigableSet s) { > + s.descendingSet().add(e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + s.tailSet(e,true).headSet(e,true).add(e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + > s.descendingSet().tailSet(e,true).headSet(e,true).add(e);}} > + }; > return new SetFrobber() {void frob(NavigableSet s) { > if (maybe(2)) check(! s.contains(e)); > - ff.frob(s); > + randomAdders[rnd.nextInt(randomAdders.length)].frob(s); > if (maybe(2)) check(! s.add(e)); > if (maybe(2)) check(s.contains(e));}}; > } > @@ -605,89 +604,112 @@ public class LockStep { > > static MapFrobber randomRemover(NavigableMap m) { > final Integer k = usedKey(m); > - switch (rnd.nextInt(7)) { > - default: throw new Error(); > - case 0: return new MapFrobber() {void frob(NavigableMap m) { > - Map.Entry e = m.firstEntry(); > - equal(m.pollFirstEntry(), e); > - checkUnusedKey(m, e.getKey());}}; > - case 1: return new MapFrobber() {void frob(NavigableMap m) { > - Map.Entry e = m.lastEntry(); > - equal(m.pollLastEntry(), e); > - checkUnusedKey(m, e.getKey());}}; > - case 2: return new MapFrobber() {void frob(NavigableMap m) { > - check(m.remove(k) != null); > - checkUnusedKey(m, k);}}; > - case 3: return new MapFrobber() {void frob(NavigableMap m) { > - m.subMap(k, true, k, true).clear(); > - checkUnusedKey(m, k);}}; > - case 4: return new MapFrobber() {void frob(NavigableMap m) { > - m.descendingMap().subMap(k, true, k, true).clear(); > - checkUnusedKey(m, k);}}; > - case 5: return new MapFrobber() {void frob(NavigableMap m) { > - final Iterator it = m.keySet().iterator(); > - while (it.hasNext()) > - if (it.next().equals(k)) { > - it.remove(); > - if (maybe(2)) > - THROWS(IllegalStateException.class, > - new Fun(){void f(){ it.remove(); }}); > - } > - checkUnusedKey(m, k);}}; > - case 6: return new MapFrobber() {void frob(NavigableMap m) { > - final Iterator it = m.entrySet().iterator(); > - while (it.hasNext()) > - if (it.next().getKey().equals(k)) { > - it.remove(); > - if (maybe(2)) > - THROWS(IllegalStateException.class, remover(it)); > - } > - checkUnusedKey(m, k);}}; > - } > + final MapFrobber[] randomRemovers = { > + new MapFrobber() {void frob(NavigableMap m) { > + Map.Entry e = m.firstEntry(); > + equal(m.pollFirstEntry(), e); > + checkUnusedKey(m, e.getKey());}}, > + new MapFrobber() {void frob(NavigableMap m) { > + Map.Entry e = m.lastEntry(); > + equal(m.pollLastEntry(), e); > + checkUnusedKey(m, e.getKey());}}, > + new MapFrobber() {void frob(NavigableMap m) { > + check(m.remove(k) != null); > + checkUnusedKey(m, k);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + m.subMap(k, true, k, true).clear(); > + checkUnusedKey(m, k);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + m.descendingMap().subMap(k, true, k, true).clear(); > + checkUnusedKey(m, k);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + final Iterator it = m.keySet().iterator(); > + while (it.hasNext()) > + if (it.next().equals(k)) { > + it.remove(); > + if (maybe(2)) > + THROWS(IllegalStateException.class, > + new Fun(){void f(){ it.remove(); }}); > + } > + checkUnusedKey(m, k);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + final Iterator it = > m.navigableKeySet().descendingIterator(); > + while (it.hasNext()) > + if (it.next().equals(k)) { > + it.remove(); > + if (maybe(2)) > + THROWS(IllegalStateException.class, > + new Fun(){void f(){ it.remove(); }}); > + } > + checkUnusedKey(m, k);}}, > + new MapFrobber() {void frob(NavigableMap m) { > + final Iterator it = m.entrySet().iterator(); > + while (it.hasNext()) > + if (it.next().getKey().equals(k)) { > + it.remove(); > + if (maybe(2)) > + THROWS(IllegalStateException.class, > remover(it)); > + } > + checkUnusedKey(m, k);}}, > + }; > + > + return randomRemovers[rnd.nextInt(randomRemovers.length)]; > } > > static SetFrobber randomRemover(NavigableSet s) { > final Integer e = usedElt(s); > - switch (rnd.nextInt(7)) { > - default: throw new Error(); > - case 0: return new SetFrobber() {void frob(NavigableSet s) { > - Object e = s.first(); > - equal(s.pollFirst(), e); > - checkUnusedElt(s, e);}}; > - case 1: return new SetFrobber() {void frob(NavigableSet s) { > - Object e = s.last(); > - equal(s.pollLast(), e); > - checkUnusedElt(s, e);}}; > - case 2: return new SetFrobber() {void frob(NavigableSet s) { > - check(s.remove(e)); > - checkUnusedElt(s, e);}}; > - case 3: return new SetFrobber() {void frob(NavigableSet s) { > - s.subSet(e, true, e, true).clear(); > - checkUnusedElt(s, e);}}; > - case 4: return new SetFrobber() {void frob(NavigableSet s) { > - s.descendingSet().subSet(e, true, e, true).clear(); > - checkUnusedElt(s, e);}}; > - case 5: return new SetFrobber() {void frob(NavigableSet s) { > - final Iterator it = s.iterator(); > - while (it.hasNext()) > - if (it.next().equals(e)) { > - it.remove(); > - if (maybe(2)) > - THROWS(IllegalStateException.class, > - new Fun(){void f(){ it.remove(); }}); > - } > - checkUnusedElt(s, e);}}; > - case 6: return new SetFrobber() {void frob(NavigableSet s) { > - final Iterator it = s.descendingSet().iterator(); > - while (it.hasNext()) > - if (it.next().equals(e)) { > - it.remove(); > - if (maybe(2)) > - THROWS(IllegalStateException.class, > - new Fun(){void f(){ it.remove(); }}); > - } > - checkUnusedElt(s, e);}}; > - } > + > + final SetFrobber[] randomRemovers = { > + new SetFrobber() {void frob(NavigableSet s) { > + Object e = s.first(); > + equal(s.pollFirst(), e); > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + Object e = s.last(); > + equal(s.pollLast(), e); > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + check(s.remove(e)); > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + s.subSet(e, true, e, true).clear(); > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + s.descendingSet().subSet(e, true, e, true).clear(); > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + final Iterator it = s.iterator(); > + while (it.hasNext()) > + if (it.next().equals(e)) { > + it.remove(); > + if (maybe(2)) > + THROWS(IllegalStateException.class, > + new Fun(){void f(){ it.remove(); }}); > + } > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + final Iterator it = s.descendingSet().iterator(); > + while (it.hasNext()) > + if (it.next().equals(e)) { > + it.remove(); > + if (maybe(2)) > + THROWS(IllegalStateException.class, > + new Fun(){void f(){ it.remove(); }}); > + } > + checkUnusedElt(s, e);}}, > + new SetFrobber() {void frob(NavigableSet s) { > + final Iterator it = s.descendingIterator(); > + while (it.hasNext()) > + if (it.next().equals(e)) { > + it.remove(); > + if (maybe(2)) > + THROWS(IllegalStateException.class, > + new Fun(){void f(){ it.remove(); }}); > + } > + checkUnusedElt(s, e);}} > + }; > + > + return randomRemovers[rnd.nextInt(randomRemovers.length)]; > } > > static void lockStep(NavigableMap m1, > > > Martin > > On Sat, Apr 19, 2008 at 2:07 PM, charlie hunt > wrote: > > > > Alan Bateman wrote: > > > > > Martin Buchholz wrote: > > > > > > > : > > > > > > > > 2. Bug creation from Charlie (or some other person empowered to do > so) > > > > I suggest making this bug P2-S2. > > > > > > > > I will need the bug id and synopsis to create the proper mercurial > > comment. > > > > > > > > > > > I don't know if Charlie is online today, but as you seem to be ready > to > > create the change-set, I've created java/classes_util bug: > > > > > > 6691185: (coll) TreeMap.navigableKeySet's descendingIterator method > > starts at first instead of last entry > > > > > > with a link to this thread. The synopsis can be changed if you want > > something different. > > > > > > -Alan. > > > > > > > Alan, thanks for filing the bug. One less item on my list of things to > do. > > :-) > > > > Fwiw, I've looked at Martin's proposed changes. From the familiarity > I've > > gotten with TreeMap over the past week or two, the changes look good to > me. > > > > charlie ... > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjb at google.com Sun Apr 20 07:26:51 2008 From: jjb at google.com (Joshua Bloch) Date: Sun, 20 Apr 2008 00:26:51 -0700 Subject: TreeMap.navigableKeySet().descendingIterator() sequence ? In-Reply-To: <17b2302a0804200007g17a194aaofbf0eb001f4fc403@mail.gmail.com> References: <4807C70A.10508@sun.com> <108fcdeb0804181439w1cd752b0g2d5ca7fabda8d1bb@mail.gmail.com> <1ccfd1c10804190137s1e891686hb452f05be6c1d347@mail.gmail.com> <480A0BE2.4070209@cs.oswego.edu> <1ccfd1c10804190854m3790e07cub7ca988c7286f54d@mail.gmail.com> <1ccfd1c10804191153v2be0fe87tc7388f07d52eec6b@mail.gmail.com> <480A5564.4010405@sun.com> <480A5EFE.5090005@sun.com> <1ccfd1c10804191756y3f6186f8h59cb0d779862a695@mail.gmail.com> <17b2302a0804200007g17a194aaofbf0eb001f4fc403@mail.gmail.com> Message-ID: <17b2302a0804200026j27bef26fsa17471fe9e5c3088@mail.gmail.com> Folks, While we're at it, here's another Collections bug discovered recently by a Googler (Scott Blum). The value of this expression should be false: new IdentityHashMap().containsValue(null) Unfortunately, it's true. Looking at the code for containsValue, it's obvious what's wrong: /** * Tests whether the specified object reference is a value in this identity * hash map. * * @param value value whose presence in this map is to be tested * @return true if this map maps one or more keys to the * specified object reference * @see #containsKey(Object) */ public boolean containsValue(Object value) { Object[] tab = table; for (int i = 1; i < tab.length; i+= 2) if (tab[i] == value) return true; return false; } Empty entries are masquerading as entries mapping to null. The fix is easy: if (tab[i] == value) becomes: if (tab[i] == value && tab[i -1] != null) (Recall that the null key (but not value) is proxied by NULL_KEY.) Josh On Sun, Apr 20, 2008 at 12:07 AM, Joshua Bloch wrote: > FWIW, I probably wrote the broken code. I wrote NavigableMap and > retrofitted TreeMap. Doug wrote ConcurrentSkipListMap. Sorry 'bout that. > > Josh > > On Sat, Apr 19, 2008 at 5:56 PM, Martin Buchholz > wrote: > > > Alan, thanks for filing the bug. > > > > Charlie, thanks for the review. However, since you are not (yet?) > > an OpenJDK committer, I will still need an official review from Doug > > (or Alan?) > > > > I noticed there was another test case, NavigableMap/LockStep.java, > > that "almost" tested the faulty code. > > > > I include a change to that test case as well, below > > (as well as making the test case a little more maintainble). > > > > diff --git a/test/java/util/NavigableMap/LockStep.java > > b/test/java/util/NavigableMap/LockStep.java > > --- a/test/java/util/NavigableMap/LockStep.java > > +++ b/test/java/util/NavigableMap/LockStep.java > > @@ -159,6 +159,7 @@ public class LockStep { > > Object[] a = new Object[1]; a[0] = Boolean.TRUE; > > equal(c.toArray(a), a); > > equal(a[0], null); > > + check(! c.iterator().hasNext()); > > } > > > > static void testEmptySet(Set c) { > > @@ -262,6 +263,16 @@ public class LockStep { > > } > > } > > > > + static void equalIterators(final Iterator it1, > > + final Iterator it2) { > > + while (it1.hasNext()) { > > + if (maybe(2)) > > + check(it2.hasNext()); > > + equal(it1.next(), it2.next()); > > + } > > + check(! it2.hasNext()); > > + } > > + > > static void equalNavigableSetsLeaf(final NavigableSet s1, > > final NavigableSet s2) { > > equal2(s1, s2); > > @@ -273,6 +284,8 @@ public class LockStep { > > equal(s1.first(), s2.first()); > > equal(s1.last(), s2.last()); > > } > > + equalIterators(s1.iterator(), s2.iterator()); > > + equalIterators(s1.descendingIterator(), > > s2.descendingIterator()); > > checkNavigableSet(s1); > > checkNavigableSet(s2); > > } > > @@ -493,30 +506,23 @@ public class LockStep { > > > > static MapFrobber randomAdder(NavigableMap m) { > > final Integer k = unusedKey(m); > > - MapFrobber f; > > - switch (rnd.nextInt(4)) { > > - case 0: f = new MapFrobber() {void frob(NavigableMap m) { > > - equal(m.put(k, k+1), null); > > - equal(m.get(k), k+1); > > - if (maybe(4)) { > > - equal(m.put(k, k+1), k+1); > > - equal(m.get(k), k+1);}}}; > > - break; > > - case 1: f = new MapFrobber() {void frob(NavigableMap m) { > > - m.descendingMap().put(k, k+1); > > - equal(m.get(k), k+1);}}; > > - break; > > - case 2: f = new MapFrobber() {void frob(NavigableMap m) { > > - m.tailMap(k,true).headMap(k,true).put(k,k+1);}}; > > - break; > > - case 3: f = new MapFrobber() {void frob(NavigableMap m) { > > - > > m.tailMap(k,true).headMap(k,true).descendingMap().put(k,k+1);}}; > > - break; > > - default: throw new Error(); > > - } > > - final MapFrobber ff = f; > > + final MapFrobber[] randomAdders = { > > + new MapFrobber() {void frob(NavigableMap m) { > > + equal(m.put(k, k+1), null); > > + equal(m.get(k), k+1); > > + if (maybe(4)) { > > + equal(m.put(k, k+1), k+1); > > + equal(m.get(k), k+1);}}}, > > + new MapFrobber() {void frob(NavigableMap m) { > > + m.descendingMap().put(k, k+1); > > + equal(m.get(k), k+1);}}, > > + new MapFrobber() {void frob(NavigableMap m) { > > + m.tailMap(k,true).headMap(k,true).put(k,k+1);}}, > > + new MapFrobber() {void frob(NavigableMap m) { > > + > > m.tailMap(k,true).headMap(k,true).descendingMap().put(k,k+1);}} > > + }; > > return new MapFrobber() {void frob(NavigableMap m) { > > - ff.frob(m); > > + randomAdders[rnd.nextInt(randomAdders.length)].frob(m); > > if (maybe(2)) equal(m.get(k), k+1); > > if (maybe(4)) { > > equal(m.put(k, k+1), k+1); > > @@ -525,26 +531,19 @@ public class LockStep { > > > > static SetFrobber randomAdder(NavigableSet s) { > > final Integer e = unusedElt(s); > > - SetFrobber f; > > - switch (rnd.nextInt(4)) { > > - case 0: f = new SetFrobber() {void frob(NavigableSet s) { > > - check(s.add(e));}}; > > - break; > > - case 1: f = new SetFrobber() {void frob(NavigableSet s) { > > - s.descendingSet().add(e);}}; > > - break; > > - case 2: f = new SetFrobber() {void frob(NavigableSet s) { > > - s.tailSet(e,true).headSet(e,true).add(e);}}; > > - break; > > - case 3: f = new SetFrobber() {void frob(NavigableSet s) { > > - > > s.descendingSet().tailSet(e,true).headSet(e,true).add(e);}}; > > - break; > > - default: throw new Error(); > > - } > > - final SetFrobber ff = f; > > + final SetFrobber[] randomAdders = { > > + new SetFrobber() {void frob(NavigableSet s) { > > + check(s.add(e));}}, > > + new SetFrobber() {void frob(NavigableSet s) { > > + s.descendingSet().add(e);}}, > > + new SetFrobber() {void frob(NavigableSet s) { > > + s.tailSet(e,true).headSet(e,true).add(e);}}, > > + new SetFrobber() {void frob(NavigableSet s) { > > + > > s.descendingSet().tailSet(e,true).headSet(e,true).add(e);}} > > + }; > > return new SetFrobber() {void frob(NavigableSet s) { > > if (maybe(2)) check(! s.contains(e)); > > - ff.frob(s); > > + randomAdders[rnd.nextInt(randomAdders.length)].frob(s); > > if (maybe(2)) check(! s.add(e)); > > if (maybe(2)) check(s.contains(e));}}; > > } > > @@ -605,89 +604,112 @@ public class LockStep { > > > > static MapFrobber randomRemover(NavigableMap m) { > > final Integer k = usedKey(m); > > - switch (rnd.nextInt(7)) { > > - default: throw new Error(); > > - case 0: return new MapFrobber() {void frob(NavigableMap m) { > > - Map.Entry e = m.firstEntry(); > > - equal(m.pollFirstEntry(), e); > > - checkUnusedKey(m, e.getKey());}}; > > - case 1: return new MapFrobber() {void frob(NavigableMap m) { > > - Map.Entry e = m.lastEntry(); > > - equal(m.pollLastEntry(), e); > > - checkUnusedKey(m, e.getKey());}}; > > - case 2: return new MapFrobber() {void frob(NavigableMap m) { > > - check(m.remove(k) != null); > > - checkUnusedKey(m, k);}}; > > - case 3: return new MapFrobber() {void frob(NavigableMap m) { > > - m.subMap(k, true, k, true).clear(); > > - checkUnusedKey(m, k);}}; > > - case 4: return new MapFrobber() {void frob(NavigableMap m) { > > - m.descendingMap().subMap(k, true, k, true).clear(); > > - checkUnusedKey(m, k);}}; > > - case 5: return new MapFrobber() {void frob(NavigableMap m) { > > - final Iterator it = m.keySet().iterator(); > > - while (it.hasNext()) > > - if (it.next().equals(k)) { > > - it.remove(); > > - if (maybe(2)) > > - THROWS(IllegalStateException.class, > > - new Fun(){void f(){ it.remove(); }}); > > - } > > - checkUnusedKey(m, k);}}; > > - case 6: return new MapFrobber() {void frob(NavigableMap m) { > > - final Iterator it = m.entrySet().iterator(); > > - while (it.hasNext()) > > - if (it.next().getKey().equals(k)) { > > - it.remove(); > > - if (maybe(2)) > > - THROWS(IllegalStateException.class, > > remover(it)); > > - } > > - checkUnusedKey(m, k);}}; > > - } > > + final MapFrobber[] randomRemovers = { > > + new MapFrobber() {void frob(NavigableMap m) { > > + Map.Entry e = m.firstEntry(); > > + equal(m.pollFirstEntry(), e); > > + checkUnusedKey(m, e.getKey());}}, > > + new MapFrobber() {void frob(NavigableMap m) { > > + Map.Entry e = m.lastEntry(); > > + equal(m.pollLastEntry(), e); > > + checkUnusedKey(m, e.getKey());}}, > > + new MapFrobber() {void frob(NavigableMap m) { > > + check(m.remove(k) != null); > > + checkUnusedKey(m, k);}}, > > + new MapFrobber() {void frob(NavigableMap m) { > > + m.subMap(k, true, k, true).clear(); > > + checkUnusedKey(m, k);}}, > > + new MapFrobber() {void frob(NavigableMap m) { > > + m.descendingMap().subMap(k, true, k, true).clear(); > > + checkUnusedKey(m, k);}}, > > + new MapFrobber() {void frob(NavigableMap m) { > > + final Iterator it = m.keySet().iterator(); > > + while (it.hasNext()) > > + if (it.next().equals(k)) { > > + it.remove(); > > + if (maybe(2)) > > + THROWS(IllegalStateException.class, > > + new Fun(){void f(){ it.remove(); > > }}); > > + } > > + checkUnusedKey(m, k);}}, > > + new MapFrobber() {void frob(NavigableMap m) { > > + final Iterator it = > > m.navigableKeySet().descendingIterator(); > > + while (it.hasNext()) > > + if (it.next().equals(k)) { > > + it.remove(); > > + if (maybe(2)) > > + THROWS(IllegalStateException.class, > > + new Fun(){void f(){ it.remove(); > > }}); > > + } > > + checkUnusedKey(m, k);}}, > > + new MapFrobber() {void frob(NavigableMap m) { > > + final Iterator it = m.entrySet().iterator(); > > + while (it.hasNext()) > > + if (it.next().getKey().equals(k)) { > > + it.remove(); > > + if (maybe(2)) > > + THROWS(IllegalStateException.class, > > remover(it)); > > + } > > + checkUnusedKey(m, k);}}, > > + }; > > + > > + return randomRemovers[rnd.nextInt(randomRemovers.length)]; > > } > > > > static SetFrobber randomRemover(NavigableSet s) { > > final Integer e = usedElt(s); > > - switch (rnd.nextInt(7)) { > > - default: throw new Error(); > > - case 0: return new SetFrobber() {void frob(NavigableSet s) { > > - Object e = s.first(); > > - equal(s.pollFirst(), e); > > - checkUnusedElt(s, e);}}; > > - case 1: return new SetFrobber() {void frob(NavigableSet s) { > > - Object e = s.last(); > > - equal(s.pollLast(), e); > > - checkUnusedElt(s, e);}}; > > - case 2: return new SetFrobber() {void frob(NavigableSet s) { > > - check(s.remove(e)); > > - checkUnusedElt(s, e);}}; > > - case 3: return new SetFrobber() {void frob(NavigableSet s) { > > - s.subSet(e, true, e, true).clear(); > > - checkUnusedElt(s, e);}}; > > - case 4: return new SetFrobber() {void frob(NavigableSet s) { > > - s.descendingSet().subSet(e, true, e, true).clear(); > > - checkUnusedElt(s, e);}}; > > - case 5: return new SetFrobber() {void frob(NavigableSet s) { > > - final Iterator it = s.iterator(); > > - while (it.hasNext()) > > - if (it.next().equals(e)) { > > - it.remove(); > > - if (maybe(2)) > > - THROWS(IllegalStateException.class, > > - new Fun(){void f(){ it.remove(); }}); > > - } > > - checkUnusedElt(s, e);}}; > > - case 6: return new SetFrobber() {void frob(NavigableSet s) { > > - final Iterator it = s.descendingSet().iterator(); > > - while (it.hasNext()) > > - if (it.next().equals(e)) { > > - it.remove(); > > - if (maybe(2)) > > - THROWS(IllegalStateException.class, > > - new Fun(){void f(){ it.remove(); }}); > > - } > > - checkUnusedElt(s, e);}}; > > - } > > + > > + final SetFrobber[] randomRemovers = { > > + new SetFrobber() {void frob(NavigableSet s) { > > + Object e = s.first(); > > + equal(s.pollFirst(), e); > > + checkUnusedElt(s, e);}}, > > + new SetFrobber() {void frob(NavigableSet s) { > > + Object e = s.last(); > > + equal(s.pollLast(), e); > > + checkUnusedElt(s, e);}}, > > + new SetFrobber() {void frob(NavigableSet s) { > > + check(s.remove(e)); > > + checkUnusedElt(s, e);}}, > > + new SetFrobber() {void frob(NavigableSet s) { > > + s.subSet(e, true, e, true).clear(); > > + checkUnusedElt(s, e);}}, > > + new SetFrobber() {void frob(NavigableSet s) { > > + s.descendingSet().subSet(e, true, e, true).clear(); > > + checkUnusedElt(s, e);}}, > > + new SetFrobber() {void frob(NavigableSet s) { > > + final Iterator it = s.iterator(); > > + while (it.hasNext()) > > + if (it.next().equals(e)) { > > + it.remove(); > > + if (maybe(2)) > > + THROWS(IllegalStateException.class, > > + new Fun(){void f(){ it.remove(); > > }}); > > + } > > + checkUnusedElt(s, e);}}, > > + new SetFrobber() {void frob(NavigableSet s) { > > + final Iterator it = s.descendingSet().iterator(); > > + while (it.hasNext()) > > + if (it.next().equals(e)) { > > + it.remove(); > > + if (maybe(2)) > > + THROWS(IllegalStateException.class, > > + new Fun(){void f(){ it.remove(); > > }}); > > + } > > + checkUnusedElt(s, e);}}, > > + new SetFrobber() {void frob(NavigableSet s) { > > + final Iterator it = s.descendingIterator(); > > + while (it.hasNext()) > > + if (it.next().equals(e)) { > > + it.remove(); > > + if (maybe(2)) > > + THROWS(IllegalStateException.class, > > + new Fun(){void f(){ it.remove(); > > }}); > > + } > > + checkUnusedElt(s, e);}} > > + }; > > + > > + return randomRemovers[rnd.nextInt(randomRemovers.length)]; > > } > > > > static void lockStep(NavigableMap m1, > > > > > > Martin > > > > On Sat, Apr 19, 2008 at 2:07 PM, charlie hunt > > wrote: > > > > > > Alan Bateman wrote: > > > > > > > Martin Buchholz wrote: > > > > > > > > > : > > > > > > > > > > 2. Bug creation from Charlie (or some other person empowered to do > > so) > > > > > I suggest making this bug P2-S2. > > > > > > > > > > I will need the bug id and synopsis to create the proper mercurial > > > comment. > > > > > > > > > > > > > > I don't know if Charlie is online today, but as you seem to be ready > > to > > > create the change-set, I've created java/classes_util bug: > > > > > > > > 6691185: (coll) TreeMap.navigableKeySet's descendingIterator method > > > starts at first instead of last entry > > > > > > > > with a link to this thread. The synopsis can be changed if you want > > > something different. > > > > > > > > -Alan. > > > > > > > > > > Alan, thanks for filing the bug. One less item on my list of things > > to do. > > > :-) > > > > > > Fwiw, I've looked at Martin's proposed changes. From the familiarity > > I've > > > gotten with TreeMap over the past week or two, the changes look good > > to me. > > > > > > charlie ... > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjb at google.com Mon Apr 21 01:20:17 2008 From: jjb at google.com (Joshua Bloch) Date: Sun, 20 Apr 2008 18:20:17 -0700 Subject: 6691215: (coll) IdentityHashMap.containsValue(null) returns true when null value not present In-Reply-To: <1ccfd1c10804201635hd266fd3y2fdbf5de50d9518a@mail.gmail.com> References: <1ccfd1c10804201635hd266fd3y2fdbf5de50d9518a@mail.gmail.com> Message-ID: <17b2302a0804201820g5c7cf15fh4d0fc30ce9c76e76@mail.gmail.com> Martin, A bit disconcerting, yes, but both of the recent discoveries are, in their own way, special cases: TreeMap: I rewrote this layer of it for Java 6, and the flaw is in a slightly obscure place. IdentityHashMap: The flaw is in a very obscure place. containsValue is infrequently used even for normal maps; this is an identity map. And it has identity value semantics, which is a bit odd. In a perfect world, we'd all write bug-free code, but hey, we've seen a binary search bug last a quarter of a century;) Josh On Sun, Apr 20, 2008 at 4:35 PM, Martin Buchholz wrote: > It's a little disconcerting to still keep finding basic correctness bugs > in > core Collections classes. > > Here's a fix (again demonstrating that the Mother Of All Collections Tests > is not thorough enough): > > Review requested from Chris Hegarty, Doug Lea > > # HG changeset patch > # User martin > # Date 1208733844 25200 > # Node ID fd80580439549ed34473cfa973f34d29f9efd7a6 > # Parent 8513593a57f180641d06cf535f1647cb9160f9e0 > 6691215: (coll) IdentityHashMap.containsValue(null) returns true when > null value not present > Reviewed-by: > Contributed-by: Scott Blum > > diff --git a/src/share/classes/java/util/IdentityHashMap.java > b/src/share/classes/java/util/IdentityHashMap.java > --- a/src/share/classes/java/util/IdentityHashMap.java > +++ b/src/share/classes/java/util/IdentityHashMap.java > @@ -188,7 +188,6 @@ public class IdentityHashMap > /** > * Use NULL_KEY for key if it is null. > */ > - > private static Object maskNull(Object key) { > return (key == null ? NULL_KEY : key); > } > @@ -378,8 +377,8 @@ public class IdentityHashMap > */ > public boolean containsValue(Object value) { > Object[] tab = table; > - for (int i = 1; i < tab.length; i+= 2) > - if (tab[i] == value) > + for (int i = 1; i < tab.length; i += 2) > + if (tab[i] == value && tab[i - 1] != null) > return true; > > return false; > @@ -905,7 +904,6 @@ public class IdentityHashMap > * view the first time this view is requested. The view is stateless, > * so there's no reason to create more than one. > */ > - > private transient Set> entrySet = null; > > /** > diff --git a/test/java/util/Collection/MOAT.java > b/test/java/util/Collection/MOAT.java > --- a/test/java/util/Collection/MOAT.java > +++ b/test/java/util/Collection/MOAT.java > @@ -25,7 +25,7 @@ > * @test > * @bug 6207984 6272521 6192552 6269713 6197726 6260652 5073546 > 4137464 > * 4155650 4216399 4294891 6282555 6318622 6355327 6383475 > 6420753 > - * 6431845 4802633 6570566 6570575 6570631 6570924 6691185 > + * 6431845 4802633 6570566 6570575 6570631 6570924 6691185 > 6691215 > * @summary Run many tests on many Collection and Map implementations > * @author Martin Buchholz > */ > @@ -247,6 +247,13 @@ public class MOAT { > testEmptySet(m.keySet()); > testEmptySet(m.entrySet()); > testEmptyCollection(m.values()); > + > + try { check(! m.containsValue(null)); } > + catch (NullPointerException _) { /* OK */ } > + try { check(! m.containsKey(null)); } > + catch (NullPointerException _) { /* OK */ } > + check(! m.containsValue(1)); > + check(! m.containsKey(1)); > } > > private static void testImmutableMap(final Map m) { > > Martin > > On Sun, Apr 20, 2008 at 3:07 AM, Alan Bateman > wrote: > > Joshua Bloch wrote: > > > > > > > > Folks, > > > > > > While we're at it, here's another Collections bug discovered recently > by a > > Googler (Scott Blum). The value of this expression should be false: > > > > > > new IdentityHashMap().containsValue(null) > > > > > > Unfortunately, it's true. Looking at the code for containsValue, it's > > obvious what's wrong: > > > > > > /** > > > * Tests whether the specified object reference is a value in this > > identity > > > * hash map. > > > * > > > * @param value value whose presence in this map is to be tested > > > * @return true if this map maps one or more keys to the > > > * specified object reference > > > * @see #containsKey(Object) > > > */ > > > public boolean containsValue(Object value) { > > > Object[] tab = table; > > > for (int i = 1; i < tab.length; i+= 2) > > > if (tab[i] == value) > > > return true; > > > > > > return false; > > > } > > > > > > Empty entries are masquerading as entries mapping to null. The fix is > > easy: > > > > > > if (tab[i] == value) > > > > > > becomes: > > > > > > if (tab[i] == value && tab[i -1] != null) > > > > > > (Recall that the null key (but not value) is proxied by NULL_KEY.) > > > > > > Josh > > > > > > > > I don't see this in the bug database so I've created the following so > that > > it doesn't get lost: > > 6691215: (coll) IdentityHashMap.containsValue(null) returns true when > null > > value not present > > > > -Alan. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joe.Darcy at Sun.COM Mon Apr 21 20:33:24 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Mon, 21 Apr 2008 13:33:24 -0700 Subject: sun.reflect.generics.* In-Reply-To: <480C8B0C.5000304@univ-mlv.fr> References: <480C8B0C.5000304@univ-mlv.fr> Message-ID: <480CFA14.1090605@sun.com> R?mi Forax wrote: > Hi all, > Is someone knows why package sun.reflect.generics is so complex ? Because it was written by Gilad ;-) > This package (and subpackage) it used to reify a generics signatures > to a java.lang.reflect.Type tree. > It creates a parser, parse the signature to create an AST, > and use a visitor to create the tree. > > This package, contains in my opinion, lot of unecessary garbage. > - It creates an AST even if the Type tree can be created in one pass. > - A bunch of interfaces has only one implementation like Visitor. > - Use a visitor even if there is only one operation. > - Use lots of generics can be removed because only one instanciation > is used. While the code is a bit elaborate compared to the minimum needed for the task at hand, I think it is otherwise well-structured and there are no plans to refactor it. -Joe From eamonn.mcmanus at sun.com Tue Apr 22 16:59:41 2008 From: eamonn.mcmanus at sun.com (eamonn.mcmanus at sun.com) Date: Tue, 22 Apr 2008 16:59:41 +0000 Subject: hg: jdk7/tl/jdk: 6692027: Custom subclasses of QueryEval don't serialize Message-ID: <20080422165957.B51CE27100@hg.openjdk.java.net> Changeset: 92ea0ac77d2f Author: emcmanus Date: 2008-04-22 18:58 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/92ea0ac77d2f 6692027: Custom subclasses of QueryEval don't serialize Summary: Remove non-public superclass of QueryEval Reviewed-by: dfuchs ! src/share/classes/javax/management/AndQueryExp.java ! src/share/classes/javax/management/BetweenQueryExp.java ! src/share/classes/javax/management/BinaryRelQueryExp.java ! src/share/classes/javax/management/NotQueryExp.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/OrQueryExp.java ! src/share/classes/javax/management/Query.java ! src/share/classes/javax/management/QueryEval.java + test/javax/management/query/CustomQueryTest.java From maurizio.cimadamore at sun.com Wed Apr 23 16:11:11 2008 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Wed, 23 Apr 2008 16:11:11 +0000 Subject: hg: jdk7/tl/langtools: 6682380: Foreach loop with generics inside finally block crashes javac with -target 1.5 Message-ID: <20080423161112.B119D27376@hg.openjdk.java.net> Changeset: ec29a1a284ca Author: mcimadamore Date: 2008-04-23 17:10 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ec29a1a284ca 6682380: Foreach loop with generics inside finally block crashes javac with -target 1.5 Summary: A missing type-erasure in Lower.java causes the compiler to crash since JDK6 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/foreach/T6682380.java From keith.mcguigan at sun.com Mon Apr 21 18:59:20 2008 From: keith.mcguigan at sun.com (keith.mcguigan at sun.com) Date: Mon, 21 Apr 2008 18:59:20 +0000 Subject: hg: jdk7/tl/jdk: 6691494: doc build broken in tracingdocs Message-ID: <20080421185944.5816F2707E@hg.openjdk.java.net> Changeset: 79b594e72df0 Author: kamg Date: 2008-04-21 11:24 -0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/79b594e72df0 6691494: doc build broken in tracingdocs Summary: Wrong variable names in makefile Reviewed-by: tbell ! make/docs/Makefile