From ahughes at redhat.com Wed Aug 1 11:40:43 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 1 Aug 2012 07:40:43 -0400 (EDT) Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <1219347110.6968405.1343820865996.JavaMail.root@redhat.com> Message-ID: <2094033787.6970277.1343821243521.JavaMail.root@redhat.com> java_props_md.c allocates a 64 byte buffer for the return value of setlocale on the stack. However, there appears to be no set limit on the return value: http://pubs.opengroup.org/onlinepubs/009604499/functions/setlocale.html and no check in the code to ensure that its length is 63 characters or less (allowing for '\0'). While language and country are defined by ISO, I don't believe there's any limit on the optional encoding and variant entries. This patch: http://cr.openjdk.java.net/~andrew/buffer_overflow/webrev.01/jdk.patch replaces the allocation with a dynamic buffer based on the length of lc. Original bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497666 Ok for tl? If so, can I have a bug ID? Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From Alan.Bateman at oracle.com Wed Aug 1 13:39:17 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 Aug 2012 14:39:17 +0100 Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <2094033787.6970277.1343821243521.JavaMail.root@redhat.com> References: <2094033787.6970277.1343821243521.JavaMail.root@redhat.com> Message-ID: <50193185.1040200@oracle.com> On 01/08/2012 12:40, Andrew Hughes wrote: > java_props_md.c allocates a 64 byte buffer for the return value of setlocale > on the stack. However, there appears to be no set limit on the return value: > > http://pubs.opengroup.org/onlinepubs/009604499/functions/setlocale.html > > and no check in the code to ensure that its length is 63 characters or less > (allowing for '\0'). While language and country are defined by ISO, I don't > believe there's any limit on the optional encoding and variant entries. > > This patch: > > http://cr.openjdk.java.net/~andrew/buffer_overflow/webrev.01/jdk.patch > > replaces the allocation with a dynamic buffer based on the length of lc. > > Original bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497666 > > Ok for tl? If so, can I have a bug ID? > Just some history on this one. Andrew Haley originally brought this up up in 2009 (embarrassing, I know), see: http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-May/001650.html Then in 2011, Omair tried again, see: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-May/006907.html I reviewed it at the time and gave a thumbs up, it's just it was the end-game for 7 at the time and that release was being locked down. I asked that it be held back until jdk8 and jdk7u. Omair's webrev is a larger patch that what you are proposing now, mostly handling malloc/realloc failing that we nit-picked in the original review. I haven't checked IcedTea to know whether it has the minimal patch you are proposing now or whether it has Omair's changes. In any case, there is a Sun bug open for this: 6844255: Potential stack corruption in GetJavaProperties Also if you read the old mails then you'll see that we were scratching our heads as to an example that would demonstrate the original issue. I suspect it may have been something that someone spotted rather than someone running with a locale of this length. -Alan. From ahughes at redhat.com Wed Aug 1 13:52:13 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 1 Aug 2012 09:52:13 -0400 (EDT) Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <50193185.1040200@oracle.com> Message-ID: <1540089398.7101445.1343829133474.JavaMail.root@redhat.com> ----- Original Message ----- > On 01/08/2012 12:40, Andrew Hughes wrote: > > java_props_md.c allocates a 64 byte buffer for the return value of > > setlocale > > on the stack. However, there appears to be no set limit on the > > return value: > > > > http://pubs.opengroup.org/onlinepubs/009604499/functions/setlocale.html > > > > and no check in the code to ensure that its length is 63 characters > > or less > > (allowing for '\0'). While language and country are defined by > > ISO, I don't > > believe there's any limit on the optional encoding and variant > > entries. > > > > This patch: > > > > http://cr.openjdk.java.net/~andrew/buffer_overflow/webrev.01/jdk.patch > > > > replaces the allocation with a dynamic buffer based on the length > > of lc. > > > > Original bug: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497666 > > > > Ok for tl? If so, can I have a bug ID? > > > Just some history on this one. > > Andrew Haley originally brought this up up in 2009 (embarrassing, I > know), see: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-May/001650.html > > Then in 2011, Omair tried again, see: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-May/006907.html > Well, it's a Red Hat patch and we're all Red Hat employees :-) The original version, posted by Andrew Haley and in IcedTea, was actually written by Lillian Angel back in 2008: 2008-09-10 Lillian Angel * patches/icedtea-lc_ctype.patch: New patch to fix this issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497666 * Makefile.am: Added patch to list. 2008-09-15 Lillian Angel * patches/icedtea-lc_ctype.patch: Fixed array size and changed to use malloc/free. and she's since left Red Hat. My version is based on this original, the one in IcedTea, with the addition of a check on the return value of malloc. I have no idea what happened with Omair's extended version. It's not in IcedTea. > I reviewed it at the time and gave a thumbs up, it's just it was the > end-game for 7 at the time and that release was being locked down. I > asked that it be held back until jdk8 and jdk7u. > > Omair's webrev is a larger patch that what you are proposing now, > mostly > handling malloc/realloc failing that we nit-picked in the original > review. I haven't checked IcedTea to know whether it has the minimal > patch you are proposing now or whether it has Omair's changes. > > In any case, there is a Sun bug open for this: > > 6844255: Potential stack corruption in GetJavaProperties > Can I take it that I can just get on and push Omair's extended version now then, with that bug ID? > Also if you read the old mails then you'll see that we were > scratching > our heads as to an example that would demonstrate the original issue. > I > suspect it may have been something that someone spotted rather than > someone running with a locale of this length. Well, the locale can be set be an environment variable, so it could potentially be anything of any length... The Debian bug posted above has an example, though I couldn't replicate it. > > -Alan. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From sean.mullan at oracle.com Wed Aug 1 15:27:07 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 01 Aug 2012 15:27:07 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120801152759.4764C472E9@hg.openjdk.java.net> Changeset: 21c590fdc8cb Author: mullan Date: 2012-08-01 11:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21c590fdc8cb 7179715: OCSP revocation checking fails if the signer certificate is identified using the key ID Reviewed-by: vinnie ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java Changeset: 9a5a3741bac9 Author: mullan Date: 2012-08-01 11:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a5a3741bac9 Merge - makefiles/LegacyMakefiles.gmk - makefiles/OldImages.gmk - makefiles/com/sun/crypto/provider/Makefile - makefiles/common/Classes.gmk - makefiles/common/Cscope.gmk - makefiles/common/Defs-embedded.gmk - makefiles/common/Defs-linux.gmk - makefiles/common/Defs-macosx.gmk - makefiles/common/Defs-solaris.gmk - makefiles/common/Defs-windows.gmk - makefiles/common/Defs.gmk - makefiles/common/Demo.gmk - makefiles/common/Library.gmk - makefiles/common/Mapfile-vers.gmk - makefiles/common/Modules.gmk - makefiles/common/Program.gmk - makefiles/common/Release-embedded.gmk - makefiles/common/Release-macosx.gmk - makefiles/common/Release.gmk - makefiles/common/Rules.gmk - makefiles/common/Subdirs.gmk - makefiles/common/internal/Defs-corba.gmk - makefiles/common/internal/Defs-jaxp.gmk - makefiles/common/internal/Defs-jaxws.gmk - makefiles/common/internal/Defs-langtools.gmk - makefiles/common/internal/ImportComponents.gmk - makefiles/common/internal/NativeCompileRules.gmk - makefiles/common/internal/Resources.gmk - makefiles/common/shared/Compiler-gcc.gmk - makefiles/common/shared/Compiler-llvm.gmk - makefiles/common/shared/Compiler-msvc.gmk - makefiles/common/shared/Compiler-sun.gmk - makefiles/common/shared/Defs-control.gmk - makefiles/common/shared/Defs-java.gmk - makefiles/common/shared/Defs-javadoc.gmk - makefiles/common/shared/Defs-linux.gmk - makefiles/common/shared/Defs-macosx.gmk - makefiles/common/shared/Defs-solaris.gmk - makefiles/common/shared/Defs-versions.gmk - makefiles/common/shared/Defs-windows.gmk - makefiles/common/shared/Defs.gmk - makefiles/common/shared/Platform.gmk - makefiles/common/shared/PrivateDefs.gmk-example - makefiles/common/shared/Sanity-Settings.gmk - makefiles/java/Makefile - makefiles/java/invoke/Makefile - makefiles/java/redist/Makefile - makefiles/java/redist/sajdi/Makefile - makefiles/javax/crypto/Defs-jce.gmk - makefiles/javax/crypto/Makefile - makefiles/javax/crypto/policy/limited/LIMITED - makefiles/javax/crypto/policy/limited/default_local.policy - makefiles/javax/crypto/policy/limited/exempt_local.policy - makefiles/javax/crypto/policy/unlimited/UNLIMITED - makefiles/javax/crypto/policy/unlimited/default_US_export.policy - makefiles/javax/crypto/policy/unlimited/default_local.policy - makefiles/mkdemo/Makefile - makefiles/mkdemo/jni/Makefile - makefiles/mkdemo/jni/Poller/Makefile - makefiles/mkdemo/jvmti/Makefile - makefiles/mkdemo/jvmti/README.txt - makefiles/mkdemo/jvmti/hprof/Makefile - makefiles/mkdemo/jvmti/mapfile-vers - makefiles/mkdemo/management/README.txt - makefiles/sun/jkernel/Makefile - makefiles/sun/security/ec/Makefile - makefiles/sun/security/pkcs11/FILES_c.gmk - makefiles/sun/security/pkcs11/Makefile - makefiles/sun/security/pkcs11/mapfile-vers - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh From mike.duigou at oracle.com Wed Aug 1 18:37:45 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 01 Aug 2012 18:37:45 +0000 Subject: hg: jdk8/tl/jdk: 6914123: (str) Missing synchronization in java.lang.String#contentEquals(CharSequence) Message-ID: <20120801183804.137F7472EF@hg.openjdk.java.net> Changeset: 184da100cf45 Author: jgish Date: 2012-07-27 16:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/184da100cf45 6914123: (str) Missing synchronization in java.lang.String#contentEquals(CharSequence) Summary: Change contentEquals( CharSequence cs ) to do synchronization if cs is a StringBuffer Reviewed-by: mduigou Contributed-by: Jim Gish ! src/share/classes/java/lang/String.java From xueming.shen at oracle.com Wed Aug 1 20:35:42 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 01 Aug 2012 13:35:42 -0700 Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <1474470812.7283741.1343851879188.JavaMail.root@redhat.com> References: <1474470812.7283741.1343851879188.JavaMail.root@redhat.com> Message-ID: <5019931E.6030102@oracle.com> Hi Andrew, No, I'm NOT against to fix this "potential" risk at all. Just tried to point out that this might not be an "immediate" breach. It was a mistake to drop the list. -Sherman On 08/01/2012 01:11 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 08/01/2012 06:52 AM, Andrew Hughes wrote: >> >> >> >> Also if you read the old mails then you'll see that we were >> scratching >> our heads as to an example that would demonstrate the original issue. >> I >> suspect it may have been something that someone spotted rather than >> someone running with a locale of this length. Well, the locale can be >> set be an environment variable, so it could potentially >> be anything of any length... >> >> The Debian bug posted above has an example, though I couldn't >> replicate it. >> The spec says >> >> " If the value of any of these environment variable searches yields a >> locale that is not supported (and non-null), setlocale () shall >> return a null pointer and the locale of the process shall not be >> changed..." >> >> So basically setLocale() should not return whatever you set in your >> corresponding environment variable, it only >> returns if such a "supported"/installed locale exists. I doubt there >> is a such a locale anywhere on a real platform. >> But in theory that could happen, if you try to config a locale with >> name> 64 and successfully install it. >> >> >> -Sherman >> >> >> > I still don't see any reason not to just close the hole. AFAICS, it's > also feasibly possible for a variant to appear in the future that takes > the length over 63 characters. > > Any reason you didn't reply on list? > > Thanks, From ahughes at redhat.com Wed Aug 1 20:44:08 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 1 Aug 2012 16:44:08 -0400 (EDT) Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <5019931E.6030102@oracle.com> Message-ID: <313873115.7291236.1343853848824.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Andrew, > > No, I'm NOT against to fix this "potential" risk at all. Just tried > to > point out that this > might not be an "immediate" breach. > Oh, I know. Just might be nice to get the patch in after four years :-) > It was a mistake to drop the list. > No problem. I don't want to post a mail publicly if it was meant to be private. > -Sherman > > On 08/01/2012 01:11 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> On 08/01/2012 06:52 AM, Andrew Hughes wrote: > >> > >> > >> > >> Also if you read the old mails then you'll see that we were > >> scratching > >> our heads as to an example that would demonstrate the original > >> issue. > >> I > >> suspect it may have been something that someone spotted rather > >> than > >> someone running with a locale of this length. Well, the locale can > >> be > >> set be an environment variable, so it could potentially > >> be anything of any length... > >> > >> The Debian bug posted above has an example, though I couldn't > >> replicate it. > >> The spec says > >> > >> " If the value of any of these environment variable searches > >> yields a > >> locale that is not supported (and non-null), setlocale () shall > >> return a null pointer and the locale of the process shall not be > >> changed..." > >> > >> So basically setLocale() should not return whatever you set in > >> your > >> corresponding environment variable, it only > >> returns if such a "supported"/installed locale exists. I doubt > >> there > >> is a such a locale anywhere on a real platform. > >> But in theory that could happen, if you try to config a locale > >> with > >> name> 64 and successfully install it. > >> > >> > >> -Sherman > >> > >> > >> > > I still don't see any reason not to just close the hole. AFAICS, > > it's > > also feasibly possible for a variant to appear in the future that > > takes > > the length over 63 characters. > > > > Any reason you didn't reply on list? > > > > Thanks, > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Wed Aug 1 20:44:37 2012 From: omajid at redhat.com (Omair Majid) Date: Wed, 01 Aug 2012 16:44:37 -0400 Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <1540089398.7101445.1343829133474.JavaMail.root@redhat.com> References: <1540089398.7101445.1343829133474.JavaMail.root@redhat.com> Message-ID: <50199535.4030400@redhat.com> On 08/01/2012 09:52 AM, Andrew Hughes wrote: > I have no idea what happened with Omair's > extended version. It's not in IcedTea. > I didn't commit it to icedtea since I assumed I would be committing it to OpenJDK7/8 anyway (and icedtea would get it on the next sync). And I didn't commit it to OpenJDK7 because only critical fixes were being accepted. Then I guess this patch fell off my radar when 7u/8 forests were created. > Can I take it that I can just get on and push Omair's extended version now then, > with that bug ID? Definitely no objections from me. Cheers, Omair From Alan.Bateman at oracle.com Wed Aug 1 21:04:48 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 01 Aug 2012 22:04:48 +0100 Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <1540089398.7101445.1343829133474.JavaMail.root@redhat.com> References: <1540089398.7101445.1343829133474.JavaMail.root@redhat.com> Message-ID: <501999F0.70102@oracle.com> On 01/08/2012 14:52, Andrew Hughes wrote: > : > > > In any case, there is a Sun bug open for this: > > 6844255: Potential stack corruption in GetJavaProperties > > Can I take it that I can just get on and push Omair's extended version now then, > with that bug ID? Yes, go ahead, I should have said that in my mail. > Well, the locale can be set be an environment variable, so it could potentially > be anything of any length... > > The Debian bug posted above has an example, though I couldn't replicate it. > I couldn't replicate it either and was just curious if anyone managed to demonstrate it. -Alan. From ahughes at redhat.com Wed Aug 1 21:13:37 2012 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 01 Aug 2012 21:13:37 +0000 Subject: hg: jdk8/tl/jdk: 6844255: Potential stack corruption in GetJavaProperties Message-ID: <20120801211403.2FF9A472F5@hg.openjdk.java.net> Changeset: 75bda37d0337 Author: omajid Date: 2012-08-01 22:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75bda37d0337 6844255: Potential stack corruption in GetJavaProperties Summary: Use dynamically allocated buffers for temp and encoding. Reviewed-by: alanb, andrew ! src/solaris/native/java/lang/java_props_md.c From ahughes at redhat.com Wed Aug 1 21:18:04 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 1 Aug 2012 17:18:04 -0400 (EDT) Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <501999F0.70102@oracle.com> Message-ID: <621822911.7298135.1343855884834.JavaMail.root@redhat.com> ----- Original Message ----- > On 01/08/2012 14:52, Andrew Hughes wrote: > > : > > > > > > In any case, there is a Sun bug open for this: > > > > 6844255: Potential stack corruption in GetJavaProperties > > > > Can I take it that I can just get on and push Omair's extended > > version now then, > > with that bug ID? > Yes, go ahead, I should have said that in my mail. > Thanks. Done: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-August/010993.html with Omair as author and yourself and I as reviewers. > > Well, the locale can be set be an environment variable, so it could > > potentially > > be anything of any length... > > > > The Debian bug posted above has an example, though I couldn't > > replicate it. > > > I couldn't replicate it either and was just curious if anyone managed > to > demonstrate it. > Yeah, I tend to think it's more potentially exploitable rather than something that's actually been hit. > -Alan. > Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Wed Aug 1 21:20:55 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 1 Aug 2012 17:20:55 -0400 (EDT) Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <50199535.4030400@redhat.com> Message-ID: <425701440.7298367.1343856055216.JavaMail.root@redhat.com> ----- Original Message ----- > On 08/01/2012 09:52 AM, Andrew Hughes wrote: > > I have no idea what happened with Omair's > > extended version. It's not in IcedTea. > > > > I didn't commit it to icedtea since I assumed I would be committing > it > to OpenJDK7/8 anyway (and icedtea would get it on the next sync). And > I > didn't commit it to OpenJDK7 because only critical fixes were being > accepted. Then I guess this patch fell off my radar when 7u/8 forests > were created. Yes, I can see the reasoning, but in retrospect, it seems a good idea to add patches to IcedTea straight away so they don't get lost, should review take a while for some reason (and they have to go through two to reach 6 or 7). It's trivial to merge the two when they do come in. > > > Can I take it that I can just get on and push Omair's extended > > version now then, > > with that bug ID? > > Definitely no objections from me. > Done: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-August/010993.html > Cheers, > Omair > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Thu Aug 2 02:14:36 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 02 Aug 2012 12:14:36 +1000 Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <621822911.7298135.1343855884834.JavaMail.root@redhat.com> References: <621822911.7298135.1343855884834.JavaMail.root@redhat.com> Message-ID: <5019E28C.1060603@oracle.com> Andrew et al, AFAICS here: 220 encoding_variant = malloc(strlen(temp)+1); 221 if (encoding_variant == NULL) { 222 JNU_ThrowOutOfMemoryError(env, NULL); 223 return 0; 224 } we also need to do free(temp). Similarly later where we return with OOM due to realloc failure, don't we also need to free what was previously malloc'd? David On 2/08/2012 7:18 AM, Andrew Hughes wrote: > > > ----- Original Message ----- >> On 01/08/2012 14:52, Andrew Hughes wrote: >>> : >>> >>> >>> In any case, there is a Sun bug open for this: >>> >>> 6844255: Potential stack corruption in GetJavaProperties >>> >>> Can I take it that I can just get on and push Omair's extended >>> version now then, >>> with that bug ID? >> Yes, go ahead, I should have said that in my mail. >> > > Thanks. > > Done: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-August/010993.html > > with Omair as author and yourself and I as reviewers. > >>> Well, the locale can be set be an environment variable, so it could >>> potentially >>> be anything of any length... >>> >>> The Debian bug posted above has an example, though I couldn't >>> replicate it. >>> >> I couldn't replicate it either and was just curious if anyone managed >> to >> demonstrate it. >> > > Yeah, I tend to think it's more potentially exploitable rather than something > that's actually been hit. > >> -Alan. >> > > Thanks, From stuart.marks at oracle.com Thu Aug 2 02:19:32 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 01 Aug 2012 19:19:32 -0700 Subject: Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop In-Reply-To: <50171C0B.4010401@oracle.com> References: <50170A68.1080508@oracle.com> <50171C0B.4010401@oracle.com> Message-ID: <5019E3B4.1070209@oracle.com> On 7/30/12 4:43 PM, David Holmes wrote: > On 31/07/2012 8:27 AM, Darryl Mocek wrote: >> Hello core-libs. Please review this webrev to fix Bug #7187876. Webrev >> can be found here: http://cr.openjdk.java.net/~dmocek/7187876/webrev.00. >> >> The rmi/transport/acceptLoop/CloseServerSocketOnTermination.java test >> throws ClassCastException due to the Throwable not being of type Error >> in TCPTransport. > > Just wondering what type it was? Something that extends Throwable directly? > > This: > > throw new Error(t.getMessage(), t.getCause()); > > loses the type of exception that was thrown. It is better to use: > > throw new Error(t); The suggestion to use new Error(t) is a good one. This case is kind of pathological. The CloseServerSocketOnTermination test injects an exception of an arbitrary type into the accept loop of an RMI connection. (See the test to see how it does this; it's rather clever.) The cast error occurs when the exception that's injected is an instance of Throwable. Oh, one more thing. Mike Duigou pointed out to me that there is something called UndeclaredThrowableException. Should we throw new UndeclaredThrowableException(t) instead? s'marks From david.holmes at oracle.com Thu Aug 2 03:05:47 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 02 Aug 2012 13:05:47 +1000 Subject: Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop In-Reply-To: <5019E3B4.1070209@oracle.com> References: <50170A68.1080508@oracle.com> <50171C0B.4010401@oracle.com> <5019E3B4.1070209@oracle.com> Message-ID: <5019EE8B.4040400@oracle.com> Hi Stuart, On 2/08/2012 12:19 PM, Stuart Marks wrote: > On 7/30/12 4:43 PM, David Holmes wrote: >> On 31/07/2012 8:27 AM, Darryl Mocek wrote: >>> Hello core-libs. Please review this webrev to fix Bug #7187876. Webrev >>> can be found here: http://cr.openjdk.java.net/~dmocek/7187876/webrev.00. >>> >>> The rmi/transport/acceptLoop/CloseServerSocketOnTermination.java test >>> throws ClassCastException due to the Throwable not being of type Error >>> in TCPTransport. >> >> Just wondering what type it was? Something that extends Throwable >> directly? >> >> This: >> >> throw new Error(t.getMessage(), t.getCause()); >> >> loses the type of exception that was thrown. It is better to use: >> >> throw new Error(t); > > The suggestion to use new Error(t) is a good one. > > This case is kind of pathological. The CloseServerSocketOnTermination > test injects an exception of an arbitrary type into the accept loop of > an RMI connection. (See the test to see how it does this; it's rather > clever.) The cast error occurs when the exception that's injected is an > instance of Throwable. I see. Can the real code actually throw an arbitrary subclass of Throwable? > Oh, one more thing. Mike Duigou pointed out to me that there is > something called UndeclaredThrowableException. Should we throw new > UndeclaredThrowableException(t) instead? It is semantically more correct as that is what we have - Throwable suclasses are checked exceptions unless Errors or RuntimeExceptions. David > s'marks From stuart.marks at oracle.com Thu Aug 2 04:13:55 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 01 Aug 2012 21:13:55 -0700 Subject: Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop In-Reply-To: <5019EE8B.4040400@oracle.com> References: <50170A68.1080508@oracle.com> <50171C0B.4010401@oracle.com> <5019E3B4.1070209@oracle.com> <5019EE8B.4040400@oracle.com> Message-ID: <5019FE83.8030503@oracle.com> On 8/1/12 8:05 PM, David Holmes wrote: >> This case is kind of pathological. The CloseServerSocketOnTermination >> test injects an exception of an arbitrary type into the accept loop of >> an RMI connection. (See the test to see how it does this; it's rather >> clever.) The cast error occurs when the exception that's injected is an >> instance of Throwable. > > I see. Can the real code actually throw an arbitrary subclass of Throwable? It potentially can. At least, this code isn't under the control of RMI. The exception/throwable might be thrown from calls on a ServerSocket (or subclass) created by an RMIServerSocketFactory, which is supplied by the user. It's hard to conceive why it would throw something other than Error or Exception, but you never know what those darned users are going to do. :-) >> Oh, one more thing. Mike Duigou pointed out to me that there is >> something called UndeclaredThrowableException. Should we throw new >> UndeclaredThrowableException(t) instead? > > It is semantically more correct as that is what we have - Throwable suclasses > are checked exceptions unless Errors or RuntimeExceptions. OK, let's go with UndeclaredThrowableException then. Thanks. s'marks From ahughes at redhat.com Thu Aug 2 09:35:00 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 2 Aug 2012 05:35:00 -0400 (EDT) Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <5019E28C.1060603@oracle.com> Message-ID: <1067886450.7514062.1343900100019.JavaMail.root@redhat.com> ----- Original Message ----- > Andrew et al, > > AFAICS here: > > 220 encoding_variant = malloc(strlen(temp)+1); > 221 if (encoding_variant == NULL) { > 222 JNU_ThrowOutOfMemoryError(env, NULL); > 223 return 0; > 224 } > > we also need to do free(temp). Similarly later where we return with > OOM > due to realloc failure, don't we also need to free what was > previously > malloc'd? > I was thinking the same just before committing, but didn't want to delay the main fix any further. While logically we do need one, I'm not sure it's worthwhile if we're going to throw the exception and exit anyway? Will the return even be reached? If we're already near enough to OOM that we can't allocate more memory, it's unlikely freeing temp is going to get us much, and I presume it will be freed anyway when the VM process exists. But I can add it if necessary. It's trivial after all and does not real harm. > David > > On 2/08/2012 7:18 AM, Andrew Hughes wrote: > > > > > > ----- Original Message ----- > >> On 01/08/2012 14:52, Andrew Hughes wrote: > >>> : > >>> > >>> > >>> In any case, there is a Sun bug open for this: > >>> > >>> 6844255: Potential stack corruption in GetJavaProperties > >>> > >>> Can I take it that I can just get on and push Omair's extended > >>> version now then, > >>> with that bug ID? > >> Yes, go ahead, I should have said that in my mail. > >> > > > > Thanks. > > > > Done: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-August/010993.html > > > > with Omair as author and yourself and I as reviewers. > > > >>> Well, the locale can be set be an environment variable, so it > >>> could > >>> potentially > >>> be anything of any length... > >>> > >>> The Debian bug posted above has an example, though I couldn't > >>> replicate it. > >>> > >> I couldn't replicate it either and was just curious if anyone > >> managed > >> to > >> demonstrate it. > >> > > > > Yeah, I tend to think it's more potentially exploitable rather than > > something > > that's actually been hit. > > > >> -Alan. > >> > > > > Thanks, > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Thu Aug 2 10:18:44 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 2 Aug 2012 06:18:44 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <488466687.5562242.1343690667873.JavaMail.root@redhat.com> Message-ID: <440643475.7539644.1343902724375.JavaMail.root@redhat.com> ----- Original Message ----- > Hi all, > > In OpenJDK 8, some support has already been added for using the > system installation of zlib > (see the thread > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010967.html), > which is very similar to the support we've had in IcedTea for the > last five years (wow, has > it really been that long?). > > This is great news for us, as it's less work we have to do in > upstreaming the patch (though > 7 still needs to be dealt with). As is, the following webrev: > > http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.01/ > > just fixes a few minor issues to match our existing setup, and fixes > a bug found when testing > the existing support. In detail, the webrev: > > * Replaces the hardcoded use of "-lz" with $(ZLIB_LIBS) and > $(ZLIB_CFLAGS), now set in > make_jdk_generic_profile.sh. > * Replaces "zlib.h" usage with (mainly to reduce difference, > searching '.' has no effect either way) > * Stops uLong being defined if SYSTEM_ZLIB is set, even if we're not > on Mac OS X. Without this fix, the build fails. > > Ok for the build forest? If so, can I please have a bug ID for this? > > Thanks, > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > > Any update on this? Submission to tl, rather than build, now planned, as suggested by Alan. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Thu Aug 2 14:34:39 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 03 Aug 2012 00:34:39 +1000 Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <1067886450.7514062.1343900100019.JavaMail.root@redhat.com> References: <1067886450.7514062.1343900100019.JavaMail.root@redhat.com> Message-ID: <501A8FFF.9090803@oracle.com> Hi Andrew, On 2/08/2012 7:35 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Andrew et al, >> >> AFAICS here: >> >> 220 encoding_variant = malloc(strlen(temp)+1); >> 221 if (encoding_variant == NULL) { >> 222 JNU_ThrowOutOfMemoryError(env, NULL); >> 223 return 0; >> 224 } >> >> we also need to do free(temp). Similarly later where we return with >> OOM >> due to realloc failure, don't we also need to free what was >> previously >> malloc'd? >> > > I was thinking the same just before committing, but didn't want to delay > the main fix any further. > > While logically we do need one, I'm not sure it's worthwhile if we're going > to throw the exception and exit anyway? Will the return even be reached? > If we're already near enough to OOM that we can't allocate more memory, > it's unlikely freeing temp is going to get us much, and I presume it will > be freed anyway when the VM process exists. Are we definitely going to exit on this error? I agree if we're out of memory we're likely to continue to run into problems if we try to continue. But I'd prefer to see proper cleanup rather than making assumptions about the context in which the code is used. > But I can add it if necessary. It's trivial after all and does not real > harm. It will also prevent us getting flagged with memory-leak warnings/errors from static analysis tools. Thanks, David >> David >> >> On 2/08/2012 7:18 AM, Andrew Hughes wrote: >>> >>> >>> ----- Original Message ----- >>>> On 01/08/2012 14:52, Andrew Hughes wrote: >>>>> : >>>>> >>>>> >>>>> In any case, there is a Sun bug open for this: >>>>> >>>>> 6844255: Potential stack corruption in GetJavaProperties >>>>> >>>>> Can I take it that I can just get on and push Omair's extended >>>>> version now then, >>>>> with that bug ID? >>>> Yes, go ahead, I should have said that in my mail. >>>> >>> >>> Thanks. >>> >>> Done: >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-August/010993.html >>> >>> with Omair as author and yourself and I as reviewers. >>> >>>>> Well, the locale can be set be an environment variable, so it >>>>> could >>>>> potentially >>>>> be anything of any length... >>>>> >>>>> The Debian bug posted above has an example, though I couldn't >>>>> replicate it. >>>>> >>>> I couldn't replicate it either and was just curious if anyone >>>> managed >>>> to >>>> demonstrate it. >>>> >>> >>> Yeah, I tend to think it's more potentially exploitable rather than >>> something >>> that's actually been hit. >>> >>>> -Alan. >>>> >>> >>> Thanks, >> > From sean.mullan at oracle.com Thu Aug 2 14:43:22 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 02 Aug 2012 14:43:22 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120802144350.F260647318@hg.openjdk.java.net> Changeset: b0bfa441d70f Author: mullan Date: 2012-08-02 10:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b0bfa441d70f 7026347: Certificate and X509CRL should have verify(PublicKey key, Provider sigProvider) Reviewed-by: mullan, xuelei, weijun Contributed-by: jason.uh at oracle.com ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java + test/sun/security/x509/X509CRLImpl/Verify.java + test/sun/security/x509/X509CertImpl/Verify.java Changeset: 4e8bafdcefda Author: mullan Date: 2012-08-02 10:42 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4e8bafdcefda Merge From xueming.shen at oracle.com Thu Aug 2 17:47:16 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 02 Aug 2012 10:47:16 -0700 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <440643475.7539644.1343902724375.JavaMail.root@redhat.com> References: <440643475.7539644.1343902724375.JavaMail.root@redhat.com> Message-ID: <501ABD24.9040708@oracle.com> Hi Andrew, I do have a ref# for this enhancement #7110151. Though my original idea is to also have a configurable mechanism to switch the zlib usage during the jvm startup (-D option for example). Let's use this one for your patch. I will take a look your patch this week. -Sherman On 08/02/2012 03:18 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Hi all, >> >> In OpenJDK 8, some support has already been added for using the >> system installation of zlib >> (see the thread >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010967.html), >> which is very similar to the support we've had in IcedTea for the >> last five years (wow, has >> it really been that long?). >> >> This is great news for us, as it's less work we have to do in >> upstreaming the patch (though >> 7 still needs to be dealt with). As is, the following webrev: >> >> http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.01/ >> >> just fixes a few minor issues to match our existing setup, and fixes >> a bug found when testing >> the existing support. In detail, the webrev: >> >> * Replaces the hardcoded use of "-lz" with $(ZLIB_LIBS) and >> $(ZLIB_CFLAGS), now set in >> make_jdk_generic_profile.sh. >> * Replaces "zlib.h" usage with (mainly to reduce difference, >> searching '.' has no effect either way) >> * Stops uLong being defined if SYSTEM_ZLIB is set, even if we're not >> on Mac OS X. Without this fix, the build fails. >> >> Ok for the build forest? If so, can I please have a bug ID for this? >> >> Thanks, >> -- >> Andrew :) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: 248BDC07 (https://keys.indymedia.org/) >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >> >> > Any update on this? Submission to tl, rather than build, now planned, as suggested by Alan. From xueming.shen at oracle.com Thu Aug 2 18:26:47 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 02 Aug 2012 11:26:47 -0700 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <1914940317.7815059.1343931237601.JavaMail.root@redhat.com> References: <1914940317.7815059.1343931237601.JavaMail.root@redhat.com> Message-ID: <501AC667.8070500@oracle.com> On 08/02/2012 11:13 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Hi Andrew, >> >> I do have a ref# for this enhancement #7110151. Though my original >> idea >> is to also have >> a configurable mechanism to switch the zlib usage during the jvm >> startup >> (-D option for >> example). Let's use this one for your patch. I will take a look your >> patch this week. >> > How would that work if we don't compile the in-tree version? The "original" thought is to still bundle the jdk version of zlib, but simply not use it if the underlying platform has its own version installed, or the user prefers to specify a "better" one (like the zlib in Intel's IPP, if you are licensed to use one when on intel's platform) -Sherman >> -Sherman >> >> On 08/02/2012 03:18 AM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Hi all, >>>> >>>> In OpenJDK 8, some support has already been added for using the >>>> system installation of zlib >>>> (see the thread >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010967.html), >>>> which is very similar to the support we've had in IcedTea for the >>>> last five years (wow, has >>>> it really been that long?). >>>> >>>> This is great news for us, as it's less work we have to do in >>>> upstreaming the patch (though >>>> 7 still needs to be dealt with). As is, the following webrev: >>>> >>>> http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.01/ >>>> >>>> just fixes a few minor issues to match our existing setup, and >>>> fixes >>>> a bug found when testing >>>> the existing support. In detail, the webrev: >>>> >>>> * Replaces the hardcoded use of "-lz" with $(ZLIB_LIBS) and >>>> $(ZLIB_CFLAGS), now set in >>>> make_jdk_generic_profile.sh. >>>> * Replaces "zlib.h" usage with (mainly to reduce >>>> difference, >>>> searching '.' has no effect either way) >>>> * Stops uLong being defined if SYSTEM_ZLIB is set, even if we're >>>> not >>>> on Mac OS X. Without this fix, the build fails. >>>> >>>> Ok for the build forest? If so, can I please have a bug ID for >>>> this? >>>> >>>> Thanks, >>>> -- >>>> Andrew :) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>>> >>>> >>> Any update on this? Submission to tl, rather than build, now >>> planned, as suggested by Alan. >> From ahughes at redhat.com Thu Aug 2 18:31:40 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 2 Aug 2012 14:31:40 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <501AC667.8070500@oracle.com> Message-ID: <953069159.7825215.1343932300045.JavaMail.root@redhat.com> ----- Original Message ----- > On 08/02/2012 11:13 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> Hi Andrew, > >> > >> I do have a ref# for this enhancement #7110151. Though my original > >> idea > >> is to also have > >> a configurable mechanism to switch the zlib usage during the jvm > >> startup > >> (-D option for > >> example). Let's use this one for your patch. I will take a look > >> your > >> patch this week. > >> > > How would that work if we don't compile the in-tree version? > > The "original" thought is to still bundle the jdk version of zlib, > but > simply not > use it if the underlying platform has its own version installed, or > the user > prefers to specify a "better" one (like the zlib in Intel's IPP, if > you > are licensed > to use one when on intel's platform) Ok, I thought that's what you were aiming at. That wouldn't solve the problem for us. We can't include a version of zlib in OpenJDK. It violates distribution policies and means security updates have to be applied in two places. We've been carrying patches for zlib (and jpeg, png, etc.) for years to avoid this. Our build actually deletes the source files before building to ensure this doesn't happen. > > -Sherman > > >> -Sherman > >> > >> On 08/02/2012 03:18 AM, Andrew Hughes wrote: > >>> ----- Original Message ----- > >>>> Hi all, > >>>> > >>>> In OpenJDK 8, some support has already been added for using the > >>>> system installation of zlib > >>>> (see the thread > >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010967.html), > >>>> which is very similar to the support we've had in IcedTea for > >>>> the > >>>> last five years (wow, has > >>>> it really been that long?). > >>>> > >>>> This is great news for us, as it's less work we have to do in > >>>> upstreaming the patch (though > >>>> 7 still needs to be dealt with). As is, the following webrev: > >>>> > >>>> http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.01/ > >>>> > >>>> just fixes a few minor issues to match our existing setup, and > >>>> fixes > >>>> a bug found when testing > >>>> the existing support. In detail, the webrev: > >>>> > >>>> * Replaces the hardcoded use of "-lz" with $(ZLIB_LIBS) and > >>>> $(ZLIB_CFLAGS), now set in > >>>> make_jdk_generic_profile.sh. > >>>> * Replaces "zlib.h" usage with (mainly to reduce > >>>> difference, > >>>> searching '.' has no effect either way) > >>>> * Stops uLong being defined if SYSTEM_ZLIB is set, even if we're > >>>> not > >>>> on Mac OS X. Without this fix, the build fails. > >>>> > >>>> Ok for the build forest? If so, can I please have a bug ID for > >>>> this? > >>>> > >>>> Thanks, > >>>> -- > >>>> Andrew :) > >>>> > >>>> Free Java Software Engineer > >>>> Red Hat, Inc. (http://www.redhat.com) > >>>> > >>>> PGP Key: 248BDC07 (https://keys.indymedia.org/) > >>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > >>>> > >>>> > >>> Any update on this? Submission to tl, rather than build, now > >>> planned, as suggested by Alan. > >> > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Thu Aug 2 18:13:57 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 2 Aug 2012 14:13:57 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <501ABD24.9040708@oracle.com> Message-ID: <1914940317.7815059.1343931237601.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Andrew, > > I do have a ref# for this enhancement #7110151. Though my original > idea > is to also have > a configurable mechanism to switch the zlib usage during the jvm > startup > (-D option for > example). Let's use this one for your patch. I will take a look your > patch this week. > How would that work if we don't compile the in-tree version? > -Sherman > > On 08/02/2012 03:18 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> Hi all, > >> > >> In OpenJDK 8, some support has already been added for using the > >> system installation of zlib > >> (see the thread > >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010967.html), > >> which is very similar to the support we've had in IcedTea for the > >> last five years (wow, has > >> it really been that long?). > >> > >> This is great news for us, as it's less work we have to do in > >> upstreaming the patch (though > >> 7 still needs to be dealt with). As is, the following webrev: > >> > >> http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.01/ > >> > >> just fixes a few minor issues to match our existing setup, and > >> fixes > >> a bug found when testing > >> the existing support. In detail, the webrev: > >> > >> * Replaces the hardcoded use of "-lz" with $(ZLIB_LIBS) and > >> $(ZLIB_CFLAGS), now set in > >> make_jdk_generic_profile.sh. > >> * Replaces "zlib.h" usage with (mainly to reduce > >> difference, > >> searching '.' has no effect either way) > >> * Stops uLong being defined if SYSTEM_ZLIB is set, even if we're > >> not > >> on Mac OS X. Without this fix, the build fails. > >> > >> Ok for the build forest? If so, can I please have a bug ID for > >> this? > >> > >> Thanks, > >> -- > >> Andrew :) > >> > >> Free Java Software Engineer > >> Red Hat, Inc. (http://www.redhat.com) > >> > >> PGP Key: 248BDC07 (https://keys.indymedia.org/) > >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > >> > >> > > Any update on this? Submission to tl, rather than build, now > > planned, as suggested by Alan. > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From darryl.mocek at oracle.com Thu Aug 2 20:50:05 2012 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Thu, 02 Aug 2012 13:50:05 -0700 Subject: Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop In-Reply-To: <5019FE83.8030503@oracle.com> References: <50170A68.1080508@oracle.com> <50171C0B.4010401@oracle.com> <5019E3B4.1070209@oracle.com> <5019EE8B.4040400@oracle.com> <5019FE83.8030503@oracle.com> Message-ID: <501AE7FD.5040808@oracle.com> Patch attached using UndeclaredThrowableException. Darryl On Wed 01 Aug 2012 09:13:55 PM PDT, Stuart Marks wrote: > > On 8/1/12 8:05 PM, David Holmes wrote: >> >>> >>> This case is kind of pathological. The CloseServerSocketOnTermination >>> test injects an exception of an arbitrary type into the accept loop of >>> an RMI connection. (See the test to see how it does this; it's rather >>> clever.) The cast error occurs when the exception that's injected is an >>> instance of Throwable. >> >> >> I see. Can the real code actually throw an arbitrary subclass of >> Throwable? > > > It potentially can. At least, this code isn't under the control of > RMI. The exception/throwable might be thrown from calls on a > ServerSocket (or subclass) created by an RMIServerSocketFactory, which > is supplied by the user. It's hard to conceive why it would throw > something other than Error or Exception, but you never know what those > darned users are going to do. :-) > >> >>> >>> Oh, one more thing. Mike Duigou pointed out to me that there is >>> something called UndeclaredThrowableException. Should we throw new >>> UndeclaredThrowableException(t) instead? >> >> >> It is semantically more correct as that is what we have - Throwable >> suclasses >> are checked exceptions unless Errors or RuntimeExceptions. > > > OK, let's go with UndeclaredThrowableException then. > > Thanks. > > s'marks From darryl.mocek at oracle.com Thu Aug 2 21:06:52 2012 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Thu, 02 Aug 2012 14:06:52 -0700 Subject: Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop In-Reply-To: <501AE7FD.5040808@oracle.com> References: <50170A68.1080508@oracle.com> <50171C0B.4010401@oracle.com> <5019E3B4.1070209@oracle.com> <5019EE8B.4040400@oracle.com> <5019FE83.8030503@oracle.com> <501AE7FD.5040808@oracle.com> Message-ID: <501AEBEC.8090003@oracle.com> Let's try again... Darryl On Thu 02 Aug 2012 01:50:05 PM PDT, Darryl Mocek wrote: > > Patch attached using UndeclaredThrowableException. > > Darryl > > On Wed 01 Aug 2012 09:13:55 PM PDT, Stuart Marks wrote: >> >> >> On 8/1/12 8:05 PM, David Holmes wrote: >>> >>> >>>> >>>> >>>> This case is kind of pathological. The CloseServerSocketOnTermination >>>> test injects an exception of an arbitrary type into the accept loop of >>>> an RMI connection. (See the test to see how it does this; it's rather >>>> clever.) The cast error occurs when the exception that's injected >>>> is an >>>> instance of Throwable. >>> >>> >>> >>> I see. Can the real code actually throw an arbitrary subclass of >>> Throwable? >> >> >> >> It potentially can. At least, this code isn't under the control of >> RMI. The exception/throwable might be thrown from calls on a >> ServerSocket (or subclass) created by an RMIServerSocketFactory, which >> is supplied by the user. It's hard to conceive why it would throw >> something other than Error or Exception, but you never know what those >> darned users are going to do. :-) >> >>> >>> >>>> >>>> >>>> Oh, one more thing. Mike Duigou pointed out to me that there is >>>> something called UndeclaredThrowableException. Should we throw new >>>> UndeclaredThrowableException(t) instead? >>> >>> >>> >>> It is semantically more correct as that is what we have - Throwable >>> suclasses >>> are checked exceptions unless Errors or RuntimeExceptions. >> >> >> >> OK, let's go with UndeclaredThrowableException then. >> >> Thanks. >> >> s'marks From darryl.mocek at oracle.com Thu Aug 2 21:14:28 2012 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Thu, 02 Aug 2012 14:14:28 -0700 Subject: Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop In-Reply-To: <501AEBEC.8090003@oracle.com> References: <50170A68.1080508@oracle.com> <50171C0B.4010401@oracle.com> <5019E3B4.1070209@oracle.com> <5019EE8B.4040400@oracle.com> <5019FE83.8030503@oracle.com> <501AE7FD.5040808@oracle.com> <501AEBEC.8090003@oracle.com> Message-ID: <501AEDB4.2040504@oracle.com> OK, not attachments allowed. Webrev can be found here: http://cr.openjdk.java.net/~dmocek/7187876/webrev.02 Darryl On Thu 02 Aug 2012 02:06:52 PM PDT, Darryl Mocek wrote: > > Let's try again... > > Darryl > > On Thu 02 Aug 2012 01:50:05 PM PDT, Darryl Mocek wrote: >> >> >> Patch attached using UndeclaredThrowableException. >> >> Darryl >> >> On Wed 01 Aug 2012 09:13:55 PM PDT, Stuart Marks wrote: >>> >>> >>> >>> On 8/1/12 8:05 PM, David Holmes wrote: >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> This case is kind of pathological. The CloseServerSocketOnTermination >>>>> test injects an exception of an arbitrary type into the accept >>>>> loop of >>>>> an RMI connection. (See the test to see how it does this; it's rather >>>>> clever.) The cast error occurs when the exception that's injected >>>>> is an >>>>> instance of Throwable. >>>> >>>> >>>> >>>> >>>> I see. Can the real code actually throw an arbitrary subclass of >>>> Throwable? >>> >>> >>> >>> >>> It potentially can. At least, this code isn't under the control of >>> RMI. The exception/throwable might be thrown from calls on a >>> ServerSocket (or subclass) created by an RMIServerSocketFactory, which >>> is supplied by the user. It's hard to conceive why it would throw >>> something other than Error or Exception, but you never know what those >>> darned users are going to do. :-) >>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> Oh, one more thing. Mike Duigou pointed out to me that there is >>>>> something called UndeclaredThrowableException. Should we throw new >>>>> UndeclaredThrowableException(t) instead? >>>> >>>> >>>> >>>> >>>> It is semantically more correct as that is what we have - Throwable >>>> suclasses >>>> are checked exceptions unless Errors or RuntimeExceptions. >>> >>> >>> >>> >>> OK, let's go with UndeclaredThrowableException then. >>> >>> Thanks. >>> >>> s'marks From xueming.shen at oracle.com Thu Aug 2 21:59:13 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 02 Aug 2012 14:59:13 -0700 Subject: Codereview request for 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native Message-ID: <501AF831.2070408@oracle.com> Hi This is the change to move the implementation of De/Inflater.getBytesRead/Written() from native to Java. Current JDK implementation uses zlib's z_stream.total_in/out fields, which are "uLong" type in original zlib source code. This may limit these two counters to 4GB on 32-bit OS [1]. These two fields are currently patched to "long long" in JDK to support the > 4G counting. It is suggested that it might be better to move this > 4G counting support to java level to remove the dependency on patching the original zlib source code, which might be critical in situation that Java runtime prefers to use OS bundled zlib, instead of the JDK bundled zlib library. Here is the webrev http://cr.openjdk.java.net/~sherman/7188852/webrev/ The test case attached only tests upto 128M by default (for running in auto testing). The test can be run manually with option "large" to test > 4G de/inflating. It takes > 4 minutes to compress/decompress 5G bytes on my linux box, guess it's probably not desirable to hold each/every run for so long in auto setting. Thanks, Sherman [1] http://www.zlib.net/zlib_faq.html#faq32 From ahughes at redhat.com Thu Aug 2 22:03:12 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 2 Aug 2012 18:03:12 -0400 (EDT) Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <501A8FFF.9090803@oracle.com> Message-ID: <1158150856.7880413.1343944992157.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Andrew, > > On 2/08/2012 7:35 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> Andrew et al, > >> > >> AFAICS here: > >> > >> 220 encoding_variant = malloc(strlen(temp)+1); > >> 221 if (encoding_variant == NULL) { > >> 222 JNU_ThrowOutOfMemoryError(env, NULL); > >> 223 return 0; > >> 224 } > >> > >> we also need to do free(temp). Similarly later where we return > >> with > >> OOM > >> due to realloc failure, don't we also need to free what was > >> previously > >> malloc'd? > >> > > > > I was thinking the same just before committing, but didn't want to > > delay > > the main fix any further. > > > > While logically we do need one, I'm not sure it's worthwhile if > > we're going > > to throw the exception and exit anyway? Will the return even be > > reached? > > If we're already near enough to OOM that we can't allocate more > > memory, > > it's unlikely freeing temp is going to get us much, and I presume > > it will > > be freed anyway when the VM process exists. > > Are we definitely going to exit on this error? I agree if we're out > of > memory we're likely to continue to run into problems if we try to > continue. But I'd prefer to see proper cleanup rather than making > assumptions about the context in which the code is used. > > > But I can add it if necessary. It's trivial after all and does not > > real > > harm. > > It will also prevent us getting flagged with memory-leak > warnings/errors > from static analysis tools. > This should cover it, I think: http://cr.openjdk.java.net/~andrew/buffer_overflow/webrev.02/ but it'll need a bug ID. > Thanks, > David > > >> David > >> > >> On 2/08/2012 7:18 AM, Andrew Hughes wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> On 01/08/2012 14:52, Andrew Hughes wrote: > >>>>> : > >>>>> > >>>>> > >>>>> In any case, there is a Sun bug open for this: > >>>>> > >>>>> 6844255: Potential stack corruption in GetJavaProperties > >>>>> > >>>>> Can I take it that I can just get on and push Omair's extended > >>>>> version now then, > >>>>> with that bug ID? > >>>> Yes, go ahead, I should have said that in my mail. > >>>> > >>> > >>> Thanks. > >>> > >>> Done: > >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-August/010993.html > >>> > >>> with Omair as author and yourself and I as reviewers. > >>> > >>>>> Well, the locale can be set be an environment variable, so it > >>>>> could > >>>>> potentially > >>>>> be anything of any length... > >>>>> > >>>>> The Debian bug posted above has an example, though I couldn't > >>>>> replicate it. > >>>>> > >>>> I couldn't replicate it either and was just curious if anyone > >>>> managed > >>>> to > >>>> demonstrate it. > >>>> > >>> > >>> Yeah, I tend to think it's more potentially exploitable rather > >>> than > >>> something > >>> that's actually been hit. > >>> > >>>> -Alan. > >>>> > >>> > >>> Thanks, > >> > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From stuart.marks at oracle.com Fri Aug 3 01:10:45 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 03 Aug 2012 01:10:45 +0000 Subject: hg: jdk8/tl/jdk: 7187876: ClassCastException in TCPTransport.executeAcceptLoop Message-ID: <20120803011056.B618C47338@hg.openjdk.java.net> Changeset: 8a82e5f9c47f Author: dmocek Date: 2012-08-02 18:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a82e5f9c47f 7187876: ClassCastException in TCPTransport.executeAcceptLoop Reviewed-by: dholmes, smarks ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java From stuart.marks at oracle.com Fri Aug 3 01:17:02 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 02 Aug 2012 18:17:02 -0700 Subject: Code Review Request 7187876: ClassCastException in TCPTransport.executeAcceptLoop In-Reply-To: <501AEDB4.2040504@oracle.com> References: <50170A68.1080508@oracle.com> <50171C0B.4010401@oracle.com> <5019E3B4.1070209@oracle.com> <5019EE8B.4040400@oracle.com> <5019FE83.8030503@oracle.com> <501AE7FD.5040808@oracle.com> <501AEBEC.8090003@oracle.com> <501AEDB4.2040504@oracle.com> Message-ID: <501B268E.2000002@oracle.com> Looks good. Pushed, http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a82e5f9c47f Please set the bug to Fix-Available in "beta" and add the "noreg-cleanup" keyword. s'marks On 8/2/12 2:14 PM, Darryl Mocek wrote: > OK, not attachments allowed. Webrev can be found here: > http://cr.openjdk.java.net/~dmocek/7187876/webrev.02 > > Darryl > > On Thu 02 Aug 2012 02:06:52 PM PDT, Darryl Mocek wrote: >> >> Let's try again... >> >> Darryl >> >> On Thu 02 Aug 2012 01:50:05 PM PDT, Darryl Mocek wrote: >>> >>> >>> Patch attached using UndeclaredThrowableException. >>> >>> Darryl >>> >>> On Wed 01 Aug 2012 09:13:55 PM PDT, Stuart Marks wrote: >>>> >>>> >>>> >>>> On 8/1/12 8:05 PM, David Holmes wrote: >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> This case is kind of pathological. The CloseServerSocketOnTermination >>>>>> test injects an exception of an arbitrary type into the accept >>>>>> loop of >>>>>> an RMI connection. (See the test to see how it does this; it's rather >>>>>> clever.) The cast error occurs when the exception that's injected >>>>>> is an >>>>>> instance of Throwable. >>>>> >>>>> >>>>> >>>>> >>>>> I see. Can the real code actually throw an arbitrary subclass of >>>>> Throwable? >>>> >>>> >>>> >>>> >>>> It potentially can. At least, this code isn't under the control of >>>> RMI. The exception/throwable might be thrown from calls on a >>>> ServerSocket (or subclass) created by an RMIServerSocketFactory, which >>>> is supplied by the user. It's hard to conceive why it would throw >>>> something other than Error or Exception, but you never know what those >>>> darned users are going to do. :-) >>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> Oh, one more thing. Mike Duigou pointed out to me that there is >>>>>> something called UndeclaredThrowableException. Should we throw new >>>>>> UndeclaredThrowableException(t) instead? >>>>> >>>>> >>>>> >>>>> >>>>> It is semantically more correct as that is what we have - Throwable >>>>> suclasses >>>>> are checked exceptions unless Errors or RuntimeExceptions. >>>> >>>> >>>> >>>> >>>> OK, let's go with UndeclaredThrowableException then. >>>> >>>> Thanks. >>>> >>>> s'marks From dingxmin at linux.vnet.ibm.com Fri Aug 3 07:39:53 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Fri, 03 Aug 2012 15:39:53 +0800 Subject: Improve registering signal handlers in java.lang.Terminator.setup() Message-ID: <501B8049.2020705@linux.vnet.ibm.com> Hi guys, I found that in java.lang.Terminator, setup() method, The following code of registering default signal handlers can be improved: / try { Signal.handle(new Signal("INT"), sh); Signal.handle(new Signal("TERM"), sh); } catch (IllegalArgumentException e) { }/ The revised code is illustrated below: / try { Signal.handle(new Signal("INT"), sh); } catch (IllegalArgumentException e) { } try { Signal.handle(new Signal("TERM"), sh); } catch (IllegalArgumentException e) { } /The improved version makes more sense since exception thrown from first Signal.handle call does not affect subsequent calls. This is more consistent with its original intention. A patch I made is available @ http://cr.openjdk.java.net/~youdwei/ojdk-430/webrev.00// /Could anybody please take a look at it? Thanks in advance/ Best regards, Frank / From maurizio.cimadamore at oracle.com Fri Aug 3 09:15:32 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 03 Aug 2012 09:15:32 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20120803091601.8756947361@hg.openjdk.java.net> Changeset: cddc2c894cc6 Author: mcimadamore Date: 2012-08-02 18:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cddc2c894cc6 7175911: Simplify error reporting API in Check.CheckContext interface Summary: Make error messages generated during Check.checkType more uniform and more scalable Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6840059/T6840059.out ! test/tools/javac/6979683/TestCast6979683_BAD34.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD35.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD36.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD37.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD38.java.errlog ! test/tools/javac/6979683/TestCast6979683_BAD39.java.errlog ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6722234/T6722234a_1.out ! test/tools/javac/Diagnostics/6722234/T6722234a_2.out ! test/tools/javac/Diagnostics/6722234/T6722234c.out ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/Diagnostics/6862608/T6862608a.out ! test/tools/javac/Diagnostics/6862608/T6862608b.out ! test/tools/javac/OverrideChecks/6400189/T6400189a.out ! test/tools/javac/OverrideChecks/6400189/T6400189b.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel1.out ! test/tools/javac/StringsInSwitch/BadlyTypedLabel2.out ! test/tools/javac/T6326754.out ! test/tools/javac/TryWithResources/TwrOnNonResource.out ! test/tools/javac/cast/6270087/T6270087neg.out ! test/tools/javac/cast/6557182/T6557182.out ! test/tools/javac/cast/6665356/T6665356.out ! test/tools/javac/cast/6795580/T6795580.out ! test/tools/javac/cast/6932571/T6932571neg.out ! test/tools/javac/cast/7005095/T7005095neg.out ! test/tools/javac/cast/7005671/T7005671.out ! test/tools/javac/diags/examples/CantApplyDiamond1.java ! test/tools/javac/diags/examples/IncompatibleTypes1.java ! test/tools/javac/diags/examples/InconvertibleTypes.java ! test/tools/javac/diags/examples/InferNoConformingAssignment.java ! test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java ! test/tools/javac/diags/examples/InferredDoNotConformToLower.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NoUniqueMaximalInstance.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PossibleLossPrecision.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereFreshTvar.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/6207386/T6207386.out ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg06.out ! test/tools/javac/generics/diamond/neg/Neg10.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/6638712/T6638712a.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712e.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/generics/inference/6838943/T6838943.out ! test/tools/javac/generics/inference/7086586/T7086586.out ! test/tools/javac/generics/inference/7154127/T7154127.out ! test/tools/javac/generics/rawOverride/7062745/T7062745neg.out ! test/tools/javac/generics/wildcards/6886247/T6886247_2.out ! test/tools/javac/multicatch/Neg06.out ! test/tools/javac/multicatch/Neg07.out ! test/tools/javac/types/CastObjectToPrimitiveTest.out ! test/tools/javac/varargs/6313164/T6313164.out ! test/tools/javac/varargs/7097436/T7097436.out Changeset: e5cf1569d3a4 Author: mcimadamore Date: 2012-08-02 18:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e5cf1569d3a4 7175538: Integrate efectively final check with DA/DU analysis Summary: Allow generalized effectively-final analysis for all local variables Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java + test/tools/javac/lambda/EffectivelyFinalTest.java + test/tools/javac/lambda/EffectivelyFinalTest01.out + test/tools/javac/lambda/EffectivelyFinalTest02.out Changeset: 2d75e7c952b8 Author: mcimadamore Date: 2012-08-02 18:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2d75e7c952b8 7187104: Inference cleanup: remove redundant exception classes in Infer.java Summary: Remove unused exception classes in Infer.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java From Alan.Bateman at oracle.com Fri Aug 3 10:40:16 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 Aug 2012 11:40:16 +0100 Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <5019E28C.1060603@oracle.com> References: <621822911.7298135.1343855884834.JavaMail.root@redhat.com> <5019E28C.1060603@oracle.com> Message-ID: <501BAA90.1050209@oracle.com> On 02/08/2012 03:14, David Holmes wrote: > Andrew et al, > > AFAICS here: > > 220 encoding_variant = malloc(strlen(temp)+1); > 221 if (encoding_variant == NULL) { > 222 JNU_ThrowOutOfMemoryError(env, NULL); > 223 return 0; > 224 } > > we also need to do free(temp). Similarly later where we return with > OOM due to realloc failure, don't we also need to free what was > previously malloc'd? > > David I see there are follow-on mails to this but just to say that this is System.initProperties time so if there is a malloc failure this early in startup then it will cause the VM initialization to fail. So for completeness (and perhaps native memory leak detection tools) then I agree but if we do have problems here then we aren't go to go very far. -Alan. From Alan.Bateman at oracle.com Fri Aug 3 11:20:57 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 Aug 2012 12:20:57 +0100 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <953069159.7825215.1343932300045.JavaMail.root@redhat.com> References: <953069159.7825215.1343932300045.JavaMail.root@redhat.com> Message-ID: <501BB419.2090301@oracle.com> On 02/08/2012 19:31, Andrew Hughes wrote: > : > > > Ok, I thought that's what you were aiming at. That wouldn't solve the problem > for us. We can't include a version of zlib in OpenJDK. It violates distribution > policies and means security updates have to be applied in two places. We've been > carrying patches for zlib (and jpeg, png, etc.) for years to avoid this. Our build > actually deletes the source files before building to ensure this doesn't happen. > As you know, we can't delete the zlib code as we still need it for other platforms, Windows mostly. From a brief scan of your patch (not a detailed review, too busy at the moment) then it looks like you've added a SYSTEM_ZLIB option to select (at build-time) whether to compile the version in the jdk repository or not. This approach make sense to me and should be separated from the changes needed to use an alternatively named zlib (which I think is what Intel IPP will require, assuming it can't be picked up by setting LD_LIBRARY_PATH). In any case, I think both efforts require 7188852 and I see Sherman has a review out on that. -Alan. From ahughes at redhat.com Fri Aug 3 15:59:56 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 3 Aug 2012 11:59:56 -0400 (EDT) Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <501BAA90.1050209@oracle.com> Message-ID: <165622234.8304360.1344009596913.JavaMail.root@redhat.com> ----- Original Message ----- > On 02/08/2012 03:14, David Holmes wrote: > > Andrew et al, > > > > AFAICS here: > > > > 220 encoding_variant = malloc(strlen(temp)+1); > > 221 if (encoding_variant == NULL) { > > 222 JNU_ThrowOutOfMemoryError(env, NULL); > > 223 return 0; > > 224 } > > > > we also need to do free(temp). Similarly later where we return with > > OOM due to realloc failure, don't we also need to free what was > > previously malloc'd? > > > > David > I see there are follow-on mails to this but just to say that this is > System.initProperties time so if there is a malloc failure this early > in > startup then it will cause the VM initialization to fail. So for > completeness (and perhaps native memory leak detection tools) then I > agree but if we do have problems here then we aren't go to go very > far. > This was my thinking too when I first spotted it. I've now posted a webrev following David's suggestions. > -Alan. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Fri Aug 3 15:58:35 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 3 Aug 2012 11:58:35 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <501BB419.2090301@oracle.com> Message-ID: <222513717.8303590.1344009515684.JavaMail.root@redhat.com> ----- Original Message ----- > On 02/08/2012 19:31, Andrew Hughes wrote: > > : > > > > > > Ok, I thought that's what you were aiming at. That wouldn't solve > > the problem > > for us. We can't include a version of zlib in OpenJDK. It > > violates distribution > > policies and means security updates have to be applied in two > > places. We've been > > carrying patches for zlib (and jpeg, png, etc.) for years to avoid > > this. Our build > > actually deletes the source files before building to ensure this > > doesn't happen. > > > As you know, we can't delete the zlib code as we still need it for > other > platforms, Windows mostly. Yes, that wasn't the suggestion. I was just pointing out that we delete it as a pre-build step, so any attempt to build it is going to fail :-) > From a brief scan of your patch (not a > detailed review, too busy at the moment) then it looks like you've > added > a SYSTEM_ZLIB option to select (at build-time) whether to compile the > version in the jdk repository or not. This approach make sense to me > and > should be separated from the changes needed to use an alternatively > named zlib (which I think is what Intel IPP will require, assuming it > can't be picked up by setting LD_LIBRARY_PATH). It's what we've had for years, and was added orthogonally to 8 in: changeset: 5118:d45bc4307996 user: michaelm date: Tue Mar 06 20:34:38 2012 +0000 summary: 7113349: Initial changeset for Macosx port to jdk though that version is broken (at least on GNU/Linux) without the change to defines.h I posted in my patch earlier this week. If IPP is binary compatible, surely setting ZLIB_LIBS/ZLIB_CFLAGS would be sufficient? I don't know how different they are. > > In any case, I think both efforts require 7188852 and I see Sherman > has > a review out on that. > Yes, I've just tried applying it this morning. Will test and report back. > -Alan. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From xueming.shen at oracle.com Fri Aug 3 16:54:47 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 03 Aug 2012 09:54:47 -0700 Subject: Fwd: JPRT: [sfbay] job notification - FAILED with job 2012-08-02-185552.sherman.zip Message-ID: <501C0257.5030607@oracle.com> Andrew, I see a build failure on macos with your patch. Any idea? -Sherman -------- Original Message -------- Received: from acsinet22.oracle.com (/141.146.126.238) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Aug 2012 18:00:58 -0700 Received: from jprt-west1.us.oracle.com (jprt-west1.us.oracle.com [10.133.137.52]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7310voP024695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2012 01:00:58 GMT Received: from jprt-west1.us.oracle.com (localhost [127.0.0.1]) by jprt-west1.us.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7310vg3003436; Thu, 2 Aug 2012 18:00:57 -0700 (PDT) Received: (from jprtadm at localhost) by jprt-west1.us.oracle.com (8.14.4+Sun/8.14.4/Submit) id q7310vJa003435; Thu, 2 Aug 2012 18:00:57 -0700 (PDT) Date: Thu, 2 Aug 2012 18:00:57 -0700 (PDT) From: jprt_admin_ww_grp at oracle.com Message-Id: <201208030100.q7310vJa003435 at jprt-west1.us.oracle.com> X-Authentication-Warning: jprt-west1.us.oracle.com: jprtadm set sender to jprt_admin_ww_grp at oracle.com using -r To: xueming.shen at oracle.com Cc: jprt_notify_ww_grp at oracle.com Subject: JPRT: [sfbay] job notification - FAILED with job 2012-08-02-185552.sherman.zip JPRT: [sfbay] job notification - FAILED with job 2012-08-02-185552.sherman.zip Failure reason: Targets failed, cannot continue. Target macosx_x64_10.7-product FAILED. JPRT Job ID: 2012-08-02-185552.sherman.zip JPRT System: sfbay JPRT Version: 2.3.9: (2012-07-23) Case of the Negligent Nymph [46c0169a9279] Job URL: http://prt-web.us.oracle.com//archive/2012/08/2012-08-02-185552.sherman.zip Job ARCHIVE: /net/prt-archiver.us.oracle.com/data/jprt/archive/2012/08/2012-08-02-185552.sherman.zip User: sherman - xueming.shen at oracle.com Release: jdk8 Source: Source Tree: /export/sherman/Workspace/jdk8_2/{langtools,jdk,make,Makefile,test} File List: {.} Exclude List: {jdk/build,langtools/build} Command Line: jprt submit -control 'langtools jdk' -ot '.*product.*' -noquickabort -nostandby -email xueming.shen at oracle.com -id zip -quickabortcount 500 Submitted at: Thursday August 2, 2012 12:00:19 PDT Time in queue: 06H 00m 37s Started at: Thursday August 2, 2012 16:18:33 PDT Finished at: Thursday August 2, 2012 18:00:57 PDT Run time: 01H 42m 24s Job state: FAILED Fail/kill comment: Targets failed, cannot continue. Target macosx_x64_10.7-product FAILED. Flags: Bundles: USE: jprt install 2012-08-02-185552.sherman.zip Run time: 01H 42m 24s Build Stats: 8 pass, 1 fail, 0 killed, 0 working, 0 initializing, 0 not started Test Stats: 45 pass, 0 fail, 0 killed, 0 working, 0 initializing, 5 not started HINT: Use 'jprt rerun -comment2012-08-02-185552.sherman.zip' to rerun this job if you suspect the results. User Comments: null Build (Release:jdk8 Boot: Import:): linux_i586_2.6-product success(09m 06s) USED: hostname=prt-x2200-1 platform=linux_i586_2.6 osname=linux osarch=i586 cpus=4 parallelcount=8 ram=3549MB instance=P1 TIMING: clean=17s init=31s work=8m12s fini=3s NEEDS: ant171,ccache,cups,freetype32,fxsdk8,fxsdk8lin32,gnumake381,jdk8drops,npapi linux_x64_2.6-product success(13m 54s) USED: hostname=prt-x2200-3 platform=linux_x64_2.6 osname=linux osarch=x64 cpus=4 parallelcount=8 ram=8006MB instance=P1 TIMING: clean=13s init=11s work=13m23s fini=4s NEEDS: ant171,ccache,cups,freetype64,fxsdk8,fxsdk8lin64,gnumake381,jdk8drops,npapi macosx_x64_10.7-product FAILED(03m 13s) USED: hostname=sc14ie03 platform=macosx_x64_10.7 osname=macosx osarch=x64 cpus=16 parallelcount=16 instance=P1 TIMING: clean=34s init=22s work=2m9s fini=4s NEEDS: ant171,cups,fxsdk8,fxsdk8mac64,gnumake381,jdk8drops,npapi,sparkle solaris_i586_5.10-product success(09m 53s) USED: hostname=jprt-host-x64-2 platform=solaris_i586_5.10 osname=solaris osarch=i586 cpus=16 parallelcount=32 ram=32256MB instance=P1 TIMING: clean=10s init=5s work=9m28s fini=7s NEEDS: SS121,ant171,ccache,cups,freetype32,freetype64,fxsdk8,gnumake381,jdk8drops,npapi solaris_sparc_5.10-product success(12m 06s) USED: hostname=sc11136038 platform=solaris_sparc_5.10 osname=solaris osarch=sparc cpus=8 parallelcount=16 ram=4096MB instance=P1 TIMING: clean=16s init=7s work=11m35s fini=5s NEEDS: SS121,ant171,ccache,cups,freetype32,freetype64,fxsdk8,gnumake381,jdk8drops,npapi solaris_sparcv9_5.10-product success(10m 51s) USED: hostname=sc11136037 platform=solaris_sparc_5.10 osname=solaris osarch=sparc cpus=8 parallelcount=16 ram=4096MB instance=P1 TIMING: clean=13s init=7s work=10m26s fini=2s NEEDS: SS121,ant171,ccache,cups,freetype32,freetype64,fxsdk8,gnumake381,jdk8drops,npapi solaris_x64_5.10-product success(09m 01s) USED: hostname=jprt-host-x64-1 platform=solaris_i586_5.10 osname=solaris osarch=i586 cpus=16 parallelcount=32 ram=32256MB instance=P1 TIMING: clean=8s init=7s work=8m41s fini=1s NEEDS: SS121,ant171,ccache,cups,freetype32,freetype64,fxsdk8,gnumake381,jdk8drops,npapi windows_i586_5.1-product success(42m 44s) USED: hostname=prt-win-x86-2 platform=windows_i586_5.1 osname=windows osarch=i586 cpus=2 parallelcount=2 ram=2047MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true ATTRS: compiler=VS2010 mks=true cygwin=true TIMING: clean=4m32s init=4m27s work=33m39s fini=3s NEEDS: ant171,freetype32,fxsdk8,fxsdk8win32,gnumake381,jdk8drops,mingw,mks,npapi,signing,sponsor_binaries1,sponsor_binaries2,wix35 windows_x64_5.2-product success(55m 26s) USED: hostname=jprt-win-x64-2 platform=windows_x64_5.2 osname=windows osarch=x64 cpus=4 parallelcount=4 ram=3967MB instance=P1 compiler=VS2003,VS2005,VS2008,VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true ATTRS: compiler=VS2010 mks=true cygwin=true TIMING: clean=4m16s init=4m41s work=46m23s fini=3s NEEDS: ant171,freetype64,fxsdk8,fxsdk8win64,gnumake381,jdk8drops,mingw,mks,npapi,signing,sponsor_binaries1,sponsor_binaries2,wix35 ------------------------------------------------------------------------------ macosx_x64_10.7-product (details from log file) /net/prt-archiver.us.oracle.com/data/jprt/archive/2012/08/2012-08-02-185552.sherman.zip/logs/macosx_x64_10.7-product.log http://prt-web.us.oracle.com//archive/2012/08/2012-08-02-185552.sherman.zip//logs/macosx_x64_10.7-product.log # Running javac: 40 files; in /private/tmp/jprt/P1/185552.sherman/s/jdk/make/java/sun_nio /opt/jprt/products/P1/jdk7u4-latest/1.7.0.jdk/Contents/Home/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar -jar /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar -Werror -Xlint:all -Xlint:-path -source 7 -target 7 -encoding ascii -Xbootclasspath:/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/classes -sourcepath ../../../src/closed/solaris/classes:../../../src/closed/share/classes:/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/gensrc:::/private/tmp/jprt/P1/185552.sherman/s/jdk/src/macosx/classes:/private/tmp/jprt/P1/185552.sherman/s/jdk/src/solaris/classes:/private/tmp/jprt/P1/185552.sherman/s/jdk/src/share/classes -d /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/classes @/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/sun/sun.nio/.classes.list.filtered # javac finished Building lib:/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/lib/jli/libjli.dylib Begin parallel compiles: /private/tmp/jprt/P1/185552.sherman/s/jdk/make/java/jli /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -F/System/Library/Frameworks/JavaVM.framework/Frameworks -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE -DRELEASE='"1.8.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 -I. -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders -I../../../src/closed/share/javavm/export -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/bin -I../../../src/macosx/bin -I../../../src/solaris/bin -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/java.o ../../../src/share/bin/java.c /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -F/System/Library/Frameworks/JavaVM.framework/Frameworks -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE -DRELEASE='"1.8.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 -I. -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders -I../../../src/closed/share/javavm/export -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/bin -I../../../src/macosx/bin -I../../../src/solaris/bin -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/splashscreen_stubs.o ../../../src/share/bin/splashscreen_stubs.c /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -F/System/Library/Frameworks/JavaVM.framework/Frameworks -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE -DRELEASE='"1.8.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 -I. -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders -I../../../src/closed/share/javavm/export -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/bin -I../../../src/macosx/bin -I../../../src/solaris/bin -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/version_comp.o ../../../src/share/bin/version_comp.c /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -F/System/Library/Frameworks/JavaVM.framework/Frameworks -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE -DRELEASE='"1.8.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 -I. -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders -I../../../src/closed/share/javavm/export -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/bin -I../../../src/macosx/bin -I../../../src/solaris/bin -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/parse_manifest.o ../../../src/share/bin/parse_manifest.c /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -F/System/Library/Frameworks/JavaVM.framework/Frameworks -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE -DRELEASE='"1.8.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 -I. -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders -I../../../src/closed/share/javavm/export -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/bin -I../../../src/macosx/bin -I../../../src/solaris/bin -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/wildcard.o ../../../src/share/bin/wildcard.c /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -F/System/Library/Frameworks/JavaVM.framework/Frameworks -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE -DRELEASE='"1.8.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 -I. -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders -I../../../src/closed/share/javavm/export -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/bin -I../../../src/macosx/bin -I../../../src/solaris/bin -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/jli_util.o ../../../src/share/bin/jli_util.c /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -F/System/Library/Frameworks/JavaVM.framework/Frameworks -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE -DRELEASE='"1.8.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 -I. -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders -I../../../src/closed/share/javavm/export -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/bin -I../../../src/macosx/bin -I../../../src/solaris/bin -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/java_md_common.o ../../../src/solaris/bin/java_md_common.c /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os -x objective-c -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -F/System/Library/Frameworks/JavaVM.framework/Frameworks -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE -DRELEASE='"1.8.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 -I. -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders -I../../../src/closed/share/javavm/export -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/bin -I../../../src/macosx/bin -I../../../src/solaris/bin -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/java_md_macosx.o ../../../src/macosx/bin/java_md_macosx.c ../../../src/macosx/bin/java_md_macosx.c: In function 'ContinueInNewThread0': ../../../src/macosx/bin/java_md_macosx.c:861: warning: cast from pointer to integer of different size Done with parallel compiles: /private/tmp/jprt/P1/185552.sherman/s/jdk/make/java/jli STATS: LIBRARY=jli, PRODUCT=java, OPTIMIZATION_LEVEL=HIGHER Rebuilding /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/lib/jli/libjli.dylib because of /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/.files_compiled /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN -F/System/Library/Frameworks/JavaVM.framework/Frameworks -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE -DRELEASE='"1.8.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 -I. -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders -I../../../src/closed/share/javavm/export -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/bin -I../../../src/macosx/bin -I../../../src/solaris/bin -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -m64 -Xlinker -rpath -Xlinker @loader_path/. -Xlinker -install_name -Xlinker @rpath/libjli.dylib -L/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/lib -framework Cocoa -framework Security -framework ApplicationServices -Wl,-install_name, at rpath/libjli.dylib -dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 -o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/lib/jli/libjli.dylib /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/java.o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/splashscreen_stubs.o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/parse_manifest.o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/version_comp.o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/wildcard.o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/jli_util.o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/java_md_common.o /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/java_md_macosx.o Undefined symbols for architecture x86_64: "_inflateInit2_", referenced from: _inflate_file in parse_manifest.o "_inflate", referenced from: _inflate_file in parse_manifest.o "_inflateEnd", referenced from: _inflate_file in parse_manifest.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make[4]: *** [/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/lib/jli/libjli.dylib] Error 1 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [jdk-build] Error 2 make: *** [build_product_image] Error 2 ########################################################### # # pwd: # /private/tmp/jprt/P1/185552.sherman/s # # uname -a: # Darwin sc14ie03.us.oracle.com 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64 # # df -k .: # Filesystem 1024-blocks Used Available Capacity Mounted on # /dev/disk0s2 1952674976 637575080 1314843896 33% / # # Finished: Thu Aug 2 16:22:53 PDT 2012 # # returned exit code 2 # ########################################################### ------------------------------------------------------------------------------ Tests: linux_i586-product-c1-jdk_lang success(06m 46s) STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 USED: hostname=sc11136024 platform=linux_i586_2.6 osname=linux osarch=i586 cpus=2 parallelcount=4 ram=3042MB instance=P1 TIMING: clean=3s init=18s work=6m21s fini=1s VMFLAGS: -client NEEDS: gnumake381,jtreg linux_i586-product-c1-jdk_math success(01m 27s) STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 USED: hostname=prt-x2200-1 platform=linux_i586_2.6 osname=linux osarch=i586 cpus=4 parallelcount=8 ram=3549MB instance=P1 TIMING: clean=7s init=39s work=38s fini=1s VMFLAGS: -client NEEDS: gnumake381,jtreg linux_i586-product-c1-jvm98 success(01m 02s) USED: hostname=sc11137363 platform=linux_x64_3.2 osname=linux osarch=x64 cpus=4 parallelcount=8 ram=7890MB instance=P1 TIMING: clean=2s init=6s work=50s fini=1s VMFLAGS: -client NEEDS: gnumake381,jtreg,jvm98 linux_i586-product-c1-langtools_jtreg success(13m 18s) USED: hostname=sc11137356 platform=linux_i586_2.6 osname=linux osarch=i586 cpus=4 parallelcount=8 ram=3041MB instance=P1 TIMING: clean=3s init=40s work=12m32s fini=1s VMFLAGS: -client NEEDS: gnumake381,jtreg linux_i586-product-c1-scimark success( 39s) USED: hostname=sc11137362 platform=linux_x64_3.2 osname=linux osarch=x64 cpus=4 parallelcount=8 ram=7890MB instance=P1 TIMING: clean=2s init=5s work=29s fini=1s VMFLAGS: -client NEEDS: gnumake381,jtreg,scimark linux_i586-product-c2-jdk_lang success(10m 06s) STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 USED: hostname=prt-x2200-2 platform=linux_i586_2.6 osname=linux osarch=i586 cpus=4 parallelcount=8 ram=3549MB instance=P1 TIMING: clean=7s init=47s work=9m9s fini=1s VMFLAGS: -server NEEDS: gnumake381,jtreg linux_i586-product-c2-jdk_math success( 38s) STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 USED: hostname=sc11137361 platform=linux_x64_3.2 osname=linux osarch=x64 cpus=4 parallelcount=8 ram=7890MB instance=P1 TIMING: clean=2s init=11s work=18s fini=4s VMFLAGS: -server NEEDS: gnumake381,jtreg linux_i586-product-c2-jvm98 success(01m 33s) USED: hostname=sc11137357 platform=linux_i586_2.6 osname=linux osarch=i586 cpus=4 parallelcount=8 ram=3041MB instance=P1 TIMING: clean=3s init=24s work=1m2s fini=1s VMFLAGS: -server NEEDS: gnumake381,jtreg,jvm98 linux_i586-product-c2-langtools_jtreg success(11m 39s) USED: hostname=sc11137355 platform=linux_i586_2.6 osname=linux osarch=i586 cpus=4 parallelcount=8 ram=3041MB instance=P1 TIMING: clean=3s init=38s work=10m55s fini=1s VMFLAGS: -server NEEDS: gnumake381,jtreg linux_i586-product-c2-scimark success( 43s) USED: hostname=sc11136053 platform=linux_i586_2.6 osname=linux osarch=i586 cpus=2 parallelcount=4 ram=3042MB instance=P1 TIMING: clean=3s init=6s work=31s fini=1s VMFLAGS: -server NEEDS: gnumake381,jtreg,scimark linux_x64-product-c2-jdk_lang success(05m 07s) STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 USED: hostname=sc11137361 platform=linux_x64_3.2 osname=linux osarch=x64 cpus=4 parallelcount=8 ram=7890MB instance=P1 TIMING: clean=2s init=9s work=4m52s fini=1s VMFLAGS: -server NEEDS: gnumake381,jtreg linux_x64-product-c2-jdk_math success( 58s) STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 USED: hostname=prt-x2200-3 platform=linux_x64_2.6 osname=linux osarch=x64 cpus=4 parallelcount=8 ram=8006MB instance=P1 TIMING: clean=8s init=17s work=30s fini=1s VMFLAGS: -server NEEDS: gnumake381,jtreg linux_x64-product-c2-jvm98 success( 46s) USED: hostname=sc11137362 platform=linux_x64_3.2 osname=linux osarch=x64 cpus=4 parallelcount=8 ram=7890MB instance=P1 TIMING: clean=1s init=5s work=37s fini=1s VMFLAGS: -server NEEDS: gnumake381,jtreg,jvm98 linux_x64-product-c2-langtools_jtreg success(06m 23s) USED: hostname=sc11137363 platform=linux_x64_3.2 osname=linux osarch=x64 cpus=4 parallelcount=8 ram=7890MB instance=P1 TIMING: clean=1s init=10s work=6m9s fini=1s VMFLAGS: -server NEEDS: gnumake381,jtreg linux_x64-product-c2-scimark success( 48s) USED: hostname=prt-x2200-4 platform=linux_x64_2.6 osname=linux osarch=x64 cpus=4 parallelcount=8 ram=8006MB instance=P1 TIMING: clean=8s init=7s work=30s fini=1s VMFLAGS: -server NEEDS: gnumake381,jtreg,scimark macosx_x64-product-c2-jdk_lang not_started( 00s) VMFLAGS: -server NEEDS: gnumake381,jtreg macosx_x64-product-c2-jdk_math not_started( 00s) VMFLAGS: -server NEEDS: gnumake381,jtreg macosx_x64-product-c2-jvm98 not_started( 00s) VMFLAGS: -server NEEDS: gnumake381,jtreg,jvm98 macosx_x64-product-c2-langtools_jtreg not_started( 00s) VMFLAGS: -server NEEDS: gnumake381,jtreg macosx_x64-product-c2-scimark not_started( 00s) VMFLAGS: -server NEEDS: gnumake381,jtreg,scimark solaris_i586-product-c1-jdk_lang success(08m 18s) STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 USED: hostname=jprt-host-x64-1 platform=solaris_i586_5.10 osname=solaris osarch=i586 cpus=16 parallelcount=32 ram=32256MB instance=P1 TIMING: clean=1s init=12s work=8m3s fini=1s VMFLAGS: -client NEEDS: SS121,gnumake381,jtreg solaris_i586-product-c1-jdk_math success( 55s) STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 USED: hostname=sc11b2206 platform=solaris_i586_5.10 osname=solaris osarch=i586 cpus=4 parallelcount=8 ram=24567MB instance=P1 TIMING: clean=2s init=14s work=36s fini=1s VMFLAGS: -client NEEDS: SS121,gnumake381,jtreg solaris_i586-product-c1-jvm98 success(01m 34s) USED: hostname=sc11b2204 platform=solaris_i586_5.10 osname=solaris osarch=i586 cpus=4 parallelcount=8 ram=24567MB instance=P1 TIMING: clean=2s init=6s work=1m23s fini=1s VMFLAGS: -client NEEDS: SS121,gnumake381,jtreg,jvm98 solaris_i586-product-c1-langtools_jtreg success(14m 55s) USED: hostname=sc11b2203 platform=solaris_i586_5.10 osname=solaris osarch=i586 cpus=4 parallelcount=8 ram=24567MB instance=P1 TIMING: clean=1s init=12s work=14m39s fini=1s VMFLAGS: -client NEEDS: SS121,gnumake381,jtreg solaris_i586-product-c1-scimark success( 29s) USED: hostname=sc11b2206 platform=solaris_i586_5.10 osname=solaris osarch=i586 cpus=4 parallelcount=8 ram=24567MB instance=P1 TIMING: clean=2s init=1s work=24s fini=1s VMFLAGS: -client NEEDS: SS121,gnumake381,jtreg,scimark solaris_sparc-product-c1-jdk_lang success(10m 02s) STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 USED: hostname=sc11136042 platform=solaris_sparc_5.10 osname=solaris osarch=sparc cpus=8 parallelcount=16 ram=4096MB instance=P1 TIMING: clean=4s init=15s work=9m41s fini=1s VMFLAGS: -client NEEDS: SS121,gnumake381,jtreg solaris_sparc-product-c1-jdk_math success(01m 05s) STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 USED: hostname=sc11136038 platform=solaris_sparc_5.10 osname=solaris osarch=sparc cpus=8 parallelcount=16 ram=4096MB instance=P1 TIMING: clean=1s init=13s work=48s fini=1s VMFLAGS: -client NEEDS: SS121,gnumake381,jtreg solaris_sparc-product-c1-jvm98 success(02m 11s) USED: hostname=sc11136037 platform=solaris_sparc_5.10 osname=solaris osarch=sparc cpus=8 parallelcount=16 ram=4096MB instance=P1 TIMING: clean=1s init=1s work=2m7s fini=1s VMFLAGS: -client NEEDS: SS121,gnumake381,jtreg,jvm98 solaris_sparc-product-c1-langtools_jtreg success(20m 48s) USED: hostname=sc11136041 platform=solaris_sparc_5.10 osname=solaris osarch=sparc cpus=8 parallelcount=16 ram=4096MB instance=P1 TIMING: clean=1s init=15s work=20m29s fini=1s VMFLAGS: -client NEEDS: SS121,gnumake381,jtreg solaris_sparc-product-c1-scimark success( 49s) USED: hostname=sc11136037 platform=solaris_sparc_5.10 osname=solaris osarch=sparc cpus=8 parallelcount=16 ram=4096MB instance=P1 TIMING: clean=3s init=12s work=30s fini=1s VMFLAGS: -client NEEDS: SS121,gnumake381,jtreg,scimark solaris_sparcv9-product-c2-jdk_lang success(09m 54s) STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 USED: hostname=sc11136039 platform=solaris_sparc_5.10 osname=solaris osarch=sparc cpus=8 parallelcount=16 ram=4096MB instance=P1 TIMING: clean=9s init=20s work=9m22s fini=1s VMFLAGS: -d64 -server NEEDS: SS121,gnumake381,jtreg solaris_sparcv9-product-c2-jdk_math success(01m 02s) STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 USED: hostname=sc11136037 platform=solaris_sparc_5.10 osname=solaris osarch=sparc cpus=8 parallelcount=16 ram=4096MB instance=P1 TIMING: clean=6s init=19s work=34s fini=1s VMFLAGS: -d64 -server NEEDS: SS121,gnumake381,jtreg solaris_sparcv9-product-c2-jvm98 success(02m 22s) USED: hostname=sc11136038 platform=solaris_sparc_5.10 osname=solaris osarch=sparc cpus=8 parallelcount=16 ram=4096MB instance=P1 TIMING: clean=8s init=10s work=2m fini=1s VMFLAGS: -d64 -server NEEDS: SS121,gnumake381,jtreg,jvm98 solaris_sparcv9-product-c2-langtools_jtreg success(17m 12s) USED: hostname=sc11136040 platform=solaris_sparc_5.10 osname=solaris osarch=sparc cpus=8 parallelcount=16 ram=4096MB instance=P1 TIMING: clean=8s init=19s work=16m42s fini=1s VMFLAGS: -d64 -server NEEDS: SS121,gnumake381,jtreg solaris_sparcv9-product-c2-scimark success( 49s) USED: hostname=sc11136041 platform=solaris_sparc_5.10 osname=solaris osarch=sparc cpus=8 parallelcount=16 ram=4096MB instance=P1 TIMING: clean=5s init=11s work=29s fini=1s VMFLAGS: -d64 -server NEEDS: SS121,gnumake381,jtreg,scimark solaris_x64-product-c2-jdk_lang success(08m 39s) STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 USED: hostname=sc11b2205 platform=solaris_i586_5.10 osname=solaris osarch=i586 cpus=4 parallelcount=8 ram=24567MB instance=P1 TIMING: clean=1s init=15s work=8m19s fini=1s VMFLAGS: -d64 -server NEEDS: SS121,gnumake381,jtreg solaris_x64-product-c2-jdk_math success( 43s) STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 USED: hostname=sc11b2204 platform=solaris_i586_5.10 osname=solaris osarch=i586 cpus=4 parallelcount=8 ram=24567MB instance=P1 TIMING: clean=4s init=15s work=20s fini=1s VMFLAGS: -d64 -server NEEDS: SS121,gnumake381,jtreg solaris_x64-product-c2-jvm98 success(01m 21s) USED: hostname=sc11b2203 platform=solaris_i586_5.10 osname=solaris osarch=i586 cpus=4 parallelcount=8 ram=24567MB instance=P1 TIMING: clean=4s init=10s work=1m3s fini=1s VMFLAGS: -d64 -server NEEDS: SS121,gnumake381,jtreg,jvm98 solaris_x64-product-c2-langtools_jtreg success(14m 36s) USED: hostname=jprt-host-x64-2 platform=solaris_i586_5.10 osname=solaris osarch=i586 cpus=16 parallelcount=32 ram=32256MB instance=P1 TIMING: clean=5s init=16s work=14m11s fini=1s VMFLAGS: -d64 -server NEEDS: SS121,gnumake381,jtreg solaris_x64-product-c2-scimark success( 48s) USED: hostname=jprt-host-x64-1 platform=solaris_i586_5.10 osname=solaris osarch=i586 cpus=16 parallelcount=32 ram=32256MB instance=P1 TIMING: clean=4s init=10s work=31s fini=1s VMFLAGS: -d64 -server NEEDS: SS121,gnumake381,jtreg,scimark windows_i586-product-c1-jdk_lang success(14m 21s) STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 USED: hostname=prt-win-x86-2 platform=windows_i586_5.1 osname=windows osarch=i586 cpus=2 parallelcount=2 ram=2047MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true ATTRS: cygwin=true TIMING: clean=1m50s init=5m8s work=7m20s fini=1s VMFLAGS: -client NEEDS: cygwin,gnumake381,jtreg windows_i586-product-c1-jdk_math success(05m 20s) STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 USED: hostname=sc11136107 platform=windows_i586_5.1 osname=windows osarch=i586 cpus=2 parallelcount=2 ram=2047MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true ATTRS: cygwin=true TIMING: clean=1m38s init=2m28s work=1m11s fini=1s VMFLAGS: -client NEEDS: cygwin,gnumake381,jtreg windows_i586-product-c1-jvm98 success(01m 37s) USED: hostname=sc11136106 platform=windows_i586_5.1 osname=windows osarch=i586 cpus=2 parallelcount=2 ram=2047MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true ATTRS: cygwin=true TIMING: clean=3s init=22s work=1m9s fini=1s VMFLAGS: -client NEEDS: cygwin,gnumake381,jtreg,jvm98 windows_i586-product-c1-langtools_jtreg success(57m 03s) USED: hostname=sc11136102 platform=windows_i586_5.1 osname=windows osarch=i586 cpus=2 parallelcount=2 ram=2047MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true ATTRS: cygwin=true TIMING: clean=13m38s init=6m35s work=36m47s fini=1s VMFLAGS: -client NEEDS: cygwin,gnumake381,jtreg windows_i586-product-c1-scimark success(02m 53s) USED: hostname=jprt-win-x64-3 platform=windows_x64_5.2 osname=windows osarch=x64 cpus=4 parallelcount=4 ram=3967MB instance=P1 compiler=VS2003,VS2005,VS2008,VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true ATTRS: cygwin=true TIMING: clean=1m57s init=20s work=33s fini=1s VMFLAGS: -client NEEDS: cygwin,gnumake381,jtreg,scimark windows_x64-product-c2-jdk_lang success(17m 14s) STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 USED: hostname=jprt-win-x64-2 platform=windows_x64_5.2 osname=windows osarch=x64 cpus=4 parallelcount=4 ram=3967MB instance=P1 compiler=VS2003,VS2005,VS2008,VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true ATTRS: cygwin=true TIMING: clean=2m43s init=4m23s work=10m4s fini=1s VMFLAGS: -server NEEDS: cygwin,gnumake381,jtreg windows_x64-product-c2-jdk_math success(02m 40s) STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 USED: hostname=sc11136119 platform=windows_x64_5.2 osname=windows osarch=x64 cpus=2 parallelcount=2 ram=4095MB instance=P1 compiler=VS2003,VS2005,VS2008,VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true ATTRS: cygwin=true TIMING: clean=1s init=1m47s work=50s fini=1s VMFLAGS: -server NEEDS: cygwin,gnumake381,jtreg windows_x64-product-c2-jvm98 success(01m 22s) USED: hostname=sc11136119 platform=windows_x64_5.2 osname=windows osarch=x64 cpus=2 parallelcount=2 ram=4095MB instance=P1 compiler=VS2003,VS2005,VS2008,VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true ATTRS: cygwin=true TIMING: clean=4s init=14s work=1m3s fini=1s VMFLAGS: -server NEEDS: cygwin,gnumake381,jtreg,jvm98 windows_x64-product-c2-langtools_jtreg success(33m 41s) USED: hostname=jprt-win-x64-3 platform=windows_x64_5.2 osname=windows osarch=x64 cpus=4 parallelcount=4 ram=3967MB instance=P1 compiler=VS2003,VS2005,VS2008,VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true ATTRS: cygwin=true TIMING: clean=1s init=4m17s work=29m20s fini=1s VMFLAGS: -server NEEDS: cygwin,gnumake381,jtreg windows_x64-product-c2-scimark success(01m 50s) USED: hostname=prt-w2003x-1 platform=windows_x64_5.2 osname=windows osarch=x64 cpus=16 parallelcount=16 ram=4095MB instance=P1 compiler=VS2010 mks=true cygwin=true installshield=true dxsdk=true pstools=true ATTRS: cygwin=true TIMING: clean=54s init=13s work=39s fini=1s VMFLAGS: -server NEEDS: cygwin,gnumake381,jtreg,scimark For announcements on downtime and availability join the alias 'jprt_announce_ww_grp at oracle.com'. Status of the queue is available at: http://prt-web.us.oracle.com//archive//sfbay.html For suspected system problems, send mail to 'jprt_admin_ww_grp at oracle.com'. All jprt information is available at the JPRT wiki page http://wiki.se.oracle.com/display/JPGINFRA/JPRT From Alan.Bateman at oracle.com Fri Aug 3 17:03:06 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 Aug 2012 18:03:06 +0100 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <222513717.8303590.1344009515684.JavaMail.root@redhat.com> References: <222513717.8303590.1344009515684.JavaMail.root@redhat.com> Message-ID: <501C044A.4050102@oracle.com> On 03/08/2012 16:58, Andrew Hughes wrote: > : > It's what we've had for years, and was added orthogonally to 8 in: > > changeset: 5118:d45bc4307996 > user: michaelm > date: Tue Mar 06 20:34:38 2012 +0000 > summary: 7113349: Initial changeset for Macosx port to jdk > > though that version is broken (at least on GNU/Linux) without the change > to defines.h I posted in my patch earlier this week. Right, that change was for Mac and it didn't have the goal to enable it on Linux. BTW: Looking at your patch then I suspect it will cause problems on other platforms as it only sets ZLIB_LIBS in jdk_generic_profile.sh. If folks aren't using this script to setup their environment then I'm sure there will be a problem on Mac at least. I don't have time to spend on it but I suspect Defs-macosx.gmk will need to be updated to make it the default as it does now. > > If IPP is binary compatible, surely setting ZLIB_LIBS/ZLIB_CFLAGS would > be sufficient? I don't know how different they are. I believe it is binary compatible but I think Sherman is thinking a runtime knob rather than a build-time option. -Alan. From ahughes at redhat.com Fri Aug 3 17:04:18 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 3 Aug 2012 13:04:18 -0400 (EDT) Subject: JPRT: [sfbay] job notification - FAILED with job 2012-08-02-185552.sherman.zip In-Reply-To: <501C0257.5030607@oracle.com> Message-ID: <1670439859.8341287.1344013458462.JavaMail.root@redhat.com> ----- Original Message ----- > Andrew, > > I see a build failure on macos with your patch. Any idea? > > -Sherman > > -------- Original Message -------- > Received: from acsinet22.oracle.com (/141.146.126.238) by default > (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Aug 2012 18:00:58 > -0700 > Received: from jprt-west1.us.oracle.com (jprt-west1.us.oracle.com > [10.133.137.52]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with > ESMTP id q7310voP024695 (version=TLSv1/SSLv3 > cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2012 > 01:00:58 GMT > Received: from jprt-west1.us.oracle.com (localhost [127.0.0.1]) by > jprt-west1.us.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id > q7310vg3003436; Thu, 2 Aug 2012 18:00:57 -0700 (PDT) > Received: (from jprtadm at localhost) by jprt-west1.us.oracle.com > (8.14.4+Sun/8.14.4/Submit) id q7310vJa003435; Thu, 2 Aug 2012 > 18:00:57 -0700 (PDT) > Date: Thu, 2 Aug 2012 18:00:57 -0700 (PDT) > From: jprt_admin_ww_grp at oracle.com > Message-Id: <201208030100.q7310vJa003435 at jprt-west1.us.oracle.com> > X-Authentication-Warning: jprt-west1.us.oracle.com: jprtadm set > sender to jprt_admin_ww_grp at oracle.com using -r > To: xueming.shen at oracle.com > Cc: jprt_notify_ww_grp at oracle.com > Subject: JPRT: [sfbay] job notification - FAILED with job > 2012-08-02-185552.sherman.zip > > JPRT: [sfbay] job notification - FAILED with job > 2012-08-02-185552.sherman.zip > > Failure reason: Targets failed, cannot continue. Target > macosx_x64_10.7-product FAILED. > > JPRT Job ID: 2012-08-02-185552.sherman.zip > JPRT System: sfbay > JPRT Version: 2.3.9: (2012-07-23) Case of the Negligent Nymph > [46c0169a9279] > Job URL: > http://prt-web.us.oracle.com//archive/2012/08/2012-08-02-185552.sherman.zip > Job ARCHIVE: > /net/prt-archiver.us.oracle.com/data/jprt/archive/2012/08/2012-08-02-185552.sherman.zip > User: sherman - xueming.shen at oracle.com Release: > jdk8 > Source: Source Tree: > /export/sherman/Workspace/jdk8_2/{langtools,jdk,make,Makefile,test} > File List: {.} > Exclude List: {jdk/build,langtools/build} > Command Line: jprt submit -control 'langtools jdk' -ot > '.*product.*' -noquickabort -nostandby -email > xueming.shen at oracle.com -id zip -quickabortcount 500 > Submitted at: Thursday August 2, 2012 12:00:19 PDT > Time in queue: 06H 00m 37s > Started at: Thursday August 2, 2012 16:18:33 PDT > Finished at: Thursday August 2, 2012 18:00:57 PDT > Run time: 01H 42m 24s > Job state: FAILED > Fail/kill comment: Targets failed, cannot continue. Target > macosx_x64_10.7-product FAILED. > Flags: > Bundles: USE: jprt install 2012-08-02-185552.sherman.zip > > Run time: 01H 42m 24s > Build Stats: 8 pass, 1 fail, 0 killed, 0 working, 0 > initializing, 0 not started > Test Stats: 45 pass, 0 fail, 0 killed, 0 working, 0 > initializing, 5 not started > > HINT: Use 'jprt rerun -comment 2012-08-02-185552.sherman.zip' > to rerun this job if you suspect the results. > > User Comments: > null > > Build (Release:jdk8 Boot: Import:): > linux_i586_2.6-product success(09m 06s) > USED: hostname=prt-x2200-1 platform=linux_i586_2.6 > osname=linux osarch=i586 cpus=4 parallelcount=8 ram=3549MB > instance=P1 > TIMING: clean=17s init=31s work=8m12s fini=3s > NEEDS: > ant171,ccache,cups,freetype32,fxsdk8,fxsdk8lin32,gnumake381,jdk8drops,npapi > linux_x64_2.6-product success(13m 54s) > USED: hostname=prt-x2200-3 platform=linux_x64_2.6 > osname=linux osarch=x64 cpus=4 parallelcount=8 ram=8006MB > instance=P1 > TIMING: clean=13s init=11s work=13m23s fini=4s > NEEDS: > ant171,ccache,cups,freetype64,fxsdk8,fxsdk8lin64,gnumake381,jdk8drops,npapi > macosx_x64_10.7-product FAILED(03m 13s) > USED: hostname=sc14ie03 platform=macosx_x64_10.7 > osname=macosx osarch=x64 cpus=16 parallelcount=16 > instance=P1 > TIMING: clean=34s init=22s work=2m9s fini=4s > NEEDS: > ant171,cups,fxsdk8,fxsdk8mac64,gnumake381,jdk8drops,npapi,sparkle > solaris_i586_5.10-product success(09m 53s) > USED: hostname=jprt-host-x64-2 platform=solaris_i586_5.10 > osname=solaris osarch=i586 cpus=16 parallelcount=32 > ram=32256MB instance=P1 > TIMING: clean=10s init=5s work=9m28s fini=7s > NEEDS: > SS121,ant171,ccache,cups,freetype32,freetype64,fxsdk8,gnumake381,jdk8drops,npapi > solaris_sparc_5.10-product success(12m 06s) > USED: hostname=sc11136038 platform=solaris_sparc_5.10 > osname=solaris osarch=sparc cpus=8 parallelcount=16 > ram=4096MB instance=P1 > TIMING: clean=16s init=7s work=11m35s fini=5s > NEEDS: > SS121,ant171,ccache,cups,freetype32,freetype64,fxsdk8,gnumake381,jdk8drops,npapi > solaris_sparcv9_5.10-product success(10m 51s) > USED: hostname=sc11136037 platform=solaris_sparc_5.10 > osname=solaris osarch=sparc cpus=8 parallelcount=16 > ram=4096MB instance=P1 > TIMING: clean=13s init=7s work=10m26s fini=2s > NEEDS: > SS121,ant171,ccache,cups,freetype32,freetype64,fxsdk8,gnumake381,jdk8drops,npapi > solaris_x64_5.10-product success(09m 01s) > USED: hostname=jprt-host-x64-1 platform=solaris_i586_5.10 > osname=solaris osarch=i586 cpus=16 parallelcount=32 > ram=32256MB instance=P1 > TIMING: clean=8s init=7s work=8m41s fini=1s > NEEDS: > SS121,ant171,ccache,cups,freetype32,freetype64,fxsdk8,gnumake381,jdk8drops,npapi > windows_i586_5.1-product success(42m 44s) > USED: hostname=prt-win-x86-2 platform=windows_i586_5.1 > osname=windows osarch=i586 cpus=2 parallelcount=2 ram=2047MB > instance=P1 compiler=VS2010 mks=true cygwin=true > installshield=true dxsdk=true pstools=true > ATTRS: compiler=VS2010 mks=true cygwin=true > TIMING: clean=4m32s init=4m27s work=33m39s fini=3s > NEEDS: > ant171,freetype32,fxsdk8,fxsdk8win32,gnumake381,jdk8drops,mingw,mks,npapi,signing,sponsor_binaries1,sponsor_binaries2,wix35 > windows_x64_5.2-product success(55m 26s) > USED: hostname=jprt-win-x64-2 platform=windows_x64_5.2 > osname=windows osarch=x64 cpus=4 parallelcount=4 ram=3967MB > instance=P1 compiler=VS2003,VS2005,VS2008,VS2010 mks=true > cygwin=true installshield=true > dxsdk=true pstools=true > ATTRS: compiler=VS2010 mks=true cygwin=true > TIMING: clean=4m16s init=4m41s work=46m23s fini=3s > NEEDS: > ant171,freetype64,fxsdk8,fxsdk8win64,gnumake381,jdk8drops,mingw,mks,npapi,signing,sponsor_binaries1,sponsor_binaries2,wix35 > > ------------------------------------------------------------------------------ > macosx_x64_10.7-product (details from log file) > /net/prt-archiver.us.oracle.com/data/jprt/archive/2012/08/2012-08-02-185552.sherman.zip/logs/macosx_x64_10.7-product.log > http://prt-web.us.oracle.com//archive/2012/08/2012-08-02-185552.sherman.zip//logs/macosx_x64_10.7-product.log > # Running javac: 40 files; in > /private/tmp/jprt/P1/185552.sherman/s/jdk/make/java/sun_nio > /opt/jprt/products/P1/jdk7u4-latest/1.7.0.jdk/Contents/Home/bin/java > -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput > -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m > -XX:MaxPermSize=160m > -Xbootclasspath/p:/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar > -jar > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar > -Werror -Xlint:all -Xlint:-path -source 7 -target 7 -encoding ascii > -Xbootclasspath:/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/classes > -sourcepath > ../../../src/closed/solaris/classes:../../../src/closed/share/classes:/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/gensrc:::/private/tmp/jprt/P1/185552.sherman/s/jdk/src/macosx/classes:/private/tmp/jprt/P1/185552.sherman/s/jdk/src/solaris/classes:/private/tmp/jprt/P1/185552.sherman/s/jdk/src/share/classes > -d > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/classes > @/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/sun/sun.nio/.classes.list.filtered > # javac finished > Building > lib:/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/lib/jli/libjli.dylib > Begin parallel compiles: > /private/tmp/jprt/P1/185552.sherman/s/jdk/make/java/jli > /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os > -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses > -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -F/System/Library/Frameworks/JavaVM.framework/Frameworks > -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks > -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE > -DRELEASE='"1.8.0-internal"' > -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 > -I. > -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders > -I../../../src/closed/share/javavm/export > -I../../../src/solaris/javavm/export > -I../../../src/share/javavm/export -I../../../src/share/bin > -I../../../src/macosx/bin -I../../../src/solaris/bin > -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/java.o > ../../../src/share/bin/java.c > /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os > -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses > -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -F/System/Library/Frameworks/JavaVM.framework/Frameworks > -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks > -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE > -DRELEASE='"1.8.0-internal"' > -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 > -I. > -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders > -I../../../src/closed/share/javavm/export > -I../../../src/solaris/javavm/export > -I../../../src/share/javavm/export -I../../../src/share/bin > -I../../../src/macosx/bin -I../../../src/solaris/bin > -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/splashscreen_stubs.o > ../../../src/share/bin/splashscreen_stubs.c > /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os > -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses > -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -F/System/Library/Frameworks/JavaVM.framework/Frameworks > -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks > -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE > -DRELEASE='"1.8.0-internal"' > -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 > -I. > -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders > -I../../../src/closed/share/javavm/export > -I../../../src/solaris/javavm/export > -I../../../src/share/javavm/export -I../../../src/share/bin > -I../../../src/macosx/bin -I../../../src/solaris/bin > -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/version_comp.o > ../../../src/share/bin/version_comp.c > /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os > -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses > -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -F/System/Library/Frameworks/JavaVM.framework/Frameworks > -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks > -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE > -DRELEASE='"1.8.0-internal"' > -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 > -I. > -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders > -I../../../src/closed/share/javavm/export > -I../../../src/solaris/javavm/export > -I../../../src/share/javavm/export -I../../../src/share/bin > -I../../../src/macosx/bin -I../../../src/solaris/bin > -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/parse_manifest.o > ../../../src/share/bin/parse_manifest.c > /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os > -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses > -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -F/System/Library/Frameworks/JavaVM.framework/Frameworks > -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks > -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE > -DRELEASE='"1.8.0-internal"' > -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 > -I. > -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders > -I../../../src/closed/share/javavm/export > -I../../../src/solaris/javavm/export > -I../../../src/share/javavm/export -I../../../src/share/bin > -I../../../src/macosx/bin -I../../../src/solaris/bin > -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/wildcard.o > ../../../src/share/bin/wildcard.c > /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os > -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses > -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -F/System/Library/Frameworks/JavaVM.framework/Frameworks > -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks > -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE > -DRELEASE='"1.8.0-internal"' > -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 > -I. > -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders > -I../../../src/closed/share/javavm/export > -I../../../src/solaris/javavm/export > -I../../../src/share/javavm/export -I../../../src/share/bin > -I../../../src/macosx/bin -I../../../src/solaris/bin > -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/jli_util.o > ../../../src/share/bin/jli_util.c > /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os > -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses > -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -F/System/Library/Frameworks/JavaVM.framework/Frameworks > -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks > -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE > -DRELEASE='"1.8.0-internal"' > -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 > -I. > -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders > -I../../../src/closed/share/javavm/export > -I../../../src/solaris/javavm/export > -I../../../src/share/javavm/export -I../../../src/share/bin > -I../../../src/macosx/bin -I../../../src/solaris/bin > -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/java_md_common.o > ../../../src/solaris/bin/java_md_common.c > /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os -x > objective-c -fno-strict-aliasing -fPIC -W -Wall -Wno-unused > -Wno-parentheses -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -F/System/Library/Frameworks/JavaVM.framework/Frameworks > -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks > -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE > -DRELEASE='"1.8.0-internal"' > -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 > -I. > -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders > -I../../../src/closed/share/javavm/export > -I../../../src/solaris/javavm/export > -I../../../src/share/javavm/export -I../../../src/share/bin > -I../../../src/macosx/bin -I../../../src/solaris/bin > -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -c -o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/java_md_macosx.o > ../../../src/macosx/bin/java_md_macosx.c > ../../../src/macosx/bin/java_md_macosx.c: In function > 'ContinueInNewThread0': > ../../../src/macosx/bin/java_md_macosx.c:861: warning: cast from > pointer to integer of different size > Done with parallel compiles: > /private/tmp/jprt/P1/185552.sherman/s/jdk/make/java/jli > STATS: LIBRARY=jli, PRODUCT=java, OPTIMIZATION_LEVEL=HIGHER > Rebuilding > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/lib/jli/libjli.dylib > because of > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/.files_compiled > /Applications/Xcode.app/Contents/Developer/usr/bin/llvm-gcc -Os > -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses > -pipe -m64 -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -F/System/Library/Frameworks/JavaVM.framework/Frameworks > -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks > -DNDEBUG -DARCH='"x86_64"' -Dx86_64 -D_ALLBSD_SOURCE > -DRELEASE='"1.8.0-internal"' > -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -DMACOSX -D_LP64=1 > -I. > -I/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/CClassHeaders > -I../../../src/closed/share/javavm/export > -I../../../src/solaris/javavm/export > -I../../../src/share/javavm/export -I../../../src/share/bin > -I../../../src/macosx/bin -I../../../src/solaris/bin > -DLIBARCHNAME='"x86_64"' -DPACKAGE_PATH=\"/opt/local\" -m64 > -Xlinker -rpath -Xlinker @loader_path/. -Xlinker -install_name > -Xlinker @rpath/libjli.dylib > -L/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/lib > -framework Cocoa -framework Security -framework > ApplicationServices -Wl,-install_name, at rpath/libjli.dylib > -dynamiclib -compatibility_version 1.0.0 -current_version 1.0.0 -o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/lib/jli/libjli.dylib > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/java.o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/splashscreen_stubs.o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/parse_manifest.o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/version_comp.o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/wildcard.o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/jli_util.o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/java_md_common.o > /private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/tmp/java/jli/obj64/java_md_macosx.o > Undefined symbols for architecture x86_64: > "_inflateInit2_", referenced from: > _inflate_file in parse_manifest.o > "_inflate", referenced from: > _inflate_file in parse_manifest.o > "_inflateEnd", referenced from: > _inflate_file in parse_manifest.o > ld: symbol(s) not found for architecture x86_64 > collect2: ld returned 1 exit status > make[4]: *** > [/private/tmp/jprt/P1/185552.sherman/s/build/macosx-x86_64/lib/jli/libjli.dylib] > Error 1 > make[3]: *** [all] Error 1 > make[2]: *** [all] Error 1 > make[1]: *** [jdk-build] Error 2 > make: *** [build_product_image] Error 2 > ########################################################### > # > # pwd: > # /private/tmp/jprt/P1/185552.sherman/s > # > # uname -a: > # Darwin sc14ie03.us.oracle.com 11.4.0 Darwin Kernel Version > 11.4.0: Mon Apr 9 19:32:15 PDT 2012; > root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64 > # > # df -k .: > # Filesystem 1024-blocks Used Available Capacity Mounted > on > # /dev/disk0s2 1952674976 637575080 1314843896 33% / > # > # Finished: Thu Aug 2 16:22:53 PDT 2012 > # > # returned exit code 2 > # > ########################################################### > > ------------------------------------------------------------------------------ > > Tests: > linux_i586-product-c1-jdk_lang success(06m 46s) > STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 > USED: hostname=sc11136024 platform=linux_i586_2.6 > osname=linux osarch=i586 cpus=2 parallelcount=4 ram=3042MB > instance=P1 > TIMING: clean=3s init=18s work=6m21s fini=1s > VMFLAGS: -client > NEEDS: gnumake381,jtreg > linux_i586-product-c1-jdk_math success(01m 27s) > STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 > USED: hostname=prt-x2200-1 platform=linux_i586_2.6 > osname=linux osarch=i586 cpus=4 parallelcount=8 ram=3549MB > instance=P1 > TIMING: clean=7s init=39s work=38s fini=1s > VMFLAGS: -client > NEEDS: gnumake381,jtreg > linux_i586-product-c1-jvm98 success(01m 02s) > USED: hostname=sc11137363 platform=linux_x64_3.2 > osname=linux osarch=x64 cpus=4 parallelcount=8 ram=7890MB > instance=P1 > TIMING: clean=2s init=6s work=50s fini=1s > VMFLAGS: -client > NEEDS: gnumake381,jtreg,jvm98 > linux_i586-product-c1-langtools_jtreg success(13m 18s) > USED: hostname=sc11137356 platform=linux_i586_2.6 > osname=linux osarch=i586 cpus=4 parallelcount=8 ram=3041MB > instance=P1 > TIMING: clean=3s init=40s work=12m32s fini=1s > VMFLAGS: -client > NEEDS: gnumake381,jtreg > linux_i586-product-c1-scimark success( 39s) > USED: hostname=sc11137362 platform=linux_x64_3.2 > osname=linux osarch=x64 cpus=4 parallelcount=8 ram=7890MB > instance=P1 > TIMING: clean=2s init=5s work=29s fini=1s > VMFLAGS: -client > NEEDS: gnumake381,jtreg,scimark > linux_i586-product-c2-jdk_lang success(10m 06s) > STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 > USED: hostname=prt-x2200-2 platform=linux_i586_2.6 > osname=linux osarch=i586 cpus=4 parallelcount=8 ram=3549MB > instance=P1 > TIMING: clean=7s init=47s work=9m9s fini=1s > VMFLAGS: -server > NEEDS: gnumake381,jtreg > linux_i586-product-c2-jdk_math success( 38s) > STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 > USED: hostname=sc11137361 platform=linux_x64_3.2 > osname=linux osarch=x64 cpus=4 parallelcount=8 ram=7890MB > instance=P1 > TIMING: clean=2s init=11s work=18s fini=4s > VMFLAGS: -server > NEEDS: gnumake381,jtreg > linux_i586-product-c2-jvm98 success(01m 33s) > USED: hostname=sc11137357 platform=linux_i586_2.6 > osname=linux osarch=i586 cpus=4 parallelcount=8 ram=3041MB > instance=P1 > TIMING: clean=3s init=24s work=1m2s fini=1s > VMFLAGS: -server > NEEDS: gnumake381,jtreg,jvm98 > linux_i586-product-c2-langtools_jtreg success(11m 39s) > USED: hostname=sc11137355 platform=linux_i586_2.6 > osname=linux osarch=i586 cpus=4 parallelcount=8 ram=3041MB > instance=P1 > TIMING: clean=3s init=38s work=10m55s fini=1s > VMFLAGS: -server > NEEDS: gnumake381,jtreg > linux_i586-product-c2-scimark success( 43s) > USED: hostname=sc11136053 platform=linux_i586_2.6 > osname=linux osarch=i586 cpus=2 parallelcount=4 ram=3042MB > instance=P1 > TIMING: clean=3s init=6s work=31s fini=1s > VMFLAGS: -server > NEEDS: gnumake381,jtreg,scimark > linux_x64-product-c2-jdk_lang success(05m 07s) > STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 > USED: hostname=sc11137361 platform=linux_x64_3.2 > osname=linux osarch=x64 cpus=4 parallelcount=8 ram=7890MB > instance=P1 > TIMING: clean=2s init=9s work=4m52s fini=1s > VMFLAGS: -server > NEEDS: gnumake381,jtreg > linux_x64-product-c2-jdk_math success( 58s) > STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 > USED: hostname=prt-x2200-3 platform=linux_x64_2.6 > osname=linux osarch=x64 cpus=4 parallelcount=8 ram=8006MB > instance=P1 > TIMING: clean=8s init=17s work=30s fini=1s > VMFLAGS: -server > NEEDS: gnumake381,jtreg > linux_x64-product-c2-jvm98 success( 46s) > USED: hostname=sc11137362 platform=linux_x64_3.2 > osname=linux osarch=x64 cpus=4 parallelcount=8 ram=7890MB > instance=P1 > TIMING: clean=1s init=5s work=37s fini=1s > VMFLAGS: -server > NEEDS: gnumake381,jtreg,jvm98 > linux_x64-product-c2-langtools_jtreg success(06m 23s) > USED: hostname=sc11137363 platform=linux_x64_3.2 > osname=linux osarch=x64 cpus=4 parallelcount=8 ram=7890MB > instance=P1 > TIMING: clean=1s init=10s work=6m9s fini=1s > VMFLAGS: -server > NEEDS: gnumake381,jtreg > linux_x64-product-c2-scimark success( 48s) > USED: hostname=prt-x2200-4 platform=linux_x64_2.6 > osname=linux osarch=x64 cpus=4 parallelcount=8 ram=8006MB > instance=P1 > TIMING: clean=8s init=7s work=30s fini=1s > VMFLAGS: -server > NEEDS: gnumake381,jtreg,scimark > macosx_x64-product-c2-jdk_lang not_started( 00s) > VMFLAGS: -server > NEEDS: gnumake381,jtreg > macosx_x64-product-c2-jdk_math not_started( 00s) > VMFLAGS: -server > NEEDS: gnumake381,jtreg > macosx_x64-product-c2-jvm98 not_started( 00s) > VMFLAGS: -server > NEEDS: gnumake381,jtreg,jvm98 > macosx_x64-product-c2-langtools_jtreg not_started( 00s) > VMFLAGS: -server > NEEDS: gnumake381,jtreg > macosx_x64-product-c2-scimark not_started( 00s) > VMFLAGS: -server > NEEDS: gnumake381,jtreg,scimark > solaris_i586-product-c1-jdk_lang success(08m 18s) > STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 > USED: hostname=jprt-host-x64-1 platform=solaris_i586_5.10 > osname=solaris osarch=i586 cpus=16 parallelcount=32 > ram=32256MB instance=P1 > TIMING: clean=1s init=12s work=8m3s fini=1s > VMFLAGS: -client > NEEDS: SS121,gnumake381,jtreg > solaris_i586-product-c1-jdk_math success( 55s) > STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 > USED: hostname=sc11b2206 platform=solaris_i586_5.10 > osname=solaris osarch=i586 cpus=4 parallelcount=8 > ram=24567MB instance=P1 > TIMING: clean=2s init=14s work=36s fini=1s > VMFLAGS: -client > NEEDS: SS121,gnumake381,jtreg > solaris_i586-product-c1-jvm98 success(01m 34s) > USED: hostname=sc11b2204 platform=solaris_i586_5.10 > osname=solaris osarch=i586 cpus=4 parallelcount=8 > ram=24567MB instance=P1 > TIMING: clean=2s init=6s work=1m23s fini=1s > VMFLAGS: -client > NEEDS: SS121,gnumake381,jtreg,jvm98 > solaris_i586-product-c1-langtools_jtreg success(14m 55s) > USED: hostname=sc11b2203 platform=solaris_i586_5.10 > osname=solaris osarch=i586 cpus=4 parallelcount=8 > ram=24567MB instance=P1 > TIMING: clean=1s init=12s work=14m39s fini=1s > VMFLAGS: -client > NEEDS: SS121,gnumake381,jtreg > solaris_i586-product-c1-scimark success( 29s) > USED: hostname=sc11b2206 platform=solaris_i586_5.10 > osname=solaris osarch=i586 cpus=4 parallelcount=8 > ram=24567MB instance=P1 > TIMING: clean=2s init=1s work=24s fini=1s > VMFLAGS: -client > NEEDS: SS121,gnumake381,jtreg,scimark > solaris_sparc-product-c1-jdk_lang success(10m 02s) > STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 > USED: hostname=sc11136042 platform=solaris_sparc_5.10 > osname=solaris osarch=sparc cpus=8 parallelcount=16 > ram=4096MB instance=P1 > TIMING: clean=4s init=15s work=9m41s fini=1s > VMFLAGS: -client > NEEDS: SS121,gnumake381,jtreg > solaris_sparc-product-c1-jdk_math success(01m 05s) > STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 > USED: hostname=sc11136038 platform=solaris_sparc_5.10 > osname=solaris osarch=sparc cpus=8 parallelcount=16 > ram=4096MB instance=P1 > TIMING: clean=1s init=13s work=48s fini=1s > VMFLAGS: -client > NEEDS: SS121,gnumake381,jtreg > solaris_sparc-product-c1-jvm98 success(02m 11s) > USED: hostname=sc11136037 platform=solaris_sparc_5.10 > osname=solaris osarch=sparc cpus=8 parallelcount=16 > ram=4096MB instance=P1 > TIMING: clean=1s init=1s work=2m7s fini=1s > VMFLAGS: -client > NEEDS: SS121,gnumake381,jtreg,jvm98 > solaris_sparc-product-c1-langtools_jtreg success(20m 48s) > USED: hostname=sc11136041 platform=solaris_sparc_5.10 > osname=solaris osarch=sparc cpus=8 parallelcount=16 > ram=4096MB instance=P1 > TIMING: clean=1s init=15s work=20m29s fini=1s > VMFLAGS: -client > NEEDS: SS121,gnumake381,jtreg > solaris_sparc-product-c1-scimark success( 49s) > USED: hostname=sc11136037 platform=solaris_sparc_5.10 > osname=solaris osarch=sparc cpus=8 parallelcount=16 > ram=4096MB instance=P1 > TIMING: clean=3s init=12s work=30s fini=1s > VMFLAGS: -client > NEEDS: SS121,gnumake381,jtreg,scimark > solaris_sparcv9-product-c2-jdk_lang success(09m 54s) > STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 > USED: hostname=sc11136039 platform=solaris_sparc_5.10 > osname=solaris osarch=sparc cpus=8 parallelcount=16 > ram=4096MB instance=P1 > TIMING: clean=9s init=20s work=9m22s fini=1s > VMFLAGS: -d64 -server > NEEDS: SS121,gnumake381,jtreg > solaris_sparcv9-product-c2-jdk_math success(01m 02s) > STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 > USED: hostname=sc11136037 platform=solaris_sparc_5.10 > osname=solaris osarch=sparc cpus=8 parallelcount=16 > ram=4096MB instance=P1 > TIMING: clean=6s init=19s work=34s fini=1s > VMFLAGS: -d64 -server > NEEDS: SS121,gnumake381,jtreg > solaris_sparcv9-product-c2-jvm98 success(02m 22s) > USED: hostname=sc11136038 platform=solaris_sparc_5.10 > osname=solaris osarch=sparc cpus=8 parallelcount=16 > ram=4096MB instance=P1 > TIMING: clean=8s init=10s work=2m fini=1s > VMFLAGS: -d64 -server > NEEDS: SS121,gnumake381,jtreg,jvm98 > solaris_sparcv9-product-c2-langtools_jtreg success(17m 12s) > USED: hostname=sc11136040 platform=solaris_sparc_5.10 > osname=solaris osarch=sparc cpus=8 parallelcount=16 > ram=4096MB instance=P1 > TIMING: clean=8s init=19s work=16m42s fini=1s > VMFLAGS: -d64 -server > NEEDS: SS121,gnumake381,jtreg > solaris_sparcv9-product-c2-scimark success( 49s) > USED: hostname=sc11136041 platform=solaris_sparc_5.10 > osname=solaris osarch=sparc cpus=8 parallelcount=16 > ram=4096MB instance=P1 > TIMING: clean=5s init=11s work=29s fini=1s > VMFLAGS: -d64 -server > NEEDS: SS121,gnumake381,jtreg,scimark > solaris_x64-product-c2-jdk_lang success(08m 39s) > STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 > USED: hostname=sc11b2205 platform=solaris_i586_5.10 > osname=solaris osarch=i586 cpus=4 parallelcount=8 > ram=24567MB instance=P1 > TIMING: clean=1s init=15s work=8m19s fini=1s > VMFLAGS: -d64 -server > NEEDS: SS121,gnumake381,jtreg > solaris_x64-product-c2-jdk_math success( 43s) > STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 > USED: hostname=sc11b2204 platform=solaris_i586_5.10 > osname=solaris osarch=i586 cpus=4 parallelcount=8 > ram=24567MB instance=P1 > TIMING: clean=4s init=15s work=20s fini=1s > VMFLAGS: -d64 -server > NEEDS: SS121,gnumake381,jtreg > solaris_x64-product-c2-jvm98 success(01m 21s) > USED: hostname=sc11b2203 platform=solaris_i586_5.10 > osname=solaris osarch=i586 cpus=4 parallelcount=8 > ram=24567MB instance=P1 > TIMING: clean=4s init=10s work=1m3s fini=1s > VMFLAGS: -d64 -server > NEEDS: SS121,gnumake381,jtreg,jvm98 > solaris_x64-product-c2-langtools_jtreg success(14m 36s) > USED: hostname=jprt-host-x64-2 platform=solaris_i586_5.10 > osname=solaris osarch=i586 cpus=16 parallelcount=32 > ram=32256MB instance=P1 > TIMING: clean=5s init=16s work=14m11s fini=1s > VMFLAGS: -d64 -server > NEEDS: SS121,gnumake381,jtreg > solaris_x64-product-c2-scimark success( 48s) > USED: hostname=jprt-host-x64-1 platform=solaris_i586_5.10 > osname=solaris osarch=i586 cpus=16 parallelcount=32 > ram=32256MB instance=P1 > TIMING: clean=4s init=10s work=31s fini=1s > VMFLAGS: -d64 -server > NEEDS: SS121,gnumake381,jtreg,scimark > windows_i586-product-c1-jdk_lang success(14m 21s) > STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 > USED: hostname=prt-win-x86-2 platform=windows_i586_5.1 > osname=windows osarch=i586 cpus=2 parallelcount=2 ram=2047MB > instance=P1 compiler=VS2010 mks=true cygwin=true > installshield=true dxsdk=true pstools=true > ATTRS: cygwin=true > TIMING: clean=1m50s init=5m8s work=7m20s fini=1s > VMFLAGS: -client > NEEDS: cygwin,gnumake381,jtreg > windows_i586-product-c1-jdk_math success(05m 20s) > STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 > USED: hostname=sc11136107 platform=windows_i586_5.1 > osname=windows osarch=i586 cpus=2 parallelcount=2 ram=2047MB > instance=P1 compiler=VS2010 mks=true cygwin=true > installshield=true dxsdk=true pstools=true > ATTRS: cygwin=true > TIMING: clean=1m38s init=2m28s work=1m11s fini=1s > VMFLAGS: -client > NEEDS: cygwin,gnumake381,jtreg > windows_i586-product-c1-jvm98 success(01m 37s) > USED: hostname=sc11136106 platform=windows_i586_5.1 > osname=windows osarch=i586 cpus=2 parallelcount=2 ram=2047MB > instance=P1 compiler=VS2010 mks=true cygwin=true > installshield=true dxsdk=true pstools=true > ATTRS: cygwin=true > TIMING: clean=3s init=22s work=1m9s fini=1s > VMFLAGS: -client > NEEDS: cygwin,gnumake381,jtreg,jvm98 > windows_i586-product-c1-langtools_jtreg success(57m 03s) > USED: hostname=sc11136102 platform=windows_i586_5.1 > osname=windows osarch=i586 cpus=2 parallelcount=2 ram=2047MB > instance=P1 compiler=VS2010 mks=true cygwin=true > installshield=true dxsdk=true pstools=true > ATTRS: cygwin=true > TIMING: clean=13m38s init=6m35s work=36m47s fini=1s > VMFLAGS: -client > NEEDS: cygwin,gnumake381,jtreg > windows_i586-product-c1-scimark success(02m 53s) > USED: hostname=jprt-win-x64-3 platform=windows_x64_5.2 > osname=windows osarch=x64 cpus=4 parallelcount=4 ram=3967MB > instance=P1 compiler=VS2003,VS2005,VS2008,VS2010 mks=true > cygwin=true installshield=true > dxsdk=true pstools=true > ATTRS: cygwin=true > TIMING: clean=1m57s init=20s work=33s fini=1s > VMFLAGS: -client > NEEDS: cygwin,gnumake381,jtreg,scimark > windows_x64-product-c2-jdk_lang success(17m 14s) > STATS: name=jdk_lang run=377 pass=377 fail=0 excluded=4 > USED: hostname=jprt-win-x64-2 platform=windows_x64_5.2 > osname=windows osarch=x64 cpus=4 parallelcount=4 ram=3967MB > instance=P1 compiler=VS2003,VS2005,VS2008,VS2010 mks=true > cygwin=true installshield=true > dxsdk=true pstools=true > ATTRS: cygwin=true > TIMING: clean=2m43s init=4m23s work=10m4s fini=1s > VMFLAGS: -server > NEEDS: cygwin,gnumake381,jtreg > windows_x64-product-c2-jdk_math success(02m 40s) > STATS: name=jdk_math run=33 pass=33 fail=0 excluded=0 > USED: hostname=sc11136119 platform=windows_x64_5.2 > osname=windows osarch=x64 cpus=2 parallelcount=2 ram=4095MB > instance=P1 compiler=VS2003,VS2005,VS2008,VS2010 mks=true > cygwin=true installshield=true > dxsdk=true pstools=true > ATTRS: cygwin=true > TIMING: clean=1s init=1m47s work=50s fini=1s > VMFLAGS: -server > NEEDS: cygwin,gnumake381,jtreg > windows_x64-product-c2-jvm98 success(01m 22s) > USED: hostname=sc11136119 platform=windows_x64_5.2 > osname=windows osarch=x64 cpus=2 parallelcount=2 ram=4095MB > instance=P1 compiler=VS2003,VS2005,VS2008,VS2010 mks=true > cygwin=true installshield=true > dxsdk=true pstools=true > ATTRS: cygwin=true > TIMING: clean=4s init=14s work=1m3s fini=1s > VMFLAGS: -server > NEEDS: cygwin,gnumake381,jtreg,jvm98 > windows_x64-product-c2-langtools_jtreg success(33m 41s) > USED: hostname=jprt-win-x64-3 platform=windows_x64_5.2 > osname=windows osarch=x64 cpus=4 parallelcount=4 ram=3967MB > instance=P1 compiler=VS2003,VS2005,VS2008,VS2010 mks=true > cygwin=true installshield=true > dxsdk=true pstools=true > ATTRS: cygwin=true > TIMING: clean=1s init=4m17s work=29m20s fini=1s > VMFLAGS: -server > NEEDS: cygwin,gnumake381,jtreg > windows_x64-product-c2-scimark success(01m 50s) > USED: hostname=prt-w2003x-1 platform=windows_x64_5.2 > osname=windows osarch=x64 cpus=16 parallelcount=16 > ram=4095MB instance=P1 compiler=VS2010 mks=true cygwin=true > installshield=true dxsdk=true pstools=true > ATTRS: cygwin=true > TIMING: clean=54s init=13s work=39s fini=1s > VMFLAGS: -server > NEEDS: cygwin,gnumake381,jtreg,scimark > > > > For announcements on downtime and availability join the alias ' > jprt_announce_ww_grp at oracle.com '. > Status of the queue is available at: > http://prt-web.us.oracle.com//archive//sfbay.html For suspected > system problems, send mail to ' jprt_admin_ww_grp at oracle.com '. > All jprt information is available at the JPRT wiki page > http://wiki.se.oracle.com/display/JPGINFRA/JPRT I'm guessing this is a case of -lz being missing as I don't see it in the output and the main change in libjli's Makefile is: - LDLIBS += -lz + LDLIBS += $(ZLIB_LIBS) Is ZLIB_LIBS being set correctly by make/jdk_generic_profile.sh? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Fri Aug 3 17:06:39 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 3 Aug 2012 13:06:39 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <501C044A.4050102@oracle.com> Message-ID: <895966333.8341480.1344013599281.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/08/2012 16:58, Andrew Hughes wrote: > > : It's what we've had for years, and was added orthogonally to 8 in: > > changeset: 5118:d45bc4307996 > user: michaelm > date: Tue Mar 06 20:34:38 2012 +0000 > summary: 7113349: Initial changeset for Macosx port to jdk > > though that version is broken (at least on GNU/Linux) without the > change > to defines.h I posted in my patch earlier this week. Right, that > change was for Mac and it didn't have the goal to enable it on > Linux. > > BTW: Looking at your patch then I suspect it will cause problems on > other platforms as it only sets ZLIB_LIBS in jdk_generic_profile.sh. > If folks aren't using this script to setup their environment then > I'm sure there will be a problem on Mac at least. I don't have time > to spend on it but I suspect Defs-macosx.gmk will need to be updated > to make it the default as it does now. > I think that's what Sherman just hit. I thought the documented way to build was using jdk_generic_profile.sh? I can add a check to Defs-macosx.gmk. > > > If IPP is binary compatible, surely setting ZLIB_LIBS/ZLIB_CFLAGS > would > be sufficient? I don't know how different they are. I believe it is > binary compatible but I think Sherman is thinking a runtime knob > rather than a build-time option. > > -Alan. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Fri Aug 3 17:50:21 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 3 Aug 2012 13:50:21 -0400 (EDT) Subject: Codereview request for 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native In-Reply-To: <501AF831.2070408@oracle.com> Message-ID: <1624495488.8354033.1344016221415.JavaMail.root@redhat.com> ----- Original Message ----- > Hi > > This is the change to move the implementation of > De/Inflater.getBytesRead/Written() > from native to Java. Current JDK implementation uses zlib's > z_stream.total_in/out fields, > which are "uLong" type in original zlib source code. This may limit > these two counters > to 4GB on 32-bit OS [1]. These two fields are currently patched to > "long long" in JDK to > support the > 4G counting. It is suggested that it might be better to > move this > 4G > counting support to java level to remove the dependency on patching > the > original zlib > source code, which might be critical in situation that Java runtime > prefers to use OS > bundled zlib, instead of the JDK bundled zlib library. > > Here is the webrev > > http://cr.openjdk.java.net/~sherman/7188852/webrev/ > > The test case attached only tests upto 128M by default (for running > in > auto testing). > The test can be run manually with option "large" to test > 4G > de/inflating. It takes > 4 > minutes to compress/decompress 5G bytes on my linux box, guess it's > probably not > desirable to hold each/every run for so long in auto setting. > > Thanks, > Sherman > > [1] http://www.zlib.net/zlib_faq.html#faq32 > > The patch looks good to me. I've also built and tested it, both with the normal and large scenarios, and with in-tree and system zlib (the latter requiring my defines.h patch) and all seems fine. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From Alan.Bateman at oracle.com Fri Aug 3 18:16:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 Aug 2012 19:16:59 +0100 Subject: Codereview request for 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native In-Reply-To: <501AF831.2070408@oracle.com> References: <501AF831.2070408@oracle.com> Message-ID: <501C159B.2000307@oracle.com> On 02/08/2012 22:59, Xueming Shen wrote: > Hi > > This is the change to move the implementation of > De/Inflater.getBytesRead/Written() > from native to Java. Current JDK implementation uses zlib's > z_stream.total_in/out fields, > which are "uLong" type in original zlib source code. This may limit > these two counters > to 4GB on 32-bit OS [1]. These two fields are currently patched to > "long long" in JDK to > support the > 4G counting. It is suggested that it might be better to > move this > 4G > counting support to java level to remove the dependency on patching > the original zlib > source code, which might be critical in situation that Java runtime > prefers to use OS > bundled zlib, instead of the JDK bundled zlib library. > > Here is the webrev > > http://cr.openjdk.java.net/~sherman/7188852/webrev/ > > The test case attached only tests upto 128M by default (for running in > auto testing). > The test can be run manually with option "large" to test > 4G > de/inflating. It takes > 4 > minutes to compress/decompress 5G bytes on my linux box, guess it's > probably not > desirable to hold each/every run for so long in auto setting. I skimmed through this and the changes looks reasonable to me. The only thing is that ChangeLog_java is a bit confusing (to me anyway) and maybe it would be clearer it just have it list of the current changes to the zlib code. -Alan. From ahughes at redhat.com Fri Aug 3 18:33:17 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 3 Aug 2012 14:33:17 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <895966333.8341480.1344013599281.JavaMail.root@redhat.com> Message-ID: <34931529.8364596.1344018797299.JavaMail.root@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > On 03/08/2012 16:58, Andrew Hughes wrote: > > > > : It's what we've had for years, and was added orthogonally to 8 > > in: > > > > changeset: 5118:d45bc4307996 > > user: michaelm > > date: Tue Mar 06 20:34:38 2012 +0000 > > summary: 7113349: Initial changeset for Macosx port to jdk > > > > though that version is broken (at least on GNU/Linux) without the > > change > > to defines.h I posted in my patch earlier this week. Right, that > > change was for Mac and it didn't have the goal to enable it on > > Linux. > > > > BTW: Looking at your patch then I suspect it will cause problems on > > other platforms as it only sets ZLIB_LIBS in > > jdk_generic_profile.sh. > > If folks aren't using this script to setup their environment then > > I'm sure there will be a problem on Mac at least. I don't have time > > to spend on it but I suspect Defs-macosx.gmk will need to be > > updated > > to make it the default as it does now. > > > > I think that's what Sherman just hit. > > I thought the documented way to build was using > jdk_generic_profile.sh? > I can add a check to Defs-macosx.gmk. > http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.02/ is an updated version which checks if ZLIB_LIBS is set on Solaris, GNU/Linux and MacOS X and sets it to -lz if not. I wasn't sure what to do with Windows but something can be added there if necessary. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From xueming.shen at oracle.com Fri Aug 3 18:45:23 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 03 Aug 2012 11:45:23 -0700 Subject: Codereview request for 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native In-Reply-To: <501C159B.2000307@oracle.com> References: <501AF831.2070408@oracle.com> <501C159B.2000307@oracle.com> Message-ID: <501C1C43.7080609@oracle.com> Just tried to leave the "trace" of the change. But I'm fine to just keep the "changes" from original zlib source. Webrev has been updated accordingly. -Sherman On 08/03/2012 11:16 AM, Alan Bateman wrote: > On 02/08/2012 22:59, Xueming Shen wrote: >> Hi >> >> This is the change to move the implementation of >> De/Inflater.getBytesRead/Written() >> from native to Java. Current JDK implementation uses zlib's >> z_stream.total_in/out fields, >> which are "uLong" type in original zlib source code. This may limit >> these two counters >> to 4GB on 32-bit OS [1]. These two fields are currently patched to >> "long long" in JDK to >> support the > 4G counting. It is suggested that it might be better to >> move this > 4G >> counting support to java level to remove the dependency on patching >> the original zlib >> source code, which might be critical in situation that Java runtime >> prefers to use OS >> bundled zlib, instead of the JDK bundled zlib library. >> >> Here is the webrev >> >> http://cr.openjdk.java.net/~sherman/7188852/webrev/ >> >> The test case attached only tests upto 128M by default (for running >> in auto testing). >> The test can be run manually with option "large" to test > 4G >> de/inflating. It takes > 4 >> minutes to compress/decompress 5G bytes on my linux box, guess it's >> probably not >> desirable to hold each/every run for so long in auto setting. > I skimmed through this and the changes looks reasonable to me. The > only thing is that ChangeLog_java is a bit confusing (to me anyway) > and maybe it would be clearer it just have it list of the current > changes to the zlib code. > > -Alan. From Alan.Bateman at oracle.com Fri Aug 3 20:15:41 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 03 Aug 2012 21:15:41 +0100 Subject: Codereview request for 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native In-Reply-To: <501C1C43.7080609@oracle.com> References: <501AF831.2070408@oracle.com> <501C159B.2000307@oracle.com> <501C1C43.7080609@oracle.com> Message-ID: <501C316D.7010402@oracle.com> On 03/08/2012 19:45, Xueming Shen wrote: > Just tried to leave the "trace" of the change. But I'm fine to just keep > the "changes" from original zlib source. > > Webrev has been updated accordingly. > > -Sherman Thanks, thumbs up from me. -Alan. From xueming.shen at oracle.com Fri Aug 3 20:36:11 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 03 Aug 2012 20:36:11 +0000 Subject: hg: jdk8/tl/jdk: 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native Message-ID: <20120803203637.C9C044736B@hg.openjdk.java.net> Changeset: 1468b0af0d06 Author: sherman Date: 2012-08-03 13:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1468b0af0d06 7188852: Move implementation of De/Inflater.getBytesRead/Writtten() to java from native Summary: re-implemented getBytesRead/Writtten() at java level Reviewed-by: andrew, alanb ! make/java/zip/mapfile-vers ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/zlib-1.2.5/compress.c ! src/share/native/java/util/zip/zlib-1.2.5/inflate.c ! src/share/native/java/util/zip/zlib-1.2.5/patches/ChangeLog_java ! src/share/native/java/util/zip/zlib-1.2.5/zlib.h + test/java/util/zip/TotalInOut.java From xueming.shen at oracle.com Fri Aug 3 20:57:55 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 03 Aug 2012 13:57:55 -0700 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <34931529.8364596.1344018797299.JavaMail.root@redhat.com> References: <34931529.8364596.1344018797299.JavaMail.root@redhat.com> Message-ID: <501C3B53.7070605@oracle.com> Andrew, I just pushed 7188852. Is it possible for you to update your webrev with this change? I would like to try a full build (and regression tests) on your final bits to make sure we don't break the build. -Sherman On 08/03/2012 11:33 AM, Andrew Hughes wrote: > ----- Original Message ----- >> >> ----- Original Message ----- >>> On 03/08/2012 16:58, Andrew Hughes wrote: >>> >>> : It's what we've had for years, and was added orthogonally to 8 >>> in: >>> >>> changeset: 5118:d45bc4307996 >>> user: michaelm >>> date: Tue Mar 06 20:34:38 2012 +0000 >>> summary: 7113349: Initial changeset for Macosx port to jdk >>> >>> though that version is broken (at least on GNU/Linux) without the >>> change >>> to defines.h I posted in my patch earlier this week. Right, that >>> change was for Mac and it didn't have the goal to enable it on >>> Linux. >>> >>> BTW: Looking at your patch then I suspect it will cause problems on >>> other platforms as it only sets ZLIB_LIBS in >>> jdk_generic_profile.sh. >>> If folks aren't using this script to setup their environment then >>> I'm sure there will be a problem on Mac at least. I don't have time >>> to spend on it but I suspect Defs-macosx.gmk will need to be >>> updated >>> to make it the default as it does now. >>> >> I think that's what Sherman just hit. >> >> I thought the documented way to build was using >> jdk_generic_profile.sh? >> I can add a check to Defs-macosx.gmk. >> > http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.02/ > > is an updated version which checks if ZLIB_LIBS is set on Solaris, GNU/Linux > and MacOS X and sets it to -lz if not. > > I wasn't sure what to do with Windows but something can be added there if necessary. From kumar.x.srinivasan at oracle.com Sat Aug 4 23:36:02 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 04 Aug 2012 23:36:02 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120804233656.5075B47389@hg.openjdk.java.net> Changeset: 3521fcad4b5f Author: ksrini Date: 2012-07-31 06:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3521fcad4b5f 7188114: (launcher) need an alternate command line parser for Windows Reviewed-by: darcy, dholmes, jjh Contributed-by: akhil.arora at oracle.com + src/windows/bin/cmdtoargs.c Changeset: 2dd41a2dfe54 Author: ksrini Date: 2012-07-31 06:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2dd41a2dfe54 7146424: Wildcard expansion for single entry classpath Reviewed-by: dholmes, darcy, jjh, sherman ! make/common/Program.gmk ! make/java/jli/Makefile ! make/java/jli/mapfile-vers ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/bin/jli_util.c ! src/share/bin/jli_util.h ! src/share/bin/main.c ! src/share/bin/wildcard.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties - src/solaris/bin/java_md.c ! src/solaris/bin/java_md_common.c ! src/windows/bin/java_md.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java ! test/tools/launcher/ToolsOpts.java From Alan.Bateman at oracle.com Sun Aug 5 21:00:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 05 Aug 2012 22:00:54 +0100 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <34931529.8364596.1344018797299.JavaMail.root@redhat.com> References: <34931529.8364596.1344018797299.JavaMail.root@redhat.com> Message-ID: <501EDF06.8020404@oracle.com> On 03/08/2012 19:33, Andrew Hughes wrote: > : > http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.02/ > > is an updated version which checks if ZLIB_LIBS is set on Solaris, GNU/Linux > and MacOS X and sets it to -lz if not. > > I wasn't sure what to do with Windows but something can be added there if necessary. Thanks for the update, it looks right to me now. To double check I did a quick build+test on all platforms with latest jdk8/tl + your patch and I don't see any issues. Now I'm wondering whether we should just bite the bullet and default SYSTEM_ZLIB to true on Linux, maybe Solaris too (Sherman - can you think of any reasons not to do this? It would avoid needing to put in a means to switch zlib at startup as it could be done simply with LD_LIBRARY_PATH). -Alan. From david.holmes at oracle.com Mon Aug 6 01:51:24 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 06 Aug 2012 11:51:24 +1000 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <501B8049.2020705@linux.vnet.ibm.com> References: <501B8049.2020705@linux.vnet.ibm.com> Message-ID: <501F231C.9050300@oracle.com> Hi Frank, On 3/08/2012 5:39 PM, Frank Ding wrote: > Hi guys, > I found that in java.lang.Terminator, setup() method, > The following code of registering default signal handlers can be improved: > / try { > Signal.handle(new Signal("INT"), sh); > Signal.handle(new Signal("TERM"), sh); > } catch (IllegalArgumentException e) { > }/ > The revised code is illustrated below: > / try { > Signal.handle(new Signal("INT"), sh); > } catch (IllegalArgumentException e) { > } > try { > Signal.handle(new Signal("TERM"), sh); > } catch (IllegalArgumentException e) { > } > /The improved version makes more sense since exception thrown from first > Signal.handle call does not affect subsequent calls. This is more > consistent with its original intention. > A patch I made is available @ > http://cr.openjdk.java.net/~youdwei/ojdk-430/webrev.00// > > /Could anybody please take a look at it? Thanks in advance/ Can you explain the context for this change. It seems to me that there is an expectation that the group of signals act homogenously: all or none, whereas your change make it appear that the success/failure for each signal is independent. Understanding exactly when/why the IllegalArgumentException is thrown is important here. I don't like seeing the duplicated comment, perhaps that can be factored out to the head of the block of code? Thanks, David Holmes > Best regards, > Frank > / From xueming.shen at oracle.com Mon Aug 6 05:40:02 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 05 Aug 2012 22:40:02 -0700 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <501EDF06.8020404@oracle.com> References: <34931529.8364596.1344018797299.JavaMail.root@redhat.com> <501EDF06.8020404@oracle.com> Message-ID: <501F58B2.9060604@oracle.com> On 8/5/2012 2:00 PM, Alan Bateman wrote: > On 03/08/2012 19:33, Andrew Hughes wrote: >> : >> http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.02/ >> >> is an updated version which checks if ZLIB_LIBS is set on Solaris, >> GNU/Linux >> and MacOS X and sets it to -lz if not. >> >> I wasn't sure what to do with Windows but something can be added >> there if necessary. > Thanks for the update, it looks right to me now. To double check I did > a quick build+test on all platforms with latest jdk8/tl + your patch > and I don't see any issues. > > Now I'm wondering whether we should just bite the bullet and default > SYSTEM_ZLIB to true on Linux, maybe Solaris too (Sherman - can you > think of any reasons not to do this? It would avoid needing to put in > a means to switch zlib at startup as it could be done simply with > LD_LIBRARY_PATH). > > -Alan. I'm still on a very old ubuntu (9.1) so I might be wrong. Does the pkg-config --cflags/libs assume the zlib-dev or some similar dev package to be installed? pkg-config says I don't have it installed, so the cflags does not get set correctly. It appears at least one ubuntu12 machine has the same situation. So I guess at least we will have to add something into the "build readme" to add this package, if it is not installed by default. I don't have a Solaris machine for a while, so just wonder if the zlib always get installed by default installation these days? -Sherman From dingxmin at linux.vnet.ibm.com Mon Aug 6 08:57:33 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Mon, 06 Aug 2012 16:57:33 +0800 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <501F231C.9050300@oracle.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> Message-ID: <501F86FD.9040801@linux.vnet.ibm.com> Hi Holmes, I agree with your comment on duplicated comment. It should be factored out. The context of the change is that the group of signal handlers should be registered at best effort, which means for all JVM, we should try to register them all in an independent way. In fact, the original code does not act homogeneously. For example, in solaris/classes/java/lang/Terminator.java, there are 3 registration calls for signal "HUP", "INT" and "TERM". On start up of some JVM, "INT" may already have been occupied for some reason and this will cause "TERM" to be skipped. It is not what the original code intends to do, is it? I provided a new revision of patch to remove the dup comment, available @ http://cr.openjdk.java.net/~youdwei/ojdk-430/webrev.01/. Your comment is much appreciated. Thanks and best regards, Frank On 8/6/2012 9:51 AM, David Holmes wrote: > Hi Frank, > > On 3/08/2012 5:39 PM, Frank Ding wrote: >> Hi guys, >> I found that in java.lang.Terminator, setup() method, >> The following code of registering default signal handlers can be >> improved: >> / try { >> Signal.handle(new Signal("INT"), sh); >> Signal.handle(new Signal("TERM"), sh); >> } catch (IllegalArgumentException e) { >> }/ >> The revised code is illustrated below: >> / try { >> Signal.handle(new Signal("INT"), sh); >> } catch (IllegalArgumentException e) { >> } >> try { >> Signal.handle(new Signal("TERM"), sh); >> } catch (IllegalArgumentException e) { >> } >> /The improved version makes more sense since exception thrown from first >> Signal.handle call does not affect subsequent calls. This is more >> consistent with its original intention. >> A patch I made is available @ >> http://cr.openjdk.java.net/~youdwei/ojdk-430/webrev.00// >> >> /Could anybody please take a look at it? Thanks in advance/ > > Can you explain the context for this change. It seems to me that there > is an expectation that the group of signals act homogenously: all or > none, whereas your change make it appear that the success/failure for > each signal is independent. Understanding exactly when/why the > IllegalArgumentException is thrown is important here. > > I don't like seeing the duplicated comment, perhaps that can be > factored out to the head of the block of code? > > Thanks, > David Holmes > >> Best regards, >> Frank >> / > From david.holmes at oracle.com Mon Aug 6 11:08:51 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 06 Aug 2012 21:08:51 +1000 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <501F86FD.9040801@linux.vnet.ibm.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> Message-ID: <501FA5C3.6040706@oracle.com> On 6/08/2012 6:57 PM, Frank Ding wrote: > Hi Holmes, > I agree with your comment on duplicated comment. It should be factored out. > The context of the change is that the group of signal handlers should be > registered at best effort, which means for all JVM, we should try to > register them all in an independent way. In fact, the original code does > not act homogeneously. For example, in > solaris/classes/java/lang/Terminator.java, there are 3 registration > calls for signal "HUP", "INT" and "TERM". On start up of some JVM, "INT" > may already have been occupied for some reason and this will cause > "TERM" to be skipped. It is not what the original code intends to do, is > it? My question is: exactly what circumstances will cause the IllegalArgumentException to be thrown? Is it only when -Xrs is specified? And if so does it then affect all of the signals? David ------ > I provided a new revision of patch to remove the dup comment, available > @ http://cr.openjdk.java.net/~youdwei/ojdk-430/webrev.01/. Your comment > is much appreciated. > > Thanks and best regards, > Frank > > On 8/6/2012 9:51 AM, David Holmes wrote: >> Hi Frank, >> >> On 3/08/2012 5:39 PM, Frank Ding wrote: >>> Hi guys, >>> I found that in java.lang.Terminator, setup() method, >>> The following code of registering default signal handlers can be >>> improved: >>> / try { >>> Signal.handle(new Signal("INT"), sh); >>> Signal.handle(new Signal("TERM"), sh); >>> } catch (IllegalArgumentException e) { >>> }/ >>> The revised code is illustrated below: >>> / try { >>> Signal.handle(new Signal("INT"), sh); >>> } catch (IllegalArgumentException e) { >>> } >>> try { >>> Signal.handle(new Signal("TERM"), sh); >>> } catch (IllegalArgumentException e) { >>> } >>> /The improved version makes more sense since exception thrown from first >>> Signal.handle call does not affect subsequent calls. This is more >>> consistent with its original intention. >>> A patch I made is available @ >>> http://cr.openjdk.java.net/~youdwei/ojdk-430/webrev.00// >>> >>> /Could anybody please take a look at it? Thanks in advance/ >> >> Can you explain the context for this change. It seems to me that there >> is an expectation that the group of signals act homogenously: all or >> none, whereas your change make it appear that the success/failure for >> each signal is independent. Understanding exactly when/why the >> IllegalArgumentException is thrown is important here. >> >> I don't like seeing the duplicated comment, perhaps that can be >> factored out to the head of the block of code? >> >> Thanks, >> David Holmes >> >>> Best regards, >>> Frank >>> / >> > From ahughes at redhat.com Mon Aug 6 12:11:44 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Mon, 6 Aug 2012 08:11:44 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <501C3B53.7070605@oracle.com> Message-ID: <1687464542.483639.1344255104251.JavaMail.root@redhat.com> ----- Original Message ----- > Andrew, > > I just pushed 7188852. Is it possible for you to update your webrev > with > this change? I would > like to try a full build (and regression tests) on your final bits to > make sure we don't break > the build. > Do you mean the ZLIB_LIBS changes? I already published an updated webrev; > -Sherman > > On 08/03/2012 11:33 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> > >> ----- Original Message ----- > >>> On 03/08/2012 16:58, Andrew Hughes wrote: > >>> > >>> : It's what we've had for years, and was added orthogonally to 8 > >>> in: > >>> > >>> changeset: 5118:d45bc4307996 > >>> user: michaelm > >>> date: Tue Mar 06 20:34:38 2012 +0000 > >>> summary: 7113349: Initial changeset for Macosx port to jdk > >>> > >>> though that version is broken (at least on GNU/Linux) without the > >>> change > >>> to defines.h I posted in my patch earlier this week. Right, that > >>> change was for Mac and it didn't have the goal to enable it on > >>> Linux. > >>> > >>> BTW: Looking at your patch then I suspect it will cause problems > >>> on > >>> other platforms as it only sets ZLIB_LIBS in > >>> jdk_generic_profile.sh. > >>> If folks aren't using this script to setup their environment then > >>> I'm sure there will be a problem on Mac at least. I don't have > >>> time > >>> to spend on it but I suspect Defs-macosx.gmk will need to be > >>> updated > >>> to make it the default as it does now. > >>> > >> I think that's what Sherman just hit. > >> > >> I thought the documented way to build was using > >> jdk_generic_profile.sh? > >> I can add a check to Defs-macosx.gmk. > >> > > http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.02/ > > > > is an updated version which checks if ZLIB_LIBS is set on Solaris, > > GNU/Linux > > and MacOS X and sets it to -lz if not. > > > > I wasn't sure what to do with Windows but something can be added > > there if necessary. > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Mon Aug 6 12:13:27 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Mon, 6 Aug 2012 08:13:27 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <501C3B53.7070605@oracle.com> Message-ID: <1831194888.484016.1344255207713.JavaMail.root@redhat.com> ----- Original Message ----- > Andrew, > > I just pushed 7188852. Is it possible for you to update your webrev > with > this change? I would > like to try a full build (and regression tests) on your final bits to > make sure we don't break > the build. > Do you mean the ZLIB_LIBS changes? I already published an updated webrev: http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.02/ Is there something more needed? If not, let me know when you're happy with the patch and I'll push it. > -Sherman > > On 08/03/2012 11:33 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> > >> ----- Original Message ----- > >>> On 03/08/2012 16:58, Andrew Hughes wrote: > >>> > >>> : It's what we've had for years, and was added orthogonally to 8 > >>> in: > >>> > >>> changeset: 5118:d45bc4307996 > >>> user: michaelm > >>> date: Tue Mar 06 20:34:38 2012 +0000 > >>> summary: 7113349: Initial changeset for Macosx port to jdk > >>> > >>> though that version is broken (at least on GNU/Linux) without the > >>> change > >>> to defines.h I posted in my patch earlier this week. Right, that > >>> change was for Mac and it didn't have the goal to enable it on > >>> Linux. > >>> > >>> BTW: Looking at your patch then I suspect it will cause problems > >>> on > >>> other platforms as it only sets ZLIB_LIBS in > >>> jdk_generic_profile.sh. > >>> If folks aren't using this script to setup their environment then > >>> I'm sure there will be a problem on Mac at least. I don't have > >>> time > >>> to spend on it but I suspect Defs-macosx.gmk will need to be > >>> updated > >>> to make it the default as it does now. > >>> > >> I think that's what Sherman just hit. > >> > >> I thought the documented way to build was using > >> jdk_generic_profile.sh? > >> I can add a check to Defs-macosx.gmk. > >> > > http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.02/ > > > > is an updated version which checks if ZLIB_LIBS is set on Solaris, > > GNU/Linux > > and MacOS X and sets it to -lz if not. > > > > I wasn't sure what to do with Windows but something can be added > > there if necessary. > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Mon Aug 6 12:16:06 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Mon, 6 Aug 2012 08:16:06 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <501F58B2.9060604@oracle.com> Message-ID: <1807448116.487097.1344255366029.JavaMail.root@redhat.com> ----- Original Message ----- > > On 8/5/2012 2:00 PM, Alan Bateman wrote: > > On 03/08/2012 19:33, Andrew Hughes wrote: > >> : > >> http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.02/ > >> > >> is an updated version which checks if ZLIB_LIBS is set on Solaris, > >> GNU/Linux > >> and MacOS X and sets it to -lz if not. > >> > >> I wasn't sure what to do with Windows but something can be added > >> there if necessary. > > Thanks for the update, it looks right to me now. To double check I > > did > > a quick build+test on all platforms with latest jdk8/tl + your > > patch > > and I don't see any issues. > > > > Now I'm wondering whether we should just bite the bullet and > > default > > SYSTEM_ZLIB to true on Linux, maybe Solaris too (Sherman - can you > > think of any reasons not to do this? It would avoid needing to put > > in > > a means to switch zlib at startup as it could be done simply with > > LD_LIBRARY_PATH). > > > > -Alan. > > I'm still on a very old ubuntu (9.1) so I might be wrong. Does the > pkg-config --cflags/libs assume the zlib-dev or > some similar dev package to be installed? pkg-config says I don't > have > it installed, so the cflags does not get > set correctly. You'll need zlib-dev both for pkg-config and the actual build, as you'll need the zlib headers. CFLAGS is usually empty anyway but pkgconfig will also provide the "-lz" for ZLIB_LIBS. > It appears at least one ubuntu12 machine has the same > situation. So I guess at least we will have > to add something into the "build readme" to add this package, if it > is > not installed by default. > Probably. This is pretty standard for building anything on a binary distribution, as binaries are split away from development headers, so it's not anything out of the ordinary. Headers for other libraries are already a requirement. > I don't have a Solaris machine for a while, so just wonder if the > zlib > always get installed by default installation > these days? > I'll defer to those better informed on this one :-) > -Sherman > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From xueming.shen at oracle.com Mon Aug 6 17:52:26 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 06 Aug 2012 10:52:26 -0700 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <1807448116.487097.1344255366029.JavaMail.root@redhat.com> References: <1807448116.487097.1344255366029.JavaMail.root@redhat.com> Message-ID: <5020045A.7020005@oracle.com> Hi Andrew, I meant if we are going to put SYSTEM_ZLIB=true as default for linux as Alan suggested, we might need to update the build document as well to include zlib-dev as the "necessary" package to build jdk on linux. Currently the SYSTEM_ZLIB=true is set in make/common/Defs-macosx.gmk. ZLIB_VERSION = 1.2.5 is setin make/common/Defs.gmk. I'm not good at Makfile structure, just wonder why not put the ZLIB_LIBS setting into same place as well, it might help the future maintenance. I'm not sure in Defs.gmk or three copies in Defs-.gmk, though. Personally, I would just put it in Defs.gmk, together with the ZLIB_VERSION. The rest looks fine to me. -Sherman On 08/06/2012 05:16 AM, Andrew Hughes wrote: > > ----- Original Message ----- >> On 8/5/2012 2:00 PM, Alan Bateman wrote: >>> On 03/08/2012 19:33, Andrew Hughes wrote: >>>> : >>>> http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.02/ >>>> >>>> is an updated version which checks if ZLIB_LIBS is set on Solaris, >>>> GNU/Linux >>>> and MacOS X and sets it to -lz if not. >>>> >>>> I wasn't sure what to do with Windows but something can be added >>>> there if necessary. >>> Thanks for the update, it looks right to me now. To double check I >>> did >>> a quick build+test on all platforms with latest jdk8/tl + your >>> patch >>> and I don't see any issues. >>> >>> Now I'm wondering whether we should just bite the bullet and >>> default >>> SYSTEM_ZLIB to true on Linux, maybe Solaris too (Sherman - can you >>> think of any reasons not to do this? It would avoid needing to put >>> in >>> a means to switch zlib at startup as it could be done simply with >>> LD_LIBRARY_PATH). >>> >>> -Alan. >> I'm still on a very old ubuntu (9.1) so I might be wrong. Does the >> pkg-config --cflags/libs assume the zlib-dev or >> some similar dev package to be installed? pkg-config says I don't >> have >> it installed, so the cflags does not get >> set correctly. > You'll need zlib-dev both for pkg-config and the actual build, as you'll > need the zlib headers. CFLAGS is usually empty anyway but pkgconfig > will also provide the "-lz" for ZLIB_LIBS. > >> It appears at least one ubuntu12 machine has the same >> situation. So I guess at least we will have >> to add something into the "build readme" to add this package, if it >> is >> not installed by default. >> > Probably. This is pretty standard for building anything on a binary distribution, > as binaries are split away from development headers, so it's not anything out of the > ordinary. Headers for other libraries are already a requirement. > >> I don't have a Solaris machine for a while, so just wonder if the >> zlib >> always get installed by default installation >> these days? >> > I'll defer to those better informed on this one :-) > >> -Sherman >> From ahughes at redhat.com Mon Aug 6 18:26:36 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Mon, 6 Aug 2012 14:26:36 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <5020045A.7020005@oracle.com> Message-ID: <727873606.691211.1344277596187.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Andrew, > > I meant if we are going to put SYSTEM_ZLIB=true as default for linux > as > Alan suggested, > we might need to update the build document as well to include > zlib-dev > as the "necessary" > package to build jdk on linux. Ok. I think that's a separate issue which warrants a separate bug & changeset. Let's have this one work on fixing the build so SYSTEM_ZLIB actually works on GNU/Linux first. At the moment, enabling SYSTEM_ZLIB=true breaks the build on anything other than MacOS/X, which seems like a bug to me. > > Currently the SYSTEM_ZLIB=true is set in make/common/Defs-macosx.gmk. Ok, so it's the default there already. That explains the defines.h logic. > ZLIB_VERSION = 1.2.5 is setin make/common/Defs.gmk. What's the relevance of this version? My system install is 1.2.7. > I'm not good at > Makfile structure, > just wonder why not put the ZLIB_LIBS setting into same place as > well, > it might help the > future maintenance. I'm not sure in Defs.gmk or three copies in > Defs-.gmk, though. > Personally, I would just put it in Defs.gmk, together with the > ZLIB_VERSION. There's more than just three Defs-.gmk files. There's also Windows and embedded, neither of which I can build and I doubt "-lz" works on Windows for linking zlib. I've used MacOS X/*BSD, Solaris and GNU/Linux enough to know it will work there. > > The rest looks fine to me. > Thanks :-) > -Sherman > > On 08/06/2012 05:16 AM, Andrew Hughes wrote: > > > > ----- Original Message ----- > >> On 8/5/2012 2:00 PM, Alan Bateman wrote: > >>> On 03/08/2012 19:33, Andrew Hughes wrote: > >>>> : > >>>> http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.02/ > >>>> > >>>> is an updated version which checks if ZLIB_LIBS is set on > >>>> Solaris, > >>>> GNU/Linux > >>>> and MacOS X and sets it to -lz if not. > >>>> > >>>> I wasn't sure what to do with Windows but something can be added > >>>> there if necessary. > >>> Thanks for the update, it looks right to me now. To double check > >>> I > >>> did > >>> a quick build+test on all platforms with latest jdk8/tl + your > >>> patch > >>> and I don't see any issues. > >>> > >>> Now I'm wondering whether we should just bite the bullet and > >>> default > >>> SYSTEM_ZLIB to true on Linux, maybe Solaris too (Sherman - can > >>> you > >>> think of any reasons not to do this? It would avoid needing to > >>> put > >>> in > >>> a means to switch zlib at startup as it could be done simply with > >>> LD_LIBRARY_PATH). > >>> > >>> -Alan. > >> I'm still on a very old ubuntu (9.1) so I might be wrong. Does > >> the > >> pkg-config --cflags/libs assume the zlib-dev or > >> some similar dev package to be installed? pkg-config says I don't > >> have > >> it installed, so the cflags does not get > >> set correctly. > > You'll need zlib-dev both for pkg-config and the actual build, as > > you'll > > need the zlib headers. CFLAGS is usually empty anyway but > > pkgconfig > > will also provide the "-lz" for ZLIB_LIBS. > > > >> It appears at least one ubuntu12 machine has the same > >> situation. So I guess at least we will have > >> to add something into the "build readme" to add this package, if > >> it > >> is > >> not installed by default. > >> > > Probably. This is pretty standard for building anything on a > > binary distribution, > > as binaries are split away from development headers, so it's not > > anything out of the > > ordinary. Headers for other libraries are already a requirement. > > > >> I don't have a Solaris machine for a while, so just wonder if the > >> zlib > >> always get installed by default installation > >> these days? > >> > > I'll defer to those better informed on this one :-) > > > >> -Sherman > >> > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From xueming.shen at oracle.com Mon Aug 6 18:59:26 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 06 Aug 2012 11:59:26 -0700 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <727873606.691211.1344277596187.JavaMail.root@redhat.com> References: <727873606.691211.1344277596187.JavaMail.root@redhat.com> Message-ID: <5020140E.4090507@oracle.com> On 08/06/2012 11:26 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Hi Andrew, >> >> I meant if we are going to put SYSTEM_ZLIB=true as default for linux >> as >> Alan suggested, >> we might need to update the build document as well to include >> zlib-dev >> as the "necessary" >> package to build jdk on linux. > Ok. I think that's a separate issue which warrants a separate bug& > changeset. Let's have this one work on fixing the build so SYSTEM_ZLIB > actually works on GNU/Linux first. At the moment, enabling SYSTEM_ZLIB=true > breaks the build on anything other than MacOS/X, which seems like a bug to me. It's a separate issue. For your current patch, since it does not set the SYSTEM_ZLIB=true for linux, it's not an issue at all. My apology for my naive question, is zlib (the library) always installed by default by most linux distributors? >> Currently the SYSTEM_ZLIB=true is set in make/common/Defs-macosx.gmk. > Ok, so it's the default there already. That explains the defines.h logic. > >> ZLIB_VERSION = 1.2.5 is setin make/common/Defs.gmk. > What's the relevance of this version? My system install is 1.2.7. That's the version bundled with jdk. Yes, 1.2.7 is the latest, out May/2012. I might try to upgrade the bundled one to the latest version at later stage of jdk8. The "relevance" is that they are all used for "zlib build", so it would be better to put them together/close for future maintenance, though some comment might be necessary to clarify one is for "bundled" version, on is for the link options for os zlib. -sherman From david.holmes at oracle.com Mon Aug 6 23:01:20 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Aug 2012 09:01:20 +1000 Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <1158150856.7880413.1343944992157.JavaMail.root@redhat.com> References: <1158150856.7880413.1343944992157.JavaMail.root@redhat.com> Message-ID: <50204CC0.1060407@oracle.com> Thanks Andrew. 7189533 created for this. David ----- On 3/08/2012 8:03 AM, Andrew Hughes wrote: > > > ----- Original Message ----- >> Hi Andrew, >> >> On 2/08/2012 7:35 PM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Andrew et al, >>>> >>>> AFAICS here: >>>> >>>> 220 encoding_variant = malloc(strlen(temp)+1); >>>> 221 if (encoding_variant == NULL) { >>>> 222 JNU_ThrowOutOfMemoryError(env, NULL); >>>> 223 return 0; >>>> 224 } >>>> >>>> we also need to do free(temp). Similarly later where we return >>>> with >>>> OOM >>>> due to realloc failure, don't we also need to free what was >>>> previously >>>> malloc'd? >>>> >>> >>> I was thinking the same just before committing, but didn't want to >>> delay >>> the main fix any further. >>> >>> While logically we do need one, I'm not sure it's worthwhile if >>> we're going >>> to throw the exception and exit anyway? Will the return even be >>> reached? >>> If we're already near enough to OOM that we can't allocate more >>> memory, >>> it's unlikely freeing temp is going to get us much, and I presume >>> it will >>> be freed anyway when the VM process exists. >> >> Are we definitely going to exit on this error? I agree if we're out >> of >> memory we're likely to continue to run into problems if we try to >> continue. But I'd prefer to see proper cleanup rather than making >> assumptions about the context in which the code is used. >> >>> But I can add it if necessary. It's trivial after all and does not >>> real >>> harm. >> >> It will also prevent us getting flagged with memory-leak >> warnings/errors >> from static analysis tools. >> > > This should cover it, I think: > > http://cr.openjdk.java.net/~andrew/buffer_overflow/webrev.02/ > > but it'll need a bug ID. > >> Thanks, >> David >> >>>> David >>>> >>>> On 2/08/2012 7:18 AM, Andrew Hughes wrote: >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> On 01/08/2012 14:52, Andrew Hughes wrote: >>>>>>> : >>>>>>> >>>>>>> >>>>>>> In any case, there is a Sun bug open for this: >>>>>>> >>>>>>> 6844255: Potential stack corruption in GetJavaProperties >>>>>>> >>>>>>> Can I take it that I can just get on and push Omair's extended >>>>>>> version now then, >>>>>>> with that bug ID? >>>>>> Yes, go ahead, I should have said that in my mail. >>>>>> >>>>> >>>>> Thanks. >>>>> >>>>> Done: >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-August/010993.html >>>>> >>>>> with Omair as author and yourself and I as reviewers. >>>>> >>>>>>> Well, the locale can be set be an environment variable, so it >>>>>>> could >>>>>>> potentially >>>>>>> be anything of any length... >>>>>>> >>>>>>> The Debian bug posted above has an example, though I couldn't >>>>>>> replicate it. >>>>>>> >>>>>> I couldn't replicate it either and was just curious if anyone >>>>>> managed >>>>>> to >>>>>> demonstrate it. >>>>>> >>>>> >>>>> Yeah, I tend to think it's more potentially exploitable rather >>>>> than >>>>> something >>>>> that's actually been hit. >>>>> >>>>>> -Alan. >>>>>> >>>>> >>>>> Thanks, >>>> >>> >> > From dingxmin at linux.vnet.ibm.com Tue Aug 7 03:03:22 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Tue, 07 Aug 2012 11:03:22 +0800 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <501FA5C3.6040706@oracle.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> Message-ID: <5020857A.30509@linux.vnet.ibm.com> Hi Holmes, It is not only when -Xrs is specified. The circumstances can be illustrated below 1. a JVM has its own extra signal registration that occupies say, "INT", prior to the execution Terminator.setup(). 2. User customizes HotSpot to have similar overridden signal handling. In both cases, I think Terminator.setup() should work at best effort to register all. Best regards, Frank On 8/6/2012 7:08 PM, David Holmes wrote: > On 6/08/2012 6:57 PM, Frank Ding wrote: >> Hi Holmes, >> I agree with your comment on duplicated comment. It should be >> factored out. >> The context of the change is that the group of signal handlers should be >> registered at best effort, which means for all JVM, we should try to >> register them all in an independent way. In fact, the original code does >> not act homogeneously. For example, in >> solaris/classes/java/lang/Terminator.java, there are 3 registration >> calls for signal "HUP", "INT" and "TERM". On start up of some JVM, "INT" >> may already have been occupied for some reason and this will cause >> "TERM" to be skipped. It is not what the original code intends to do, is >> it? > > My question is: exactly what circumstances will cause the > IllegalArgumentException to be thrown? Is it only when -Xrs is > specified? And if so does it then affect all of the signals? > > David > ------ > >> I provided a new revision of patch to remove the dup comment, available >> @ http://cr.openjdk.java.net/~youdwei/ojdk-430/webrev.01/. Your comment >> is much appreciated. >> >> Thanks and best regards, >> Frank >> >> On 8/6/2012 9:51 AM, David Holmes wrote: >>> Hi Frank, >>> >>> On 3/08/2012 5:39 PM, Frank Ding wrote: >>>> Hi guys, >>>> I found that in java.lang.Terminator, setup() method, >>>> The following code of registering default signal handlers can be >>>> improved: >>>> / try { >>>> Signal.handle(new Signal("INT"), sh); >>>> Signal.handle(new Signal("TERM"), sh); >>>> } catch (IllegalArgumentException e) { >>>> }/ >>>> The revised code is illustrated below: >>>> / try { >>>> Signal.handle(new Signal("INT"), sh); >>>> } catch (IllegalArgumentException e) { >>>> } >>>> try { >>>> Signal.handle(new Signal("TERM"), sh); >>>> } catch (IllegalArgumentException e) { >>>> } >>>> /The improved version makes more sense since exception thrown from >>>> first >>>> Signal.handle call does not affect subsequent calls. This is more >>>> consistent with its original intention. >>>> A patch I made is available @ >>>> http://cr.openjdk.java.net/~youdwei/ojdk-430/webrev.00// >>>> >>>> /Could anybody please take a look at it? Thanks in advance/ >>> >>> Can you explain the context for this change. It seems to me that there >>> is an expectation that the group of signals act homogenously: all or >>> none, whereas your change make it appear that the success/failure for >>> each signal is independent. Understanding exactly when/why the >>> IllegalArgumentException is thrown is important here. >>> >>> I don't like seeing the duplicated comment, perhaps that can be >>> factored out to the head of the block of code? >>> >>> Thanks, >>> David Holmes >>> >>>> Best regards, >>>> Frank >>>> / >>> >> > From david.holmes at oracle.com Tue Aug 7 03:35:47 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Aug 2012 13:35:47 +1000 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <5020857A.30509@linux.vnet.ibm.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> Message-ID: <50208D13.2090006@oracle.com> On 7/08/2012 1:03 PM, Frank Ding wrote: > Hi Holmes, David :) > It is not only when -Xrs is specified. The circumstances can be > illustrated below > 1. a JVM has its own extra signal registration that occupies say, "INT", > prior to the execution Terminator.setup(). > 2. User customizes HotSpot to have similar overridden signal handling. > In both cases, I think Terminator.setup() should work at best effort to > register all. The change is harmless but as far as I can see you would have to customize the VM before this change would have any affect. The signals involved here are the SHUTDOWNn_SIGNAL values (which for linux/solaris are HUP, INT and TERM). JVM_RegisterSignal simply does: case SHUTDOWN1_SIGNAL: case SHUTDOWN2_SIGNAL: case SHUTDOWN3_SIGNAL: if (ReduceSignalUsage) return (void*)-1; if (os::Linux::is_sig_ignored(sig)) return (void*)1; } So with -Xrs all values will get rejected as a group. As far as I can see this is the only time that -1 will be returned to Signal.handle0 and hence the only circumstance where IllegalArgumentException will be thrown. So without customizing the VM if any of these signals cause IllegalArgumentException then they all will and hence having distinct try/catch blocks for each is pointless. Did I miss something? David ----- > Best regards, > Frank > > On 8/6/2012 7:08 PM, David Holmes wrote: >> On 6/08/2012 6:57 PM, Frank Ding wrote: >>> Hi Holmes, >>> I agree with your comment on duplicated comment. It should be >>> factored out. >>> The context of the change is that the group of signal handlers should be >>> registered at best effort, which means for all JVM, we should try to >>> register them all in an independent way. In fact, the original code does >>> not act homogeneously. For example, in >>> solaris/classes/java/lang/Terminator.java, there are 3 registration >>> calls for signal "HUP", "INT" and "TERM". On start up of some JVM, "INT" >>> may already have been occupied for some reason and this will cause >>> "TERM" to be skipped. It is not what the original code intends to do, is >>> it? >> >> My question is: exactly what circumstances will cause the >> IllegalArgumentException to be thrown? Is it only when -Xrs is >> specified? And if so does it then affect all of the signals? >> >> David >> ------ >> >>> I provided a new revision of patch to remove the dup comment, available >>> @ http://cr.openjdk.java.net/~youdwei/ojdk-430/webrev.01/. Your comment >>> is much appreciated. >>> >>> Thanks and best regards, >>> Frank >>> >>> On 8/6/2012 9:51 AM, David Holmes wrote: >>>> Hi Frank, >>>> >>>> On 3/08/2012 5:39 PM, Frank Ding wrote: >>>>> Hi guys, >>>>> I found that in java.lang.Terminator, setup() method, >>>>> The following code of registering default signal handlers can be >>>>> improved: >>>>> / try { >>>>> Signal.handle(new Signal("INT"), sh); >>>>> Signal.handle(new Signal("TERM"), sh); >>>>> } catch (IllegalArgumentException e) { >>>>> }/ >>>>> The revised code is illustrated below: >>>>> / try { >>>>> Signal.handle(new Signal("INT"), sh); >>>>> } catch (IllegalArgumentException e) { >>>>> } >>>>> try { >>>>> Signal.handle(new Signal("TERM"), sh); >>>>> } catch (IllegalArgumentException e) { >>>>> } >>>>> /The improved version makes more sense since exception thrown from >>>>> first >>>>> Signal.handle call does not affect subsequent calls. This is more >>>>> consistent with its original intention. >>>>> A patch I made is available @ >>>>> http://cr.openjdk.java.net/~youdwei/ojdk-430/webrev.00// >>>>> >>>>> /Could anybody please take a look at it? Thanks in advance/ >>>> >>>> Can you explain the context for this change. It seems to me that there >>>> is an expectation that the group of signals act homogenously: all or >>>> none, whereas your change make it appear that the success/failure for >>>> each signal is independent. Understanding exactly when/why the >>>> IllegalArgumentException is thrown is important here. >>>> >>>> I don't like seeing the duplicated comment, perhaps that can be >>>> factored out to the head of the block of code? >>>> >>>> Thanks, >>>> David Holmes >>>> >>>>> Best regards, >>>>> Frank >>>>> / >>>> >>> >> > From yiming.wang at oracle.com Tue Aug 7 07:00:49 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 07 Aug 2012 15:00:49 +0800 Subject: [PATCH] Review Request: 7076644 TEST_BUG: test/java/io/File/Basic.java fails with cygwin Message-ID: <5020BD21.3070105@oracle.com> Hi Alan, Can you please help to review the fix below for bug http://monaco.us.oracle.com/detail.jsf?cr=7076644? http://dl.dropbox.com/u/90659131/fixes/7076644/webrev/index.html As discussed, it is caused a known issue of cygwin that chmod doesn't work, see http://cygwin.com/faq/faq-nochunks.html#faq.using.chmod. The fix is to replace "chmod ugo-w" to dos command "attrib +R" when test is executed in CYGWIN or MKS. Thanks, Eric From dawid.weiss at gmail.com Tue Aug 7 08:14:20 2012 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Tue, 7 Aug 2012 10:14:20 +0200 Subject: Process.exec() hung on Windows, how to tell what happened from dmp file? Message-ID: Hi everyone, Seems like the right list to ask, but redirect me if there's a better place, please. I have a Java process that forks a process and waits for it. When repeatedly running on: Windows (64 bit) java version "1.7.0_05" Java(TM) SE Runtime Environment (build 1.7.0_05-b05) Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode) it once hung on: "pool-10-thread-1" prio=6 tid=0x000000000a31b800 nid=0x1964 runnable [0x000000000a49e000] java.lang.Thread.State: RUNNABLE at java.lang.ProcessImpl.waitForInterruptibly(Native Method) at java.lang.ProcessImpl.waitFor(ProcessImpl.java:252) Interestingly, the forked process was not visible to jps, jstack or any other tools. Neither could it be killed using procexp. I've created a mini and full dump file to see where it actually was and what happened but I don't know the windows toolchain enough to be able to analyze it. What I did get to is load windbg and a dump threads from a full dump: 0:000> ~*kL WARNING: Teb 0 pointer is NULL - defaulting to 00000000`7ffde000 WARNING: 00000000`7ffde000 does not appear to be a TEB . 0 Id: ec8.e88 Suspend: -1 Teb: 00000000`7ffde000 Unfrozen WARNING: Teb 0 pointer is NULL - defaulting to 00000000`7ffde000 WARNING: 00000000`7ffde000 does not appear to be a TEB Child-SP RetAddr Call Site 00000000`06d5fb48 00000000`7753418b ntdll!NtTerminateProcess+0xa 00000000`06d5fb50 00000000`74320cf5 ntdll!RtlExitUserProcess+0x9b *** ERROR: Symbol file could not be found. Defaulted to export symbols for jvm.dll - 00000000`06d5fb80 00000000`6c4e3c75 msvcr100!get_pgmptr+0x249 00000000`06d5fbf0 00000000`6c514d85 jvm!JVM_ResolveClass+0x19d25 00000000`06d5fc20 00000000`6c513db1 jvm!JVM_ResolveClass+0x4ae35 00000000`06d5fc50 00000000`6c514183 jvm!JVM_ResolveClass+0x49e61 00000000`06d5fcc0 00000000`6c51464e jvm!JVM_ResolveClass+0x4a233 00000000`06d5fd30 00000000`6c54556e jvm!JVM_ResolveClass+0x4a6fe 00000000`06d5fd90 00000000`74321db7 jvm!JVM_FindSignal+0x633e 00000000`06d5fdd0 00000000`74321e53 msvcr100!endthreadex+0x43 *** ERROR: Symbol file could not be found. Defaulted to export symbols for kernel32.dll - 00000000`06d5fe00 00000000`7740652d msvcr100!endthreadex+0xdf 00000000`06d5fe30 00000000`7753c521 kernel32!BaseThreadInitThunk+0xd 00000000`06d5fe60 00000000`00000000 ntdll!RtlUserThreadStart+0x21 This was a permanent state, lasted a few hours. Any help decoding what's happened will be greatly appreciated. Dawid From Alan.Bateman at oracle.com Tue Aug 7 09:10:29 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Aug 2012 10:10:29 +0100 Subject: [PATCH] Review Request: 7076644 TEST_BUG: test/java/io/File/Basic.java fails with cygwin In-Reply-To: <5020BD21.3070105@oracle.com> References: <5020BD21.3070105@oracle.com> Message-ID: <5020DB85.1040800@oracle.com> On 07/08/2012 08:00, Eric Wang wrote: > Hi Alan, > > Can you please help to review the fix below for bug > http://monaco.us.oracle.com/detail.jsf?cr=7076644? > > http://dl.dropbox.com/u/90659131/fixes/7076644/webrev/index.html > > As discussed, it is caused a known issue of cygwin that chmod doesn't > work, see http://cygwin.com/faq/faq-nochunks.html#faq.using.chmod. > The fix is to replace "chmod ugo-w" to dos command "attrib +R" when > test is executed in CYGWIN or MKS. Thanks Eric, it good to another test off the exclude list. Minor comment is that the other shell tests check for Windows* rather than Windows_*, I can change it for you when pushing the fix. -Alan From Alan.Bateman at oracle.com Tue Aug 7 09:15:36 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Aug 2012 10:15:36 +0100 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <50208D13.2090006@oracle.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> Message-ID: <5020DCB8.4010609@oracle.com> On 07/08/2012 04:35, David Holmes wrote: > > The change is harmless but as far as I can see you would have to > customize the VM before this change would have any affect. The signals > involved here are the SHUTDOWNn_SIGNAL values (which for linux/solaris > are HUP, INT and TERM). JVM_RegisterSignal simply does: > > case SHUTDOWN1_SIGNAL: > case SHUTDOWN2_SIGNAL: > case SHUTDOWN3_SIGNAL: > if (ReduceSignalUsage) return (void*)-1; > if (os::Linux::is_sig_ignored(sig)) return (void*)1; > } > > So with -Xrs all values will get rejected as a group. As far as I can > see this is the only time that -1 will be returned to Signal.handle0 > and hence the only circumstance where IllegalArgumentException will be > thrown. So without customizing the VM if any of these signals cause > IllegalArgumentException then they all will and hence having distinct > try/catch blocks for each is pointless. > > Did I miss something? I agree with David and I think this thread is just missing an explanation as to how you ran into this. It this AIX and -Xrs is mapped to a different set of signals, maybe it was an observation when reading the code?? -Alan. From ahughes at redhat.com Tue Aug 7 11:48:19 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 7 Aug 2012 07:48:19 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <5020140E.4090507@oracle.com> Message-ID: <391830811.1218929.1344340099561.JavaMail.root@redhat.com> ----- Original Message ----- > On 08/06/2012 11:26 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> Hi Andrew, > >> > >> I meant if we are going to put SYSTEM_ZLIB=true as default for > >> linux > >> as > >> Alan suggested, > >> we might need to update the build document as well to include > >> zlib-dev > >> as the "necessary" > >> package to build jdk on linux. > > Ok. I think that's a separate issue which warrants a separate bug& > > changeset. Let's have this one work on fixing the build so > > SYSTEM_ZLIB > > actually works on GNU/Linux first. At the moment, enabling > > SYSTEM_ZLIB=true > > breaks the build on anything other than MacOS/X, which seems like a > > bug to me. > > It's a separate issue. For your current patch, since it does not set > the > SYSTEM_ZLIB=true > for linux, it's not an issue at all. As we override the default anyway, I'd prefer not to be the one pushing for it if it causes problems down the road :-) My apology for my naive > question, > is zlib (the library) > always installed by default by most linux distributors? No apology required. It's not that naive a question as there are plenty of distributions out there, so giving a completely accurate answer is impossible. There's more than likely someone who doesn't :-) I would say it's extremely unlikely that the library's not installed. Looking at the dependency tree, it's a requirement of perl, nss, libpng, freetype, openssh, firefox, kdelibs & cairo to name a few. You're not going to get much of a GUI environment going without it, that's for sure. As you pointed out earlier in the thread, binary distributions tend to separate the library and the development headers / pkgconfig files. It's much less likely that zlib-devel (or whatever it gets called) is installed on a standard system, but for someone doing builds, it becomes more likely especially as it's a dependency for other development packages such as the one for libpng. > > >> Currently the SYSTEM_ZLIB=true is set in > >> make/common/Defs-macosx.gmk. > > Ok, so it's the default there already. That explains the defines.h > > logic. > > > >> ZLIB_VERSION = 1.2.5 is setin make/common/Defs.gmk. > > What's the relevance of this version? My system install is 1.2.7. > > That's the version bundled with jdk. Yes, 1.2.7 is the latest, out > May/2012. I might try to > upgrade the bundled one to the latest version at later stage of jdk8. > The "relevance" is that they are all used for "zlib build", so it > would > be better to put them > together/close for future maintenance, though some comment might be > necessary to clarify > one is for "bundled" version, on is for the link options for os zlib. > Ah, ok. So it's irrelevant if SYSTEM_ZLIB=true. I was worried the idea might be for the build to do a version check like it does with Freetype. That's been a pain in the past. So is the patch ok for me to push? And do we have a bug ID if so? Sorry if you've already mentioned one, but I've lost track in this thread :-) > -sherman > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From alan.bateman at oracle.com Tue Aug 7 11:48:43 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 07 Aug 2012 11:48:43 +0000 Subject: hg: jdk8/tl/jdk: 7076644: TEST_BUG: test/java/io/File/Basic.java fails with cygwin Message-ID: <20120807114853.E377C473D2@hg.openjdk.java.net> Changeset: e0ef14d89741 Author: alanb Date: 2012-08-07 12:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0ef14d89741 7076644: TEST_BUG: test/java/io/File/Basic.java fails with cygwin Reviewed-by: alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/io/File/basic.sh From ahughes at redhat.com Tue Aug 7 11:49:28 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 7 Aug 2012 07:49:28 -0400 (EDT) Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <50204CC0.1060407@oracle.com> Message-ID: <445074554.1219383.1344340168460.JavaMail.root@redhat.com> ----- Original Message ----- > Thanks Andrew. 7189533 created for this. > Thanks. Ok to push then? :-) > David > ----- > > On 3/08/2012 8:03 AM, Andrew Hughes wrote: > > > > > > ----- Original Message ----- > >> Hi Andrew, > >> > >> On 2/08/2012 7:35 PM, Andrew Hughes wrote: > >>> ----- Original Message ----- > >>>> Andrew et al, > >>>> > >>>> AFAICS here: > >>>> > >>>> 220 encoding_variant = malloc(strlen(temp)+1); > >>>> 221 if (encoding_variant == NULL) { > >>>> 222 JNU_ThrowOutOfMemoryError(env, NULL); > >>>> 223 return 0; > >>>> 224 } > >>>> > >>>> we also need to do free(temp). Similarly later where we return > >>>> with > >>>> OOM > >>>> due to realloc failure, don't we also need to free what was > >>>> previously > >>>> malloc'd? > >>>> > >>> > >>> I was thinking the same just before committing, but didn't want > >>> to > >>> delay > >>> the main fix any further. > >>> > >>> While logically we do need one, I'm not sure it's worthwhile if > >>> we're going > >>> to throw the exception and exit anyway? Will the return even be > >>> reached? > >>> If we're already near enough to OOM that we can't allocate more > >>> memory, > >>> it's unlikely freeing temp is going to get us much, and I presume > >>> it will > >>> be freed anyway when the VM process exists. > >> > >> Are we definitely going to exit on this error? I agree if we're > >> out > >> of > >> memory we're likely to continue to run into problems if we try to > >> continue. But I'd prefer to see proper cleanup rather than making > >> assumptions about the context in which the code is used. > >> > >>> But I can add it if necessary. It's trivial after all and does > >>> not > >>> real > >>> harm. > >> > >> It will also prevent us getting flagged with memory-leak > >> warnings/errors > >> from static analysis tools. > >> > > > > This should cover it, I think: > > > > http://cr.openjdk.java.net/~andrew/buffer_overflow/webrev.02/ > > > > but it'll need a bug ID. > > > >> Thanks, > >> David > >> > >>>> David > >>>> > >>>> On 2/08/2012 7:18 AM, Andrew Hughes wrote: > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> On 01/08/2012 14:52, Andrew Hughes wrote: > >>>>>>> : > >>>>>>> > >>>>>>> > >>>>>>> In any case, there is a Sun bug open for this: > >>>>>>> > >>>>>>> 6844255: Potential stack corruption in GetJavaProperties > >>>>>>> > >>>>>>> Can I take it that I can just get on and push Omair's > >>>>>>> extended > >>>>>>> version now then, > >>>>>>> with that bug ID? > >>>>>> Yes, go ahead, I should have said that in my mail. > >>>>>> > >>>>> > >>>>> Thanks. > >>>>> > >>>>> Done: > >>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-August/010993.html > >>>>> > >>>>> with Omair as author and yourself and I as reviewers. > >>>>> > >>>>>>> Well, the locale can be set be an environment variable, so it > >>>>>>> could > >>>>>>> potentially > >>>>>>> be anything of any length... > >>>>>>> > >>>>>>> The Debian bug posted above has an example, though I couldn't > >>>>>>> replicate it. > >>>>>>> > >>>>>> I couldn't replicate it either and was just curious if anyone > >>>>>> managed > >>>>>> to > >>>>>> demonstrate it. > >>>>>> > >>>>> > >>>>> Yeah, I tend to think it's more potentially exploitable rather > >>>>> than > >>>>> something > >>>>> that's actually been hit. > >>>>> > >>>>>> -Alan. > >>>>>> > >>>>> > >>>>> Thanks, > >>>> > >>> > >> > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From neil.richards at ngmr.net Tue Aug 7 14:02:11 2012 From: neil.richards at ngmr.net (Neil Richards) Date: Tue, 07 Aug 2012 15:02:11 +0100 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <5020DCB8.4010609@oracle.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> Message-ID: <1344348131.28663.42.camel@chalkhill> On Tue, 2012-08-07 at 10:15 +0100, Alan Bateman wrote: > On 07/08/2012 04:35, David Holmes wrote: > > > > The change is harmless but as far as I can see you would have to > > customize the VM before this change would have any affect. The signals > > involved here are the SHUTDOWNn_SIGNAL values (which for linux/solaris > > are HUP, INT and TERM). JVM_RegisterSignal simply does: > > > > case SHUTDOWN1_SIGNAL: > > case SHUTDOWN2_SIGNAL: > > case SHUTDOWN3_SIGNAL: > > if (ReduceSignalUsage) return (void*)-1; > > if (os::Linux::is_sig_ignored(sig)) return (void*)1; > > } > > > > So with -Xrs all values will get rejected as a group. As far as I can > > see this is the only time that -1 will be returned to Signal.handle0 > > and hence the only circumstance where IllegalArgumentException will be > > thrown. So without customizing the VM if any of these signals cause > > IllegalArgumentException then they all will and hence having distinct > > try/catch blocks for each is pointless. > > > > Did I miss something? > I agree with David and I think this thread is just missing an > explanation as to how you ran into this. It this AIX and -Xrs is mapped > to a different set of signals, maybe it was an observation when reading > the code?? > > -Alan. >From a Java Class Library point of view, it seems to me that the desire is to register shutdown hooks for any of these signals (HUP, INT and TERM) whose use has not been restricted by the VM. So an attempt to register for each of these signals should be made, independent of the result of any of the other attempts. To do anything else builds into the Java class library code assumptions about the behaviour of the VM which are inherently implementation (version?) specific, which is a brittle thing to do. It currently assumes that the VM will either have restricted all these signals (the -Xrs case) or none of them. This assumption holds true for the current version of Hotspot VM, but not necessarily for other VM implementations, whose mix of signal usage may differ. So I think Frank's suggested change helps this code to adhere the VM / Class Library interface boundary, and so makes it less brittle. Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From xueming.shen at oracle.com Tue Aug 7 16:40:47 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 07 Aug 2012 09:40:47 -0700 Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <445074554.1219383.1344340168460.JavaMail.root@redhat.com> References: <445074554.1219383.1344340168460.JavaMail.root@redhat.com> Message-ID: <5021450F.6070701@oracle.com> Andrew, Since we are here:-) are we also supposed to "free" the old_temp at #250 and old_temp and old_ev at the end? -Sherman On 08/07/2012 04:49 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Thanks Andrew. 7189533 created for this. >> > Thanks. Ok to push then? :-) > >> David >> ----- >> >> On 3/08/2012 8:03 AM, Andrew Hughes wrote: >>> >>> ----- Original Message ----- >>>> Hi Andrew, >>>> >>>> On 2/08/2012 7:35 PM, Andrew Hughes wrote: >>>>> ----- Original Message ----- >>>>>> Andrew et al, >>>>>> >>>>>> AFAICS here: >>>>>> >>>>>> 220 encoding_variant = malloc(strlen(temp)+1); >>>>>> 221 if (encoding_variant == NULL) { >>>>>> 222 JNU_ThrowOutOfMemoryError(env, NULL); >>>>>> 223 return 0; >>>>>> 224 } >>>>>> >>>>>> we also need to do free(temp). Similarly later where we return >>>>>> with >>>>>> OOM >>>>>> due to realloc failure, don't we also need to free what was >>>>>> previously >>>>>> malloc'd? >>>>>> >>>>> I was thinking the same just before committing, but didn't want >>>>> to >>>>> delay >>>>> the main fix any further. >>>>> >>>>> While logically we do need one, I'm not sure it's worthwhile if >>>>> we're going >>>>> to throw the exception and exit anyway? Will the return even be >>>>> reached? >>>>> If we're already near enough to OOM that we can't allocate more >>>>> memory, >>>>> it's unlikely freeing temp is going to get us much, and I presume >>>>> it will >>>>> be freed anyway when the VM process exists. >>>> Are we definitely going to exit on this error? I agree if we're >>>> out >>>> of >>>> memory we're likely to continue to run into problems if we try to >>>> continue. But I'd prefer to see proper cleanup rather than making >>>> assumptions about the context in which the code is used. >>>> >>>>> But I can add it if necessary. It's trivial after all and does >>>>> not >>>>> real >>>>> harm. >>>> It will also prevent us getting flagged with memory-leak >>>> warnings/errors >>>> from static analysis tools. >>>> >>> This should cover it, I think: >>> >>> http://cr.openjdk.java.net/~andrew/buffer_overflow/webrev.02/ >>> >>> but it'll need a bug ID. >>> >>>> Thanks, >>>> David >>>> >>>>>> David >>>>>> >>>>>> On 2/08/2012 7:18 AM, Andrew Hughes wrote: >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> On 01/08/2012 14:52, Andrew Hughes wrote: >>>>>>>>> : >>>>>>>>> >>>>>>>>> >>>>>>>>> In any case, there is a Sun bug open for this: >>>>>>>>> >>>>>>>>> 6844255: Potential stack corruption in GetJavaProperties >>>>>>>>> >>>>>>>>> Can I take it that I can just get on and push Omair's >>>>>>>>> extended >>>>>>>>> version now then, >>>>>>>>> with that bug ID? >>>>>>>> Yes, go ahead, I should have said that in my mail. >>>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Done: >>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-August/010993.html >>>>>>> >>>>>>> with Omair as author and yourself and I as reviewers. >>>>>>> >>>>>>>>> Well, the locale can be set be an environment variable, so it >>>>>>>>> could >>>>>>>>> potentially >>>>>>>>> be anything of any length... >>>>>>>>> >>>>>>>>> The Debian bug posted above has an example, though I couldn't >>>>>>>>> replicate it. >>>>>>>>> >>>>>>>> I couldn't replicate it either and was just curious if anyone >>>>>>>> managed >>>>>>>> to >>>>>>>> demonstrate it. >>>>>>>> >>>>>>> Yeah, I tend to think it's more potentially exploitable rather >>>>>>> than >>>>>>> something >>>>>>> that's actually been hit. >>>>>>> >>>>>>>> -Alan. >>>>>>>> >>>>>>> Thanks, From Alan.Bateman at oracle.com Tue Aug 7 17:01:13 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 07 Aug 2012 18:01:13 +0100 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <1344348131.28663.42.camel@chalkhill> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> Message-ID: <502149D9.6060304@oracle.com> On 07/08/2012 15:02, Neil Richards wrote: > : > > From a Java Class Library point of view, it seems to me that the desire > is to register shutdown hooks for any of these signals (HUP, INT and > TERM) whose use has not been restricted by the VM. > > So an attempt to register for each of these signals should be made, > independent of the result of any of the other attempts. > > To do anything else builds into the Java class library code assumptions > about the behaviour of the VM which are inherently implementation > (version?) specific, which is a brittle thing to do. > > It currently assumes that the VM will either have restricted all these > signals (the -Xrs case) or none of them. > > This assumption holds true for the current version of Hotspot VM, but > not necessarily for other VM implementations, whose mix of signal usage > may differ. > > So I think Frank's suggested change helps this code to adhere the VM / > Class Library interface boundary, and so makes it less brittle. > As David said, the proposed change is harmless and I don't think anyone has any issue with it. It's really just us trying to understand whether there is really an issue here or not as it is has not been clear from the mails so far. I'm guessing it's AIX or J9 where -Xrs may be mapped to a different set of signals. FWIW, the termination setup has not been touched in >10 years. Looking at it now then it could have been done in other ways that wouldn't have been VM specific. Whether it's worth doing this now isn't clear as it just hasn't been an issue (to my knowledge anyway). -Alan From kumar.x.srinivasan at oracle.COM Tue Aug 7 17:16:47 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Tue, 07 Aug 2012 10:16:47 -0700 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <391830811.1218929.1344340099561.JavaMail.root@redhat.com> References: <391830811.1218929.1344340099561.JavaMail.root@redhat.com> Message-ID: <50214D7F.4080804@oracle.COM> Hi, Please make sure that the jdk/test/tools/* tests are run and validated. Both the java launcher and the pack200 tools are dependent on zlib entry points for inflate/deflate and other things. Kumar > ----- Original Message ----- >> On 08/06/2012 11:26 AM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Hi Andrew, >>>> >>>> I meant if we are going to put SYSTEM_ZLIB=true as default for >>>> linux >>>> as >>>> Alan suggested, >>>> we might need to update the build document as well to include >>>> zlib-dev >>>> as the "necessary" >>>> package to build jdk on linux. >>> Ok. I think that's a separate issue which warrants a separate bug& >>> changeset. Let's have this one work on fixing the build so >>> SYSTEM_ZLIB >>> actually works on GNU/Linux first. At the moment, enabling >>> SYSTEM_ZLIB=true >>> breaks the build on anything other than MacOS/X, which seems like a >>> bug to me. >> It's a separate issue. For your current patch, since it does not set >> the >> SYSTEM_ZLIB=true >> for linux, it's not an issue at all. > As we override the default anyway, I'd prefer not to be the one pushing > for it if it causes problems down the road :-) > > My apology for my naive >> question, >> is zlib (the library) >> always installed by default by most linux distributors? > No apology required. It's not that naive a question as there are plenty > of distributions out there, so giving a completely accurate answer is > impossible. There's more than likely someone who doesn't :-) > > I would say it's extremely unlikely that the library's not installed. > Looking at the dependency tree, it's a requirement of perl, nss, libpng, > freetype, openssh, firefox, kdelibs& cairo to name a few. You're not going to get > much of a GUI environment going without it, that's for sure. > > As you pointed out earlier in the thread, binary distributions tend to > separate the library and the development headers / pkgconfig files. It's > much less likely that zlib-devel (or whatever it gets called) is installed > on a standard system, but for someone doing builds, it becomes more likely > especially as it's a dependency for other development packages such as the one > for libpng. > >>>> Currently the SYSTEM_ZLIB=true is set in >>>> make/common/Defs-macosx.gmk. >>> Ok, so it's the default there already. That explains the defines.h >>> logic. >>> >>>> ZLIB_VERSION = 1.2.5 is setin make/common/Defs.gmk. >>> What's the relevance of this version? My system install is 1.2.7. >> That's the version bundled with jdk. Yes, 1.2.7 is the latest, out >> May/2012. I might try to >> upgrade the bundled one to the latest version at later stage of jdk8. >> The "relevance" is that they are all used for "zlib build", so it >> would >> be better to put them >> together/close for future maintenance, though some comment might be >> necessary to clarify >> one is for "bundled" version, on is for the link options for os zlib. >> > Ah, ok. So it's irrelevant if SYSTEM_ZLIB=true. I was worried the idea might > be for the build to do a version check like it does with Freetype. That's been > a pain in the past. > > So is the patch ok for me to push? And do we have a bug ID if so? Sorry if you've > already mentioned one, but I've lost track in this thread :-) > >> -sherman >> >> From neil.richards at ngmr.net Tue Aug 7 18:07:07 2012 From: neil.richards at ngmr.net (Neil Richards) Date: Tue, 07 Aug 2012 19:07:07 +0100 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <502149D9.6060304@oracle.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> Message-ID: <1344362827.27351.22.camel@chalkhill> On Tue, 2012-08-07 at 18:01 +0100, Alan Bateman wrote: > On 07/08/2012 15:02, Neil Richards wrote: > > : > > > From a Java Class Library point of view, it seems to me that the desire > > is to register shutdown hooks for any of these signals (HUP, INT and > > TERM) whose use has not been restricted by the VM. > > > > So an attempt to register for each of these signals should be made, > > independent of the result of any of the other attempts. > > > > To do anything else builds into the Java class library code assumptions > > about the behaviour of the VM which are inherently implementation > > (version?) specific, which is a brittle thing to do. > > > > It currently assumes that the VM will either have restricted all these > > signals (the -Xrs case) or none of them. > > > > This assumption holds true for the current version of Hotspot VM, but > > not necessarily for other VM implementations, whose mix of signal usage > > may differ. > > > > So I think Frank's suggested change helps this code to adhere the VM / > > Class Library interface boundary, and so makes it less brittle. > > > As David said, the proposed change is harmless and I don't think anyone > has any issue with it. It's really just us trying to understand whether > there is really an issue here or not as it is has not been clear from > the mails so far. I'm guessing it's AIX or J9 where -Xrs may be mapped > to a different set of signals. FWIW, the termination setup has not been > touched in >10 years. Looking at it now then it could have been done in > other ways that wouldn't have been VM specific. Whether it's worth doing > this now isn't clear as it just hasn't been an issue (to my knowledge > anyway). > > -Alan Digging back into its history, I see that it all stems from running java under 'nohup' (e.g. 'nohup java ProgramWithShutdownHooks &'). 'nohup' prevents things being registered against SIGHUP, so trying to do so causes an exception to be thrown. When this happens, the Terminator code currently decides that it shouldn't bother trying to register shutdown hooks for SIGINT or SIGTERM either. The result is that shutdown hooks aren't currently run when a java process run using 'nohup' is sent a SIGINT or SIGTERM signal, because of the code's (false) assumption that a failure to register a handler for SIGHUP must mean that the VM is running in -Xrs mode. I don't think the current observed behaviour in this scenario is either expected or desirable. It occurs for both J9 and Hotspot (at least, on my Ubuntu box, bash shell). Hope this helps to clarify the scenario. Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From david.holmes at oracle.com Wed Aug 8 00:33:50 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 Aug 2012 10:33:50 +1000 Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <5021450F.6070701@oracle.com> References: <445074554.1219383.1344340168460.JavaMail.root@redhat.com> <5021450F.6070701@oracle.com> Message-ID: <5021B3EE.9040709@oracle.com> On 8/08/2012 2:40 AM, Xueming Shen wrote: > > Andrew, > > Since we are here:-) are we also supposed to "free" the old_temp at #250 > and old_temp and old_ev at the end? No. They are aliases for temp and encoding_variant, which are freed at the end. There are only ever at most two things to free. Andrew: this is fine by me, but needs TL approval (Alan?) David ----- > > -Sherman > > On 08/07/2012 04:49 AM, Andrew Hughes wrote: >> ----- Original Message ----- >>> Thanks Andrew. 7189533 created for this. >>> >> Thanks. Ok to push then? :-) >> >>> David >>> ----- >>> >>> On 3/08/2012 8:03 AM, Andrew Hughes wrote: >>>> >>>> ----- Original Message ----- >>>>> Hi Andrew, >>>>> >>>>> On 2/08/2012 7:35 PM, Andrew Hughes wrote: >>>>>> ----- Original Message ----- >>>>>>> Andrew et al, >>>>>>> >>>>>>> AFAICS here: >>>>>>> >>>>>>> 220 encoding_variant = malloc(strlen(temp)+1); >>>>>>> 221 if (encoding_variant == NULL) { >>>>>>> 222 JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>> 223 return 0; >>>>>>> 224 } >>>>>>> >>>>>>> we also need to do free(temp). Similarly later where we return >>>>>>> with >>>>>>> OOM >>>>>>> due to realloc failure, don't we also need to free what was >>>>>>> previously >>>>>>> malloc'd? >>>>>>> >>>>>> I was thinking the same just before committing, but didn't want >>>>>> to >>>>>> delay >>>>>> the main fix any further. >>>>>> >>>>>> While logically we do need one, I'm not sure it's worthwhile if >>>>>> we're going >>>>>> to throw the exception and exit anyway? Will the return even be >>>>>> reached? >>>>>> If we're already near enough to OOM that we can't allocate more >>>>>> memory, >>>>>> it's unlikely freeing temp is going to get us much, and I presume >>>>>> it will >>>>>> be freed anyway when the VM process exists. >>>>> Are we definitely going to exit on this error? I agree if we're >>>>> out >>>>> of >>>>> memory we're likely to continue to run into problems if we try to >>>>> continue. But I'd prefer to see proper cleanup rather than making >>>>> assumptions about the context in which the code is used. >>>>> >>>>>> But I can add it if necessary. It's trivial after all and does >>>>>> not >>>>>> real >>>>>> harm. >>>>> It will also prevent us getting flagged with memory-leak >>>>> warnings/errors >>>>> from static analysis tools. >>>>> >>>> This should cover it, I think: >>>> >>>> http://cr.openjdk.java.net/~andrew/buffer_overflow/webrev.02/ >>>> >>>> but it'll need a bug ID. >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>>> David >>>>>>> >>>>>>> On 2/08/2012 7:18 AM, Andrew Hughes wrote: >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> On 01/08/2012 14:52, Andrew Hughes wrote: >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In any case, there is a Sun bug open for this: >>>>>>>>>> >>>>>>>>>> 6844255: Potential stack corruption in GetJavaProperties >>>>>>>>>> >>>>>>>>>> Can I take it that I can just get on and push Omair's >>>>>>>>>> extended >>>>>>>>>> version now then, >>>>>>>>>> with that bug ID? >>>>>>>>> Yes, go ahead, I should have said that in my mail. >>>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Done: >>>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-August/010993.html >>>>>>>> >>>>>>>> >>>>>>>> with Omair as author and yourself and I as reviewers. >>>>>>>> >>>>>>>>>> Well, the locale can be set be an environment variable, so it >>>>>>>>>> could >>>>>>>>>> potentially >>>>>>>>>> be anything of any length... >>>>>>>>>> >>>>>>>>>> The Debian bug posted above has an example, though I couldn't >>>>>>>>>> replicate it. >>>>>>>>>> >>>>>>>>> I couldn't replicate it either and was just curious if anyone >>>>>>>>> managed >>>>>>>>> to >>>>>>>>> demonstrate it. >>>>>>>>> >>>>>>>> Yeah, I tend to think it's more potentially exploitable rather >>>>>>>> than >>>>>>>> something >>>>>>>> that's actually been hit. >>>>>>>> >>>>>>>>> -Alan. >>>>>>>>> >>>>>>>> Thanks, > From david.holmes at oracle.com Wed Aug 8 00:57:29 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 08 Aug 2012 10:57:29 +1000 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <1344362827.27351.22.camel@chalkhill> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> <1344362827.27351.22.camel@chalkhill> Message-ID: <5021B979.5060409@oracle.com> On 8/08/2012 4:07 AM, Neil Richards wrote: > On Tue, 2012-08-07 at 18:01 +0100, Alan Bateman wrote: >> On 07/08/2012 15:02, Neil Richards wrote: >>> : >>>> From a Java Class Library point of view, it seems to me that the desire >>> is to register shutdown hooks for any of these signals (HUP, INT and >>> TERM) whose use has not been restricted by the VM. >>> >>> So an attempt to register for each of these signals should be made, >>> independent of the result of any of the other attempts. >>> >>> To do anything else builds into the Java class library code assumptions >>> about the behaviour of the VM which are inherently implementation >>> (version?) specific, which is a brittle thing to do. >>> >>> It currently assumes that the VM will either have restricted all these >>> signals (the -Xrs case) or none of them. >>> >>> This assumption holds true for the current version of Hotspot VM, but >>> not necessarily for other VM implementations, whose mix of signal usage >>> may differ. >>> >>> So I think Frank's suggested change helps this code to adhere the VM / >>> Class Library interface boundary, and so makes it less brittle. >>> >> As David said, the proposed change is harmless and I don't think anyone >> has any issue with it. It's really just us trying to understand whether >> there is really an issue here or not as it is has not been clear from >> the mails so far. I'm guessing it's AIX or J9 where -Xrs may be mapped >> to a different set of signals. FWIW, the termination setup has not been >> touched in>10 years. Looking at it now then it could have been done in >> other ways that wouldn't have been VM specific. Whether it's worth doing >> this now isn't clear as it just hasn't been an issue (to my knowledge >> anyway). >> >> -Alan > > Digging back into its history, I see that it all stems from running java > under 'nohup' (e.g. 'nohup java ProgramWithShutdownHooks&'). > > 'nohup' prevents things being registered against SIGHUP, so trying to do > so causes an exception to be thrown. > > When this happens, the Terminator code currently decides that it > shouldn't bother trying to register shutdown hooks for SIGINT or SIGTERM > either. Thanks Neil that is a much more convincing justification. The "interface is brittle" argument is rather tenous as the key issue is when the underlying method will throw IllegalArgumentException - which is inherently part of the unwritten contract with the native method and thence the VM. The code already assumes that it is okay to ignore the IllegalArgumentException, which implies it knows the exact circumstances when it will be thrown. Anyway the change is okay to push. CR 7189865 created for this. Thanks, David ----- > The result is that shutdown hooks aren't currently run when a java > process run using 'nohup' is sent a SIGINT or SIGTERM signal, because of > the code's (false) assumption that a failure to register a handler for > SIGHUP must mean that the VM is running in -Xrs mode. > > I don't think the current observed behaviour in this scenario is either > expected or desirable. > It occurs for both J9 and Hotspot (at least, on my Ubuntu box, bash > shell). > > Hope this helps to clarify the scenario. > > Regards, > Neil > From xueming.shen at oracle.com Wed Aug 8 01:13:32 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 07 Aug 2012 18:13:32 -0700 Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <5021B3EE.9040709@oracle.com> References: <445074554.1219383.1344340168460.JavaMail.root@redhat.com> <5021450F.6070701@oracle.com> <5021B3EE.9040709@oracle.com> Message-ID: <5021BD3C.4050504@oracle.com> On 8/7/12 5:33 PM, David Holmes wrote: > On 8/08/2012 2:40 AM, Xueming Shen wrote: >> >> Andrew, >> >> Since we are here:-) are we also supposed to "free" the old_temp at #250 >> and old_temp and old_ev at the end? > > No. They are aliases for temp and encoding_variant, which are freed at > the end. There are only ever at most two things to free. oops, I did not see it's a realloc.... > > Andrew: this is fine by me, but needs TL approval (Alan?) > > David > ----- > >> >> -Sherman >> >> On 08/07/2012 04:49 AM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Thanks Andrew. 7189533 created for this. >>>> >>> Thanks. Ok to push then? :-) >>> >>>> David >>>> ----- >>>> >>>> On 3/08/2012 8:03 AM, Andrew Hughes wrote: >>>>> >>>>> ----- Original Message ----- >>>>>> Hi Andrew, >>>>>> >>>>>> On 2/08/2012 7:35 PM, Andrew Hughes wrote: >>>>>>> ----- Original Message ----- >>>>>>>> Andrew et al, >>>>>>>> >>>>>>>> AFAICS here: >>>>>>>> >>>>>>>> 220 encoding_variant = malloc(strlen(temp)+1); >>>>>>>> 221 if (encoding_variant == NULL) { >>>>>>>> 222 JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>> 223 return 0; >>>>>>>> 224 } >>>>>>>> >>>>>>>> we also need to do free(temp). Similarly later where we return >>>>>>>> with >>>>>>>> OOM >>>>>>>> due to realloc failure, don't we also need to free what was >>>>>>>> previously >>>>>>>> malloc'd? >>>>>>>> >>>>>>> I was thinking the same just before committing, but didn't want >>>>>>> to >>>>>>> delay >>>>>>> the main fix any further. >>>>>>> >>>>>>> While logically we do need one, I'm not sure it's worthwhile if >>>>>>> we're going >>>>>>> to throw the exception and exit anyway? Will the return even be >>>>>>> reached? >>>>>>> If we're already near enough to OOM that we can't allocate more >>>>>>> memory, >>>>>>> it's unlikely freeing temp is going to get us much, and I presume >>>>>>> it will >>>>>>> be freed anyway when the VM process exists. >>>>>> Are we definitely going to exit on this error? I agree if we're >>>>>> out >>>>>> of >>>>>> memory we're likely to continue to run into problems if we try to >>>>>> continue. But I'd prefer to see proper cleanup rather than making >>>>>> assumptions about the context in which the code is used. >>>>>> >>>>>>> But I can add it if necessary. It's trivial after all and does >>>>>>> not >>>>>>> real >>>>>>> harm. >>>>>> It will also prevent us getting flagged with memory-leak >>>>>> warnings/errors >>>>>> from static analysis tools. >>>>>> >>>>> This should cover it, I think: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/buffer_overflow/webrev.02/ >>>>> >>>>> but it'll need a bug ID. >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 2/08/2012 7:18 AM, Andrew Hughes wrote: >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>>> On 01/08/2012 14:52, Andrew Hughes wrote: >>>>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In any case, there is a Sun bug open for this: >>>>>>>>>>> >>>>>>>>>>> 6844255: Potential stack corruption in GetJavaProperties >>>>>>>>>>> >>>>>>>>>>> Can I take it that I can just get on and push Omair's >>>>>>>>>>> extended >>>>>>>>>>> version now then, >>>>>>>>>>> with that bug ID? >>>>>>>>>> Yes, go ahead, I should have said that in my mail. >>>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> Done: >>>>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-August/010993.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> with Omair as author and yourself and I as reviewers. >>>>>>>>> >>>>>>>>>>> Well, the locale can be set be an environment variable, so it >>>>>>>>>>> could >>>>>>>>>>> potentially >>>>>>>>>>> be anything of any length... >>>>>>>>>>> >>>>>>>>>>> The Debian bug posted above has an example, though I couldn't >>>>>>>>>>> replicate it. >>>>>>>>>>> >>>>>>>>>> I couldn't replicate it either and was just curious if anyone >>>>>>>>>> managed >>>>>>>>>> to >>>>>>>>>> demonstrate it. >>>>>>>>>> >>>>>>>>> Yeah, I tend to think it's more potentially exploitable rather >>>>>>>>> than >>>>>>>>> something >>>>>>>>> that's actually been hit. >>>>>>>>> >>>>>>>>>> -Alan. >>>>>>>>>> >>>>>>>>> Thanks, >> From lana.steuck at oracle.com Wed Aug 8 06:06:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:06:54 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b50 for changeset 2fd67618b9a3 Message-ID: <20120808060654.ECD174740F@hg.openjdk.java.net> Changeset: 57c0aee73090 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/57c0aee73090 Added tag jdk8-b50 for changeset 2fd67618b9a3 ! .hgtags From lana.steuck at oracle.com Wed Aug 8 06:06:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:06:54 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b50 for changeset d20d9eb9f093 Message-ID: <20120808060658.0931F47410@hg.openjdk.java.net> Changeset: 9b0f841ca9f7 Author: katleman Date: 2012-08-02 15:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/9b0f841ca9f7 Added tag jdk8-b50 for changeset d20d9eb9f093 ! .hgtags From lana.steuck at oracle.com Wed Aug 8 06:07:03 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:03 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b50 for changeset 2791ec55f66b Message-ID: <20120808060714.543A047411@hg.openjdk.java.net> Changeset: dc1ea77ed9d9 Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/dc1ea77ed9d9 Added tag jdk8-b50 for changeset 2791ec55f66b ! .hgtags From lana.steuck at oracle.com Wed Aug 8 06:07:05 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:05 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b50 for changeset bdab72e87b83 Message-ID: <20120808060714.A9C1447412@hg.openjdk.java.net> Changeset: 1a70b6333ebe Author: katleman Date: 2012-08-02 15:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/1a70b6333ebe Added tag jdk8-b50 for changeset bdab72e87b83 ! .hgtags From lana.steuck at oracle.com Wed Aug 8 06:07:10 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:10 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20120808060731.B65B047413@hg.openjdk.java.net> Changeset: c4cd4cab2220 Author: katleman Date: 2012-08-02 15:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c4cd4cab2220 Added tag jdk8-b50 for changeset b2d8a270f5f2 ! .hgtags Changeset: cfa70d7ac944 Author: lana Date: 2012-08-07 20:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cfa70d7ac944 Merge From lana.steuck at oracle.com Wed Aug 8 06:07:26 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:26 +0000 Subject: hg: jdk8/tl/hotspot: 37 new changesets Message-ID: <20120808060917.2339E47414@hg.openjdk.java.net> Changeset: 54e66510c9cd Author: amurillo Date: 2012-07-13 14:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/54e66510c9cd 7184050: new hotspot build - hs24-b17 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8150fa46d2ed Author: jiangli Date: 2012-06-26 19:08 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8150fa46d2ed 7178145: Change constMethodOop::_exception_table to optionally inlined u2 table. Summary: Change constMethodOop::_exception_table to optionally inlined u2 table. Reviewed-by: bdelsart, coleenp, kamg ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java + agent/src/share/classes/sun/jvm/hotspot/oops/ExceptionTableElement.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constMethodOop.cpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f0b82641fb7e Author: bdelsart Date: 2012-07-02 04:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f0b82641fb7e Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/memory/dump.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: d68b1274b9ba Author: jiangli Date: 2012-07-05 18:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d68b1274b9ba 7180914: Compilation warning after: 7172967: Eliminate the constMethod's _method backpointer to the methodOop. Summary: Use read_pointer(J...) to access from 'constMethod' base in name_for_methodOop(), libjvm_db.c. Reviewed-by: kvn, coleenp ! src/os/solaris/dtrace/libjvm_db.c Changeset: 161ae369407d Author: jiangli Date: 2012-07-05 20:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/161ae369407d 7181632: nsk classLoad001_14 failure and CompileTheWorld crash after 7178145. Summary: Need to copy the inlined exception table to the new constMethodOop during method rewriting. Reviewed-by: coleenp, dholmes ! src/share/vm/oops/methodOop.cpp Changeset: e74da3c2b827 Author: jiangli Date: 2012-07-13 20:14 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e74da3c2b827 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 0bca41b2fa63 Author: jiangli Date: 2012-07-17 12:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0bca41b2fa63 Merge Changeset: 922993931b3d Author: brutisso Date: 2012-07-11 22:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/922993931b3d 7178361: G1: Make sure that PrintGC and PrintGCDetails use the same timing for the GC pause Summary: Also reviewed by: vitalyd at gmail.com. Move the timing out of G1CollectorPolicy into the G1GCPhaseTimes class Reviewed-by: johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 3a431b605145 Author: jmasa Date: 2012-07-16 13:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a431b605145 Merge ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp + src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp Changeset: 7553d441b878 Author: jmasa Date: 2012-07-17 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7553d441b878 Merge Changeset: 6d8f36bcef55 Author: jrose Date: 2012-07-12 00:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d8f36bcef55 6711908: JVM needs direct access to some annotations Summary: Add annotation extraction code to class file parser. Reviewed-by: twisti, jrose, kvn Contributed-by: michael.haupt at oracle.com ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/methodOop.hpp Changeset: ed21db7b3fda Author: kvn Date: 2012-07-13 17:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed21db7b3fda 7123926: Some CTW test crash: !_control.contains(ctrl) Summary: Don't eliminate Integer::toString() call node during String concatenation optimization if it has several uses. Reviewed-by: twisti ! src/share/vm/opto/stringopts.cpp Changeset: 56c4f88474b3 Author: twisti Date: 2012-07-16 11:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/56c4f88474b3 7087357: JSR 292: remove obsolete code after 7085860 Reviewed-by: kvn, never ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 2c368ea3e844 Author: kvn Date: 2012-07-16 17:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c368ea3e844 7181494: cleanup avx and vectors code Summary: renamed mach nodes which use scalar AVX instructions, added integer vectors shuffling instructions Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/x86.ad ! src/share/vm/code/vmreg.hpp Changeset: 9c9fb30d2b3b Author: kvn Date: 2012-07-16 19:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c9fb30d2b3b Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/unsafe.cpp Changeset: dd785aabe02b Author: kvn Date: 2012-07-17 11:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dd785aabe02b Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.hpp Changeset: bc3e01899804 Author: kvn Date: 2012-07-19 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bc3e01899804 Merge Changeset: d900d95bfdb0 Author: fparain Date: 2012-07-16 04:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d900d95bfdb0 7183754: Test runtime/6294277/Test6294277.sh runs wrong JVM Reviewed-by: kamg, coleenp, ctornqvi ! test/runtime/6294277/SourceDebugExtension.java - test/runtime/6294277/Test6294277.sh Changeset: 149c36689fcb Author: asaha Date: 2012-07-17 22:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/149c36689fcb 7053586: TEST: runtime/7020373/Test7020373.sh fails on 64-bit platforms Reviewed-by: kamg ! test/runtime/7020373/Test7020373.sh Changeset: 7e5976e66c62 Author: zgu Date: 2012-07-19 09:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7e5976e66c62 7182543: NMT ON: Aggregate a few NMT related bugs Summary: 1) Fixed MemTrackWorker::generations_in_used() calculation 2) Ensured NMT not to leak memory recorders after shutdown 3) Used ThreadCritical to block safepoint safe threads Reviewed-by: acorn, coleenp, dholmes, kvn ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: f1f45dddb0bd Author: zgu Date: 2012-07-16 14:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1f45dddb0bd 7181986: NMT ON: Assertion failure when running jdi ExpiredRequestDeletionTest Summary: Changed _query_lock to heap object from static object. Also fixed _query_lock and snapshot lock ranks, so they can participate deadlock detection. Reviewed-by: coleenp, dholmes, kvn ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: d5bc62fcfac7 Author: zgu Date: 2012-07-19 09:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d5bc62fcfac7 Merge ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 04a9b3789683 Author: zgu Date: 2012-07-16 14:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04a9b3789683 7181989: NMT ON: Assertion failure when NMT checks thread's native stack base address Summary: Assertion on stack base is not necessary Reviewed-by: coleenp, dholmes, kvn ! src/share/vm/services/memTracker.cpp Changeset: 58a04a45a549 Author: zgu Date: 2012-07-19 09:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58a04a45a549 Merge ! src/share/vm/services/memTracker.cpp Changeset: 950ed41429e5 Author: zgu Date: 2012-07-19 06:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/950ed41429e5 Merge Changeset: 12fc2571a6e2 Author: coleenp Date: 2012-07-20 12:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/12fc2571a6e2 Merge - test/runtime/6294277/Test6294277.sh Changeset: bd54fe36b5e5 Author: amurillo Date: 2012-07-23 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd54fe36b5e5 Merge - test/runtime/6294277/Test6294277.sh Changeset: 15eb2b903b04 Author: amurillo Date: 2012-07-23 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15eb2b903b04 Added tag hs24-b17 for changeset bd54fe36b5e5 ! .hgtags Changeset: aba91a731143 Author: amurillo Date: 2012-07-23 13:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aba91a731143 7185775: new hotspot build - hs24-b18 Reviewed-by: jcoomes ! make/hotspot_version Changeset: fe94b4e7212b Author: asaha Date: 2012-07-23 14:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe94b4e7212b 7185550: TEST: runtime/7020373/Test7020373.sh fails because there is no test/runtime/7020373/testcase.jar Reviewed-by: coleenp ! test/runtime/7020373/Test7020373.sh + test/runtime/7020373/testcase.jar Changeset: 43541217e9f7 Author: jiangli Date: 2012-07-26 17:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/43541217e9f7 7187046: Crash in ClassFileParser on solaris-ia32 during RetransformClasses. Summary: Lower compiler optimization level when compiling jvmtiClassFileReconstituter.cpp as a workaround for the solaris x86 5.10 cc bug. Reviewed-by: kvn, coleenp ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make Changeset: 611e8a669a2c Author: dlong Date: 2012-07-16 15:31 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/611e8a669a2c 7147464: Java crashed while executing method with over 8k of dneg operations Summary: replace recursive method with iterative Reviewed-by: kvn, twisti Contributed-by: dean.long at oracle.com ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp Changeset: a93a6d2c9e6c Author: jiangli Date: 2012-07-24 13:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a93a6d2c9e6c Merge Changeset: bcd1b9d98558 Author: jiangli Date: 2012-07-26 16:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bcd1b9d98558 Merge Changeset: 72e0362c3f0c Author: amurillo Date: 2012-07-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/72e0362c3f0c Merge ! .hgtags - test/runtime/6294277/Test6294277.sh Changeset: 58f237a9e83a Author: amurillo Date: 2012-07-27 12:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58f237a9e83a Added tag hs24-b18 for changeset 72e0362c3f0c ! .hgtags Changeset: c01c8e05ec8c Author: katleman Date: 2012-08-02 15:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c01c8e05ec8c Added tag jdk8-b50 for changeset 58f237a9e83a ! .hgtags From lana.steuck at oracle.com Wed Aug 8 06:07:56 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 08 Aug 2012 06:07:56 +0000 Subject: hg: jdk8/tl/jdk: 14 new changesets Message-ID: <20120808061039.F37A747415@hg.openjdk.java.net> Changeset: 79c9847d4a5f Author: katleman Date: 2012-08-02 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79c9847d4a5f Added tag jdk8-b50 for changeset e4bae5c53fca ! .hgtags Changeset: 28665fa73b4a Author: rupashka Date: 2012-07-19 19:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/28665fa73b4a 7124330: [macosx] javax.swing.JComboBox throws unexpected ClassCastException Reviewed-by: kizune ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java Changeset: b1c5e4a843f3 Author: leonidr Date: 2012-07-19 19:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1c5e4a843f3 7181027: [macosx] Unable to use headless mode Reviewed-by: anthony ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/solaris/native/java/lang/java_props_md.c Changeset: f04d8dee2da9 Author: alexsch Date: 2012-07-23 17:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f04d8dee2da9 7185512: The printout doesn't match image on screen. Reviewed-by: serb, bagiras ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h Changeset: 8a5a71e853ed Author: alexsch Date: 2012-07-24 16:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a5a71e853ed 7129800: [macosx] Regression test OverrideRedirectWindowActivationTest fails due to timing issue Reviewed-by: rupashka + test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java Changeset: 3502753a9d66 Author: rupashka Date: 2012-07-25 13:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3502753a9d66 7167780: Hang javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests Reviewed-by: alexsch ! src/share/classes/javax/swing/TimerQueue.java Changeset: 1a410846d85b Author: malenkov Date: 2012-07-25 19:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1a410846d85b 4650871: Classes in sunw.* should be removed from workspace and rt.jar Reviewed-by: art, rupashka ! make/Makefile ! make/common/Release.gmk ! make/docs/CORE_PKGS.gmk - make/sunw/Makefile ! makefiles/CreateJars.gmk ! makefiles/docs/CORE_PKGS.gmk ! src/share/classes/sun/misc/MetaIndex.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java Changeset: 80b1ecc79852 Author: denis Date: 2012-07-27 19:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80b1ecc79852 7149068: java/awt/Window/Grab/GrabTest.java failed Reviewed-by: art, ant + test/java/awt/Window/Grab/GrabTest.java Changeset: 1579507a736f Author: lana Date: 2012-07-27 22:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1579507a736f Merge - src/share/classes/sun/security/krb5/ServiceName.java - test/sun/security/krb5/ServiceNameClone.java - test/sun/security/mscapi/ShortRSAKey512.sh - test/sun/security/mscapi/ShortRSAKey768.sh Changeset: 1abb270d9038 Author: malenkov Date: 2012-07-30 13:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1abb270d9038 7187618: PropertyDescriptor Performance Slow Reviewed-by: rupashka ! src/share/classes/com/sun/beans/TypeResolver.java ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Performance/Test7122740.java + test/java/beans/Performance/Test7184799.java Changeset: 896322c6f35f Author: alexsch Date: 2012-07-30 14:31 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/896322c6f35f 7184365: closed/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest fails Reviewed-by: serb, bagiras ! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java ! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java ! src/share/classes/java/awt/TextComponent.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java + test/java/awt/event/TextEvent/TextEventSequenceTest/TextEventSequenceTest.java Changeset: b08697af1c56 Author: lana Date: 2012-07-31 18:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b08697af1c56 Merge - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java Changeset: e865efbc7105 Author: lana Date: 2012-08-06 15:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e865efbc7105 Merge - make/sunw/Makefile - src/share/classes/sun/nio/cs/SingleByteDecoder.java - src/share/classes/sun/nio/cs/SingleByteEncoder.java - src/share/classes/sun/nio/cs/ext/DoubleByteDecoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0201.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_MS932_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0208_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Decoder.java - src/share/classes/sun/nio/cs/ext/JIS_X_0212_Solaris_Encoder.java - src/share/classes/sun/nio/cs/ext/PCK.java - src/share/classes/sun/nio/cs/ext/SJIS.java - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java Changeset: b0d6552ba301 Author: lana Date: 2012-08-07 20:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b0d6552ba301 Merge - make/sunw/Makefile - src/share/classes/sunw/io/Serializable.java - src/share/classes/sunw/util/EventListener.java - src/share/classes/sunw/util/EventObject.java ! src/solaris/native/java/lang/java_props_md.c From Alan.Bateman at oracle.com Wed Aug 8 09:51:08 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Aug 2012 10:51:08 +0100 Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <5021B3EE.9040709@oracle.com> References: <445074554.1219383.1344340168460.JavaMail.root@redhat.com> <5021450F.6070701@oracle.com> <5021B3EE.9040709@oracle.com> Message-ID: <5022368C.1000300@oracle.com> On 08/08/2012 01:33, David Holmes wrote: > On 8/08/2012 2:40 AM, Xueming Shen wrote: >> >> Andrew, >> >> Since we are here:-) are we also supposed to "free" the old_temp at #250 >> and old_temp and old_ev at the end? > > No. They are aliases for temp and encoding_variant, which are freed at > the end. There are only ever at most two things to free. > > Andrew: this is fine by me, but needs TL approval (Alan?) You are a reviewer on the jdk8 project so Andrew should be all set. In any case, the update looks good to me too. -Alan. From ahughes at redhat.com Wed Aug 8 11:38:12 2012 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 08 Aug 2012 11:38:12 +0000 Subject: hg: jdk8/tl/jdk: 7189533: GetJavaProperties should free temporary file if subsequent allocations fails Message-ID: <20120808113853.0E03047419@hg.openjdk.java.net> Changeset: d87e86aaf2b3 Author: andrew Date: 2012-08-08 12:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d87e86aaf2b3 7189533: GetJavaProperties should free temporary file if subsequent allocations fails Summary: Add missing calls to free Reviewed-by: alanb, dholmes, sherman ! src/solaris/native/java/lang/java_props_md.c From ahughes at redhat.com Wed Aug 8 11:40:08 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 8 Aug 2012 07:40:08 -0400 (EDT) Subject: [PATCH FOR REVIEW] Potential Buffer Overflow in java_props_md.c In-Reply-To: <5022368C.1000300@oracle.com> Message-ID: <1876721653.1848968.1344426008473.JavaMail.root@redhat.com> ----- Original Message ----- > On 08/08/2012 01:33, David Holmes wrote: > > On 8/08/2012 2:40 AM, Xueming Shen wrote: > >> > >> Andrew, > >> > >> Since we are here:-) are we also supposed to "free" the old_temp > >> at #250 > >> and old_temp and old_ev at the end? > > > > No. They are aliases for temp and encoding_variant, which are freed > > at > > the end. There are only ever at most two things to free. > > > > Andrew: this is fine by me, but needs TL approval (Alan?) > You are a reviewer on the jdk8 project so Andrew should be all set. > In > any case, the update looks good to me too. > > -Alan. > Looks like we all are, from the census :-) Pushed: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d87e86aaf2b3 Thanks everyone! -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From Alan.Bateman at oracle.com Wed Aug 8 12:28:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 08 Aug 2012 13:28:59 +0100 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <1344362827.27351.22.camel@chalkhill> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> <1344362827.27351.22.camel@chalkhill> Message-ID: <50225B8B.4040307@oracle.com> On 07/08/2012 19:07, Neil Richards wrote: > : > Digging back into its history, I see that it all stems from running java > under 'nohup' (e.g. 'nohup java ProgramWithShutdownHooks&'). > > 'nohup' prevents things being registered against SIGHUP, so trying to do > so causes an exception to be thrown. > > When this happens, the Terminator code currently decides that it > shouldn't bother trying to register shutdown hooks for SIGINT or SIGTERM > either. > > The result is that shutdown hooks aren't currently run when a java > process run using 'nohup' is sent a SIGINT or SIGTERM signal, because of > the code's (false) assumption that a failure to register a handler for > SIGHUP must mean that the VM is running in -Xrs mode. > > I don't think the current observed behaviour in this scenario is either > expected or desirable. > It occurs for both J9 and Hotspot (at least, on my Ubuntu box, bash > shell). > > Hope this helps to clarify the scenario. > Thanks for helping to clarify what this issue is about. One thing that still isn't clear (to me anyway) is whether IAE is really thrown in this case. I did a quick test on Ubuntu 12.04: $ nohup strace -f java Test 2> log & and in the log I see the sigactions as I expected: [pid 13829] rt_sigaction(SIGHUP, NULL, {SIG_IGN, [], 0}, 8) = 0 [pid 13829] rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0 [pid 13829] rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0 So I don't think we are actually getting an IllegalArgumentException in this case. Maybe you are seeing something different? -Alan. From alan.bateman at oracle.com Wed Aug 8 14:32:54 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 08 Aug 2012 14:32:54 +0000 Subject: hg: jdk8/tl/jdk: 7189886: (aio) Add test coverage for AsynchronousChannelGroup.withThreadPool Message-ID: <20120808143325.73F714741B@hg.openjdk.java.net> Changeset: a50e92a980a5 Author: alanb Date: 2012-08-08 15:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a50e92a980a5 7189886: (aio) Add test coverage for AsynchronousChannelGroup.withThreadPool Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java From kumar.x.srinivasan at oracle.COM Wed Aug 8 14:35:01 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Wed, 08 Aug 2012 07:35:01 -0700 Subject: Request for simple review of launcher tests 7189944 Message-ID: <50227915.4010900@oracle.COM> Hi, In my previous push for http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/ I missed adding CR number to the regression test Arrrghs.java, also some minor improvements to TestHelper.java for better diagnosis of failing tests. http://cr.openjdk.java.net/~ksrini/7189944/webrev.0/ Thanks Kumar From jim.gish at oracle.com Wed Aug 8 15:37:30 2012 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 08 Aug 2012 11:37:30 -0400 Subject: Request for simple review of launcher tests 7189944 In-Reply-To: <50227915.4010900@oracle.COM> References: <50227915.4010900@oracle.COM> Message-ID: <502287BA.3000607@oracle.com> Looks good to me. Jim On 08/08/2012 10:35 AM, Kumar Srinivasan wrote: > Hi, > > In my previous push for > http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/ > I missed adding CR number to the regression test Arrrghs.java, also some > minor improvements to TestHelper.java for better diagnosis of failing > tests. > > http://cr.openjdk.java.net/~ksrini/7189944/webrev.0/ > > Thanks > Kumar > > -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From joe.darcy at oracle.com Wed Aug 8 16:05:32 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 08 Aug 2012 09:05:32 -0700 Subject: Request for simple review of launcher tests 7189944 In-Reply-To: <50227915.4010900@oracle.COM> References: <50227915.4010900@oracle.COM> Message-ID: <50228E4C.8030903@oracle.com> Looks fine Kumar. Cheers, -Joe On 8/8/2012 7:35 AM, Kumar Srinivasan wrote: > Hi, > > In my previous push for > http://cr.openjdk.java.net/~ksrini/7146424/webrev.0/ > I missed adding CR number to the regression test Arrrghs.java, also some > minor improvements to TestHelper.java for better diagnosis of failing > tests. > > http://cr.openjdk.java.net/~ksrini/7189944/webrev.0/ > > Thanks > Kumar > > From neil.richards at ngmr.net Wed Aug 8 16:10:09 2012 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 08 Aug 2012 17:10:09 +0100 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <50225B8B.4040307@oracle.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> <1344362827.27351.22.camel@chalkhill> <50225B8B.4040307@oracle.com> Message-ID: <1344442209.23350.232.camel@chalkhill> On Wed, 2012-08-08 at 13:28 +0100, Alan Bateman wrote: > On 07/08/2012 19:07, Neil Richards wrote: > > : > > Digging back into its history, I see that it all stems from running java > > under 'nohup' (e.g. 'nohup java ProgramWithShutdownHooks&'). > > > > 'nohup' prevents things being registered against SIGHUP, so trying to do > > so causes an exception to be thrown. > > > > When this happens, the Terminator code currently decides that it > > shouldn't bother trying to register shutdown hooks for SIGINT or SIGTERM > > either. > > > > The result is that shutdown hooks aren't currently run when a java > > process run using 'nohup' is sent a SIGINT or SIGTERM signal, because of > > the code's (false) assumption that a failure to register a handler for > > SIGHUP must mean that the VM is running in -Xrs mode. > > > > I don't think the current observed behaviour in this scenario is either > > expected or desirable. > > It occurs for both J9 and Hotspot (at least, on my Ubuntu box, bash > > shell). > > > > Hope this helps to clarify the scenario. > > > Thanks for helping to clarify what this issue is about. One thing that > still isn't clear (to me anyway) is whether IAE is really thrown in this > case. I did a quick test on Ubuntu 12.04: > > $ nohup strace -f java Test 2> log & > > and in the log I see the sigactions as I expected: > > [pid 13829] rt_sigaction(SIGHUP, NULL, {SIG_IGN, [], 0}, 8) = 0 > [pid 13829] rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0 > [pid 13829] rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0 > > So I don't think we are actually getting an IllegalArgumentException in > this case. Maybe you are seeing something different? > > -Alan. Hi Alan, Apologies, I confused myself about the Hotspot behaviour. (I was testing with 'nohup', but not checking the contents of 'nohup.out' for the output from my registered shutdown hook - doh!). You're correct, when running with Hotspot with 'nohup', no exception is thrown when trying to register a handler for SIGHUP. When running with J9 with 'nohup', the VM notices that a handler registered for SIGHUP is never going to get triggered, so throws the exception to notify the caller (of Signal.handle( )) about this. Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From kumar.x.srinivasan at oracle.com Wed Aug 8 16:33:24 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 08 Aug 2012 16:33:24 +0000 Subject: hg: jdk8/tl/jdk: 7189944: (launcher) test/tools/launcher/Arrrrghs.java needs a couple of minor fixes Message-ID: <20120808163344.942374741F@hg.openjdk.java.net> Changeset: a44671e0b6d7 Author: ksrini Date: 2012-08-08 09:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a44671e0b6d7 7189944: (launcher) test/tools/launcher/Arrrrghs.java needs a couple of minor fixes Reviewed-by: darcy, jgish ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/TestHelper.java From sundararajan.athijegannathan at oracle.com Wed Aug 8 16:45:37 2012 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Wed, 08 Aug 2012 16:45:37 +0000 Subject: hg: jdk8/tl/langtools: 7178324: Crash when compiling for(i : x) try(AutoCloseable x = ...) {} Message-ID: <20120808164541.2905947420@hg.openjdk.java.net> Changeset: f071cd32d297 Author: sundar Date: 2012-08-08 22:17 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f071cd32d297 7178324: Crash when compiling for(i : x) try(AutoCloseable x = ...) {} Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/TryWithResources/T7178324.java From naoto.sato at oracle.com Wed Aug 8 21:13:42 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 08 Aug 2012 14:13:42 -0700 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <5020E699.3000600@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> Message-ID: <5022D686.9070203@oracle.com> On 8/7/12 2:57 AM, Erik Joelsson wrote: > See inline > > On 2012-07-13 22:20, Kelly O'Hair wrote: >> Something seems strange here: >> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html >> >> It's like someone was avoiding overall quotes, but using them to add >> spaces somehow... >> I sure would like to get rid of this shell logic, seems like there are >> lots repeated logic that >> this script does over and over or could be done with makefile pattern >> subst's instead of exec's. > The new version isn't any worse than the old in my opinion. In > build-infra, this file is indeed replaced with make logic. After having > decoded both versions I'm confident in converting the changes. >> Overall, just looking at the makefiles, the build-infra team may need >> some time to fully absorb this into the >> new makefiles, some of it will be trivial, not sure all of it will be. >> > I have applied the patch to a clone of build-infra and done the minimal > changes to keep build-infra building, which was rather trivial. The > resulting build has large differences since I haven't converted all of > it yet. There are a couple of things that will require some more work, > but not more than a day or two. >> Not sure how to proceed here, the build-infra team does need an action >> item to deal with this, maybe >> before it gets integrated because I suspect the new makefiles will >> break with all the filename or >> directory changes. But I hate to hold up your integration plans. > I see these as possible options: > > 1. Let this go in, build-infra will break in jdk8 until we do our next > push and it trickles through the repos. > 2. The build-infra project provides a patch with the full conversion > that can go in together with these changes. > 3. The build-infra project provides a simple patch which just keeps the > build-infra-build from failing that can go in with these changes. > > The conversion needs to happen regardless of option. The changes > required are pretty isolated from remaining build-infra work. What do > you think? Either way is fine with me. If build-infra team prefers 2 or 3, please give me the patch, and I will go ahead and merge them to my changeset. Naoto > > Other than that, I have no objections to the review. > > /Erik > >> I'd like to get some advice from Erik on this before saying anything >> further. >> >> -kto >> >> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: >> >>> Hello, >>> >>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>> Packaging and Adopt Unicode CLDR Data >>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>> >>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>> >>> The main bug id for this enhancement is: >>> >>> 6336885: RFE: Locale Data Deployment Enhancements >>> >>> Along with this, the following bugs/enhancements are also implemented >>> in this change: >>> >>> 4609153 Provide locale data for Indic locales >>> 5104387 Support for gl_ES locale (galician language) >>> 6337471 desktop/system locale preferences support >>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>> 7058206 Provide CalendarData SPI for week params and display field >>> value names >>> 7073852 Support multiple scripts for digits and decimal symbols per >>> locale >>> 7079560 [Fmt-Da] Context dependent month names support in >>> SimpleDateFormat >>> 7171324 getAvailableLocales() of locale sensitive services should >>> return the actual availability of locales >>> 7151414 (cal) Support calendar type identification >>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>> 7171372 (cal) locale's default Calendar should be created if unknown >>> calendar is specified >>> >>> Please note that packaging changes that relate to Jigsaw module >>> system aren't included in this changeset. >>> >>> Naoto Sato and Masayoshi Okutsu From xueming.shen at oracle.com Wed Aug 8 21:58:37 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 08 Aug 2012 14:58:37 -0700 Subject: Codereview request for 7189363: Regex Pattern compilation buggy for special sequences Message-ID: <5022E10D.1080303@oracle.com> Hi It appears the optimization (flatten a binary tree structure into a branch/ switch) we put into JDK6 for alternation operation [1] has problem if the first construct is a group "(...)" followed by a greedy/reluctant "once or not at all" quantifier. For example regex "(a)?bc|d" or "(a)??bc|d" can't be found for input "d", while "a?bc|d" or "a??bc|d" just works fine. The root cause is that expr() mistakenly to use the Branch node from the sub-expression (in above case, the branch node for "(a)?" instead of using its own Branch node (because the incorrect use of "prev instance of Branch", see the diff), which basically messes up the internal regex node tree [2] The webrev is at http://cr.openjdk.java.net/~sherman/7189363/webrev Thanks, -Sherman PS: I'm surprised this bug has not been noticed until now. One of the reasons is that the "messed up" regex node tree actually works for most of the cases for this particular regex, for example Pattern.compile("(a)?bc|d").matcher("d").matches() Pattern.compile("(a)?bc|d").matcher("bc").matches() Pattern.compile("(a)?bc|d").matcher("abc").matches() and even Pattern.compile("(a)?bc|de").matcher("de").find() all return true. The "find()" for single "d" fails only because the "minimum length" check (see [2] for details, if interested) [1] http://cr.openjdk.java.net/~sherman/5013651_6271399_6342544/ [2] http://cr.openjdk.java.net/~sherman/7189363/nodes From paul.sandoz at oracle.com Thu Aug 9 08:38:53 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 9 Aug 2012 10:38:53 +0200 Subject: Codereview request for 7189363: Regex Pattern compilation buggy for special sequences In-Reply-To: <5022E10D.1080303@oracle.com> References: <5022E10D.1080303@oracle.com> Message-ID: <349482F4-5925-4876-981D-A9C0066D264B@oracle.com> Looks OK to me. Paul. On Aug 8, 2012, at 11:58 PM, Xueming Shen wrote: > Hi > > It appears the optimization (flatten a binary tree structure into a branch/ > switch) we put into JDK6 for alternation operation [1] has problem if the > first construct is a group "(...)" followed by a greedy/reluctant "once or not > at all" quantifier. For example regex "(a)?bc|d" or "(a)??bc|d" can't be found > for input "d", while "a?bc|d" or "a??bc|d" just works fine. > > The root cause is that expr() mistakenly to use the Branch node from the > sub-expression (in above case, the branch node for "(a)?" instead of using > its own Branch node (because the incorrect use of "prev instance of Branch", > see the diff), which basically messes up the internal regex node tree [2] > > The webrev is at > http://cr.openjdk.java.net/~sherman/7189363/webrev > > Thanks, > -Sherman > > PS: > I'm surprised this bug has not been noticed until now. One of the reasons is > that the "messed up" regex node tree actually works for most of the cases > for this particular regex, for example > > Pattern.compile("(a)?bc|d").matcher("d").matches() > Pattern.compile("(a)?bc|d").matcher("bc").matches() > Pattern.compile("(a)?bc|d").matcher("abc").matches() > and even > Pattern.compile("(a)?bc|de").matcher("de").find() > > all return true. The "find()" for single "d" fails only because the "minimum > length" check (see [2] for details, if interested) > > [1] http://cr.openjdk.java.net/~sherman/5013651_6271399_6342544/ > [2] http://cr.openjdk.java.net/~sherman/7189363/nodes From dingxmin at linux.vnet.ibm.com Thu Aug 9 08:39:03 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Thu, 09 Aug 2012 16:39:03 +0800 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <5021B979.5060409@oracle.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> <1344362827.27351.22.camel@chalkhill> <5021B979.5060409@oracle.com> Message-ID: <50237727.7050902@linux.vnet.ibm.com> Thanks Neil for clarifying it in such a convincing way. And David for creating CR. So now we're ready to commit this patch? Best regards, Frank On 8/8/2012 8:57 AM, David Holmes wrote: > On 8/08/2012 4:07 AM, Neil Richards wrote: >> On Tue, 2012-08-07 at 18:01 +0100, Alan Bateman wrote: >>> On 07/08/2012 15:02, Neil Richards wrote: >>>> : >>>>> From a Java Class Library point of view, it seems to me that the >>>>> desire >>>> is to register shutdown hooks for any of these signals (HUP, INT and >>>> TERM) whose use has not been restricted by the VM. >>>> >>>> So an attempt to register for each of these signals should be made, >>>> independent of the result of any of the other attempts. >>>> >>>> To do anything else builds into the Java class library code >>>> assumptions >>>> about the behaviour of the VM which are inherently implementation >>>> (version?) specific, which is a brittle thing to do. >>>> >>>> It currently assumes that the VM will either have restricted all these >>>> signals (the -Xrs case) or none of them. >>>> >>>> This assumption holds true for the current version of Hotspot VM, but >>>> not necessarily for other VM implementations, whose mix of signal >>>> usage >>>> may differ. >>>> >>>> So I think Frank's suggested change helps this code to adhere the VM / >>>> Class Library interface boundary, and so makes it less brittle. >>>> >>> As David said, the proposed change is harmless and I don't think anyone >>> has any issue with it. It's really just us trying to understand whether >>> there is really an issue here or not as it is has not been clear from >>> the mails so far. I'm guessing it's AIX or J9 where -Xrs may be mapped >>> to a different set of signals. FWIW, the termination setup has not been >>> touched in>10 years. Looking at it now then it could have been done in >>> other ways that wouldn't have been VM specific. Whether it's worth >>> doing >>> this now isn't clear as it just hasn't been an issue (to my knowledge >>> anyway). >>> >>> -Alan >> >> Digging back into its history, I see that it all stems from running java >> under 'nohup' (e.g. 'nohup java ProgramWithShutdownHooks&'). >> >> 'nohup' prevents things being registered against SIGHUP, so trying to do >> so causes an exception to be thrown. >> >> When this happens, the Terminator code currently decides that it >> shouldn't bother trying to register shutdown hooks for SIGINT or SIGTERM >> either. > > Thanks Neil that is a much more convincing justification. > > The "interface is brittle" argument is rather tenous as the key issue > is when the underlying method will throw IllegalArgumentException - > which is inherently part of the unwritten contract with the native > method and thence the VM. The code already assumes that it is okay to > ignore the IllegalArgumentException, which implies it knows the exact > circumstances when it will be thrown. > > Anyway the change is okay to push. CR 7189865 created for this. > > Thanks, > David > ----- > > >> The result is that shutdown hooks aren't currently run when a java >> process run using 'nohup' is sent a SIGINT or SIGTERM signal, because of >> the code's (false) assumption that a failure to register a handler for >> SIGHUP must mean that the VM is running in -Xrs mode. >> >> I don't think the current observed behaviour in this scenario is either >> expected or desirable. >> It occurs for both J9 and Hotspot (at least, on my Ubuntu box, bash >> shell). >> >> Hope this helps to clarify the scenario. >> >> Regards, >> Neil >> > From Alan.Bateman at oracle.com Thu Aug 9 08:45:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 09 Aug 2012 09:45:27 +0100 Subject: Codereview request for 7189363: Regex Pattern compilation buggy for special sequences In-Reply-To: <5022E10D.1080303@oracle.com> References: <5022E10D.1080303@oracle.com> Message-ID: <502378A7.8040007@oracle.com> On 08/08/2012 22:58, Xueming Shen wrote: > Hi > > It appears the optimization (flatten a binary tree structure into a > branch/ > switch) we put into JDK6 for alternation operation [1] has problem if the > first construct is a group "(...)" followed by a greedy/reluctant > "once or not > at all" quantifier. For example regex "(a)?bc|d" or "(a)??bc|d" can't > be found > for input "d", while "a?bc|d" or "a??bc|d" just works fine. > > The root cause is that expr() mistakenly to use the Branch node from the > sub-expression (in above case, the branch node for "(a)?" instead of > using > its own Branch node (because the incorrect use of "prev instance of > Branch", > see the diff), which basically messes up the internal regex node tree [2] > > The webrev is at > http://cr.openjdk.java.net/~sherman/7189363/webrev This looks okay to me too. I'm also surprised it hasn't been noticed before now. -Alan. From Alan.Bateman at oracle.com Thu Aug 9 08:54:00 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 09 Aug 2012 09:54:00 +0100 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <1344442209.23350.232.camel@chalkhill> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> <1344362827.27351.22.camel@chalkhill> <50225B8B.4040307@oracle.com> <1344442209.23350.232.camel@chalkhill> Message-ID: <50237AA8.1040801@oracle.com> On 08/08/2012 17:10, Neil Richards wrote: > : > Hi Alan, > Apologies, I confused myself about the Hotspot behaviour. > (I was testing with 'nohup', but not checking the contents of > 'nohup.out' for the output from my registered shutdown hook - doh!). > > You're correct, when running with Hotspot with 'nohup', no exception is > thrown when trying to register a handler for SIGHUP. > > When running with J9 with 'nohup', the VM notices that a handler > registered for SIGHUP is never going to get triggered, so throws the > exception to notify the caller (of Signal.handle( )) about this. > > Regards, > Neil This probably comes back to documenting the interface between the VM and the libraries that you and Steve are working on. In this case, JVM_RegisterSignal is expected to return 1 when the action is SIG_IGN where it sounds like J9 is returning -1. -Alan. From dmitry.samersoff at oracle.com Thu Aug 9 10:53:29 2012 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Thu, 09 Aug 2012 10:53:29 +0000 Subject: hg: jdk8/tl/jdk: 7183753: [TEST] Some colon in the diff for this test Message-ID: <20120809105414.95DC44744A@hg.openjdk.java.net> Changeset: bf85c3ab2637 Author: dsamersoff Date: 2012-08-09 14:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf85c3ab2637 7183753: [TEST] Some colon in the diff for this test Summary: Reference output file contains extra colon Reviewed-by: sspitsyn, mgronlun ! test/sun/tools/jcmd/help_help.out From luchsh at linux.vnet.ibm.com Thu Aug 9 12:16:43 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Thu, 09 Aug 2012 20:16:43 +0800 Subject: Code review request 7190219 CharBuffer position changed after BufferOverflowException in put() Message-ID: <5023AA2B.9030502@linux.vnet.ibm.com> Hi folks, Here's a patch for bug 7190219, could you please help to have a look? http://cr.openjdk.java.net/~luchsh/7190219/ According to the specification, in the method java.nio.CharBuffer.put(String src, int start, int end). If there are more chars to be copied from the string than remain in this buffer, that is, if end - start > remaining(), then no chars are transferred and a|BufferOverflowException||| is thrown. But actually the test case from that webrev proves that the buffer was modified even after BufferOverflowException, so I suggest to add additional check after checkBounds() call, in the same way as java.nio.CharBuffer.put(char[] src, int offset, int length). Thanks Jonathan From Alan.Bateman at oracle.com Thu Aug 9 13:28:44 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 09 Aug 2012 14:28:44 +0100 Subject: Code review request 7190219 CharBuffer position changed after BufferOverflowException in put() In-Reply-To: <5023AA2B.9030502@linux.vnet.ibm.com> References: <5023AA2B.9030502@linux.vnet.ibm.com> Message-ID: <5023BB0C.2080406@oracle.com> On 09/08/2012 13:16, Jonathan Lu wrote: > Hi folks, > > Here's a patch for bug 7190219, could you please help to have a look? > http://cr.openjdk.java.net/~luchsh/7190219/ > > According to the specification, in the method > java.nio.CharBuffer.put(String src, int start, int end). > If there are more chars to be copied from the string than remain in > this buffer, that is, if end - start > remaining(), then no chars are > transferred and a|BufferOverflowException||| > is thrown. > > But actually the test case from that webrev proves that the buffer was > modified even after BufferOverflowException, so I suggest to add > additional check after checkBounds() call, in the same way as > java.nio.CharBuffer.put(char[] src, int offset, int length). You're right, it's missing a check to make sure that there is remaining space and the proposed change looks right to me. Just to keep things locally consistent you can remove the braces around the throw new BufferOverflowException. I think the test could be improved. In particular it could duplicate the buffer and then check that it is equals to the duplicate after the put fails (in addition to checking that that the position hasn't changed). That way you really check that the buffer content haven't been modified. Do you mind seeing if you can add this to the existing unit test for the buffer classes rather than adding a new test? You'll see the existing tests in Basic.java and Basic-X.java.template. I see you've submitted an incident via bugs.sun.com for this, I've moved to the right place as: 7190219: (bf) CharBuffer.put(String,int,int) modifies position even if BufferOverflowException thrown -Alan. From ahughes at redhat.com Thu Aug 9 13:31:39 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 9 Aug 2012 09:31:39 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <5020140E.4090507@oracle.com> Message-ID: <1135816264.2560518.1344519099121.JavaMail.root@redhat.com> ----- Original Message ----- > On 08/06/2012 11:26 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> Hi Andrew, > >> > >> I meant if we are going to put SYSTEM_ZLIB=true as default for > >> linux > >> as > >> Alan suggested, > >> we might need to update the build document as well to include > >> zlib-dev > >> as the "necessary" > >> package to build jdk on linux. > > Ok. I think that's a separate issue which warrants a separate bug& > > changeset. Let's have this one work on fixing the build so > > SYSTEM_ZLIB > > actually works on GNU/Linux first. At the moment, enabling > > SYSTEM_ZLIB=true > > breaks the build on anything other than MacOS/X, which seems like a > > bug to me. > > It's a separate issue. For your current patch, since it does not set > the > SYSTEM_ZLIB=true > for linux, it's not an issue at all. My apology for my naive > question, > is zlib (the library) > always installed by default by most linux distributors? > > >> Currently the SYSTEM_ZLIB=true is set in > >> make/common/Defs-macosx.gmk. > > Ok, so it's the default there already. That explains the defines.h > > logic. > > > >> ZLIB_VERSION = 1.2.5 is setin make/common/Defs.gmk. > > What's the relevance of this version? My system install is 1.2.7. > > That's the version bundled with jdk. Yes, 1.2.7 is the latest, out > May/2012. I might try to > upgrade the bundled one to the latest version at later stage of jdk8. > The "relevance" is that they are all used for "zlib build", so it > would > be better to put them > together/close for future maintenance, though some comment might be > necessary to clarify > one is for "bundled" version, on is for the link options for os zlib. > > -sherman > > Just checking on the status of this. Am I ok to push: http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.02/ as #7110151 to tl? Once that's in and system zlib support is working, we can decide whether to turn it on by default. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From xueming.shen at oracle.com Thu Aug 9 17:15:49 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 09 Aug 2012 17:15:49 +0000 Subject: hg: jdk8/tl/jdk: 7189363: Regex Pattern compilation buggy for special sequences Message-ID: <20120809171612.1831D4744F@hg.openjdk.java.net> Changeset: 717ed00b7787 Author: sherman Date: 2012-08-09 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/717ed00b7787 7189363: Regex Pattern compilation buggy for special sequences Summary: fixed the incorrect implementation in expr(...) Reviewed-by: psandoz, alanb ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java From sean.mullan at oracle.com Fri Aug 10 13:19:51 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 10 Aug 2012 13:19:51 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120810132030.15BD147483@hg.openjdk.java.net> Changeset: 57b5025548d6 Author: mullan Date: 2012-08-10 09:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57b5025548d6 7187962: sun.security.pkcs11.P11DSAKeyFactory.implTranslatePublicKey doesn't check if params is null Reviewed-by: valeriep ! src/share/classes/sun/security/provider/certpath/BasicChecker.java Changeset: 629f357fc17b Author: mullan Date: 2012-08-10 09:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/629f357fc17b Merge From xueming.shen at oracle.com Fri Aug 10 16:38:53 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 10 Aug 2012 09:38:53 -0700 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <1135816264.2560518.1344519099121.JavaMail.root@redhat.com> References: <1135816264.2560518.1344519099121.JavaMail.root@redhat.com> Message-ID: <5025391D.2090309@oracle.com> Hi Andrew Alan mentioned the other day that the build (with your latest patch, with zlib-dev) failed at pack200 when he tried to turn it on on linux. Can your double check on your system? -Sherman On 08/09/2012 06:31 AM, Andrew Hughes wrote: > Just checking on the status of this. > > Am I ok to push: > > http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.02/ > > as #7110151 to tl? > > Once that's in and system zlib support is working, we can decide whether to turn it > on by default. > > Thanks, From Lance.Andersen at oracle.com Fri Aug 10 17:19:32 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 10 Aug 2012 13:19:32 -0400 Subject: Review request 7190657 Modify getDriver() to call Thread.currentThread().getContextClassLoader(); Message-ID: Looking for a reviewer for the following change: - add a call to Thread.currentThread().getContextClassLoader() to DriverManager.getDriver() - Remove the synchronized block for the same call in getConnection() Thank you. Best Lance localhost:sql lanceandersen$ hg diff DriverManager.java diff -r 629f357fc17b src/share/classes/java/sql/DriverManager.java --- a/src/share/classes/java/sql/DriverManager.java Fri Aug 10 09:17:14 2012 -0400 +++ b/src/share/classes/java/sql/DriverManager.java Fri Aug 10 13:05:00 2012 -0400 @@ -264,6 +264,10 @@ // be null. ClassLoader callerCL = DriverManager.getCallerClassLoader(); + if(callerCL == null) { + callerCL = Thread.currentThread().getContextClassLoader(); + } + // Walk through the loaded registeredDrivers attempting to locate someone // who understands the given URL. for (DriverInfo aDriver : registeredDrivers) { @@ -563,11 +567,8 @@ * classloader, so that the JDBC driver class outside rt.jar * can be loaded from here. */ - synchronized(DriverManager.class) { - // synchronize loading of the correct classloader. - if(callerCL == null) { - callerCL = Thread.currentThread().getContextClassLoader(); - } + if(callerCL == null) { + callerCL = Thread.currentThread().getContextClassLoader(); } if(url == null) { localhost:sql lanceandersen$ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From ahughes at redhat.com Fri Aug 10 17:40:36 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 10 Aug 2012 13:40:36 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <5025391D.2090309@oracle.com> Message-ID: <605271241.3277547.1344620436424.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Andrew > > Alan mentioned the other day that the build (with your latest patch, > with zlib-dev) failed at pack200 > when he tried to turn it on on linux. Can your double check on your > system? > What kind of failure? All webrevs I've posted pass a complete build here, and we've been using system zlib for years as previously mentioned, so I'm surprised by this. > -Sherman > > > On 08/09/2012 06:31 AM, Andrew Hughes wrote: > > Just checking on the status of this. > > > > Am I ok to push: > > > > http://cr.openjdk.java.net/~andrew/syslibs/zlib/webrev.02/ > > > > as #7110151 to tl? > > > > Once that's in and system zlib support is working, we can decide > > whether to turn it > > on by default. > > > > Thanks, > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From Alan.Bateman at oracle.com Fri Aug 10 18:55:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 10 Aug 2012 19:55:59 +0100 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <605271241.3277547.1344620436424.JavaMail.root@redhat.com> References: <605271241.3277547.1344620436424.JavaMail.root@redhat.com> Message-ID: <5025593F.3080102@oracle.com> On 10/08/2012 18:40, Andrew Hughes wrote: > ----- Original Message ----- >> Hi Andrew >> >> Alan mentioned the other day that the build (with your latest patch, >> with zlib-dev) failed at pack200 >> when he tried to turn it on on linux. Can your double check on your >> system? >> > What kind of failure? All webrevs I've posted pass a complete build here, > and we've been using system zlib for years as previously mentioned, so I'm > surprised by this. > I grabbed your patch a few days ago and did a build+test job on all platforms (Linux/Solaris/Mac/Windows) and didn't see any issues. This was of course using the defaults, I didn't set SYSTEM_ZLIB explicitly. However I did see an issue on Ubuntu 12.0.4 (32-bit) with SYSTEM_ZLIB=true. Attached is the tail of the log. I haven't had time to look at it but I do see that libzip.so is built as expected (ldd shows it is linked to libz). The build failure is with unpack200 as it uses the the zlib functions. Building with SYSTEM_ZLIB=false is fine on this system. -Alan rm -f ../../../../../build/linux-i586/bin/unpack200 rm -f ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack/mapfile-vers /bin/cp mapfile-vers-unpack200 ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack/mapfile-vers /usr/bin/gcc -O2 -DPRODUCT -fPIC -DCC_NOEX -W -Wall -Wno-unused -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN -DFULL -DSYSTEM_ZLIB -DNDEBUG -DARCH='"i586"' -Di586 -DLINUX -DRELEASE='"1.8.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -I. -I../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack/CClassHeaders -I../../../../../src/closed/share/javavm/export -I../../../../../src/solaris/javavm/export -I../../../../../src/share/javavm/export -I../../../../../src/share/native/common -I../../../../../src/solaris/native/common -I../../../../../src/share/native/com/sun/java/util/jar/pack -I../../../../../src/solaris/native/com/sun/java/util/jar/pack -Xlinker -O1 -Xlinker -version-script=mapfile-vers -Wl,--hash-style=both -Xlinker -z -Xlinker origin -Xlinker -rpath -Xlinker \$ORIGIN -Xlinker -z -Xlinker defs -L../../../../../build/linux-i586/lib/i386 -Wl,-soname=libunpack.so -lz -lc ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/bands.o ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/bytes.o ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/coding.o ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/unpack.o ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/utils.o ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/zip.o ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/main.o -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -o ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack/unpack200 ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/zip.o: In function `jar::deflate_bytes(bytes&, bytes&)': zip.cpp:(.text+0x79b): undefined reference to `deflateInit2_' zip.cpp:(.text+0x828): undefined reference to `deflate' zip.cpp:(.text+0x842): undefined reference to `deflateEnd' zip.cpp:(.text+0x854): undefined reference to `deflateEnd' zip.cpp:(.text+0x87c): undefined reference to `deflate' ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/zip.o: In function `jar::addJarEntry(char const*, bool, int, bytes&, bytes&)': zip.cpp:(.text+0x8d2): undefined reference to `crc32' zip.cpp:(.text+0x9d1): undefined reference to `crc32' zip.cpp:(.text+0x9ee): undefined reference to `crc32' ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/zip.o: In function `gunzip::free()': zip.cpp:(.text+0xb33): undefined reference to `inflateEnd' ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/zip.o: In function `read_input_via_gzip(unpacker*, void*, long long, long long)': zip.cpp:(.text+0xbfe): undefined reference to `inflate' ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/zip.o: In function `gunzip::start(int)': zip.cpp:(.text+0xf35): undefined reference to `inflateInit2_' collect2: ld returned 1 exit status From valerie.peng at oracle.com Fri Aug 10 20:11:14 2012 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Fri, 10 Aug 2012 20:11:14 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20120810201145.E123447493@hg.openjdk.java.net> Changeset: 114fbbeb8f75 Author: valeriep Date: 2012-08-10 13:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/114fbbeb8f75 7107613: scalability bloker in javax.crypto.CryptoPermissions Summary: Changed the type of field "perms" from Hashtable to ConcurrentHashMap. Reviewed-by: weijun, xuelei ! src/share/classes/javax/crypto/CryptoPermissions.java Changeset: 175036ada2e3 Author: valeriep Date: 2012-08-10 13:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/175036ada2e3 7107616: scalability bloker in javax.crypto.JceSecurityManager Summary: Changed the type of field "exemptCache" from HashMap to ConcurrentHashMap. Reviewed-by: weijun, xuelei ! src/share/classes/javax/crypto/JceSecurityManager.java Changeset: 9e97dacbfd35 Author: valeriep Date: 2012-08-10 13:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e97dacbfd35 7185471: Avoid key expansion when AES cipher is re-init w/ the same key Summary: Saved the last cipher key value and skip key expansion if key value is the same. Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/crypto/provider/AESCrypt.java From lana.steuck at oracle.com Fri Aug 10 21:01:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:07 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b51 for changeset 57c0aee73090 Message-ID: <20120810210107.E226347494@hg.openjdk.java.net> Changeset: 8d24def5ceb3 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8d24def5ceb3 Added tag jdk8-b51 for changeset 57c0aee73090 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 21:01:07 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:07 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b51 for changeset 9b0f841ca9f7 Message-ID: <20120810210111.8CE8547495@hg.openjdk.java.net> Changeset: 80689ff9cb49 Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/80689ff9cb49 Added tag jdk8-b51 for changeset 9b0f841ca9f7 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 21:01:09 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:09 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b51 for changeset 1a70b6333ebe Message-ID: <20120810210118.0A27C47496@hg.openjdk.java.net> Changeset: f62bc618122e Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f62bc618122e Added tag jdk8-b51 for changeset 1a70b6333ebe ! .hgtags From lana.steuck at oracle.com Fri Aug 10 21:01:14 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:14 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20120810210121.DBA8347497@hg.openjdk.java.net> Changeset: 23032c78b2d1 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/23032c78b2d1 Added tag jdk8-b51 for changeset c4cd4cab2220 ! .hgtags Changeset: 1d2db0e5eabc Author: lana Date: 2012-08-10 10:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1d2db0e5eabc Merge From lana.steuck at oracle.com Fri Aug 10 21:01:21 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:21 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b51 for changeset dc1ea77ed9d9 Message-ID: <20120810210129.0D22B47498@hg.openjdk.java.net> Changeset: bd3c00d57614 Author: katleman Date: 2012-08-09 18:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bd3c00d57614 Added tag jdk8-b51 for changeset dc1ea77ed9d9 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 21:01:12 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:12 +0000 Subject: hg: jdk8/tl/hotspot: 15 new changesets Message-ID: <20120810210149.78C0C47499@hg.openjdk.java.net> Changeset: 86a687be3f02 Author: amurillo Date: 2012-07-27 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/86a687be3f02 7187463: new hotspot build - hs24-b19 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 594dff5e3c2e Author: johnc Date: 2012-07-17 11:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/594dff5e3c2e 7173712: G1: Duplicated code in G1UpdateRSOrPushRefOopClosure::do_oop_nv() Summary: Duplicated code from G1RemSet::par_write_ref() inlined into G1UpdateRSOrPushRefOopClosure::do_oop_nv() was showing up in profiles with a fairly high amount of CPU time. Manually inline the main part of G1RemSet::par_write_ref() to eliminate the code duplication. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: d42fe3c3001d Author: johnc Date: 2012-07-17 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d42fe3c3001d 7184772: G1: Incorrect assert in HeapRegionLinkedList::add_as_head() Summary: Assertion incorrectly checks that _head is NULL and should be checking that _tail is NULL instead. Reviewed-by: johnc Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp Changeset: db823a892a55 Author: johnc Date: 2012-07-17 12:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db823a892a55 7182260: G1: Fine grain RSet freeing bottleneck Summary: Chain the fine grain PerRegionTables in an individual RSet together and free them in bulk using a single operation. Reviewed-by: johnc, brutisso Contributed-by: Thomas Schatzl ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp Changeset: a2f7274eb6ef Author: tonyp Date: 2012-07-19 15:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a2f7274eb6ef 7114678: G1: various small fixes, code cleanup, and refactoring Summary: Various cleanups as a prelude to introducing iterators for HeapRegions. Reviewed-by: johnc, brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp Changeset: 113f4c73df61 Author: jmasa Date: 2012-07-24 14:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/113f4c73df61 Merge Changeset: 3080f4743cf2 Author: jmasa Date: 2012-07-26 23:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3080f4743cf2 Merge Changeset: ff58dfd5b977 Author: jmasa Date: 2012-07-27 21:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff58dfd5b977 Merge Changeset: 3b01d0321dfa Author: zgu Date: 2012-07-30 10:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b01d0321dfa 7186778: MachO decoder implementation for MacOSX Summary: Implementation of decoder for Apple's MacOSX. The implementation is based on the patch provided by Kevin Walls. Reviewed-by: coleenp, kamg, kevinw ! src/os/bsd/vm/decoder_machO.cpp ! src/os/bsd/vm/decoder_machO.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/decoder_elf.hpp Changeset: 4bfef6df8881 Author: zgu Date: 2012-07-30 07:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4bfef6df8881 Merge Changeset: 5e2dc722e70d Author: andrew Date: 2012-07-31 16:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e2dc722e70d 7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 Summary: Templates need this object if not using template parameter in call Reviewed-by: coleenp, kamg, dholmes ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp Changeset: e37a5219e297 Author: dcubed Date: 2012-07-31 18:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e37a5219e297 Merge Changeset: 3b3ad1642970 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b3ad1642970 Merge Changeset: 663fc23da8d5 Author: amurillo Date: 2012-08-03 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/663fc23da8d5 Added tag hs24-b19 for changeset 3b3ad1642970 ! .hgtags Changeset: abc951e44e1b Author: katleman Date: 2012-08-09 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/abc951e44e1b Added tag jdk8-b51 for changeset 663fc23da8d5 ! .hgtags From lana.steuck at oracle.com Fri Aug 10 21:01:25 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 10 Aug 2012 21:01:25 +0000 Subject: hg: jdk8/tl/jdk: 4 new changesets Message-ID: <20120810210210.96A404749A@hg.openjdk.java.net> Changeset: b3b0d75cb117 Author: katleman Date: 2012-08-09 18:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3b0d75cb117 Added tag jdk8-b51 for changeset e865efbc7105 ! .hgtags Changeset: da8649489aff Author: lana Date: 2012-08-10 10:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da8649489aff Merge Changeset: 449c17c7a63a Author: lana Date: 2012-08-10 12:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/449c17c7a63a Merge Changeset: e8b14276d434 Author: lana Date: 2012-08-10 14:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8b14276d434 Merge From schlosna at gmail.com Fri Aug 10 21:02:49 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Fri, 10 Aug 2012 17:02:49 -0400 Subject: Review request 7190657 Modify getDriver() to call Thread.currentThread().getContextClassLoader(); In-Reply-To: References: Message-ID: Lance, There are a couple of other uses of DriverManager.getCallerClassLoader() that do no fall back to Thread.currentThread().getContextClassLoader() if the caller class loader is null (bootstrap loader). Should these be updated as well? >From http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/sql/DriverManager.java: Line 334 in deregisterDriver(Driver driver) Line 365 in getDrivers() Thanks, Dave On Fri, Aug 10, 2012 at 1:19 PM, Lance Andersen - Oracle wrote: > Looking for a reviewer for the following change: > > - add a call to Thread.currentThread().getContextClassLoader() to DriverManager.getDriver() > - Remove the synchronized block for the same call in getConnection() > > Thank you. > > Best > Lance > > localhost:sql lanceandersen$ hg diff DriverManager.java > diff -r 629f357fc17b src/share/classes/java/sql/DriverManager.java > --- a/src/share/classes/java/sql/DriverManager.java Fri Aug 10 09:17:14 2012 -0400 > +++ b/src/share/classes/java/sql/DriverManager.java Fri Aug 10 13:05:00 2012 -0400 > @@ -264,6 +264,10 @@ > // be null. > ClassLoader callerCL = DriverManager.getCallerClassLoader(); > > + if(callerCL == null) { > + callerCL = Thread.currentThread().getContextClassLoader(); > + } > + > // Walk through the loaded registeredDrivers attempting to locate someone > // who understands the given URL. > for (DriverInfo aDriver : registeredDrivers) { > @@ -563,11 +567,8 @@ > * classloader, so that the JDBC driver class outside rt.jar > * can be loaded from here. > */ > - synchronized(DriverManager.class) { > - // synchronize loading of the correct classloader. > - if(callerCL == null) { > - callerCL = Thread.currentThread().getContextClassLoader(); > - } > + if(callerCL == null) { > + callerCL = Thread.currentThread().getContextClassLoader(); > } > > if(url == null) { > localhost:sql lanceandersen$ > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From Lance.Andersen at oracle.com Sat Aug 11 17:15:30 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Sat, 11 Aug 2012 13:15:30 -0400 Subject: Review request 7190657 Modify getDriver() to call Thread.currentThread().getContextClassLoader(); In-Reply-To: References: Message-ID: <8C3D5683-DCF2-4FCC-B763-6216C259D751@oracle.com> For completeness, they could be added and I guess I can do it as part of this particular change. I would probably move the call to DriverManager.getCallerClassLoader() to avoid the duplication of the if block. Best Lance On Aug 10, 2012, at 5:02 PM, David Schlosnagle wrote: > Lance, > > There are a couple of other uses of > DriverManager.getCallerClassLoader() that do no fall back to > Thread.currentThread().getContextClassLoader() if the caller class > loader is null (bootstrap loader). Should these be updated as well? > >> From http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/sql/DriverManager.java: > Line 334 in deregisterDriver(Driver driver) > Line 365 in getDrivers() > > Thanks, > Dave > > > On Fri, Aug 10, 2012 at 1:19 PM, Lance Andersen - Oracle > wrote: >> Looking for a reviewer for the following change: >> >> - add a call to Thread.currentThread().getContextClassLoader() to DriverManager.getDriver() >> - Remove the synchronized block for the same call in getConnection() >> >> Thank you. >> >> Best >> Lance >> >> localhost:sql lanceandersen$ hg diff DriverManager.java >> diff -r 629f357fc17b src/share/classes/java/sql/DriverManager.java >> --- a/src/share/classes/java/sql/DriverManager.java Fri Aug 10 09:17:14 2012 -0400 >> +++ b/src/share/classes/java/sql/DriverManager.java Fri Aug 10 13:05:00 2012 -0400 >> @@ -264,6 +264,10 @@ >> // be null. >> ClassLoader callerCL = DriverManager.getCallerClassLoader(); >> >> + if(callerCL == null) { >> + callerCL = Thread.currentThread().getContextClassLoader(); >> + } >> + >> // Walk through the loaded registeredDrivers attempting to locate someone >> // who understands the given URL. >> for (DriverInfo aDriver : registeredDrivers) { >> @@ -563,11 +567,8 @@ >> * classloader, so that the JDBC driver class outside rt.jar >> * can be loaded from here. >> */ >> - synchronized(DriverManager.class) { >> - // synchronize loading of the correct classloader. >> - if(callerCL == null) { >> - callerCL = Thread.currentThread().getContextClassLoader(); >> - } >> + if(callerCL == null) { >> + callerCL = Thread.currentThread().getContextClassLoader(); >> } >> >> if(url == null) { >> localhost:sql lanceandersen$ >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From david.holmes at oracle.com Sun Aug 12 11:19:32 2012 From: david.holmes at oracle.com (David Holmes) Date: Sun, 12 Aug 2012 21:19:32 +1000 Subject: Review request 7190657 Modify getDriver() to call Thread.currentThread().getContextClassLoader(); In-Reply-To: References: Message-ID: <50279144.7000109@oracle.com> Lance, On 11/08/2012 3:19 AM, Lance Andersen - Oracle wrote: > Looking for a reviewer for the following change: > > - add a call to Thread.currentThread().getContextClassLoader() to DriverManager.getDriver() > - Remove the synchronized block for the same call in getConnection() What is the context for the change? What is it trying to achieve or avoid? David > Thank you. > > Best > Lance > > localhost:sql lanceandersen$ hg diff DriverManager.java > diff -r 629f357fc17b src/share/classes/java/sql/DriverManager.java > --- a/src/share/classes/java/sql/DriverManager.java Fri Aug 10 09:17:14 2012 -0400 > +++ b/src/share/classes/java/sql/DriverManager.java Fri Aug 10 13:05:00 2012 -0400 > @@ -264,6 +264,10 @@ > // be null. > ClassLoader callerCL = DriverManager.getCallerClassLoader(); > > + if(callerCL == null) { > + callerCL = Thread.currentThread().getContextClassLoader(); > + } > + > // Walk through the loaded registeredDrivers attempting to locate someone > // who understands the given URL. > for (DriverInfo aDriver : registeredDrivers) { > @@ -563,11 +567,8 @@ > * classloader, so that the JDBC driver class outside rt.jar > * can be loaded from here. > */ > - synchronized(DriverManager.class) { > - // synchronize loading of the correct classloader. > - if(callerCL == null) { > - callerCL = Thread.currentThread().getContextClassLoader(); > - } > + if(callerCL == null) { > + callerCL = Thread.currentThread().getContextClassLoader(); > } > > if(url == null) { > localhost:sql lanceandersen$ > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From chris.hegarty at oracle.com Sun Aug 12 21:57:58 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 12 Aug 2012 21:57:58 +0000 Subject: hg: jdk8/tl/jdk: 7188755: Crash due to missing synchronization on gconf_client in DefaultProxySelector.c Message-ID: <20120812215828.DDB64474C8@hg.openjdk.java.net> Changeset: e7d125f2575b Author: chegar Date: 2012-08-12 22:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7d125f2575b 7188755: Crash due to missing synchronization on gconf_client in DefaultProxySelector.c Reviewed-by: chegar Contributed-by: Christian Schulte ! src/share/classes/sun/net/spi/DefaultProxySelector.java + test/java/net/ProxySelector/MultiThreadedSystemProxies.java From luchsh at linux.vnet.ibm.com Mon Aug 13 08:26:52 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 13 Aug 2012 16:26:52 +0800 Subject: Code review request 7190219 CharBuffer position changed after BufferOverflowException in put() In-Reply-To: <5023BB0C.2080406@oracle.com> References: <5023AA2B.9030502@linux.vnet.ibm.com> <5023BB0C.2080406@oracle.com> Message-ID: <5028BA4C.2030405@linux.vnet.ibm.com> Hello Alan, Thanks for reviewing, I've updated the webrev, could you please take a look? http://cr.openjdk.java.net/~luchsh/7190219_2/ On 08/09/2012 09:28 PM, Alan Bateman wrote: > On 09/08/2012 13:16, Jonathan Lu wrote: >> Hi folks, >> >> Here's a patch for bug 7190219, could you please help to have a look? >> http://cr.openjdk.java.net/~luchsh/7190219/ >> >> According to the specification, in the method >> java.nio.CharBuffer.put(String src, int start, int end). >> If there are more chars to be copied from the string than remain in >> this buffer, that is, if end - start > remaining(), then no chars are >> transferred and a|BufferOverflowException||| >> is thrown. >> >> But actually the test case from that webrev proves that the buffer >> was modified even after BufferOverflowException, so I suggest to add >> additional check after checkBounds() call, in the same way as >> java.nio.CharBuffer.put(char[] src, int offset, int length). > You're right, it's missing a check to make sure that there is > remaining space and the proposed change looks right to me. Just to > keep things locally consistent you can remove the braces around the > throw new BufferOverflowException. > > I think the test could be improved. In particular it could duplicate > the buffer and then check that it is equals to the duplicate after the > put fails (in addition to checking that that the position hasn't > changed). That way you really check that the buffer content haven't > been modified. Do you mind seeing if you can add this to the existing > unit test for the buffer classes rather than adding a new test? You'll > see the existing tests in Basic.java and Basic-X.java.template. In the updated webrev, I'm using relGet() to perform the content checking after put(). And I also updated all the generated Basic.java files using genBasic.sh. > > I see you've submitted an incident via bugs.sun.com for this, I've > moved to the right place as: > > 7190219: (bf) CharBuffer.put(String,int,int) modifies position even if > BufferOverflowException thrown > > -Alan. > Thanks & regards Jonathan From yiming.wang at oracle.com Mon Aug 13 09:30:25 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Mon, 13 Aug 2012 17:30:25 +0800 Subject: [PATCH] Review Request for bug 7132247 java/rmi/registry/readTest/readTest.sh failing with Cygwin Message-ID: <5028C931.7080905@oracle.com> Hi Alan, Please help to review the below fix for** bug 7132247 java/rmi/registry/readTest/readTest.sh failing with Cygwin. http://dl.dropbox.com/u/90659131/fixes/7132247/webrev/index.html Root cause of this bug is: 1. CYGWIN doesn't handle "\\" correctly, if say FS="\\"; echo $FS, in cgywin, will print \\\\ which cause file not found. 2. Java doesn't recognize CYGWIN style path like "/cygwin/d/...", should use cygpath to convert to Windows native path. Thanks, Eric From Alan.Bateman at oracle.com Mon Aug 13 10:34:57 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Aug 2012 11:34:57 +0100 Subject: [PATCH] Review Request for bug 7132247 java/rmi/registry/readTest/readTest.sh failing with Cygwin In-Reply-To: <5028C931.7080905@oracle.com> References: <5028C931.7080905@oracle.com> Message-ID: <5028D851.50803@oracle.com> On 13/08/2012 10:30, Eric Wang wrote: > Hi Alan, > > Please help to review the below fix for** bug 7132247 > > java/rmi/registry/readTest/readTest.sh failing with Cygwin. > http://dl.dropbox.com/u/90659131/fixes/7132247/webrev/index.html > > Root cause of this bug is: > 1. CYGWIN doesn't handle "\\" correctly, if say FS="\\"; echo $FS, in > cgywin, will print \\\\ which cause file not found. > 2. Java doesn't recognize CYGWIN style path like "/cygwin/d/...", > should use cygpath to convert to Windows native path. > > Thanks, > Eric This looks good to me and good to have another test off the exclude list. Stuart - are you going to sponsor this one? -Alan. From Alan.Bateman at oracle.com Mon Aug 13 10:41:26 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Aug 2012 11:41:26 +0100 Subject: Code review request 7190219 CharBuffer position changed after BufferOverflowException in put() In-Reply-To: <5028BA4C.2030405@linux.vnet.ibm.com> References: <5023AA2B.9030502@linux.vnet.ibm.com> <5023BB0C.2080406@oracle.com> <5028BA4C.2030405@linux.vnet.ibm.com> Message-ID: <5028D9D6.8070901@oracle.com> On 13/08/2012 09:26, Jonathan Lu wrote: > Hello Alan, > > Thanks for reviewing, I've updated the webrev, could you please take a > look? > > http://cr.openjdk.java.net/~luchsh/7190219_2/ > > : > In the updated webrev, I'm using relGet() to perform the content > checking after put(). > And I also updated all the generated Basic.java files using > genBasic.sh. > This looks good to me and thanks for adding the test to to the main unit test for this area. Do you mind adding the bugID to the list in Basic.java before you push this? Also, minor nit, can add a space "//String ops" then it will keep the comments locally consistent (no need to re-generate the webrev on these points). -Alan From luchsh at linux.vnet.ibm.com Mon Aug 13 11:52:47 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Mon, 13 Aug 2012 11:52:47 +0000 Subject: hg: jdk8/tl/jdk: 7190219: (bf) CharBuffer.put(String, int, int) modifies position even if BufferOverflowException thrown Message-ID: <20120813115315.AA9ED474D7@hg.openjdk.java.net> Changeset: bf0c6f91bc22 Author: luchsh Date: 2012-08-13 19:51 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf0c6f91bc22 7190219: (bf) CharBuffer.put(String,int,int) modifies position even if BufferOverflowException thrown Reviewed-by: alanb ! src/share/classes/java/nio/X-Buffer.java.template ! test/java/nio/Buffer/Basic-X.java.template ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java From luchsh at linux.vnet.ibm.com Mon Aug 13 11:55:50 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Mon, 13 Aug 2012 19:55:50 +0800 Subject: Code review request 7190219 CharBuffer position changed after BufferOverflowException in put() In-Reply-To: <5028D9D6.8070901@oracle.com> References: <5023AA2B.9030502@linux.vnet.ibm.com> <5023BB0C.2080406@oracle.com> <5028BA4C.2030405@linux.vnet.ibm.com> <5028D9D6.8070901@oracle.com> Message-ID: <5028EB46.1060500@linux.vnet.ibm.com> On 08/13/2012 06:41 PM, Alan Bateman wrote: > On 13/08/2012 09:26, Jonathan Lu wrote: >> Hello Alan, >> >> Thanks for reviewing, I've updated the webrev, could you please take >> a look? >> >> http://cr.openjdk.java.net/~luchsh/7190219_2/ >> >> : >> In the updated webrev, I'm using relGet() to perform the content >> checking after put(). >> And I also updated all the generated Basic.java files using >> genBasic.sh. >> > This looks good to me and thanks for adding the test to to the main > unit test for this area. Do you mind adding the bugID to the list in > Basic.java before you push this? Also, minor nit, can add a space > "//String ops" then it will keep the comments locally consistent (no > need to re-generate the webrev on these points). > > -Alan > Thanks, Alan. I've pushed the changes. Best regards Jonathan From chris.hegarty at oracle.com Mon Aug 13 12:42:04 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 13 Aug 2012 12:42:04 +0000 Subject: hg: jdk8/tl/jdk: 7190254: NetworkInterface getFlags implementation should support full integer bit range for flags value Message-ID: <20120813124227.27CDB474DB@hg.openjdk.java.net> Changeset: 399c2adf3ad6 Author: chegar Date: 2012-08-13 13:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/399c2adf3ad6 7190254: NetworkInterface getFlags implementation should support full integer bit range for flags value Reviewed-by: chegar Contributed-by: Shirish Kuncolienkar ! src/solaris/native/java/net/NetworkInterface.c From vincent.x.ryan at oracle.com Mon Aug 13 13:13:18 2012 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 13 Aug 2012 13:13:18 +0000 Subject: hg: jdk8/tl/jdk: 7190945: pkcs11 problem loading NSS libs on Ubuntu Message-ID: <20120813131337.54712474DD@hg.openjdk.java.net> Changeset: 5e5bdfd18325 Author: vinnie Date: 2012-08-13 14:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e5bdfd18325 7190945: pkcs11 problem loading NSS libs on Ubuntu Reviewed-by: xuelei, alanb ! src/share/classes/sun/security/pkcs11/Secmod.java ! test/sun/security/pkcs11/PKCS11Test.java ! test/sun/security/pkcs11/Secmod/keystore.jks From rob.mckenna at oracle.com Mon Aug 13 14:31:23 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 13 Aug 2012 15:31:23 +0100 Subject: Codereview request: 6931128: (spec) File attribute tests fail when run as root. Message-ID: <50290FBB.8050405@oracle.com> Hi folks, Looking for a codereview for a spec change in jdk8. In summary, when a java application is run as root it can perform file operations regardless of the permissions attributed to that file. I.e. canExecute, canRead, canWrite would return true even though the File may not have those permissions set. webrev at: http://cr.openjdk.java.net/~robm/6931128/webrev.01/ Thanks, -Rob From Alan.Bateman at oracle.com Mon Aug 13 14:49:34 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 13 Aug 2012 15:49:34 +0100 Subject: Codereview request: 6931128: (spec) File attribute tests fail when run as root. In-Reply-To: <50290FBB.8050405@oracle.com> References: <50290FBB.8050405@oracle.com> Message-ID: <502913FE.3010208@oracle.com> On 13/08/2012 15:31, Rob McKenna wrote: > Hi folks, > > Looking for a codereview for a spec change in jdk8. > > In summary, when a java application is run as root it can perform file > operations regardless of the permissions attributed to that file. I.e. > canExecute, canRead, canWrite would return true even though the File > may not have those permissions set. > > webrev at: http://cr.openjdk.java.net/~robm/6931128/webrev.01/ > > > Thanks, > > -Rob Thanks for taking this one, the changes looks good to me. -Alan. From jonathan.gibbons at oracle.com Mon Aug 13 19:16:08 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 13 Aug 2012 19:16:08 +0000 Subject: hg: jdk8/tl/jdk: 7188442: rename java.lang.annotation.ContainerAnnotation to ContainedBy Message-ID: <20120813191618.C7FEE474E6@hg.openjdk.java.net> Changeset: f0bf7358ba23 Author: jfranck Date: 2012-08-09 17:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0bf7358ba23 7188442: rename java.lang.annotation.ContainerAnnotation to ContainedBy Reviewed-by: darcy, jjg + src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerAnnotation.java From naoto.sato at oracle.com Mon Aug 13 21:43:33 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 13 Aug 2012 14:43:33 -0700 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <5022D686.9070203@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> <5022D686.9070203@oracle.com> Message-ID: <50297505.7050603@oracle.com> Since I haven't heard any more comments from Erik/Kelly, I would like to push the changeset without the new build infra patch. Erik/Kelly, can you please give us an official "GO" in terms of the build related changes? Aside from build changes, I have updated the changeset based on an internal review: http://cr.openjdk.java.net/~naoto/6336885/webrev.01/ This includes: - a couple of fixes to the CLDR Converter - Added fallback for any bad SPI implementations which return null for requested instances. Still asking for review comments. Naoto On 8/8/12 2:13 PM, Naoto Sato wrote: > On 8/7/12 2:57 AM, Erik Joelsson wrote: >> See inline >> >> On 2012-07-13 22:20, Kelly O'Hair wrote: >>> Something seems strange here: >>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html >>> >>> >>> It's like someone was avoiding overall quotes, but using them to add >>> spaces somehow... >>> I sure would like to get rid of this shell logic, seems like there are >>> lots repeated logic that >>> this script does over and over or could be done with makefile pattern >>> subst's instead of exec's. >> The new version isn't any worse than the old in my opinion. In >> build-infra, this file is indeed replaced with make logic. After having >> decoded both versions I'm confident in converting the changes. >>> Overall, just looking at the makefiles, the build-infra team may need >>> some time to fully absorb this into the >>> new makefiles, some of it will be trivial, not sure all of it will be. >>> >> I have applied the patch to a clone of build-infra and done the minimal >> changes to keep build-infra building, which was rather trivial. The >> resulting build has large differences since I haven't converted all of >> it yet. There are a couple of things that will require some more work, >> but not more than a day or two. >>> Not sure how to proceed here, the build-infra team does need an action >>> item to deal with this, maybe >>> before it gets integrated because I suspect the new makefiles will >>> break with all the filename or >>> directory changes. But I hate to hold up your integration plans. >> I see these as possible options: >> >> 1. Let this go in, build-infra will break in jdk8 until we do our next >> push and it trickles through the repos. >> 2. The build-infra project provides a patch with the full conversion >> that can go in together with these changes. >> 3. The build-infra project provides a simple patch which just keeps the >> build-infra-build from failing that can go in with these changes. >> >> The conversion needs to happen regardless of option. The changes >> required are pretty isolated from remaining build-infra work. What do >> you think? > > Either way is fine with me. If build-infra team prefers 2 or 3, please > give me the patch, and I will go ahead and merge them to my changeset. > > Naoto > >> >> Other than that, I have no objections to the review. >> >> /Erik >> >>> I'd like to get some advice from Erik on this before saying anything >>> further. >>> >>> -kto >>> >>> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: >>> >>>> Hello, >>>> >>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>> Packaging and Adopt Unicode CLDR Data >>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>> >>>> The main bug id for this enhancement is: >>>> >>>> 6336885: RFE: Locale Data Deployment Enhancements >>>> >>>> Along with this, the following bugs/enhancements are also implemented >>>> in this change: >>>> >>>> 4609153 Provide locale data for Indic locales >>>> 5104387 Support for gl_ES locale (galician language) >>>> 6337471 desktop/system locale preferences support >>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>> 7058206 Provide CalendarData SPI for week params and display field >>>> value names >>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>> locale >>>> 7079560 [Fmt-Da] Context dependent month names support in >>>> SimpleDateFormat >>>> 7171324 getAvailableLocales() of locale sensitive services should >>>> return the actual availability of locales >>>> 7151414 (cal) Support calendar type identification >>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>> calendar is specified >>>> >>>> Please note that packaging changes that relate to Jigsaw module >>>> system aren't included in this changeset. >>>> >>>> Naoto Sato and Masayoshi Okutsu > From david.holmes at oracle.com Tue Aug 14 06:57:21 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Aug 2012 16:57:21 +1000 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <50297505.7050603@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> <5022D686.9070203@oracle.com> <50297505.7050603@oracle.com> Message-ID: <5029F6D1.1020602@oracle.com> Ni Naoto, Where will this be pushed to initially? It is a big set of changes, albeit localized (no pun intended :) ), so it would be good to see this get some bake time before propagating up. Further we're just about to have a "flag day" between hotspot and JDK due to JSR292 changes, so it would be good to also add some space between those changes and these ones - if that is feasible. This isn't my call, I'm just airing concerns :) Thanks, David On 14/08/2012 7:43 AM, Naoto Sato wrote: > Since I haven't heard any more comments from Erik/Kelly, I would like to > push the changeset without the new build infra patch. Erik/Kelly, can > you please give us an official "GO" in terms of the build related changes? > > Aside from build changes, I have updated the changeset based on an > internal review: > > http://cr.openjdk.java.net/~naoto/6336885/webrev.01/ > > This includes: > > - a couple of fixes to the CLDR Converter > - Added fallback for any bad SPI implementations which return null for > requested instances. > > Still asking for review comments. > > Naoto > > On 8/8/12 2:13 PM, Naoto Sato wrote: >> On 8/7/12 2:57 AM, Erik Joelsson wrote: >>> See inline >>> >>> On 2012-07-13 22:20, Kelly O'Hair wrote: >>>> Something seems strange here: >>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html >>>> >>>> >>>> >>>> It's like someone was avoiding overall quotes, but using them to add >>>> spaces somehow... >>>> I sure would like to get rid of this shell logic, seems like there are >>>> lots repeated logic that >>>> this script does over and over or could be done with makefile pattern >>>> subst's instead of exec's. >>> The new version isn't any worse than the old in my opinion. In >>> build-infra, this file is indeed replaced with make logic. After having >>> decoded both versions I'm confident in converting the changes. >>>> Overall, just looking at the makefiles, the build-infra team may need >>>> some time to fully absorb this into the >>>> new makefiles, some of it will be trivial, not sure all of it will be. >>>> >>> I have applied the patch to a clone of build-infra and done the minimal >>> changes to keep build-infra building, which was rather trivial. The >>> resulting build has large differences since I haven't converted all of >>> it yet. There are a couple of things that will require some more work, >>> but not more than a day or two. >>>> Not sure how to proceed here, the build-infra team does need an action >>>> item to deal with this, maybe >>>> before it gets integrated because I suspect the new makefiles will >>>> break with all the filename or >>>> directory changes. But I hate to hold up your integration plans. >>> I see these as possible options: >>> >>> 1. Let this go in, build-infra will break in jdk8 until we do our next >>> push and it trickles through the repos. >>> 2. The build-infra project provides a patch with the full conversion >>> that can go in together with these changes. >>> 3. The build-infra project provides a simple patch which just keeps the >>> build-infra-build from failing that can go in with these changes. >>> >>> The conversion needs to happen regardless of option. The changes >>> required are pretty isolated from remaining build-infra work. What do >>> you think? >> >> Either way is fine with me. If build-infra team prefers 2 or 3, please >> give me the patch, and I will go ahead and merge them to my changeset. >> >> Naoto >> >>> >>> Other than that, I have no objections to the review. >>> >>> /Erik >>> >>>> I'd like to get some advice from Erik on this before saying anything >>>> further. >>>> >>>> -kto >>>> >>>> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: >>>> >>>>> Hello, >>>>> >>>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>>> Packaging and Adopt Unicode CLDR Data >>>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>>> >>>>> The main bug id for this enhancement is: >>>>> >>>>> 6336885: RFE: Locale Data Deployment Enhancements >>>>> >>>>> Along with this, the following bugs/enhancements are also implemented >>>>> in this change: >>>>> >>>>> 4609153 Provide locale data for Indic locales >>>>> 5104387 Support for gl_ES locale (galician language) >>>>> 6337471 desktop/system locale preferences support >>>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>>> 7058206 Provide CalendarData SPI for week params and display field >>>>> value names >>>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>>> locale >>>>> 7079560 [Fmt-Da] Context dependent month names support in >>>>> SimpleDateFormat >>>>> 7171324 getAvailableLocales() of locale sensitive services should >>>>> return the actual availability of locales >>>>> 7151414 (cal) Support calendar type identification >>>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>>> calendar is specified >>>>> >>>>> Please note that packaging changes that relate to Jigsaw module >>>>> system aren't included in this changeset. >>>>> >>>>> Naoto Sato and Masayoshi Okutsu >> > From ahughes at redhat.com Tue Aug 14 09:51:48 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 14 Aug 2012 05:51:48 -0400 (EDT) Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <4FFC93CF.40105@oracle.com> Message-ID: <737597189.4451353.1344937908713.JavaMail.root@redhat.com> ----- Original Message ----- > Hello, > > Please review the JDK8 changes for JEP 127: Improve Locale Data > Packaging and Adopt Unicode CLDR Data > (http://openjdk.java.net/jeps/127). The webrev is located at: > > http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ > > The main bug id for this enhancement is: > > 6336885: RFE: Locale Data Deployment Enhancements > > Along with this, the following bugs/enhancements are also implemented > in > this change: > > 4609153 Provide locale data for Indic locales > 5104387 Support for gl_ES locale (galician language) > 6337471 desktop/system locale preferences support > 7056139 (cal) SPI support for locale-dependent Calendar parameters > 7058206 Provide CalendarData SPI for week params and display field > value > names > 7073852 Support multiple scripts for digits and decimal symbols per > locale > 7079560 [Fmt-Da] Context dependent month names support in > SimpleDateFormat > 7171324 getAvailableLocales() of locale sensitive services should > return > the actual availability of locales > 7151414 (cal) Support calendar type identification > 7168528 LocaleServiceProvider needs to be aware of Locale extensions > 7171372 (cal) locale's default Calendar should be created if unknown > calendar is specified > > Please note that packaging changes that relate to Jigsaw module > system > aren't included in this changeset. > > Naoto Sato and Masayoshi Okutsu > First of all, I'd like to say congratulations on completing this week and adopting the CLDR as a source for locale data. This is something we've used for GNU Classpath's locale data for many years, and, with these changes, it should mean that the Java API itself should see changes which allow it to support some of the features present in the CLDR data. However, I am a little concerned by the inclusion of CLDR data files in this webrev with a GPL header assigning copyright to Oracle e.g. http://cr.openjdk.java.net/~naoto/6336885/webrev.00/src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq.xml.patch Is this legal? IANAL, but http://unicode.org/copyright.html#Exhibit1 seems to state that the header given there should be present on this data. The current files make it look like this data was created by Oracle this year, which is clearly inaccurate. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Tue Aug 14 12:36:24 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 14 Aug 2012 08:36:24 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <5025593F.3080102@oracle.com> Message-ID: <1435389182.4622712.1344947784274.JavaMail.root@redhat.com> ----- Original Message ----- > On 10/08/2012 18:40, Andrew Hughes wrote: > > ----- Original Message ----- > >> Hi Andrew > >> > >> Alan mentioned the other day that the build (with your latest > >> patch, > >> with zlib-dev) failed at pack200 > >> when he tried to turn it on on linux. Can your double check on > >> your > >> system? > >> > > What kind of failure? All webrevs I've posted pass a complete > > build here, > > and we've been using system zlib for years as previously mentioned, > > so I'm > > surprised by this. > > > I grabbed your patch a few days ago and did a build+test job on all > platforms (Linux/Solaris/Mac/Windows) and didn't see any issues. This > was of course using the defaults, I didn't set SYSTEM_ZLIB > explicitly. > > However I did see an issue on Ubuntu 12.0.4 (32-bit) with > SYSTEM_ZLIB=true. Attached is the tail of the log. I haven't had time > to > look at it but I do see that libzip.so is built as expected (ldd > shows > it is linked to libz). The build failure is with unpack200 as it uses > the the zlib functions. Building with SYSTEM_ZLIB=false is fine on > this > system. > > -Alan > > rm -f ../../../../../build/linux-i586/bin/unpack200 > rm -f > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack/mapfile-vers > /bin/cp mapfile-vers-unpack200 > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack/mapfile-vers > /usr/bin/gcc -O2 -DPRODUCT -fPIC -DCC_NOEX -W -Wall -Wno-unused > -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN -DFULL > -DSYSTEM_ZLIB -DNDEBUG -DARCH='"i586"' -Di586 -DLINUX > -DRELEASE='"1.8.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE > -D_REENTRANT -I. > -I../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack/CClassHeaders > -I../../../../../src/closed/share/javavm/export > -I../../../../../src/solaris/javavm/export > -I../../../../../src/share/javavm/export > -I../../../../../src/share/native/common > -I../../../../../src/solaris/native/common > -I../../../../../src/share/native/com/sun/java/util/jar/pack > -I../../../../../src/solaris/native/com/sun/java/util/jar/pack > -Xlinker -O1 -Xlinker -version-script=mapfile-vers > -Wl,--hash-style=both -Xlinker -z -Xlinker origin -Xlinker -rpath > -Xlinker \$ORIGIN -Xlinker -z -Xlinker defs > -L../../../../../build/linux-i586/lib/i386 -Wl,-soname=libunpack.so > -lz -lc > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/bands.o > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/bytes.o > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/coding.o > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/unpack.o > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/utils.o > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/zip.o > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/main.o > -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -o > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack/unpack200 > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/zip.o: > In function `jar::deflate_bytes(bytes&, bytes&)': > zip.cpp:(.text+0x79b): undefined reference to `deflateInit2_' > zip.cpp:(.text+0x828): undefined reference to `deflate' > zip.cpp:(.text+0x842): undefined reference to `deflateEnd' > zip.cpp:(.text+0x854): undefined reference to `deflateEnd' > zip.cpp:(.text+0x87c): undefined reference to `deflate' > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/zip.o: > In function `jar::addJarEntry(char const*, bool, int, bytes&, > bytes&)': > zip.cpp:(.text+0x8d2): undefined reference to `crc32' > zip.cpp:(.text+0x9d1): undefined reference to `crc32' > zip.cpp:(.text+0x9ee): undefined reference to `crc32' > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/zip.o: > In function `gunzip::free()': > zip.cpp:(.text+0xb33): undefined reference to `inflateEnd' > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/zip.o: > In function `read_input_via_gzip(unpacker*, void*, long long, long > long)': > zip.cpp:(.text+0xbfe): undefined reference to `inflate' > ../../../../../build/linux-i586/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj/zip.o: > In function `gunzip::start(int)': > zip.cpp:(.text+0xf35): undefined reference to `inflateInit2_' > collect2: ld returned 1 exit status > > Ok, the obvious difference between my output and yours is you seem to be linking statically via gcc rather than dynamically with g++. /usr/bin/g++ -O2 -DPRODUCT -fPIC -DCC_NOEX -W -Wall \ -Wno-unused -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN -g \ -DFULL -DSYSTEM_ZLIB -DNDEBUG -DARCH='"amd64"' -Damd64 -DLINUX -DRELEASE='"1.8.0-internal"' \ -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -D_LP64=1 -I. \ -I/home/andrew/builder/awt/tmp/sun/com.sun.java.util.jar.pack/unpack/CClassHeaders \ -I../../../../../src/solaris/javavm/export -I../../../../../src/share/javavm/export \ -I../../../../../src/share/native/common -I../../../../../src/solaris/native/common \ -I../../../../../src/share/native/com/sun/java/util/jar/pack \ -I../../../../../src/solaris/native/com/sun/java/util/jar/pack \ -Xlinker -O1 -Xlinker -version-script=mapfile-vers -Xlinker -z -Xlinker origin \ -Xlinker -rpath -Xlinker \$ORIGIN -Xlinker -z -Xlinker defs -L/home/andrew/builder/awt/lib/amd64\ -Wl,-soname=libunpack.so -lz -lc \ /home/andrew/builder/awt/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64/bands.o \ /home/andrew/builder/awt/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64/bytes.o \ /home/andrew/builder/awt/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64/coding.o \ /home/andrew/builder/awt/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64/unpack.o \ /home/andrew/builder/awt/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64/utils.o \ /home/andrew/builder/awt/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64/zip.o \ /home/andrew/builder/awt/tmp/sun/com.sun.java.util.jar.pack/unpack-cmd/obj64/main.o \ -lstdc++ -o /home/andrew/builder/awt/tmp/sun/com.sun.java.util.jar.pack/unpack/unpack200 /bin/cp /home/andrew/builder/awt/tmp/sun/com.sun.java.util.jar.pack/unpack/unpack200 \ /home/andrew/builder/awt/bin/unpack200 Checking for mapfile use in: /home/andrew/builder/awt/bin/unpack200 Library loads for: /home/andrew/builder/awt/bin/unpack200 linux-vdso.so.1 (0x00007ffff315c000) libz.so.1 => /lib64/libz.so.1 (0x00007fd609351000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/libstdc++.so.6 (0x00007fd60904a000) libm.so.6 => /lib64/libm.so.6 (0x00007fd608d56000) libc.so.6 => /lib64/libc.so.6 (0x00007fd6089ac000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/libgcc_s.so.1 (0x00007fd608796000) /lib64/ld-linux-x86-64.so.2 (0x00007fd609567000) RUNPATH for: /home/andrew/builder/awt/bin/unpack200 0x0000000000000001 (NEEDED) Shared library: [libz.so.1] 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x000000000000000f (RPATH) Library rpath: [$ORIGIN] 0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN] Do you have a static libz.a installed (from zlib1g-dev) and all dependent static libraries? I suspect you'll get the same failure with or without my patch (though you'll probably need the change to defines.h to get this far...) I'd guess you have STATIC_CXX set to true (the default apparently): >From Compiler-gcc.gmk: STATIC_CXX = true ifeq ($(STATIC_CXX),true) # g++ always dynamically links libstdc++, even we use "-Wl,-Bstatic -lstdc++" # We need to use gcc to statically link the C++ runtime. gcc and g++ use # the same subprocess to compile C++ files, so it is OK to build using gcc. CXX = $(COMPILER_PATH)gcc else CXX = $(COMPILER_PATH)g++ endif >From Defs-linux.gmk: ifeq ($(STATIC_CXX),true) override LIBCXX = -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic else override LIBCXX = -lstdc++ endif -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From Alan.Bateman at oracle.com Tue Aug 14 12:59:19 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Aug 2012 13:59:19 +0100 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <1435389182.4622712.1344947784274.JavaMail.root@redhat.com> References: <1435389182.4622712.1344947784274.JavaMail.root@redhat.com> Message-ID: <502A4BA7.8000206@oracle.com> On 14/08/2012 13:36, Andrew Hughes wrote: > : > > Do you have a static libz.a installed (from zlib1g-dev) and all dependent static libraries? I think you're right about the static linking but this was just a quick test to see if SYSTEM_ZLIB=true worked with everything else as default. pack200 has C++ so that explains why we see it there and not when building libzip. $ dpkg -s zlib1g-dev Package: zlib1g-dev Status: install ok installed Multi-Arch: same Priority: optional Section: libdevel Installed-Size: 366 Maintainer: Ubuntu Developers Architecture: i386 Source: zlib Version: 1:1.2.3.4.dfsg-3ubuntu4 Provides: libz-dev Depends: zlib1g (= 1:1.2.3.4.dfsg-3ubuntu4), libc6-dev | libc-dev Conflicts: zlib1-dev Description: compression library - development zlib is a library implementing the deflate compression method found in gzip and PKZIP. This package includes the development support files. Homepage: http://zlib.net/ Original-Maintainer: Mark Brown $ apt-file search libz.a lib64z1-dev: /usr/lib64/libz.a zlib1g-dev: /usr/lib/i386-linux-gnu/libz.a $ ls -l /usr/lib/i386-linux-gnu/libz.a -rw-r--r-- 1 root root 98772 Nov 10 2011 /usr/lib/i386-linux-gnu/libz.a > > I suspect you'll get the same failure with or without my patch (though you'll probably need the change > to defines.h to get this far...) SYSTEM_ZLIB is currently Mac only so I wouldn't expect to have got very far without your changes. > > I'd guess you have STATIC_CXX set to true (the default apparently): I didn't specify any other build options so it's using the default. BTW: I should mention that I don't have any issues with the patch proposed as it works as it does now because SYSTEM_ZLIB is false. It may be that there is follow-up to allow SYSTEM_ZLIB=true and static linking to work together. -Alan. From ahughes at redhat.com Tue Aug 14 13:13:54 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 14 Aug 2012 09:13:54 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <502A4BA7.8000206@oracle.com> Message-ID: <1534727880.4651279.1344950034109.JavaMail.root@redhat.com> ----- Original Message ----- > On 14/08/2012 13:36, Andrew Hughes wrote: > > : > > > > Do you have a static libz.a installed (from zlib1g-dev) and all > > dependent static libraries? > I think you're right about the static linking but this was just a > quick > test to see if SYSTEM_ZLIB=true worked with everything else as > default. > Ah right. > pack200 has C++ so that explains why we see it there and not when > building libzip. > Right. BTW, it appears gcc 4.5 and later have a new option -static-libstdc++. I don't know if that would work better than the options currently used. http://gcc.gnu.org/gcc-4.5/changes.html > $ dpkg -s zlib1g-dev > Package: zlib1g-dev > Status: install ok installed > Multi-Arch: same > Priority: optional > Section: libdevel > Installed-Size: 366 > Maintainer: Ubuntu Developers > Architecture: i386 > Source: zlib > Version: 1:1.2.3.4.dfsg-3ubuntu4 > Provides: libz-dev > Depends: zlib1g (= 1:1.2.3.4.dfsg-3ubuntu4), libc6-dev | libc-dev > Conflicts: zlib1-dev > Description: compression library - development > zlib is a library implementing the deflate compression method found > in gzip and PKZIP. This package includes the development support > files. > Homepage: http://zlib.net/ > Original-Maintainer: Mark Brown > > $ apt-file search libz.a > lib64z1-dev: /usr/lib64/libz.a > zlib1g-dev: /usr/lib/i386-linux-gnu/libz.a > > $ ls -l /usr/lib/i386-linux-gnu/libz.a > -rw-r--r-- 1 root root 98772 Nov 10 2011 > /usr/lib/i386-linux-gnu/libz.a > > > > > I suspect you'll get the same failure with or without my patch > > (though you'll probably need the change > > to defines.h to get this far...) > SYSTEM_ZLIB is currently Mac only so I wouldn't expect to have got > very > far without your changes. Yes, the defines.h change I refer to is the one that removes the Mac clause. It fails earlier without that change (I've been hitting it on most builds now I have SYSTEM_ZLIB set), so the patch is an improvement, even if it doesn't work in all cases. > > > > > I'd guess you have STATIC_CXX set to true (the default apparently): > I didn't specify any other build options so it's using the default. > An odd default, though I can understand why, given OpenJDK's history. > BTW: I should mention that I don't have any issues with the patch > proposed as it works as it does now because SYSTEM_ZLIB is false. It > may > be that there is follow-up to allow SYSTEM_ZLIB=true and static > linking > to work together. > Can I take that as it's good to push? :-D > -Alan. > Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From xueming.shen at oracle.com Tue Aug 14 15:08:33 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 14 Aug 2012 08:08:33 -0700 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <1534727880.4651279.1344950034109.JavaMail.root@redhat.com> References: <1534727880.4651279.1344950034109.JavaMail.root@redhat.com> Message-ID: <502A69F1.4010709@oracle.com> Yes, you are good to go. Thanks! -Sherman On 8/14/2012 6:13 AM, Andrew Hughes wrote: > ----- Original Message ----- >> On 14/08/2012 13:36, Andrew Hughes wrote: >>> : >>> >>> Do you have a static libz.a installed (from zlib1g-dev) and all >>> dependent static libraries? >> I think you're right about the static linking but this was just a >> quick >> test to see if SYSTEM_ZLIB=true worked with everything else as >> default. >> > Ah right. > >> pack200 has C++ so that explains why we see it there and not when >> building libzip. >> > Right. BTW, it appears gcc 4.5 and later have a new option -static-libstdc++. > I don't know if that would work better than the options currently used. > > http://gcc.gnu.org/gcc-4.5/changes.html > >> $ dpkg -s zlib1g-dev >> Package: zlib1g-dev >> Status: install ok installed >> Multi-Arch: same >> Priority: optional >> Section: libdevel >> Installed-Size: 366 >> Maintainer: Ubuntu Developers >> Architecture: i386 >> Source: zlib >> Version: 1:1.2.3.4.dfsg-3ubuntu4 >> Provides: libz-dev >> Depends: zlib1g (= 1:1.2.3.4.dfsg-3ubuntu4), libc6-dev | libc-dev >> Conflicts: zlib1-dev >> Description: compression library - development >> zlib is a library implementing the deflate compression method found >> in gzip and PKZIP. This package includes the development support >> files. >> Homepage: http://zlib.net/ >> Original-Maintainer: Mark Brown >> >> $ apt-file search libz.a >> lib64z1-dev: /usr/lib64/libz.a >> zlib1g-dev: /usr/lib/i386-linux-gnu/libz.a >> >> $ ls -l /usr/lib/i386-linux-gnu/libz.a >> -rw-r--r-- 1 root root 98772 Nov 10 2011 >> /usr/lib/i386-linux-gnu/libz.a >> >>> I suspect you'll get the same failure with or without my patch >>> (though you'll probably need the change >>> to defines.h to get this far...) >> SYSTEM_ZLIB is currently Mac only so I wouldn't expect to have got >> very >> far without your changes. > Yes, the defines.h change I refer to is the one that removes the Mac > clause. It fails earlier without that change (I've been hitting it > on most builds now I have SYSTEM_ZLIB set), so the patch is an > improvement, even if it doesn't work in all cases. > >>> I'd guess you have STATIC_CXX set to true (the default apparently): >> I didn't specify any other build options so it's using the default. >> > An odd default, though I can understand why, given OpenJDK's history. > >> BTW: I should mention that I don't have any issues with the patch >> proposed as it works as it does now because SYSTEM_ZLIB is false. It >> may >> be that there is follow-up to allow SYSTEM_ZLIB=true and static >> linking >> to work together. >> > Can I take that as it's good to push? :-D > >> -Alan. >> > Thanks, From jeff.dinkins at oracle.com Tue Aug 14 16:16:12 2012 From: jeff.dinkins at oracle.com (Jeff Dinkins) Date: Tue, 14 Aug 2012 09:16:12 -0700 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <737597189.4451353.1344937908713.JavaMail.root@redhat.com> References: <737597189.4451353.1344937908713.JavaMail.root@redhat.com> Message-ID: <84F7A368-1206-4D3C-A79F-9F2C6F8EC719@oracle.com> Andrew - good catch. We're reviewing. On Aug 14, 2012, at 2:51 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Hello, >> >> Please review the JDK8 changes for JEP 127: Improve Locale Data >> Packaging and Adopt Unicode CLDR Data >> (http://openjdk.java.net/jeps/127). The webrev is located at: >> >> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >> >> The main bug id for this enhancement is: >> >> 6336885: RFE: Locale Data Deployment Enhancements >> >> Along with this, the following bugs/enhancements are also implemented >> in >> this change: >> >> 4609153 Provide locale data for Indic locales >> 5104387 Support for gl_ES locale (galician language) >> 6337471 desktop/system locale preferences support >> 7056139 (cal) SPI support for locale-dependent Calendar parameters >> 7058206 Provide CalendarData SPI for week params and display field >> value >> names >> 7073852 Support multiple scripts for digits and decimal symbols per >> locale >> 7079560 [Fmt-Da] Context dependent month names support in >> SimpleDateFormat >> 7171324 getAvailableLocales() of locale sensitive services should >> return >> the actual availability of locales >> 7151414 (cal) Support calendar type identification >> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >> 7171372 (cal) locale's default Calendar should be created if unknown >> calendar is specified >> >> Please note that packaging changes that relate to Jigsaw module >> system >> aren't included in this changeset. >> >> Naoto Sato and Masayoshi Okutsu >> > > First of all, I'd like to say congratulations on completing this week and > adopting the CLDR as a source for locale data. This is something we've used > for GNU Classpath's locale data for many years, and, with these changes, it > should mean that the Java API itself should see changes which allow it to > support some of the features present in the CLDR data. > > However, I am a little concerned by the inclusion of CLDR data files in this > webrev with a GPL header assigning copyright to Oracle e.g. > > http://cr.openjdk.java.net/~naoto/6336885/webrev.00/src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq.xml.patch > > Is this legal? IANAL, but http://unicode.org/copyright.html#Exhibit1 seems to > state that the header given there should be present on this data. The current > files make it look like this data was created by Oracle this year, which is clearly > inaccurate. > > Thanks, > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > From Alan.Bateman at oracle.com Tue Aug 14 16:37:01 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Aug 2012 17:37:01 +0100 Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <1534727880.4651279.1344950034109.JavaMail.root@redhat.com> References: <1534727880.4651279.1344950034109.JavaMail.root@redhat.com> Message-ID: <502A7EAD.4030209@oracle.com> On 14/08/2012 14:13, Andrew Hughes wrote: > Can I take that as it's good to push? :-D No objection from me although if the default is changed to SYSTEM_ZLIB=true for Linux (and maybe Solaris) then it will require making sure that it builds everywhere without needing other options. -Alan. From sean.coffey at oracle.com Tue Aug 14 16:38:25 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 14 Aug 2012 17:38:25 +0100 Subject: RFR: 7056731: Race condition in CORBA code causes re-use of ABORTed connections Message-ID: <502A7F01.8050702@oracle.com> I'm looking to forward port this corba fix from 6u34 to jdk8 (and eventually port to 7u) d.macdonald at auckland.ac.nz originally reported this issue and I'll be marking the fix as contributed by him. He's already signed the OCA. There's a good description in bug report. We have a race like condition if the corba server is shut down while there are still workers/client threads in a waiting queue waiting for server. The issue arises when the purgeCalls method marks a socket state as ABORTed or CLOSE_RECVD but fails to remove that socket from the socket connectionCache. Fix is to wrap the removal of the socket in a finally block. The CorbaResponseWaitingRoomImpl changes are more focused on ensuring that the Map holding these clients is better synchronized. webrev : http://cr.openjdk.java.net/~coffeys/webrev.7056731.jdk8/ bug report : http://bugs.sun.com/view_bug.do?bug_id=7056731 Regards, Sean. From naoto.sato at oracle.com Tue Aug 14 18:09:33 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 14 Aug 2012 11:09:33 -0700 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <5029F6D1.1020602@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> <5022D686.9070203@oracle.com> <50297505.7050603@oracle.com> <5029F6D1.1020602@oracle.com> Message-ID: <502A945D.6030903@oracle.com> Hi David, We are planning to push the changes through T/L repos. Although I think it's unlikely that our changes and JSR 292 ones would interfere, it would be good to push them in a later promotion build. I will shoot for the next one after the "flag day." Naoto On 8/13/12 11:57 PM, David Holmes wrote: > Ni Naoto, > > Where will this be pushed to initially? > > It is a big set of changes, albeit localized (no pun intended :) ), so > it would be good to see this get some bake time before propagating up. > Further we're just about to have a "flag day" between hotspot and JDK > due to JSR292 changes, so it would be good to also add some space > between those changes and these ones - if that is feasible. > > This isn't my call, I'm just airing concerns :) > > Thanks, > David > > On 14/08/2012 7:43 AM, Naoto Sato wrote: >> Since I haven't heard any more comments from Erik/Kelly, I would like to >> push the changeset without the new build infra patch. Erik/Kelly, can >> you please give us an official "GO" in terms of the build related >> changes? >> >> Aside from build changes, I have updated the changeset based on an >> internal review: >> >> http://cr.openjdk.java.net/~naoto/6336885/webrev.01/ >> >> This includes: >> >> - a couple of fixes to the CLDR Converter >> - Added fallback for any bad SPI implementations which return null for >> requested instances. >> >> Still asking for review comments. >> >> Naoto >> >> On 8/8/12 2:13 PM, Naoto Sato wrote: >>> On 8/7/12 2:57 AM, Erik Joelsson wrote: >>>> See inline >>>> >>>> On 2012-07-13 22:20, Kelly O'Hair wrote: >>>>> Something seems strange here: >>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html >>>>> >>>>> >>>>> >>>>> >>>>> It's like someone was avoiding overall quotes, but using them to add >>>>> spaces somehow... >>>>> I sure would like to get rid of this shell logic, seems like there are >>>>> lots repeated logic that >>>>> this script does over and over or could be done with makefile pattern >>>>> subst's instead of exec's. >>>> The new version isn't any worse than the old in my opinion. In >>>> build-infra, this file is indeed replaced with make logic. After having >>>> decoded both versions I'm confident in converting the changes. >>>>> Overall, just looking at the makefiles, the build-infra team may need >>>>> some time to fully absorb this into the >>>>> new makefiles, some of it will be trivial, not sure all of it will be. >>>>> >>>> I have applied the patch to a clone of build-infra and done the minimal >>>> changes to keep build-infra building, which was rather trivial. The >>>> resulting build has large differences since I haven't converted all of >>>> it yet. There are a couple of things that will require some more work, >>>> but not more than a day or two. >>>>> Not sure how to proceed here, the build-infra team does need an action >>>>> item to deal with this, maybe >>>>> before it gets integrated because I suspect the new makefiles will >>>>> break with all the filename or >>>>> directory changes. But I hate to hold up your integration plans. >>>> I see these as possible options: >>>> >>>> 1. Let this go in, build-infra will break in jdk8 until we do our next >>>> push and it trickles through the repos. >>>> 2. The build-infra project provides a patch with the full conversion >>>> that can go in together with these changes. >>>> 3. The build-infra project provides a simple patch which just keeps the >>>> build-infra-build from failing that can go in with these changes. >>>> >>>> The conversion needs to happen regardless of option. The changes >>>> required are pretty isolated from remaining build-infra work. What do >>>> you think? >>> >>> Either way is fine with me. If build-infra team prefers 2 or 3, please >>> give me the patch, and I will go ahead and merge them to my changeset. >>> >>> Naoto >>> >>>> >>>> Other than that, I have no objections to the review. >>>> >>>> /Erik >>>> >>>>> I'd like to get some advice from Erik on this before saying anything >>>>> further. >>>>> >>>>> -kto >>>>> >>>>> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>>>> Packaging and Adopt Unicode CLDR Data >>>>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>>>> >>>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>>>> >>>>>> The main bug id for this enhancement is: >>>>>> >>>>>> 6336885: RFE: Locale Data Deployment Enhancements >>>>>> >>>>>> Along with this, the following bugs/enhancements are also implemented >>>>>> in this change: >>>>>> >>>>>> 4609153 Provide locale data for Indic locales >>>>>> 5104387 Support for gl_ES locale (galician language) >>>>>> 6337471 desktop/system locale preferences support >>>>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>>>> 7058206 Provide CalendarData SPI for week params and display field >>>>>> value names >>>>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>>>> locale >>>>>> 7079560 [Fmt-Da] Context dependent month names support in >>>>>> SimpleDateFormat >>>>>> 7171324 getAvailableLocales() of locale sensitive services should >>>>>> return the actual availability of locales >>>>>> 7151414 (cal) Support calendar type identification >>>>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>>>> calendar is specified >>>>>> >>>>>> Please note that packaging changes that relate to Jigsaw module >>>>>> system aren't included in this changeset. >>>>>> >>>>>> Naoto Sato and Masayoshi Okutsu >>> >> From naoto.sato at oracle.com Tue Aug 14 21:17:42 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 14 Aug 2012 14:17:42 -0700 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <5029F2C5.6030109@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> <5022D686.9070203@oracle.com> <50297505.7050603@oracle.com> <5029F2C5.6030109@oracle.com> Message-ID: <502AC076.3050809@oracle.com> Thanks, Erik! I incorporated your build-infra changes into the main changeset, and created a new combined webrev as follows: http://cr.openjdk.java.net/~naoto/6336885/webrev.02/ Naoto On 8/13/12 11:40 PM, Erik Joelsson wrote: > I finished making the changes yesterday, but didn't manage to get the > patch completed before I had to run. (webrev and mercurial wouldn't > cooperate). I will get it done asap today. > > /Erik > > On 2012-08-13 23:43, Naoto Sato wrote: >> Since I haven't heard any more comments from Erik/Kelly, I would like >> to push the changeset without the new build infra patch. Erik/Kelly, >> can you please give us an official "GO" in terms of the build related >> changes? >> >> Aside from build changes, I have updated the changeset based on an >> internal review: >> >> http://cr.openjdk.java.net/~naoto/6336885/webrev.01/ >> >> This includes: >> >> - a couple of fixes to the CLDR Converter >> - Added fallback for any bad SPI implementations which return null for >> requested instances. >> >> Still asking for review comments. >> >> Naoto >> >> On 8/8/12 2:13 PM, Naoto Sato wrote: >>> On 8/7/12 2:57 AM, Erik Joelsson wrote: >>>> See inline >>>> >>>> On 2012-07-13 22:20, Kelly O'Hair wrote: >>>>> Something seems strange here: >>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html >>>>> >>>>> >>>>> >>>>> It's like someone was avoiding overall quotes, but using them to add >>>>> spaces somehow... >>>>> I sure would like to get rid of this shell logic, seems like there are >>>>> lots repeated logic that >>>>> this script does over and over or could be done with makefile pattern >>>>> subst's instead of exec's. >>>> The new version isn't any worse than the old in my opinion. In >>>> build-infra, this file is indeed replaced with make logic. After having >>>> decoded both versions I'm confident in converting the changes. >>>>> Overall, just looking at the makefiles, the build-infra team may need >>>>> some time to fully absorb this into the >>>>> new makefiles, some of it will be trivial, not sure all of it will be. >>>>> >>>> I have applied the patch to a clone of build-infra and done the minimal >>>> changes to keep build-infra building, which was rather trivial. The >>>> resulting build has large differences since I haven't converted all of >>>> it yet. There are a couple of things that will require some more work, >>>> but not more than a day or two. >>>>> Not sure how to proceed here, the build-infra team does need an action >>>>> item to deal with this, maybe >>>>> before it gets integrated because I suspect the new makefiles will >>>>> break with all the filename or >>>>> directory changes. But I hate to hold up your integration plans. >>>> I see these as possible options: >>>> >>>> 1. Let this go in, build-infra will break in jdk8 until we do our next >>>> push and it trickles through the repos. >>>> 2. The build-infra project provides a patch with the full conversion >>>> that can go in together with these changes. >>>> 3. The build-infra project provides a simple patch which just keeps the >>>> build-infra-build from failing that can go in with these changes. >>>> >>>> The conversion needs to happen regardless of option. The changes >>>> required are pretty isolated from remaining build-infra work. What do >>>> you think? >>> >>> Either way is fine with me. If build-infra team prefers 2 or 3, please >>> give me the patch, and I will go ahead and merge them to my changeset. >>> >>> Naoto >>> >>>> >>>> Other than that, I have no objections to the review. >>>> >>>> /Erik >>>> >>>>> I'd like to get some advice from Erik on this before saying anything >>>>> further. >>>>> >>>>> -kto >>>>> >>>>> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>>>> Packaging and Adopt Unicode CLDR Data >>>>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>>>> >>>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>>>> >>>>>> The main bug id for this enhancement is: >>>>>> >>>>>> 6336885: RFE: Locale Data Deployment Enhancements >>>>>> >>>>>> Along with this, the following bugs/enhancements are also implemented >>>>>> in this change: >>>>>> >>>>>> 4609153 Provide locale data for Indic locales >>>>>> 5104387 Support for gl_ES locale (galician language) >>>>>> 6337471 desktop/system locale preferences support >>>>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>>>> 7058206 Provide CalendarData SPI for week params and display field >>>>>> value names >>>>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>>>> locale >>>>>> 7079560 [Fmt-Da] Context dependent month names support in >>>>>> SimpleDateFormat >>>>>> 7171324 getAvailableLocales() of locale sensitive services should >>>>>> return the actual availability of locales >>>>>> 7151414 (cal) Support calendar type identification >>>>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>>>> calendar is specified >>>>>> >>>>>> Please note that packaging changes that relate to Jigsaw module >>>>>> system aren't included in this changeset. >>>>>> >>>>>> Naoto Sato and Masayoshi Okutsu >>> >> From ahughes at redhat.com Tue Aug 14 23:08:42 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Tue, 14 Aug 2012 19:08:42 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <502A7EAD.4030209@oracle.com> Message-ID: <56264318.4953126.1344985722489.JavaMail.root@redhat.com> ----- Original Message ----- > On 14/08/2012 14:13, Andrew Hughes wrote: > > Can I take that as it's good to push? :-D > No objection from me although if the default is changed to > SYSTEM_ZLIB=true for Linux (and maybe Solaris) then it will require > making sure that it builds everywhere without needing other options. > I have no plans to do this, and certainly not in this patch. I wouldn't feel comfortable enabling it unless the default was changed to build with shared libraries, as that's what we've tested extensively. >From my side, I think the shared solution is what the average user would expect (on GNU/Linux anyway), as that's what pretty much every other codebase does, and that enabling the static options should be done in the Oracle builds. But that's a whole other debate. The current defaults are a result of the codebase being used (and still being used) to produce proprietary binaries for over ten years and so it's no surprise that there are conflicts with attempting to adapt it to a completely different paradigm. > -Alan. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Wed Aug 15 13:36:16 2012 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 15 Aug 2012 13:36:16 +0000 Subject: hg: jdk8/tl/jdk: 7110151: Use underlying platform's zlib library for Java zlib support Message-ID: <20120815133648.516A647534@hg.openjdk.java.net> Changeset: 35e024c6a62c Author: andrew Date: 2012-08-15 14:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35e024c6a62c 7110151: Use underlying platform's zlib library for Java zlib support Summary: Make SYSTEM_ZLIB more flexible by using ZLIB_{CFLAGS,LIBS} and building on more than just MACOSX. Reviewed-by: sherman, alanb ! make/com/sun/java/pack/Makefile ! make/common/Program.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-macosx.gmk ! make/common/shared/Defs-solaris.gmk ! make/java/jli/Makefile ! make/java/zip/Makefile ! make/jdk_generic_profile.sh ! make/sun/splashscreen/Makefile ! src/share/native/com/sun/java/util/jar/pack/defines.h ! src/share/native/java/util/zip/Adler32.c ! src/share/native/java/util/zip/CRC32.c ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/zip_util.c From Lance.Andersen at oracle.com Wed Aug 15 14:03:21 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 15 Aug 2012 10:03:21 -0400 Subject: RFR: 7056731: Race condition in CORBA code causes re-use of ABORTed connections In-Reply-To: <502A7F01.8050702@oracle.com> References: <502A7F01.8050702@oracle.com> Message-ID: Hi Sean, This looks good. Best Lance On Aug 14, 2012, at 12:38 PM, Se?n Coffey wrote: > I'm looking to forward port this corba fix from 6u34 to jdk8 (and eventually port to 7u) > > d.macdonald at auckland.ac.nz originally reported this issue and I'll be marking the fix as contributed by him. He's already signed the OCA. There's a good description in bug report. We have a race like condition if the corba server is shut down while there are still workers/client threads in a waiting queue waiting for server. The issue arises when the purgeCalls method marks a socket state as ABORTed or CLOSE_RECVD but fails to remove that socket from the socket connectionCache. Fix is to wrap the removal of the socket in a finally block. > > The CorbaResponseWaitingRoomImpl changes are more focused on ensuring that the Map holding these clients is better synchronized. > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.7056731.jdk8/ > bug report : http://bugs.sun.com/view_bug.do?bug_id=7056731 > > Regards, > Sean. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From ahughes at redhat.com Wed Aug 15 14:20:21 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 15 Aug 2012 10:20:21 -0400 (EDT) Subject: PING: [PATCH FOR REVIEW] System Zlib Support In-Reply-To: <502A69F1.4010709@oracle.com> Message-ID: <437649345.5323006.1345040421365.JavaMail.root@redhat.com> ----- Original Message ----- > Yes, you are good to go. > Thanks! Pushed: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35e024c6a62c > Thanks! > -Sherman > > > On 8/14/2012 6:13 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> On 14/08/2012 13:36, Andrew Hughes wrote: > >>> : > >>> > >>> Do you have a static libz.a installed (from zlib1g-dev) and all > >>> dependent static libraries? > >> I think you're right about the static linking but this was just a > >> quick > >> test to see if SYSTEM_ZLIB=true worked with everything else as > >> default. > >> > > Ah right. > > > >> pack200 has C++ so that explains why we see it there and not when > >> building libzip. > >> > > Right. BTW, it appears gcc 4.5 and later have a new option > > -static-libstdc++. > > I don't know if that would work better than the options currently > > used. > > > > http://gcc.gnu.org/gcc-4.5/changes.html > > > >> $ dpkg -s zlib1g-dev > >> Package: zlib1g-dev > >> Status: install ok installed > >> Multi-Arch: same > >> Priority: optional > >> Section: libdevel > >> Installed-Size: 366 > >> Maintainer: Ubuntu Developers > >> > >> Architecture: i386 > >> Source: zlib > >> Version: 1:1.2.3.4.dfsg-3ubuntu4 > >> Provides: libz-dev > >> Depends: zlib1g (= 1:1.2.3.4.dfsg-3ubuntu4), libc6-dev | libc-dev > >> Conflicts: zlib1-dev > >> Description: compression library - development > >> zlib is a library implementing the deflate compression method > >> found > >> in gzip and PKZIP. This package includes the development > >> support > >> files. > >> Homepage: http://zlib.net/ > >> Original-Maintainer: Mark Brown > >> > >> $ apt-file search libz.a > >> lib64z1-dev: /usr/lib64/libz.a > >> zlib1g-dev: /usr/lib/i386-linux-gnu/libz.a > >> > >> $ ls -l /usr/lib/i386-linux-gnu/libz.a > >> -rw-r--r-- 1 root root 98772 Nov 10 2011 > >> /usr/lib/i386-linux-gnu/libz.a > >> > >>> I suspect you'll get the same failure with or without my patch > >>> (though you'll probably need the change > >>> to defines.h to get this far...) > >> SYSTEM_ZLIB is currently Mac only so I wouldn't expect to have got > >> very > >> far without your changes. > > Yes, the defines.h change I refer to is the one that removes the > > Mac > > clause. It fails earlier without that change (I've been hitting it > > on most builds now I have SYSTEM_ZLIB set), so the patch is an > > improvement, even if it doesn't work in all cases. > > > >>> I'd guess you have STATIC_CXX set to true (the default > >>> apparently): > >> I didn't specify any other build options so it's using the > >> default. > >> > > An odd default, though I can understand why, given OpenJDK's > > history. > > > >> BTW: I should mention that I don't have any issues with the patch > >> proposed as it works as it does now because SYSTEM_ZLIB is false. > >> It > >> may > >> be that there is follow-up to allow SYSTEM_ZLIB=true and static > >> linking > >> to work together. > >> > > Can I take that as it's good to push? :-D > > > >> -Alan. > >> > > Thanks, > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From james.holmlund at oracle.com Wed Aug 15 20:49:54 2012 From: james.holmlund at oracle.com (james.holmlund at oracle.com) Date: Wed, 15 Aug 2012 20:49:54 +0000 Subject: hg: jdk8/tl/langtools: 7191449: update copyright year to match last edit in jdk8 langtools repository Message-ID: <20120815204957.4373F4753D@hg.openjdk.java.net> Changeset: 9d47f4850714 Author: jjh Date: 2012-08-15 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 7191449: update copyright year to match last edit in jdk8 langtools repository Reviewed-by: jjh Contributed-by: steve.sides at oracle.com ! make/jprt.properties ! make/tools/anttasks/CompilePropertiesTask.java ! make/tools/anttasks/GenStubsTask.java ! make/tools/anttasks/SelectToolTask.java ! make/tools/compileproperties/CompileProperties.java ! make/tools/genstubs/GenStubs.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh ! test/tools/javac/api/7086261/T7086261.java ! test/tools/javac/api/T6397104.java ! test/tools/javac/diags/CheckExamples.java ! test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java ! test/tools/javac/diags/examples/ApplicableMethodFound1.java ! test/tools/javac/diags/examples/IllegalDot.java ! test/tools/javac/diags/examples/InconvertibleTypes.java ! test/tools/javac/diags/examples/KindnameConstructor.java ! test/tools/javac/diags/examples/NotApplicableMethodFound.java ! test/tools/javac/diags/examples/PossibleLossPrecision.java ! test/tools/javac/diags/examples/ResourceNotApplicableToType.java ! test/tools/javac/diags/examples/VarargsArgumentMismatch.java ! test/tools/javac/diags/examples/VerboseResolveMulti1.java ! test/tools/javac/diags/examples/WhereCaptured.java ! test/tools/javac/diags/examples/WhereCaptured1.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/diags/examples/WhereTypeVar.java ! test/tools/javac/generics/typevars/T7148242.java ! test/tools/javac/newlines/Newlines.sh ! test/tools/javac/parser/T4881269.java ! test/tools/javac/processing/TestWarnErrorCount.java From rob.mckenna at oracle.com Wed Aug 15 21:45:47 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Wed, 15 Aug 2012 21:45:47 +0000 Subject: hg: jdk8/tl/jdk: 6931128: (spec) File attribute tests fail when run as root. Message-ID: <20120815214616.DAD5F4753E@hg.openjdk.java.net> Changeset: da14e2c90bcb Author: robm Date: 2012-08-15 22:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da14e2c90bcb 6931128: (spec) File attribute tests fail when run as root. Reviewed-by: alanb ! src/share/classes/java/io/File.java ! test/java/io/File/Basic.java ! test/java/io/File/SetAccess.java ! test/java/io/File/SetReadOnly.java ! test/java/io/File/SymLinks.java + test/java/io/File/Util.java From rob.mckenna at oracle.com Wed Aug 15 23:09:36 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 16 Aug 2012 00:09:36 +0100 Subject: Request for review: 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 Message-ID: <502C2C30.8050506@oracle.com> Hi folks, One of the tests from 4244896 failed once during nightly testing. It isn't known how much of a delay will be necessary in order for it to pass. In any case the tolerance can't really be loosened much more without making the test meaningless so I've decided to remove it. http://cr.openjdk.java.net/~robm/7191777/webrev.01/ Thanks, -Rob From david.holmes at oracle.com Thu Aug 16 02:18:50 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Aug 2012 12:18:50 +1000 Subject: Request for review: 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 In-Reply-To: <502C2C30.8050506@oracle.com> References: <502C2C30.8050506@oracle.com> Message-ID: <502C588A.1030402@oracle.com> Hi Rob, On 16/08/2012 9:09 AM, Rob McKenna wrote: > Hi folks, > > One of the tests from 4244896 failed once during nightly testing. It > isn't known how much of a delay will be necessary in order for it to > pass. In any case the tolerance can't really be loosened much more > without making the test meaningless so I've decided to remove it. > > http://cr.openjdk.java.net/~robm/7191777/webrev.01/ > Can we not leave the waitFor in place but simply not check how long we waited? That way if it really takes "too long" we hit the default test timeout. David ----- > Thanks, > > -Rob From Alan.Bateman at oracle.com Thu Aug 16 07:19:47 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Aug 2012 08:19:47 +0100 Subject: Request for review: 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 In-Reply-To: <502C588A.1030402@oracle.com> References: <502C2C30.8050506@oracle.com> <502C588A.1030402@oracle.com> Message-ID: <502C9F13.3010006@oracle.com> On 16/08/2012 03:18, David Holmes wrote: > Hi Rob, > > On 16/08/2012 9:09 AM, Rob McKenna wrote: >> Hi folks, >> >> One of the tests from 4244896 failed once during nightly testing. It >> isn't known how much of a delay will be necessary in order for it to >> pass. In any case the tolerance can't really be loosened much more >> without making the test meaningless so I've decided to remove it. >> >> http://cr.openjdk.java.net/~robm/7191777/webrev.01/ >> > > Can we not leave the waitFor in place but simply not check how long we > waited? That way if it really takes "too long" we hit the default test > timeout. That seems a good idea as it also exercises waitFor at around the time that the process is terminating. -Alan. From amy.lu at oracle.com Thu Aug 16 09:24:08 2012 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 16 Aug 2012 17:24:08 +0800 Subject: Code review request 7191892: ProblemList.txt updates (8/2012) Message-ID: <502CBC38.1030103@oracle.com> Following bugs have been resolved, tests have been verified working fine. CR and related tests should be removed from ProblemList: 7149181 [Fix-Delivered]: sun/management/jmxremote/startstop/JMXStartStopTest.sh failing on all platforms 7174532 [Fix-Delivered]: jdk/test/java/lang/Math/WorstCaseTests.java failing on x86 Following test still fail, but the related CR should be 7172176: sun/tools/jconsole/ResourceCheckTest.sh Please review the ProblemList updates: http://cr.openjdk.java.net/~alanb/7191892/webrev/ Thanks, Amy From sean.coffey at oracle.com Thu Aug 16 09:32:58 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 16 Aug 2012 09:32:58 +0000 Subject: hg: jdk8/tl/jdk: 7056731: Race condition in CORBA code causes re-use of ABORTed connections Message-ID: <20120816093349.7EF9C47550@hg.openjdk.java.net> Changeset: 39b01268b845 Author: coffeys Date: 2012-08-16 10:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b01268b845 7056731: Race condition in CORBA code causes re-use of ABORTed connections Reviewed-by: lancea Contributed-by: d.macdonald at auckland.ac.nz ! test/Makefile + test/com/sun/corba/cachedSocket/7056731.sh + test/com/sun/corba/cachedSocket/Hello.idl + test/com/sun/corba/cachedSocket/HelloClient.java + test/com/sun/corba/cachedSocket/HelloServer.java From sean.coffey at oracle.com Thu Aug 16 09:34:28 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 16 Aug 2012 09:34:28 +0000 Subject: hg: jdk8/tl/corba: 7056731: Race condition in CORBA code causes re-use of ABORTed connections Message-ID: <20120816093431.6142B47551@hg.openjdk.java.net> Changeset: 18a02ad8dc73 Author: coffeys Date: 2012-08-16 10:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/18a02ad8dc73 7056731: Race condition in CORBA code causes re-use of ABORTed connections Reviewed-by: lancea Contributed-by: d.macdonald at auckland.ac.nz ! src/share/classes/com/sun/corba/se/impl/transport/CorbaResponseWaitingRoomImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java From sean.coffey at oracle.com Thu Aug 16 09:46:06 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 16 Aug 2012 09:46:06 +0000 Subject: hg: jdk8/tl/jdk: 7185965: Build error in javadoc make stage for bundles not containing crypto package Message-ID: <20120816094633.1DA8047552@hg.openjdk.java.net> Changeset: 56d8756749bd Author: coffeys Date: 2012-08-16 10:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56d8756749bd 7185965: Build error in javadoc make stage for bundles not containing crypto package Reviewed-by: chegar ! make/common/shared/Defs-java.gmk From alan.bateman at oracle.com Thu Aug 16 10:19:54 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Aug 2012 10:19:54 +0000 Subject: hg: jdk8/tl/jdk: 7191556: (fs) UnixNativeDispatcher.getextmntent should be moved into platform specific code Message-ID: <20120816102027.68A4047555@hg.openjdk.java.net> Changeset: e48a9a1c14e3 Author: alanb Date: 2012-08-16 11:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e48a9a1c14e3 7191556: (fs) UnixNativeDispatcher.getextmntent should be moved into platform specific code Reviewed-by: andrew ! make/java/nio/Makefile ! make/java/nio/mapfile-bsd ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/solaris/classes/sun/nio/fs/DefaultFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/native/sun/nio/fs/BsdNativeDispatcher.c ! src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c ! src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c ! src/solaris/native/sun/nio/fs/SolarisNativeDispatcher.c ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c From Alan.Bateman at oracle.com Thu Aug 16 10:34:42 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Aug 2012 11:34:42 +0100 Subject: Code review request 7191892: ProblemList.txt updates (8/2012) In-Reply-To: <502CBC38.1030103@oracle.com> References: <502CBC38.1030103@oracle.com> Message-ID: <502CCCC2.4080406@oracle.com> On 16/08/2012 10:24, Amy Lu wrote: > Following bugs have been resolved, tests have been verified working fine. > CR and related tests should be removed from ProblemList: > > 7149181 [Fix-Delivered]: > sun/management/jmxremote/startstop/JMXStartStopTest.sh failing on all > platforms > 7174532 [Fix-Delivered]: jdk/test/java/lang/Math/WorstCaseTests.java > failing on x86 > > Following test still fail, but the related CR should be 7172176: > sun/tools/jconsole/ResourceCheckTest.sh > > Please review the ProblemList updates: > http://cr.openjdk.java.net/~alanb/7191892/webrev/ Thanks Amy, I realize it's a bit of a chore to keep the exclude list up to date but fingers crossed that someday we will get to the point where we don't have to be excluding tests. I'll push this one for you. -Alan. From alan.bateman at oracle.com Thu Aug 16 10:42:55 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Aug 2012 10:42:55 +0000 Subject: hg: jdk8/tl/jdk: 7191892: ProblemList.txt updates (8/2012) Message-ID: <20120816104317.4D07A47556@hg.openjdk.java.net> Changeset: 4fb8792725d5 Author: alanb Date: 2012-08-16 11:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fb8792725d5 7191892: ProblemList.txt updates (8/2012) Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt From alan.bateman at oracle.com Thu Aug 16 13:35:49 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 16 Aug 2012 13:35:49 +0000 Subject: hg: jdk8/tl/jdk: 7132247: java/rmi/registry/readTest/readTest.sh failing with Cygwin Message-ID: <20120816133612.A8DEF4755A@hg.openjdk.java.net> Changeset: e50a39d011b5 Author: alanb Date: 2012-08-16 14:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e50a39d011b5 7132247: java/rmi/registry/readTest/readTest.sh failing with Cygwin Reviewed-by: alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/rmi/registry/readTest/readTest.sh From neil.richards at ngmr.net Thu Aug 16 15:32:32 2012 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 16 Aug 2012 16:32:32 +0100 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <50237AA8.1040801@oracle.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> <1344362827.27351.22.camel@chalkhill> <50225B8B.4040307@oracle.com> <1344442209.23350.232.camel@chalkhill> <50237AA8.1040801@oracle.com> Message-ID: <1345131152.2980.302.camel@chalkhill> On Thu, 2012-08-09 at 09:54 +0100, Alan Bateman wrote: > On 08/08/2012 17:10, Neil Richards wrote: > > : > > Hi Alan, > > Apologies, I confused myself about the Hotspot behaviour. > > (I was testing with 'nohup', but not checking the contents of > > 'nohup.out' for the output from my registered shutdown hook - doh!). > > > > You're correct, when running with Hotspot with 'nohup', no exception is > > thrown when trying to register a handler for SIGHUP. > > > > When running with J9 with 'nohup', the VM notices that a handler > > registered for SIGHUP is never going to get triggered, so throws the > > exception to notify the caller (of Signal.handle( )) about this. > > > > Regards, > > Neil > This probably comes back to documenting the interface between the VM and > the libraries that you and Steve are working on. In this case, > JVM_RegisterSignal is expected to return 1 when the action is SIG_IGN > where it sounds like J9 is returning -1. > > -Alan. Hi Alan, Thanks for your response. First, I think the discussion on the particular VM implementation behaviour is a slight diversion from Frank's suggested change, which I believe is all about making the Java code more robust / agnostic to the VM implementation behaviour. >From the perspective of the code in Terminator.setup(), I think the pertinent question is: Should the code try to register shutdown hook handlers for other signals if the attempt to register for one signal fails with an exception? Or, to put it another way: Should the registration of the shutdown hook handler for each signal be independent of each other? Frank's suggested change, and my argument, is that these registrations should be independent - i.e. that Terminator.setup() should register shutdown hook handlers for all (shutdown) signals that the system (VM) allows it to. It is self-evident from the Signal.handle() method that it may throw an exception on failure to register a handler - that's declared in its signature, after all - so Terminator.setup() should be coded to robustly handle that condition. Discussions on particular VM implementations' behaviours below Signal.handle() just serves to reinforce the rationale and efficacy of the suggested change, I feel. --- Having said that, and separate from the specifics of Frank's changes, I think it's interesting to consider what is the best behaviour of Signal.handle() (and JVM_RegisterSignal that underpins it). Let's consider the form of sun.misc.Signal.handle() (ignoring access modifiers for simplicity: SignalHandler handle(Signal sig, SignalHandler newHandler) throws IllegalArgumentException; So, it can return a SignalHandler object, or throw an IllegalArgumentException (IAG). If an exception is thrown, it is clear that the SignalHandler given to handle() has not been successfully registered. If, instead, a SignalHandler is returned, the returned value is generally that for the previously registered signal handler - i.e. the one that has just been replaced with the new handler. In J9's case, this is precisely the behaviour it provides: if the new handler is registered, the old handler is returned; if the new handler is not registered, an exception is thrown. However, in Hotspot's case, if the current handler is SIG_IGN, the new handler is not registered, no exception is thrown, and SIG_IGN is returned. So, on the surface, the call seems to have "succeeded", but actually, the new handler has not been registered. This behaviour forces a caller (who's interested in understanding if their new handler is actually getting registered) to understand this extra complexity in behaviour, and to do extra checking around the call to handle() in case it returns SIG_IGN to account for it. That doesn't seem to me like well-designed behaviour for the interface. I don't see any advantage gained in having this extra semantic complexity. Currently, both VMs decide not to replace SIG_IGN with any other handler, even if the SIG_IGN has been set up via a previous call to Signal.handle(). Thus setting a signal to be ignored is a one-way street to a dead end (in a vehicle with no reverse). But note that this behaviour is a choice of the VM (implementer). It isn't inherently the case that signal set to SIG_IGN can't be replaced with another action (at the C level), only that the JVM chooses never to do so. Perhaps in the future, Java might wish to allow the overriding of SIG_IGN signal handlers set up via a previous call to Signal.handle(), whilst respecting the setting if it has genuinely come from the OS / environment. (Also note this isn't only an issue for the HUP signal, either - using "trap '' SIGNUM" can set up (almost) any signal to be ignored.) So I'd submit J9's behaviour for JVM_RegisterSignal would be the better on which to standardize. --- However, I still consider that VM modification would be logically orthogonal to Frank's suggested change, and suggest that his change could continue to be approved for contribution at this point, regardless of the separate VM-related discussion in this area. Please get back to me with your thoughts and comments on any of the above. (If you agree to the separation of concerns I suggest, perhaps the discussion of the VM-related behaviour should be split to a separate thread ?) Regards, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From rob.mckenna at oracle.com Thu Aug 16 16:33:34 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 16 Aug 2012 17:33:34 +0100 Subject: Request for review: 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 In-Reply-To: <502C9F13.3010006@oracle.com> References: <502C2C30.8050506@oracle.com> <502C588A.1030402@oracle.com> <502C9F13.3010006@oracle.com> Message-ID: <502D20DE.6020601@oracle.com> Sounds good: http://cr.openjdk.java.net/~robm/7191777/webrev.02/test/java/lang/ProcessBuilder/Basic.java.cdiff.html -Rob On 16/08/12 08:19, Alan Bateman wrote: > On 16/08/2012 03:18, David Holmes wrote: >> Hi Rob, >> >> On 16/08/2012 9:09 AM, Rob McKenna wrote: >>> Hi folks, >>> >>> One of the tests from 4244896 failed once during nightly testing. It >>> isn't known how much of a delay will be necessary in order for it to >>> pass. In any case the tolerance can't really be loosened much more >>> without making the test meaningless so I've decided to remove it. >>> >>> http://cr.openjdk.java.net/~robm/7191777/webrev.01/ >>> >> >> Can we not leave the waitFor in place but simply not check how long >> we waited? That way if it really takes "too long" we hit the default >> test timeout. > That seems a good idea as it also exercises waitFor at around the time > that the process is terminating. > > -Alan. From david.holmes at oracle.com Thu Aug 16 20:53:28 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Aug 2012 06:53:28 +1000 Subject: Request for review: 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 In-Reply-To: <502D20DE.6020601@oracle.com> References: <502C2C30.8050506@oracle.com> <502C588A.1030402@oracle.com> <502C9F13.3010006@oracle.com> <502D20DE.6020601@oracle.com> Message-ID: <502D5DC8.10502@oracle.com> On 17/08/2012 2:33 AM, Rob McKenna wrote: > Sounds good: > > http://cr.openjdk.java.net/~robm/7191777/webrev.02/test/java/lang/ProcessBuilder/Basic.java.cdiff.html > I think we would want the non-timed version of waitFor. Otherwise the default timeout will never kick in (unless the timing aspect of waitFor is broken). Hmmm - can't test two things at once. See what Alan says. :) David > > -Rob > > On 16/08/12 08:19, Alan Bateman wrote: >> On 16/08/2012 03:18, David Holmes wrote: >>> Hi Rob, >>> >>> On 16/08/2012 9:09 AM, Rob McKenna wrote: >>>> Hi folks, >>>> >>>> One of the tests from 4244896 failed once during nightly testing. It >>>> isn't known how much of a delay will be necessary in order for it to >>>> pass. In any case the tolerance can't really be loosened much more >>>> without making the test meaningless so I've decided to remove it. >>>> >>>> http://cr.openjdk.java.net/~robm/7191777/webrev.01/ >>>> >>> >>> Can we not leave the waitFor in place but simply not check how long >>> we waited? That way if it really takes "too long" we hit the default >>> test timeout. >> That seems a good idea as it also exercises waitFor at around the time >> that the process is terminating. >> >> -Alan. > From kumar.x.srinivasan at oracle.COM Thu Aug 16 21:16:26 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 16 Aug 2012 14:16:26 -0700 Subject: Please review: 7190750 (pack200) the java unpacker produces non spec. compliant classfile with lambda classfiles Message-ID: <502D632A.5050306@oracle.COM> Hi, fyi. already reviewed by John Rose. http://cr.openjdk.java.net/~ksrini/7190750/webrev.0/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7190750 Thanks Kumar From huizhe.wang at oracle.com Fri Aug 17 04:07:55 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 16 Aug 2012 21:07:55 -0700 Subject: RFR [7u8] (JAXP): 7191547 : XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work as expected Message-ID: <502DC39B.9050400@oracle.com> In the patch for 6756677, we fixed errors in StAX's input and output factories where factoryId such as 'javax.xml.stream.XMLInputFactory" was taken as factory class e.g. com.sun.xml.internal.stream.XMLInputFactoryImpl. Unfortunately, we missed XMLEventFactory in that patch. So this is a patch for XMLEventFactory similar to that of XMLInputFactory and XMLOutputFactory. The change itself is to search an implementation class using the provided factory id instead of trying to create a instance directly. The webrev is here: http://cr.openjdk.java.net/~joehw/7u8/7191547/webrev/ All tests pass except two XMLEventFactory tests that assumed the factoryId to mean factory class. They will be updated once this patch is approved. Thanks, Joe From Alan.Bateman at oracle.com Fri Aug 17 08:58:07 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Aug 2012 09:58:07 +0100 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <1345131152.2980.302.camel@chalkhill> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> <1344362827.27351.22.camel@chalkhill> <50225B8B.4040307@oracle.com> <1344442209.23350.232.camel@chalkhill> <50237AA8.1040801@oracle.com> <1345131152.2980.302.camel@chalkhill> Message-ID: <502E079F.1080706@oracle.com> On 16/08/2012 16:32, Neil Richards wrote: > : > > First, I think the discussion on the particular VM implementation > behaviour is a slight diversion from Frank's suggested change, which I > believe is all about making the Java code more robust / agnostic to the > VM implementation behaviour. I think it was important to get some context as it was missing in the original mails. > > > From the perspective of the code in Terminator.setup(), I think the > pertinent question is: > Should the code try to register shutdown hook handlers for other > signals if the attempt to register for one signal fails with an > exception? > Or, to put it another way: > Should the registration of the shutdown hook handler for each > signal be independent of each other? > > Frank's suggested change, and my argument, is that these registrations > should be independent - i.e. that Terminator.setup() should register > shutdown hook handlers for all (shutdown) signals that the system (VM) > allows it to. I think we're in agreement on that. On JVM_RegisterSignal then it returns -1 if the signal is in use by the VM or there is an error examining/changing the action. If the signal is ignored (existing action is SIG_IGN) then it just returns SIG_IGN without attempting to change it. It probably should have defined a specific error for this case as the caller can't distinguish it from the case that the action was changed and the previous action was SIG_IGN. If there was an error for this case then sun.misc.Signal could have mapped it to an exception, perhaps IllegalStateException. Whether it's worth changing this now isn't clear to me but changing it is potentially disruptive. Disruptive meaning that it would change the behavior of sun.misc.Signal so that it would throw an exception for a case where it doesn't do so today. Folks shouldn't be using sun.misc.Signal of course but we know that they do. > : > > However, I still consider that VM modification would be logically > orthogonal to Frank's suggested change, and suggest that his change > could continue to be approved for contribution at this point, regardless > of the separate VM-related discussion in this area. > Both David and I have already reviewed Frank's change and okay with it. I'll leave it to you whether you want to propose a change to JVM_RegisterSignal. -Alan From luchsh at linux.vnet.ibm.com Fri Aug 17 09:15:38 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Fri, 17 Aug 2012 09:15:38 +0000 Subject: hg: jdk8/tl/jdk: 7191275: Cleanup OS specific blocks in PlainDatagramSocketImpl.c to support more unix-like platforms Message-ID: <20120817091746.C6ED04759F@hg.openjdk.java.net> Changeset: 4993f8aa7f2e Author: dingxmin Date: 2012-08-17 17:10 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4993f8aa7f2e 7191275: Cleanup OS specific blocks in PlainDatagramSocketImpl.c to support more unix-like platforms Reviewed-by: chegar ! src/solaris/native/java/net/PlainDatagramSocketImpl.c From i30817 at gmail.com Fri Aug 17 10:08:26 2012 From: i30817 at gmail.com (Paulo Levi) Date: Fri, 17 Aug 2012 11:08:26 +0100 Subject: LinkedHashMap containsKeyBetween(K target, K low, K high) method? Message-ID: I tried to make a LinkedHashMap.subMap(K low, K high) with a map implementation i had implemented inspired by linked list where the map keeps linked Nodes as values and unwraps them on get() I failed of course, because i couldn't find a good way to deal with remove() on the original Map. The sublist implementation on the JDK depends on a modification counter to make sure no concurrent modifications from using the original list while the sublist is being used occur, which is fine for the linked list. However a submap needs to limit their get() on a different way from linkedlist since it can't just check for range - though about adding a index to the nodes but that's obviously wrong since any remove from the map would ruin efficient size() if based on those indexes (even removes from before submap construction). So i got less ambitious: public boolean containsKeyBetween(K target, K low, K high){ if(isEmpty()) return false; Node targetN = delegate.get(target); if(targetN == null) return false; Node highN, lowN; if(low == null) lowN = head.next; else lowN = delegate.get(low); if(high == null) highN = head.previous; else highN = delegate.get(high); return lowN != null && highN != null && lowN.index <= targetN.index && targetN.index <= highN.index; } Node needs a monotonically increasing int index created when put(). I don't actually think it needs the forward and backwards links (i was just reusing code), but LinkedHashMap/Set (where it would be useful), use them already. Is a method like this suitable for the JDK LinkedMap/Set? From Alan.Bateman at oracle.com Fri Aug 17 11:46:45 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Aug 2012 12:46:45 +0100 Subject: Request for review: 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 In-Reply-To: <502D5DC8.10502@oracle.com> References: <502C2C30.8050506@oracle.com> <502C588A.1030402@oracle.com> <502C9F13.3010006@oracle.com> <502D20DE.6020601@oracle.com> <502D5DC8.10502@oracle.com> Message-ID: <502E2F25.8070008@oracle.com> On 16/08/2012 21:53, David Holmes wrote: > On 17/08/2012 2:33 AM, Rob McKenna wrote: >> Sounds good: >> >> http://cr.openjdk.java.net/~robm/7191777/webrev.02/test/java/lang/ProcessBuilder/Basic.java.cdiff.html >> >> >> > > I think we would want the non-timed version of waitFor. Otherwise the > default timeout will never kick in (unless the timing aspect of > waitFor is broken). Hmmm - can't test two things at once. See what > Alan says. :) Alan says we should not spend too much time on this :-) I think what is in the webrev is fine. This part of the test is exercising the waitFor(timeout) method so I'd leave it at that. If nothing else it exercises the code for the case where the process is terminating at just around the time that the waitFor(timeout) method is called. -Alan From i30817 at gmail.com Fri Aug 17 14:58:02 2012 From: i30817 at gmail.com (Paulo Levi) Date: Fri, 17 Aug 2012 15:58:02 +0100 Subject: LinkedHashMap containsKeyBetween(K target, K low, K high) method? In-Reply-To: References: Message-ID: Never mind about this, found a much better way (just for sets i think) by using a Integer as value as HashSet uses booleans as values and a delegate LinkedHashMap. Works for implementing < and > as long and i'm careful not to loose the old value in add(). From Lance.Andersen at oracle.com Fri Aug 17 15:26:27 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 17 Aug 2012 11:26:27 -0400 Subject: RFR [7u8] (JAXP): 7191547 : XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work as expected In-Reply-To: <502DC39B.9050400@oracle.com> References: <502DC39B.9050400@oracle.com> Message-ID: Hi Joe, Looks fine. Best Lance On Aug 17, 2012, at 12:07 AM, Joe Wang wrote: > In the patch for 6756677, we fixed errors in StAX's input and output factories where factoryId such as 'javax.xml.stream.XMLInputFactory" was taken as factory class e.g. com.sun.xml.internal.stream.XMLInputFactoryImpl. Unfortunately, we missed XMLEventFactory in that patch. > > So this is a patch for XMLEventFactory similar to that of XMLInputFactory and XMLOutputFactory. The change itself is to search an implementation class using the provided factory id instead of trying to create a instance directly. > > The webrev is here: http://cr.openjdk.java.net/~joehw/7u8/7191547/webrev/ > > All tests pass except two XMLEventFactory tests that assumed the factoryId to mean factory class. They will be updated once this patch is approved. > > Thanks, > Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Fri Aug 17 15:51:13 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 17 Aug 2012 08:51:13 -0700 Subject: RFR [7u8] (JAXP): 7191547 : XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work as expected In-Reply-To: References: <502DC39B.9050400@oracle.com> Message-ID: <502E6871.9090102@oracle.com> Thanks, Lance! On 8/17/2012 8:26 AM, Lance Andersen - Oracle wrote: > Hi Joe, > > Looks fine. > > Best > Lance > On Aug 17, 2012, at 12:07 AM, Joe Wang wrote: > >> In the patch for 6756677, we fixed errors in StAX's input and output >> factories where factoryId such as 'javax.xml.stream.XMLInputFactory" >> was taken as factory class e.g. >> com.sun.xml.internal.stream.XMLInputFactoryImpl. Unfortunately, we >> missed XMLEventFactory in that patch. >> >> So this is a patch for XMLEventFactory similar to that of >> XMLInputFactory and XMLOutputFactory. The change itself is to search >> an implementation class using the provided factory id instead of >> trying to create a instance directly. >> >> The webrev is here: >> http://cr.openjdk.java.net/~joehw/7u8/7191547/webrev/ >> >> >> All tests pass except two XMLEventFactory tests that assumed the >> factoryId to mean factory class. They will be updated once this patch >> is approved. >> >> Thanks, >> Joe >> > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > From huizhe.wang at oracle.com Fri Aug 17 16:47:27 2012 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Fri, 17 Aug 2012 16:47:27 +0000 Subject: hg: jdk8/tl/jaxp: 7191547: XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work as expected Message-ID: <20120817164731.96CBA475B1@hg.openjdk.java.net> Changeset: 2946807a6d7f Author: joehw Date: 2012-08-17 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2946807a6d7f 7191547: XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work as expected Summary: similar to the patch for 6756677 for XMLInputFactory and XMLOutputFactory, this patch fixes an error in XMLEventFactory where factoryId was taken as factory class. Reviewed-by: lancea ! src/javax/xml/stream/XMLEventFactory.java From sean.mullan at oracle.com Fri Aug 17 18:36:09 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 17 Aug 2012 18:36:09 +0000 Subject: hg: jdk8/tl/jdk: 6500133: REGRESSION: CertificateParsingException for CRL Distribution Point with blank Message-ID: <20120817183630.404F8475B3@hg.openjdk.java.net> Changeset: 6b2ebf3c4964 Author: mullan Date: 2012-08-17 14:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b2ebf3c4964 6500133: REGRESSION: CertificateParsingException for CRL Distribution Point with blank Reviewed-by: mullan Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/x509/URIName.java + test/sun/security/x509/URIName/Parse.java From daniel.daugherty at oracle.com Fri Aug 17 19:53:33 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 17 Aug 2012 19:53:33 +0000 Subject: hg: jdk8/tl/jdk: 7191322: add test for 7064927 to java.lang.instrument Message-ID: <20120817195352.E35B9475B6@hg.openjdk.java.net> Changeset: 509421263cdd Author: dcubed Date: 2012-08-17 12:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/509421263cdd 7191322: add test for 7064927 to java.lang.instrument Summary: Add support for canRetransform attribute to the test manager. Add test for 7064927. Reviewed-by: dsamersoff, sspitsyn, ohair ! test/java/lang/instrument/ATransformerManagementTestCase.java + test/java/lang/instrument/DummyClassWithLVT.java + test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java + test/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh + test/java/lang/instrument/retransformAgent.mf From jonathan.gibbons at oracle.com Sat Aug 18 00:30:26 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 18 Aug 2012 00:30:26 +0000 Subject: hg: jdk8/tl/langtools: 7192449: fix up tests to accommodate jtreg spec change Message-ID: <20120818003031.31DB1475B9@hg.openjdk.java.net> Changeset: 5ac2e9ee969e Author: jjg Date: 2012-08-17 17:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5ac2e9ee969e 7192449: fix up tests to accommodate jtreg spec change Reviewed-by: darcy ! test/tools/javac/processing/6414633/T6414633.java ! test/tools/javac/processing/options/testPrintProcessorInfo/TestWithXstdout.java From kumar.x.srinivasan at oracle.com Sat Aug 18 12:17:11 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Sat, 18 Aug 2012 12:17:11 +0000 Subject: hg: jdk8/tl/jdk: 7190750: (pack200) the java unpacker produces non spec. compliant classfile with lambda classfiles Message-ID: <20120818121739.E1A6F475C3@hg.openjdk.java.net> Changeset: 16f2865aac24 Author: ksrini Date: 2012-08-17 08:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/16f2865aac24 7190750: (pack200) the java unpacker produces non spec. compliant classfile with lambda classfiles Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java From alan.bateman at oracle.com Sun Aug 19 12:06:11 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Aug 2012 12:06:11 +0000 Subject: hg: jdk8/tl/jdk: 7192275: Minimize LogManager dependencies on java.beans Message-ID: <20120819120704.462214762F@hg.openjdk.java.net> Changeset: a2359f0f9533 Author: alanb Date: 2012-08-19 13:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2359f0f9533 7192275: Minimize LogManager dependencies on java.beans Summary: Reduce dependency to PropertyChangeListener and PropertyChangeEvent. Also add basic test coverage. Reviewed-by: dcubed, dsamersoff, mchung ! src/share/classes/java/util/logging/LogManager.java + test/java/util/logging/Listeners.java + test/java/util/logging/ListenersWithSM.java + test/java/util/logging/java.policy From alan.bateman at oracle.com Sun Aug 19 12:30:25 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 19 Aug 2012 12:30:25 +0000 Subject: hg: jdk8/tl/jdk: 7191467: (fs) WatchService periodically fails to queue ENTRY_DELETE event for short lived file [sol11] Message-ID: <20120819123045.5436247630@hg.openjdk.java.net> Changeset: 5e7cfe034df4 Author: alanb Date: 2012-08-19 13:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e7cfe034df4 7191467: (fs) WatchService periodically fails to queue ENTRY_DELETE event for short lived file [sol11] Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! test/java/nio/file/WatchService/MayFlies.java From weijun.wang at oracle.com Mon Aug 20 00:00:18 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 20 Aug 2012 00:00:18 +0000 Subject: hg: jdk8/tl/jdk: 7192202: Make sure keytool prints both unknown and unparseable extensions Message-ID: <20120820000050.9204147635@hg.openjdk.java.net> Changeset: 86c963b1dbf8 Author: weijun Date: 2012-08-20 07:59 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86c963b1dbf8 7192202: Make sure keytool prints both unknown and unparseable extensions Reviewed-by: mullan + test/sun/security/tools/keytool/UnknownAndUnparseable.java From yiming.wang at oracle.com Mon Aug 20 08:18:22 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Mon, 20 Aug 2012 16:18:22 +0800 Subject: CR 6899850 Updated, jeff.dinkins now responsible manager, P4 java/classes_util TESTBUG: DateRegression fails with "Date hashCode misbehaves" In-Reply-To: <502F42A7.6040601@oracle.com> References: <11051417.1345119908430.JavaMail.sbladm@swsblss4-new.central.sun.com> <502D28A2.6040005@oracle.com> <502D29B9.5020402@oracle.com> <502F42A7.6040601@oracle.com> Message-ID: <5031F2CE.3090908@oracle.com> Hi Alan, Please review the code changes http://dl.dropbox.com/u/90659131/fixes/6899850/webrev/java/util/Date/DateRegression.java.udiff.html As described in monaco, this bug is caused by wrong assumption that precision of Date is second instead of millionsecond. If you think OK, I'll send a formal request. This is a closed test, which group can review it? Regards, Eric On 2012/8/18 15:22, Alan Bateman wrote: > > Eric - is this a test bug that could be added to your list? It seems > the chances of running into this issue is very low but intermittent > failures are killing us then maybe we should just fix this while it is > fresh in our minds. > > (Naoto - I should explain that Eric Wang is in the SQE team and has > been spending some time on fixing several of our regression tests that > we excluded, by putting down on ProblemList). > > -Alan > > > On 16/08/2012 18:11, Alan Bateman wrote: >> On 16/08/2012 18:06, Naoto Sato wrote: >>> Hi Alan, >>> >>> Not directly related to this bug, but I am just curious. I've been >>> running JPRT jdk8 jobs with "-testset core" option, but have never >>> seen this failure. Is the setting for TL nightly build different >>> from JPRT's? >>> >>> Naoto >>> >> TL nightly runs the tests the same way as JPRT. I don't think we've >> seen it fail before, I guess we just got lucky. >> >> -Alan >> > From chris.hegarty at oracle.com Mon Aug 20 08:47:40 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 20 Aug 2012 09:47:40 +0100 Subject: CR 6899850 Updated, jeff.dinkins now responsible manager, P4 java/classes_util TESTBUG: DateRegression fails with "Date hashCode misbehaves" In-Reply-To: <5031F2CE.3090908@oracle.com> References: <11051417.1345119908430.JavaMail.sbladm@swsblss4-new.central.sun.com> <502D28A2.6040005@oracle.com> <502D29B9.5020402@oracle.com> <502F42A7.6040601@oracle.com> <5031F2CE.3090908@oracle.com> Message-ID: <5031F9AC.4060503@oracle.com> Eric, The changes look fine to me. You can list me as reviewer, but Naoto and Alan may also want to take a quick look. -Chris. On 20/08/12 09:18, Eric Wang wrote: > Hi Alan, > > Please review the code changes > http://dl.dropbox.com/u/90659131/fixes/6899850/webrev/java/util/Date/DateRegression.java.udiff.html > > As described in monaco, this bug is caused by wrong assumption that > precision of Date is second instead of millionsecond. > If you think OK, I'll send a formal request. This is a closed test, > which group can review it? > > Regards, > Eric > > On 2012/8/18 15:22, Alan Bateman wrote: >> >> Eric - is this a test bug that could be added to your list? It seems >> the chances of running into this issue is very low but intermittent >> failures are killing us then maybe we should just fix this while it is >> fresh in our minds. >> >> (Naoto - I should explain that Eric Wang is in the SQE team and has >> been spending some time on fixing several of our regression tests that >> we excluded, by putting down on ProblemList). >> >> -Alan >> >> >> On 16/08/2012 18:11, Alan Bateman wrote: >>> On 16/08/2012 18:06, Naoto Sato wrote: >>>> Hi Alan, >>>> >>>> Not directly related to this bug, but I am just curious. I've been >>>> running JPRT jdk8 jobs with "-testset core" option, but have never >>>> seen this failure. Is the setting for TL nightly build different >>>> from JPRT's? >>>> >>>> Naoto >>>> >>> TL nightly runs the tests the same way as JPRT. I don't think we've >>> seen it fail before, I guess we just got lucky. >>> >>> -Alan >>> >> > From rob.mckenna at oracle.com Mon Aug 20 13:50:34 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Mon, 20 Aug 2012 13:50:34 +0000 Subject: hg: jdk8/tl/jdk: 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 Message-ID: <20120820135100.E98944763F@hg.openjdk.java.net> Changeset: 59aa7660ade4 Author: robm Date: 2012-08-20 14:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59aa7660ade4 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 Reviewed-by: dholmes, alanb ! test/java/lang/ProcessBuilder/Basic.java From sundararajan.athijegannathan at oracle.com Mon Aug 20 15:52:11 2012 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 20 Aug 2012 15:52:11 +0000 Subject: hg: jdk8/tl/langtools: 7181320: javac NullPointerException for switch labels with cast to String expressions Message-ID: <20120820155215.0C83D47641@hg.openjdk.java.net> Changeset: 464f52f59f7d Author: sundar Date: 2012-08-20 21:24 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/464f52f59f7d 7181320: javac NullPointerException for switch labels with cast to String expressions Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/StringsInSwitch/7181320/BinOpInCaseLabel.java + test/tools/javac/StringsInSwitch/7181320/CastInCaseLabel.java + test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel.java + test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel1.java + test/tools/javac/StringsInSwitch/7181320/CondExprInCaseLabel2.java From naoto.sato at oracle.com Mon Aug 20 16:26:27 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 20 Aug 2012 09:26:27 -0700 Subject: CR 6899850 Updated, jeff.dinkins now responsible manager, P4 java/classes_util TESTBUG: DateRegression fails with "Date hashCode misbehaves" In-Reply-To: <5031F9AC.4060503@oracle.com> References: <11051417.1345119908430.JavaMail.sbladm@swsblss4-new.central.sun.com> <502D28A2.6040005@oracle.com> <502D29B9.5020402@oracle.com> <502F42A7.6040601@oracle.com> <5031F2CE.3090908@oracle.com> <5031F9AC.4060503@oracle.com> Message-ID: <50326533.8040104@oracle.com> Looks good to me too. Naoto On 2012/08/20 1:47, Chris Hegarty wrote: > Eric, > > The changes look fine to me. You can list me as reviewer, but Naoto and > Alan may also want to take a quick look. > > -Chris. > > On 20/08/12 09:18, Eric Wang wrote: >> Hi Alan, >> >> Please review the code changes >> http://dl.dropbox.com/u/90659131/fixes/6899850/webrev/java/util/Date/DateRegression.java.udiff.html >> >> >> As described in monaco, this bug is caused by wrong assumption that >> precision of Date is second instead of millionsecond. >> If you think OK, I'll send a formal request. This is a closed test, >> which group can review it? >> >> Regards, >> Eric >> >> On 2012/8/18 15:22, Alan Bateman wrote: >>> >>> Eric - is this a test bug that could be added to your list? It seems >>> the chances of running into this issue is very low but intermittent >>> failures are killing us then maybe we should just fix this while it is >>> fresh in our minds. >>> >>> (Naoto - I should explain that Eric Wang is in the SQE team and has >>> been spending some time on fixing several of our regression tests that >>> we excluded, by putting down on ProblemList). >>> >>> -Alan >>> >>> >>> On 16/08/2012 18:11, Alan Bateman wrote: >>>> On 16/08/2012 18:06, Naoto Sato wrote: >>>>> Hi Alan, >>>>> >>>>> Not directly related to this bug, but I am just curious. I've been >>>>> running JPRT jdk8 jobs with "-testset core" option, but have never >>>>> seen this failure. Is the setting for TL nightly build different >>>>> from JPRT's? >>>>> >>>>> Naoto >>>>> >>>> TL nightly runs the tests the same way as JPRT. I don't think we've >>>> seen it fail before, I guess we just got lucky. >>>> >>>> -Alan >>>> >>> >> From naoto.sato at oracle.com Mon Aug 20 17:14:18 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 20 Aug 2012 10:14:18 -0700 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <84F7A368-1206-4D3C-A79F-9F2C6F8EC719@oracle.com> References: <737597189.4451353.1344937908713.JavaMail.root@redhat.com> <84F7A368-1206-4D3C-A79F-9F2C6F8EC719@oracle.com> Message-ID: <5032706A.8060007@oracle.com> I have updated the changeset by removing the copyright headers from all of the CLDR files, and added a LICENSE file at the top of CLDR source directory (src/share/classes/sun/util/cldr/resources/21_0_1). No other changes have been made this time. http://cr.openjdk.java.net/~naoto/6336885/webrev.03/ Naoto On H.24/08/14 9:16, Jeff Dinkins wrote: > > Andrew - good catch. We're reviewing. > > On Aug 14, 2012, at 2:51 AM, Andrew Hughes wrote: >> ----- Original Message ----- >>> Hello, >>> >>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>> Packaging and Adopt Unicode CLDR Data >>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>> >>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>> >>> The main bug id for this enhancement is: >>> >>> 6336885: RFE: Locale Data Deployment Enhancements >>> >>> Along with this, the following bugs/enhancements are also implemented >>> in >>> this change: >>> >>> 4609153 Provide locale data for Indic locales >>> 5104387 Support for gl_ES locale (galician language) >>> 6337471 desktop/system locale preferences support >>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>> 7058206 Provide CalendarData SPI for week params and display field >>> value >>> names >>> 7073852 Support multiple scripts for digits and decimal symbols per >>> locale >>> 7079560 [Fmt-Da] Context dependent month names support in >>> SimpleDateFormat >>> 7171324 getAvailableLocales() of locale sensitive services should >>> return >>> the actual availability of locales >>> 7151414 (cal) Support calendar type identification >>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>> 7171372 (cal) locale's default Calendar should be created if unknown >>> calendar is specified >>> >>> Please note that packaging changes that relate to Jigsaw module >>> system >>> aren't included in this changeset. >>> >>> Naoto Sato and Masayoshi Okutsu >>> >> >> First of all, I'd like to say congratulations on completing this week and >> adopting the CLDR as a source for locale data. This is something we've used >> for GNU Classpath's locale data for many years, and, with these changes, it >> should mean that the Java API itself should see changes which allow it to >> support some of the features present in the CLDR data. >> >> However, I am a little concerned by the inclusion of CLDR data files in this >> webrev with a GPL header assigning copyright to Oracle e.g. >> >> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq.xml.patch >> >> Is this legal? IANAL, but http://unicode.org/copyright.html#Exhibit1 seems to >> state that the header given there should be present on this data. The current >> files make it look like this data was created by Oracle this year, which is clearly >> inaccurate. >> >> Thanks, >> -- >> Andrew :) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: 248BDC07 (https://keys.indymedia.org/) >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >> > From jonathan.gibbons at oracle.com Mon Aug 20 20:50:39 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 20 Aug 2012 20:50:39 +0000 Subject: hg: jdk8/tl/langtools: 7192744: fix up tests to accommodate jtreg spec change Message-ID: <20120820205043.5BB7B4764C@hg.openjdk.java.net> Changeset: 37008b4cd97a Author: jjg Date: 2012-08-20 13:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/37008b4cd97a 7192744: fix up tests to accommodate jtreg spec change Reviewed-by: darcy ! test/tools/javac/processing/6348499/T6348499.java ! test/tools/javac/processing/T6920317.java From alan.bateman at oracle.com Tue Aug 21 12:45:35 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 21 Aug 2012 12:45:35 +0000 Subject: hg: jdk8/tl/jdk: 7132889: (se) AbstractSelectableChannel.register and configureBlocking not safe from asynchronous close Message-ID: <20120821124603.52E8E4765B@hg.openjdk.java.net> Changeset: 6d29c2af040f Author: alanb Date: 2012-08-21 13:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d29c2af040f 7132889: (se) AbstractSelectableChannel.register and configureBlocking not safe from asynchronous close Reviewed-by: alanb Contributed-by: Shirish Kuncolienkar ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java + test/java/nio/channels/SelectionKey/RacyRegister.java From yuka.kamiya at oracle.com Tue Aug 21 13:21:09 2012 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Tue, 21 Aug 2012 22:21:09 +0900 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <5032706A.8060007@oracle.com> References: <737597189.4451353.1344937908713.JavaMail.root@redhat.com> <84F7A368-1206-4D3C-A79F-9F2C6F8EC719@oracle.com> <5032706A.8060007@oracle.com> Message-ID: <50338B45.4050906@oracle.com> Hi, It looks good to me. Thanks, -- Yuka (12/08/21 2:14), Naoto Sato wrote: > I have updated the changeset by removing the copyright headers from all of the CLDR files, and added a LICENSE file at the top of CLDR source directory (src/share/classes/sun/util/cldr/resources/21_0_1). No other changes have been made this time. > > http://cr.openjdk.java.net/~naoto/6336885/webrev.03/ > > Naoto > > On H.24/08/14 9:16, Jeff Dinkins wrote: >> >> Andrew - good catch. We're reviewing. >> >> On Aug 14, 2012, at 2:51 AM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Hello, >>>> >>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>> Packaging and Adopt Unicode CLDR Data >>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>> >>>> The main bug id for this enhancement is: >>>> >>>> 6336885: RFE: Locale Data Deployment Enhancements >>>> >>>> Along with this, the following bugs/enhancements are also implemented >>>> in >>>> this change: >>>> >>>> 4609153 Provide locale data for Indic locales >>>> 5104387 Support for gl_ES locale (galician language) >>>> 6337471 desktop/system locale preferences support >>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>> 7058206 Provide CalendarData SPI for week params and display field >>>> value >>>> names >>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>> locale >>>> 7079560 [Fmt-Da] Context dependent month names support in >>>> SimpleDateFormat >>>> 7171324 getAvailableLocales() of locale sensitive services should >>>> return >>>> the actual availability of locales >>>> 7151414 (cal) Support calendar type identification >>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>> calendar is specified >>>> >>>> Please note that packaging changes that relate to Jigsaw module >>>> system >>>> aren't included in this changeset. >>>> >>>> Naoto Sato and Masayoshi Okutsu >>>> >>> >>> First of all, I'd like to say congratulations on completing this week and >>> adopting the CLDR as a source for locale data. This is something we've used >>> for GNU Classpath's locale data for many years, and, with these changes, it >>> should mean that the Java API itself should see changes which allow it to >>> support some of the features present in the CLDR data. >>> >>> However, I am a little concerned by the inclusion of CLDR data files in this >>> webrev with a GPL header assigning copyright to Oracle e.g. >>> >>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq.xml.patch >>> >>> Is this legal? IANAL, but http://unicode.org/copyright.html#Exhibit1 seems to >>> state that the header given there should be present on this data. The current >>> files make it look like this data was created by Oracle this year, which is clearly >>> inaccurate. >>> >>> Thanks, >>> -- >>> Andrew :) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> PGP Key: 248BDC07 (https://keys.indymedia.org/) >>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>> >> > From fuyou001 at gmail.com Tue Aug 21 15:36:36 2012 From: fuyou001 at gmail.com (Fuyou001) Date: Tue, 21 Aug 2012 23:36:36 +0800 Subject: Fwd: rmi network traffic References: Message-ID: ???? iPhone ????????? > ???: fuyou > ??: 2012?8?21? ????????+080016?11?14? > ???: core-libs-dev-request at openjdk.java.net > ??: rmi network traffic > > Hi all > I deploy a RMI Service ,write a RMI Client(J2SE project) to access it and is ok .but the some code in web project,I use wireshark to find that every RMI request sent from our client to our server containing the list of all jars in the classpath for the application, My problem is similar to bugs.sun.com > How to slove it ? > Thanks a lot > > -- > ============================================= > fuyou001 > Best Regards > > From fuyou001 at gmail.com Tue Aug 21 15:47:39 2012 From: fuyou001 at gmail.com (Fuyou001) Date: Tue, 21 Aug 2012 23:47:39 +0800 Subject: rmi network traffic References: Message-ID: <75C65AFC-A14B-4C77-8702-27E8E08DB829@gmail.com> > > Hi all > I deploy a RMI Service ,write a RMI Client(J2SE project) to access it and is ok .but the some code in web project,I use wireshark to find that every RMI request sent from our client to our server containing the list of all jars in the classpath for the application, My problem is similar to bugs.sun.com > How to slove it ? > Thanks a lot > > -- > ============================================= > fuyou001 > Best Regards > > From fuyou001 at gmail.com Tue Aug 21 16:04:06 2012 From: fuyou001 at gmail.com (Fuyou001) Date: Wed, 22 Aug 2012 00:04:06 +0800 Subject: rmi network traffic References: <75C65AFC-A14B-4C77-8702-27E8E08DB829@gmail.com> Message-ID: <8CCADD03-03ED-4B29-8136-81626E607B46@gmail.com> >> >> Hi all >> I deploy a RMI Service ,write a RMI Client(J2SE project) to access it and is ok .but the some code in web project,I use wireshark to find that every RMI request sent from our client to our server containing the list of all jars in the classpath for the application, My problem is similar to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6664389 >> How to slove it ? >> Thanks a lot >> >> -- >> ============================================= >> fuyou001 >> Best Regards >> >> From darryl.mocek at oracle.com Tue Aug 21 16:37:17 2012 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Tue, 21 Aug 2012 09:37:17 -0700 Subject: rmi network traffic In-Reply-To: <8CCADD03-03ED-4B29-8136-81626E607B46@gmail.com> References: <75C65AFC-A14B-4C77-8702-27E8E08DB829@gmail.com> <8CCADD03-03ED-4B29-8136-81626E607B46@gmail.com> Message-ID: <5033B93D.8030403@oracle.com> Fuyou001, the problem was fixed in Java 6u10. Which version of Java are you using? If you upgrade to 6u10 or later, the problem should be solved. Darryl On 08/21/2012 09:04 AM, Fuyou001 wrote: >>> Hi all >>> I deploy a RMI Service ,write a RMI Client(J2SE project) to access it and is ok .but the some code in web project,I use wireshark to find that every RMI request sent from our client to our server containing the list of all jars in the classpath for the application, My problem is similar to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6664389 >>> How to slove it ? >>> Thanks a lot >>> >>> -- >>> ============================================= >>> fuyou001 >>> Best Regards >>> >>> From naoto.sato at oracle.com Tue Aug 21 18:03:47 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 21 Aug 2012 18:03:47 +0000 Subject: hg: jdk8/tl/jdk: 6336885: RFE: Locale Data Deployment Enhancements; ... Message-ID: <20120821180407.CD1CF4766A@hg.openjdk.java.net> Changeset: 131a683a2ce0 Author: naoto Date: 2012-08-21 11:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/131a683a2ce0 6336885: RFE: Locale Data Deployment Enhancements 4609153: Provide locale data for Indic locales 5104387: Support for gl_ES locale (galician language) 6337471: desktop/system locale preferences support 7056139: (cal) SPI support for locale-dependent Calendar parameters 7058206: Provide CalendarData SPI for week params and display field value names 7073852: Support multiple scripts for digits and decimal symbols per locale 7079560: [Fmt-Da] Context dependent month names support in SimpleDateFormat 7171324: getAvailableLocales() of locale sensitive services should return the actual availability of locales 7151414: (cal) Support calendar type identification 7168528: LocaleServiceProvider needs to be aware of Locale extensions 7171372: (cal) locale's default Calendar should be created if unknown calendar is specified Summary: JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data (part 1 w/o packaging changes. by Naoto Sato and Masayoshi Okutsu) Reviewed-by: erikj, sherman, peytoia ! make/java/java/Exportedfiles.gmk ! make/java/java/FILES_c.gmk ! make/java/java/FILES_java.gmk ! make/java/java/Makefile ! make/java/java/genlocales.gmk ! make/java/java/localegen.sh ! make/java/java/mapfile-vers ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_java.gmk ! make/java/util/FILES_properties.gmk ! make/java/util/Makefile ! make/sun/Makefile + make/sun/cldr/Makefile ! make/sun/text/FILES_java.gmk ! make/sun/text/FILES_properties.gmk ! make/sun/text/Makefile ! make/tools/Makefile + make/tools/cldrconverter/Makefile + make/tools/src/build/tools/cldrconverter/AbstractLDMLHandler.java + make/tools/src/build/tools/cldrconverter/Bundle.java + make/tools/src/build/tools/cldrconverter/BundleGenerator.java + make/tools/src/build/tools/cldrconverter/CLDRConverter.java + make/tools/src/build/tools/cldrconverter/CalendarType.java + make/tools/src/build/tools/cldrconverter/Container.java + make/tools/src/build/tools/cldrconverter/CopyrightHeaders.java + make/tools/src/build/tools/cldrconverter/Entry.java + make/tools/src/build/tools/cldrconverter/IgnoredContainer.java + make/tools/src/build/tools/cldrconverter/KeyContainer.java + make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java + make/tools/src/build/tools/cldrconverter/MetaZonesParseHandler.java + make/tools/src/build/tools/cldrconverter/NumberingSystemsParseHandler.java + make/tools/src/build/tools/cldrconverter/ResourceBundleGenerator.java + make/tools/src/build/tools/cldrconverter/StringArrayElement.java + make/tools/src/build/tools/cldrconverter/StringArrayEntry.java + make/tools/src/build/tools/cldrconverter/StringEntry.java + make/tools/src/build/tools/cldrconverter/SupplementDataParseHandler.java + make/tools/src/build/tools/generatebreakiteratordata/BreakIteratorRBControl.java ! make/tools/src/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GenerateJavaSources.gmk + makefiles/GensrcCLDR.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcProperties.gmk ! makefiles/Tools.gmk + src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java + src/macosx/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c - src/share/classes/java/text/BreakDictionary.java ! src/share/classes/java/text/BreakIterator.java - src/share/classes/java/text/CollationRules.java ! src/share/classes/java/text/Collator.java ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java - src/share/classes/java/text/DictionaryBasedBreakIterator.java ! src/share/classes/java/text/NumberFormat.java - src/share/classes/java/text/RuleBasedBreakIterator.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/text/spi/DecimalFormatSymbolsProvider.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/TimeZone.java + src/share/classes/java/util/spi/CalendarDataProvider.java ! src/share/classes/java/util/spi/CurrencyNameProvider.java ! src/share/classes/java/util/spi/LocaleServiceProvider.java ! src/share/classes/javax/swing/JSpinner.java - src/share/classes/sun/text/resources/BreakIteratorInfo_th.java - src/share/classes/sun/text/resources/BreakIteratorRules_th.java - src/share/classes/sun/text/resources/CollationData_ar.java - src/share/classes/sun/text/resources/CollationData_be.java - src/share/classes/sun/text/resources/CollationData_bg.java - src/share/classes/sun/text/resources/CollationData_ca.java - src/share/classes/sun/text/resources/CollationData_cs.java - src/share/classes/sun/text/resources/CollationData_da.java - src/share/classes/sun/text/resources/CollationData_de.java - src/share/classes/sun/text/resources/CollationData_el.java - src/share/classes/sun/text/resources/CollationData_en.java - src/share/classes/sun/text/resources/CollationData_es.java - src/share/classes/sun/text/resources/CollationData_et.java - src/share/classes/sun/text/resources/CollationData_fi.java - src/share/classes/sun/text/resources/CollationData_fr.java - src/share/classes/sun/text/resources/CollationData_hi.java - src/share/classes/sun/text/resources/CollationData_hr.java - src/share/classes/sun/text/resources/CollationData_hu.java - src/share/classes/sun/text/resources/CollationData_is.java - src/share/classes/sun/text/resources/CollationData_it.java - src/share/classes/sun/text/resources/CollationData_iw.java - src/share/classes/sun/text/resources/CollationData_ja.java - src/share/classes/sun/text/resources/CollationData_ko.java - src/share/classes/sun/text/resources/CollationData_lt.java - src/share/classes/sun/text/resources/CollationData_lv.java - src/share/classes/sun/text/resources/CollationData_mk.java - src/share/classes/sun/text/resources/CollationData_nl.java - src/share/classes/sun/text/resources/CollationData_no.java - src/share/classes/sun/text/resources/CollationData_pl.java - src/share/classes/sun/text/resources/CollationData_pt.java - src/share/classes/sun/text/resources/CollationData_ro.java - src/share/classes/sun/text/resources/CollationData_ru.java - src/share/classes/sun/text/resources/CollationData_sk.java - src/share/classes/sun/text/resources/CollationData_sl.java - src/share/classes/sun/text/resources/CollationData_sq.java - src/share/classes/sun/text/resources/CollationData_sr.java - src/share/classes/sun/text/resources/CollationData_sr_Latn.java - src/share/classes/sun/text/resources/CollationData_sv.java - src/share/classes/sun/text/resources/CollationData_th.java - src/share/classes/sun/text/resources/CollationData_tr.java - src/share/classes/sun/text/resources/CollationData_uk.java - src/share/classes/sun/text/resources/CollationData_vi.java - src/share/classes/sun/text/resources/CollationData_zh.java - src/share/classes/sun/text/resources/CollationData_zh_HK.java - src/share/classes/sun/text/resources/CollationData_zh_TW.java ! src/share/classes/sun/text/resources/FormatData.java - src/share/classes/sun/text/resources/FormatData_ar.java - src/share/classes/sun/text/resources/FormatData_ar_AE.java - src/share/classes/sun/text/resources/FormatData_ar_BH.java - src/share/classes/sun/text/resources/FormatData_ar_DZ.java - src/share/classes/sun/text/resources/FormatData_ar_EG.java - src/share/classes/sun/text/resources/FormatData_ar_IQ.java - src/share/classes/sun/text/resources/FormatData_ar_JO.java - src/share/classes/sun/text/resources/FormatData_ar_KW.java - src/share/classes/sun/text/resources/FormatData_ar_LB.java - src/share/classes/sun/text/resources/FormatData_ar_LY.java - src/share/classes/sun/text/resources/FormatData_ar_MA.java - src/share/classes/sun/text/resources/FormatData_ar_OM.java - src/share/classes/sun/text/resources/FormatData_ar_QA.java - src/share/classes/sun/text/resources/FormatData_ar_SA.java - src/share/classes/sun/text/resources/FormatData_ar_SD.java - src/share/classes/sun/text/resources/FormatData_ar_SY.java - src/share/classes/sun/text/resources/FormatData_ar_TN.java - src/share/classes/sun/text/resources/FormatData_ar_YE.java - src/share/classes/sun/text/resources/FormatData_be.java - src/share/classes/sun/text/resources/FormatData_be_BY.java - src/share/classes/sun/text/resources/FormatData_bg.java - src/share/classes/sun/text/resources/FormatData_bg_BG.java - src/share/classes/sun/text/resources/FormatData_ca.java - src/share/classes/sun/text/resources/FormatData_ca_ES.java - src/share/classes/sun/text/resources/FormatData_cs.java - src/share/classes/sun/text/resources/FormatData_cs_CZ.java - src/share/classes/sun/text/resources/FormatData_da.java - src/share/classes/sun/text/resources/FormatData_da_DK.java - src/share/classes/sun/text/resources/FormatData_de.java - src/share/classes/sun/text/resources/FormatData_de_AT.java - src/share/classes/sun/text/resources/FormatData_de_CH.java - src/share/classes/sun/text/resources/FormatData_de_DE.java - src/share/classes/sun/text/resources/FormatData_de_LU.java - src/share/classes/sun/text/resources/FormatData_el.java - src/share/classes/sun/text/resources/FormatData_el_CY.java - src/share/classes/sun/text/resources/FormatData_el_GR.java - src/share/classes/sun/text/resources/FormatData_en.java - src/share/classes/sun/text/resources/FormatData_en_AU.java - src/share/classes/sun/text/resources/FormatData_en_CA.java - src/share/classes/sun/text/resources/FormatData_en_GB.java - src/share/classes/sun/text/resources/FormatData_en_IE.java - src/share/classes/sun/text/resources/FormatData_en_IN.java - src/share/classes/sun/text/resources/FormatData_en_MT.java - src/share/classes/sun/text/resources/FormatData_en_NZ.java - src/share/classes/sun/text/resources/FormatData_en_PH.java - src/share/classes/sun/text/resources/FormatData_en_SG.java - src/share/classes/sun/text/resources/FormatData_en_US.java - src/share/classes/sun/text/resources/FormatData_en_ZA.java - src/share/classes/sun/text/resources/FormatData_es.java - src/share/classes/sun/text/resources/FormatData_es_AR.java - src/share/classes/sun/text/resources/FormatData_es_BO.java - src/share/classes/sun/text/resources/FormatData_es_CL.java - src/share/classes/sun/text/resources/FormatData_es_CO.java - src/share/classes/sun/text/resources/FormatData_es_CR.java - src/share/classes/sun/text/resources/FormatData_es_DO.java - src/share/classes/sun/text/resources/FormatData_es_EC.java - src/share/classes/sun/text/resources/FormatData_es_ES.java - src/share/classes/sun/text/resources/FormatData_es_GT.java - src/share/classes/sun/text/resources/FormatData_es_HN.java - src/share/classes/sun/text/resources/FormatData_es_MX.java - src/share/classes/sun/text/resources/FormatData_es_NI.java - src/share/classes/sun/text/resources/FormatData_es_PA.java - src/share/classes/sun/text/resources/FormatData_es_PE.java - src/share/classes/sun/text/resources/FormatData_es_PR.java - src/share/classes/sun/text/resources/FormatData_es_PY.java - src/share/classes/sun/text/resources/FormatData_es_SV.java - src/share/classes/sun/text/resources/FormatData_es_US.java - src/share/classes/sun/text/resources/FormatData_es_UY.java - src/share/classes/sun/text/resources/FormatData_es_VE.java - src/share/classes/sun/text/resources/FormatData_et.java - src/share/classes/sun/text/resources/FormatData_et_EE.java - src/share/classes/sun/text/resources/FormatData_fi.java - src/share/classes/sun/text/resources/FormatData_fi_FI.java - src/share/classes/sun/text/resources/FormatData_fr.java - src/share/classes/sun/text/resources/FormatData_fr_BE.java - src/share/classes/sun/text/resources/FormatData_fr_CA.java - src/share/classes/sun/text/resources/FormatData_fr_CH.java - src/share/classes/sun/text/resources/FormatData_fr_FR.java - src/share/classes/sun/text/resources/FormatData_fr_LU.java - src/share/classes/sun/text/resources/FormatData_ga.java - src/share/classes/sun/text/resources/FormatData_ga_IE.java - src/share/classes/sun/text/resources/FormatData_hi_IN.java - src/share/classes/sun/text/resources/FormatData_hr.java - src/share/classes/sun/text/resources/FormatData_hr_HR.java - src/share/classes/sun/text/resources/FormatData_hu.java - src/share/classes/sun/text/resources/FormatData_hu_HU.java - src/share/classes/sun/text/resources/FormatData_in.java - src/share/classes/sun/text/resources/FormatData_in_ID.java - src/share/classes/sun/text/resources/FormatData_is.java - src/share/classes/sun/text/resources/FormatData_is_IS.java - src/share/classes/sun/text/resources/FormatData_it.java - src/share/classes/sun/text/resources/FormatData_it_CH.java - src/share/classes/sun/text/resources/FormatData_it_IT.java - src/share/classes/sun/text/resources/FormatData_iw.java - src/share/classes/sun/text/resources/FormatData_iw_IL.java - src/share/classes/sun/text/resources/FormatData_ja.java - src/share/classes/sun/text/resources/FormatData_ja_JP.java - src/share/classes/sun/text/resources/FormatData_ja_JP_JP.java - src/share/classes/sun/text/resources/FormatData_ko.java - src/share/classes/sun/text/resources/FormatData_ko_KR.java - src/share/classes/sun/text/resources/FormatData_lt.java - src/share/classes/sun/text/resources/FormatData_lt_LT.java - src/share/classes/sun/text/resources/FormatData_lv.java - src/share/classes/sun/text/resources/FormatData_lv_LV.java - src/share/classes/sun/text/resources/FormatData_mk.java - src/share/classes/sun/text/resources/FormatData_mk_MK.java - src/share/classes/sun/text/resources/FormatData_ms.java - src/share/classes/sun/text/resources/FormatData_ms_MY.java - src/share/classes/sun/text/resources/FormatData_mt.java - src/share/classes/sun/text/resources/FormatData_mt_MT.java - src/share/classes/sun/text/resources/FormatData_nl.java - src/share/classes/sun/text/resources/FormatData_nl_BE.java - src/share/classes/sun/text/resources/FormatData_nl_NL.java - src/share/classes/sun/text/resources/FormatData_no.java - src/share/classes/sun/text/resources/FormatData_no_NO.java - src/share/classes/sun/text/resources/FormatData_no_NO_NY.java - src/share/classes/sun/text/resources/FormatData_pl.java - src/share/classes/sun/text/resources/FormatData_pl_PL.java - src/share/classes/sun/text/resources/FormatData_pt.java - src/share/classes/sun/text/resources/FormatData_pt_BR.java - src/share/classes/sun/text/resources/FormatData_pt_PT.java - src/share/classes/sun/text/resources/FormatData_ro.java - src/share/classes/sun/text/resources/FormatData_ro_RO.java - src/share/classes/sun/text/resources/FormatData_ru.java - src/share/classes/sun/text/resources/FormatData_ru_RU.java - src/share/classes/sun/text/resources/FormatData_sk.java - src/share/classes/sun/text/resources/FormatData_sk_SK.java - src/share/classes/sun/text/resources/FormatData_sl.java - src/share/classes/sun/text/resources/FormatData_sl_SI.java - src/share/classes/sun/text/resources/FormatData_sq.java - src/share/classes/sun/text/resources/FormatData_sq_AL.java - src/share/classes/sun/text/resources/FormatData_sr.java - src/share/classes/sun/text/resources/FormatData_sr_BA.java - src/share/classes/sun/text/resources/FormatData_sr_CS.java - src/share/classes/sun/text/resources/FormatData_sr_Latn.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_BA.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_ME.java - src/share/classes/sun/text/resources/FormatData_sr_Latn_RS.java - src/share/classes/sun/text/resources/FormatData_sr_ME.java - src/share/classes/sun/text/resources/FormatData_sr_RS.java - src/share/classes/sun/text/resources/FormatData_sv.java - src/share/classes/sun/text/resources/FormatData_sv_SE.java - src/share/classes/sun/text/resources/FormatData_th.java - src/share/classes/sun/text/resources/FormatData_th_TH.java - src/share/classes/sun/text/resources/FormatData_th_TH_TH.java - src/share/classes/sun/text/resources/FormatData_tr.java - src/share/classes/sun/text/resources/FormatData_tr_TR.java - src/share/classes/sun/text/resources/FormatData_uk.java - src/share/classes/sun/text/resources/FormatData_uk_UA.java - src/share/classes/sun/text/resources/FormatData_vi.java - src/share/classes/sun/text/resources/FormatData_vi_VN.java - src/share/classes/sun/text/resources/FormatData_zh.java - src/share/classes/sun/text/resources/FormatData_zh_CN.java - src/share/classes/sun/text/resources/FormatData_zh_HK.java - src/share/classes/sun/text/resources/FormatData_zh_SG.java - src/share/classes/sun/text/resources/FormatData_zh_TW.java + src/share/classes/sun/text/resources/ar/CollationData_ar.java + src/share/classes/sun/text/resources/ar/FormatData_ar.java + src/share/classes/sun/text/resources/ar/FormatData_ar_JO.java + src/share/classes/sun/text/resources/ar/FormatData_ar_LB.java + src/share/classes/sun/text/resources/ar/FormatData_ar_SY.java + src/share/classes/sun/text/resources/be/CollationData_be.java + src/share/classes/sun/text/resources/be/FormatData_be.java + src/share/classes/sun/text/resources/be/FormatData_be_BY.java + src/share/classes/sun/text/resources/bg/CollationData_bg.java + src/share/classes/sun/text/resources/bg/FormatData_bg.java + src/share/classes/sun/text/resources/bg/FormatData_bg_BG.java + src/share/classes/sun/text/resources/ca/CollationData_ca.java + src/share/classes/sun/text/resources/ca/FormatData_ca.java + src/share/classes/sun/text/resources/ca/FormatData_ca_ES.java + src/share/classes/sun/text/resources/cs/CollationData_cs.java + src/share/classes/sun/text/resources/cs/FormatData_cs.java + src/share/classes/sun/text/resources/cs/FormatData_cs_CZ.java + src/share/classes/sun/text/resources/da/CollationData_da.java + src/share/classes/sun/text/resources/da/FormatData_da.java + src/share/classes/sun/text/resources/da/FormatData_da_DK.java + src/share/classes/sun/text/resources/de/FormatData_de.java + src/share/classes/sun/text/resources/de/FormatData_de_AT.java + src/share/classes/sun/text/resources/de/FormatData_de_CH.java + src/share/classes/sun/text/resources/de/FormatData_de_DE.java + src/share/classes/sun/text/resources/de/FormatData_de_LU.java + src/share/classes/sun/text/resources/el/CollationData_el.java + src/share/classes/sun/text/resources/el/FormatData_el.java + src/share/classes/sun/text/resources/el/FormatData_el_CY.java + src/share/classes/sun/text/resources/el/FormatData_el_GR.java + src/share/classes/sun/text/resources/en/FormatData_en.java + src/share/classes/sun/text/resources/en/FormatData_en_AU.java + src/share/classes/sun/text/resources/en/FormatData_en_CA.java + src/share/classes/sun/text/resources/en/FormatData_en_GB.java + src/share/classes/sun/text/resources/en/FormatData_en_IE.java + src/share/classes/sun/text/resources/en/FormatData_en_IN.java + src/share/classes/sun/text/resources/en/FormatData_en_MT.java + src/share/classes/sun/text/resources/en/FormatData_en_NZ.java + src/share/classes/sun/text/resources/en/FormatData_en_PH.java + src/share/classes/sun/text/resources/en/FormatData_en_SG.java + src/share/classes/sun/text/resources/en/FormatData_en_US.java + src/share/classes/sun/text/resources/en/FormatData_en_ZA.java + src/share/classes/sun/text/resources/es/CollationData_es.java + src/share/classes/sun/text/resources/es/FormatData_es.java + src/share/classes/sun/text/resources/es/FormatData_es_AR.java + src/share/classes/sun/text/resources/es/FormatData_es_BO.java + src/share/classes/sun/text/resources/es/FormatData_es_CL.java + src/share/classes/sun/text/resources/es/FormatData_es_CO.java + src/share/classes/sun/text/resources/es/FormatData_es_CR.java + src/share/classes/sun/text/resources/es/FormatData_es_DO.java + src/share/classes/sun/text/resources/es/FormatData_es_EC.java + src/share/classes/sun/text/resources/es/FormatData_es_ES.java + src/share/classes/sun/text/resources/es/FormatData_es_GT.java + src/share/classes/sun/text/resources/es/FormatData_es_HN.java + src/share/classes/sun/text/resources/es/FormatData_es_MX.java + src/share/classes/sun/text/resources/es/FormatData_es_NI.java + src/share/classes/sun/text/resources/es/FormatData_es_PA.java + src/share/classes/sun/text/resources/es/FormatData_es_PE.java + src/share/classes/sun/text/resources/es/FormatData_es_PR.java + src/share/classes/sun/text/resources/es/FormatData_es_PY.java + src/share/classes/sun/text/resources/es/FormatData_es_SV.java + src/share/classes/sun/text/resources/es/FormatData_es_US.java + src/share/classes/sun/text/resources/es/FormatData_es_UY.java + src/share/classes/sun/text/resources/es/FormatData_es_VE.java + src/share/classes/sun/text/resources/et/CollationData_et.java + src/share/classes/sun/text/resources/et/FormatData_et.java + src/share/classes/sun/text/resources/et/FormatData_et_EE.java + src/share/classes/sun/text/resources/fi/CollationData_fi.java + src/share/classes/sun/text/resources/fi/FormatData_fi.java + src/share/classes/sun/text/resources/fi/FormatData_fi_FI.java + src/share/classes/sun/text/resources/fr/CollationData_fr.java + src/share/classes/sun/text/resources/fr/FormatData_fr.java + src/share/classes/sun/text/resources/fr/FormatData_fr_BE.java + src/share/classes/sun/text/resources/fr/FormatData_fr_CA.java + src/share/classes/sun/text/resources/fr/FormatData_fr_CH.java + src/share/classes/sun/text/resources/fr/FormatData_fr_FR.java + src/share/classes/sun/text/resources/ga/FormatData_ga.java + src/share/classes/sun/text/resources/ga/FormatData_ga_IE.java + src/share/classes/sun/text/resources/hi/CollationData_hi.java + src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java + src/share/classes/sun/text/resources/hr/CollationData_hr.java + src/share/classes/sun/text/resources/hr/FormatData_hr.java + src/share/classes/sun/text/resources/hr/FormatData_hr_HR.java + src/share/classes/sun/text/resources/hu/CollationData_hu.java + src/share/classes/sun/text/resources/hu/FormatData_hu.java + src/share/classes/sun/text/resources/hu/FormatData_hu_HU.java + src/share/classes/sun/text/resources/in/FormatData_in.java + src/share/classes/sun/text/resources/in/FormatData_in_ID.java + src/share/classes/sun/text/resources/is/CollationData_is.java + src/share/classes/sun/text/resources/is/FormatData_is.java + src/share/classes/sun/text/resources/is/FormatData_is_IS.java + src/share/classes/sun/text/resources/it/FormatData_it.java + src/share/classes/sun/text/resources/it/FormatData_it_CH.java + src/share/classes/sun/text/resources/it/FormatData_it_IT.java + src/share/classes/sun/text/resources/iw/CollationData_iw.java + src/share/classes/sun/text/resources/iw/FormatData_iw.java + src/share/classes/sun/text/resources/iw/FormatData_iw_IL.java + src/share/classes/sun/text/resources/ja/CollationData_ja.java + src/share/classes/sun/text/resources/ja/FormatData_ja.java + src/share/classes/sun/text/resources/ja/FormatData_ja_JP.java + src/share/classes/sun/text/resources/ko/CollationData_ko.java + src/share/classes/sun/text/resources/ko/FormatData_ko.java + src/share/classes/sun/text/resources/ko/FormatData_ko_KR.java + src/share/classes/sun/text/resources/lt/CollationData_lt.java + src/share/classes/sun/text/resources/lt/FormatData_lt.java + src/share/classes/sun/text/resources/lt/FormatData_lt_LT.java + src/share/classes/sun/text/resources/lv/CollationData_lv.java + src/share/classes/sun/text/resources/lv/FormatData_lv.java + src/share/classes/sun/text/resources/lv/FormatData_lv_LV.java + src/share/classes/sun/text/resources/mk/CollationData_mk.java + src/share/classes/sun/text/resources/mk/FormatData_mk.java + src/share/classes/sun/text/resources/mk/FormatData_mk_MK.java + src/share/classes/sun/text/resources/ms/FormatData_ms.java + src/share/classes/sun/text/resources/ms/FormatData_ms_MY.java + src/share/classes/sun/text/resources/mt/FormatData_mt.java + src/share/classes/sun/text/resources/mt/FormatData_mt_MT.java + src/share/classes/sun/text/resources/nl/FormatData_nl.java + src/share/classes/sun/text/resources/nl/FormatData_nl_BE.java + src/share/classes/sun/text/resources/nl/FormatData_nl_NL.java + src/share/classes/sun/text/resources/no/CollationData_no.java + src/share/classes/sun/text/resources/no/FormatData_no.java + src/share/classes/sun/text/resources/no/FormatData_no_NO.java + src/share/classes/sun/text/resources/no/FormatData_no_NO_NY.java + src/share/classes/sun/text/resources/pl/CollationData_pl.java + src/share/classes/sun/text/resources/pl/FormatData_pl.java + src/share/classes/sun/text/resources/pl/FormatData_pl_PL.java + src/share/classes/sun/text/resources/pt/FormatData_pt.java + src/share/classes/sun/text/resources/pt/FormatData_pt_BR.java + src/share/classes/sun/text/resources/pt/FormatData_pt_PT.java + src/share/classes/sun/text/resources/ro/CollationData_ro.java + src/share/classes/sun/text/resources/ro/FormatData_ro.java + src/share/classes/sun/text/resources/ro/FormatData_ro_RO.java + src/share/classes/sun/text/resources/ru/CollationData_ru.java + src/share/classes/sun/text/resources/ru/FormatData_ru.java + src/share/classes/sun/text/resources/ru/FormatData_ru_RU.java + src/share/classes/sun/text/resources/sk/CollationData_sk.java + src/share/classes/sun/text/resources/sk/FormatData_sk.java + src/share/classes/sun/text/resources/sk/FormatData_sk_SK.java + src/share/classes/sun/text/resources/sl/CollationData_sl.java + src/share/classes/sun/text/resources/sl/FormatData_sl.java + src/share/classes/sun/text/resources/sl/FormatData_sl_SI.java + src/share/classes/sun/text/resources/sq/CollationData_sq.java + src/share/classes/sun/text/resources/sq/FormatData_sq.java + src/share/classes/sun/text/resources/sq/FormatData_sq_AL.java + src/share/classes/sun/text/resources/sr/CollationData_sr.java + src/share/classes/sun/text/resources/sr/CollationData_sr_Latn.java + src/share/classes/sun/text/resources/sr/FormatData_sr.java + src/share/classes/sun/text/resources/sr/FormatData_sr_BA.java + src/share/classes/sun/text/resources/sr/FormatData_sr_CS.java + src/share/classes/sun/text/resources/sr/FormatData_sr_Latn.java + src/share/classes/sun/text/resources/sr/FormatData_sr_Latn_ME.java + src/share/classes/sun/text/resources/sr/FormatData_sr_ME.java + src/share/classes/sun/text/resources/sr/FormatData_sr_RS.java + src/share/classes/sun/text/resources/sv/CollationData_sv.java + src/share/classes/sun/text/resources/sv/FormatData_sv.java + src/share/classes/sun/text/resources/sv/FormatData_sv_SE.java + src/share/classes/sun/text/resources/th/BreakIteratorInfo_th.java + src/share/classes/sun/text/resources/th/BreakIteratorRules_th.java + src/share/classes/sun/text/resources/th/CollationData_th.java + src/share/classes/sun/text/resources/th/FormatData_th.java + src/share/classes/sun/text/resources/th/FormatData_th_TH.java + src/share/classes/sun/text/resources/th/thai_dict - src/share/classes/sun/text/resources/thai_dict + src/share/classes/sun/text/resources/tr/CollationData_tr.java + src/share/classes/sun/text/resources/tr/FormatData_tr.java + src/share/classes/sun/text/resources/tr/FormatData_tr_TR.java + src/share/classes/sun/text/resources/uk/CollationData_uk.java + src/share/classes/sun/text/resources/uk/FormatData_uk.java + src/share/classes/sun/text/resources/uk/FormatData_uk_UA.java + src/share/classes/sun/text/resources/vi/CollationData_vi.java + src/share/classes/sun/text/resources/vi/FormatData_vi.java + src/share/classes/sun/text/resources/vi/FormatData_vi_VN.java + src/share/classes/sun/text/resources/zh/CollationData_zh.java + src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java + src/share/classes/sun/text/resources/zh/CollationData_zh_TW.java + src/share/classes/sun/text/resources/zh/FormatData_zh.java + src/share/classes/sun/text/resources/zh/FormatData_zh_CN.java + src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java + src/share/classes/sun/text/resources/zh/FormatData_zh_SG.java + src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java ! src/share/classes/sun/util/BuddhistCalendar.java - src/share/classes/sun/util/EmptyListResourceBundle.java - src/share/classes/sun/util/LocaleDataMetaInfo-XLocales.java.template - src/share/classes/sun/util/LocaleServiceProviderPool.java - src/share/classes/sun/util/TimeZoneNameUtility.java + src/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java + src/share/classes/sun/util/cldr/resources/21_0_1/LICENSE + src/share/classes/sun/util/cldr/resources/21_0_1/common/dtd/ldml.dtd + src/share/classes/sun/util/cldr/resources/21_0_1/common/dtd/ldmlSupplemental.dtd + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_DJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/aa_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af_NA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/af_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/agq_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ak.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ak_GH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/am.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/am_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_001.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_AE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_BH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_DZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_EG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_IQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_JO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_KW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_LB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_LY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_OM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_QA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_SY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_TN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ar_YE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/as.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/as_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/asa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/asa_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Cyrl_AZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/az_Latn_AZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bas.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bas_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/be.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/be_BY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bem.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bem_ZM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bez.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bez_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bg_BG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bm.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bm_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn_BD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bn_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo_CN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bo_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/br.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/br_FR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/brx.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/brx_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bs.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/bs_BA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/byn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/byn_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ca.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ca_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cgg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cgg_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/chr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/chr_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cs.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cs_CZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/cy_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/da.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/da_DK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dav.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dav_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_AT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_DE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_LI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/de_LU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dje.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dje_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dua.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dua_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dyo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dyo_SN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dz.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/dz_BT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ebu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ebu_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee_GH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ee_TG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el_CY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/el_GR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_AS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_AU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_BZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_CA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_Dsrt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_Dsrt_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_GY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_HK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_IE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_JM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_MU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_NA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_NZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_PH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_PK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_SG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_TT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_UM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_US_POSIX.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_VI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/en_ZW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_419.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_AR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_BO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_CR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_DO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_EC.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_GQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_GT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_HN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_MX.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_NI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_PY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_SV.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_UY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/es_VE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/et.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/et_EE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/eu_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ewo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ewo_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa_AF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fa_IR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ff.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ff_SN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fi_FI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fil.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fil_PH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fo_FO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_BL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_DJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_FR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_GQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_KM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_LU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MC.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_MQ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_RE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_RW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_SN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_TD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_TG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fr_YT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fur.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/fur_IT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ga.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ga_IE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gd.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gd_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gl_ES.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gsw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gsw_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gu_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/guz.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/guz_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gv.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/gv_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_GH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ha_Latn_NG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/haw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/haw_US.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/he.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/he_IL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hi_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hr_HR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hu_HU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/hy_AM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ia.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/id.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/id_ID.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ig.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ig_NG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ii.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ii_CN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/is.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/is_IS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/it_IT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ja.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ja_JP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/jmc.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/jmc_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ka.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ka_GE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kab.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kab_DZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kam.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kam_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kde.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kde_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kea.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kea_CV.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/khq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/khq_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ki.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ki_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kk_Cyrl_KZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kl_GL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kln.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kln_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/km.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/km_KH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kn_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ko.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ko_KR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kok.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kok_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksb.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksb_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksf.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksf_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ksh_DE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/kw_GB.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lag.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lag_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lg_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ln_CG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lo_LA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lt_LT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lu_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luo_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/luy_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lv.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/lv_LV.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mas_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mer.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mer_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mfe.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mfe_MU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mg_MG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mgh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mgh_MZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mk_MK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ml.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ml_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mr_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms_BN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ms_MY.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mt_MT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mua.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/mua_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/my.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/my_MM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/naq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/naq_NA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nb.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nb_NO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nd.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nd_ZW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ne_NP.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_AW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_BE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_CW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_NL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nl_SX.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nmg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nmg_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nn_NO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nr_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nso.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nso_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nus.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nus_SD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nyn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/nyn_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/om_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/or.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/or_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Arab.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Arab_PK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Guru.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pa_Guru_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pl_PL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ps.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ps_AF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_AO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_BR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_GW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_MZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_PT.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/pt_ST.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rm.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rm_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rn_BI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro_MD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ro_RO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rof.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rof_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/root.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_MD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_RU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ru_UA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rw_RW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rwk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/rwk_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sah.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sah_RU.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/saq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/saq_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sbp.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sbp_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se_FI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/se_NO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/seh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/seh_MZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ses.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ses_ML.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sg_CF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Latn_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Tfng.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/shi_Tfng_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/si.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/si_LK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sk_SK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sl_SI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sn_ZW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_DJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/so_SO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sq_AL.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_BA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_ME.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Cyrl_RS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_BA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_ME.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sr_Latn_RS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss_SZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ss_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ssy.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ssy_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st_LS.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/st_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv_FI.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sv_SE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/sw_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/swc.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/swc_CD.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ta_LK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/te.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/te_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo_KE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/teo_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tg_Cyrl_TJ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/th.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/th_TH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ti_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tig.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tig_ER.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tn_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/to.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/to_TO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tr.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tr_TR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ts.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ts_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/twq.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/twq_NE.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/tzm_Latn_MA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uk.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uk_UA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur_IN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ur_PK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Arab.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Arab_AF.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Cyrl.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Cyrl_UZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/uz_Latn_UZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Latn.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Latn_LR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Vaii.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vai_Vaii_LR.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ve.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ve_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vi.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vi_VN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vun.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/vun_TZ.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wae.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wae_CH.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wal.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/wal_ET.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xh_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xog.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/xog_UG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yav.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yav_CM.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yo.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/yo_NG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_CN.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_HK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_MO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hans_SG.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_HK.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_MO.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zh_Hant_TW.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zu.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/main/zu_ZA.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/metaZones.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/numberingSystems.xml + src/share/classes/sun/util/cldr/resources/21_0_1/common/supplemental/supplementalData.xml ! src/share/classes/sun/util/locale/LocaleUtils.java + src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/AvailableLanguageTags.java + src/share/classes/sun/util/locale/provider/BreakDictionary.java + src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java + src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java + src/share/classes/sun/util/locale/provider/CalendarDataUtility.java + src/share/classes/sun/util/locale/provider/CollationRules.java + src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java + src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java + src/share/classes/sun/util/locale/provider/DateFormatProviderImpl.java + src/share/classes/sun/util/locale/provider/DateFormatSymbolsProviderImpl.java + src/share/classes/sun/util/locale/provider/DecimalFormatSymbolsProviderImpl.java + src/share/classes/sun/util/locale/provider/DictionaryBasedBreakIterator.java + src/share/classes/sun/util/locale/provider/HostLocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/JRELocaleConstants.java + src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template + src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java + src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/LocaleResources.java + src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java + src/share/classes/sun/util/locale/provider/NumberFormatProviderImpl.java + src/share/classes/sun/util/locale/provider/RuleBasedBreakIterator.java + src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java + src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java + src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java - src/share/classes/sun/util/resources/CalendarData_ar.properties - src/share/classes/sun/util/resources/CalendarData_be.properties - src/share/classes/sun/util/resources/CalendarData_bg.properties - src/share/classes/sun/util/resources/CalendarData_ca.properties - src/share/classes/sun/util/resources/CalendarData_cs.properties - src/share/classes/sun/util/resources/CalendarData_da.properties - src/share/classes/sun/util/resources/CalendarData_de.properties - src/share/classes/sun/util/resources/CalendarData_el.properties - src/share/classes/sun/util/resources/CalendarData_el_CY.properties - src/share/classes/sun/util/resources/CalendarData_en.properties - src/share/classes/sun/util/resources/CalendarData_en_GB.properties - src/share/classes/sun/util/resources/CalendarData_en_IE.properties - src/share/classes/sun/util/resources/CalendarData_en_MT.properties - src/share/classes/sun/util/resources/CalendarData_es.properties - src/share/classes/sun/util/resources/CalendarData_es_ES.properties - src/share/classes/sun/util/resources/CalendarData_es_US.properties - src/share/classes/sun/util/resources/CalendarData_et.properties - src/share/classes/sun/util/resources/CalendarData_fi.properties - src/share/classes/sun/util/resources/CalendarData_fr.properties - src/share/classes/sun/util/resources/CalendarData_fr_CA.properties - src/share/classes/sun/util/resources/CalendarData_hi.properties - src/share/classes/sun/util/resources/CalendarData_hr.properties - src/share/classes/sun/util/resources/CalendarData_hu.properties - src/share/classes/sun/util/resources/CalendarData_in_ID.properties - src/share/classes/sun/util/resources/CalendarData_is.properties - src/share/classes/sun/util/resources/CalendarData_it.properties - src/share/classes/sun/util/resources/CalendarData_iw.properties - src/share/classes/sun/util/resources/CalendarData_ja.properties - src/share/classes/sun/util/resources/CalendarData_ko.properties - src/share/classes/sun/util/resources/CalendarData_lt.properties - src/share/classes/sun/util/resources/CalendarData_lv.properties - src/share/classes/sun/util/resources/CalendarData_mk.properties - src/share/classes/sun/util/resources/CalendarData_ms_MY.properties - src/share/classes/sun/util/resources/CalendarData_mt.properties - src/share/classes/sun/util/resources/CalendarData_mt_MT.properties - src/share/classes/sun/util/resources/CalendarData_nl.properties - src/share/classes/sun/util/resources/CalendarData_no.properties - src/share/classes/sun/util/resources/CalendarData_pl.properties - src/share/classes/sun/util/resources/CalendarData_pt.properties - src/share/classes/sun/util/resources/CalendarData_pt_PT.properties - src/share/classes/sun/util/resources/CalendarData_ro.properties - src/share/classes/sun/util/resources/CalendarData_ru.properties - src/share/classes/sun/util/resources/CalendarData_sk.properties - src/share/classes/sun/util/resources/CalendarData_sl.properties - src/share/classes/sun/util/resources/CalendarData_sq.properties - src/share/classes/sun/util/resources/CalendarData_sr.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CalendarData_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CalendarData_sv.properties - src/share/classes/sun/util/resources/CalendarData_th.properties - src/share/classes/sun/util/resources/CalendarData_tr.properties - src/share/classes/sun/util/resources/CalendarData_uk.properties - src/share/classes/sun/util/resources/CalendarData_vi.properties - src/share/classes/sun/util/resources/CalendarData_zh.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_AE.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_BH.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_DZ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_EG.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_IQ.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_JO.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_KW.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LB.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_LY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_MA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_OM.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_QA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SA.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SD.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_SY.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_TN.properties - src/share/classes/sun/util/resources/CurrencyNames_ar_YE.properties - src/share/classes/sun/util/resources/CurrencyNames_be_BY.properties - src/share/classes/sun/util/resources/CurrencyNames_bg_BG.properties - src/share/classes/sun/util/resources/CurrencyNames_ca_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_cs_CZ.properties - src/share/classes/sun/util/resources/CurrencyNames_da_DK.properties - src/share/classes/sun/util/resources/CurrencyNames_de.properties - src/share/classes/sun/util/resources/CurrencyNames_de_AT.properties - src/share/classes/sun/util/resources/CurrencyNames_de_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_de_DE.properties - src/share/classes/sun/util/resources/CurrencyNames_de_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_de_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_el_CY.properties - src/share/classes/sun/util/resources/CurrencyNames_el_GR.properties - src/share/classes/sun/util/resources/CurrencyNames_en_AU.properties - src/share/classes/sun/util/resources/CurrencyNames_en_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_en_GB.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_en_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_en_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_en_NZ.properties - src/share/classes/sun/util/resources/CurrencyNames_en_PH.properties - src/share/classes/sun/util/resources/CurrencyNames_en_SG.properties - src/share/classes/sun/util/resources/CurrencyNames_en_US.properties - src/share/classes/sun/util/resources/CurrencyNames_en_ZA.properties - src/share/classes/sun/util/resources/CurrencyNames_es.properties - src/share/classes/sun/util/resources/CurrencyNames_es_AR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_BO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CL.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_CU.properties - src/share/classes/sun/util/resources/CurrencyNames_es_DO.properties - src/share/classes/sun/util/resources/CurrencyNames_es_EC.properties - src/share/classes/sun/util/resources/CurrencyNames_es_ES.properties - src/share/classes/sun/util/resources/CurrencyNames_es_GT.properties - src/share/classes/sun/util/resources/CurrencyNames_es_HN.properties - src/share/classes/sun/util/resources/CurrencyNames_es_MX.properties - src/share/classes/sun/util/resources/CurrencyNames_es_NI.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PA.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PE.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PR.properties - src/share/classes/sun/util/resources/CurrencyNames_es_PY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_SV.properties - src/share/classes/sun/util/resources/CurrencyNames_es_US.properties - src/share/classes/sun/util/resources/CurrencyNames_es_UY.properties - src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties - src/share/classes/sun/util/resources/CurrencyNames_et_EE.properties - src/share/classes/sun/util/resources/CurrencyNames_fi_FI.properties - src/share/classes/sun/util/resources/CurrencyNames_fr.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CA.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_FR.properties - src/share/classes/sun/util/resources/CurrencyNames_fr_LU.properties - src/share/classes/sun/util/resources/CurrencyNames_ga_IE.properties - src/share/classes/sun/util/resources/CurrencyNames_hi_IN.properties - src/share/classes/sun/util/resources/CurrencyNames_hr_HR.properties - src/share/classes/sun/util/resources/CurrencyNames_hu_HU.properties - src/share/classes/sun/util/resources/CurrencyNames_in_ID.properties - src/share/classes/sun/util/resources/CurrencyNames_is_IS.properties - src/share/classes/sun/util/resources/CurrencyNames_it.properties - src/share/classes/sun/util/resources/CurrencyNames_it_CH.properties - src/share/classes/sun/util/resources/CurrencyNames_it_IT.properties - src/share/classes/sun/util/resources/CurrencyNames_iw_IL.properties - src/share/classes/sun/util/resources/CurrencyNames_ja.properties - src/share/classes/sun/util/resources/CurrencyNames_ja_JP.properties - src/share/classes/sun/util/resources/CurrencyNames_ko.properties - src/share/classes/sun/util/resources/CurrencyNames_ko_KR.properties - src/share/classes/sun/util/resources/CurrencyNames_lt_LT.properties - src/share/classes/sun/util/resources/CurrencyNames_lv_LV.properties - src/share/classes/sun/util/resources/CurrencyNames_mk_MK.properties - src/share/classes/sun/util/resources/CurrencyNames_ms_MY.properties - src/share/classes/sun/util/resources/CurrencyNames_mt_MT.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_BE.properties - src/share/classes/sun/util/resources/CurrencyNames_nl_NL.properties - src/share/classes/sun/util/resources/CurrencyNames_no_NO.properties - src/share/classes/sun/util/resources/CurrencyNames_pl_PL.properties - src/share/classes/sun/util/resources/CurrencyNames_pt.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_BR.properties - src/share/classes/sun/util/resources/CurrencyNames_pt_PT.properties - src/share/classes/sun/util/resources/CurrencyNames_ro_RO.properties - src/share/classes/sun/util/resources/CurrencyNames_ru_RU.properties - src/share/classes/sun/util/resources/CurrencyNames_sk_SK.properties - src/share/classes/sun/util/resources/CurrencyNames_sl_SI.properties - src/share/classes/sun/util/resources/CurrencyNames_sq_AL.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_CS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_BA.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_Latn_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_ME.properties - src/share/classes/sun/util/resources/CurrencyNames_sr_RS.properties - src/share/classes/sun/util/resources/CurrencyNames_sv.properties - src/share/classes/sun/util/resources/CurrencyNames_sv_SE.properties - src/share/classes/sun/util/resources/CurrencyNames_th_TH.properties - src/share/classes/sun/util/resources/CurrencyNames_tr_TR.properties - src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties - src/share/classes/sun/util/resources/CurrencyNames_vi_VN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties - src/share/classes/sun/util/resources/CurrencyNames_zh_HK.java - src/share/classes/sun/util/resources/CurrencyNames_zh_SG.java - src/share/classes/sun/util/resources/CurrencyNames_zh_TW.properties ! src/share/classes/sun/util/resources/LocaleData.java - src/share/classes/sun/util/resources/LocaleNames_ar.properties - src/share/classes/sun/util/resources/LocaleNames_be.properties - src/share/classes/sun/util/resources/LocaleNames_bg.properties - src/share/classes/sun/util/resources/LocaleNames_ca.properties - src/share/classes/sun/util/resources/LocaleNames_cs.properties - src/share/classes/sun/util/resources/LocaleNames_da.properties - src/share/classes/sun/util/resources/LocaleNames_de.properties - src/share/classes/sun/util/resources/LocaleNames_el.properties - src/share/classes/sun/util/resources/LocaleNames_el_CY.properties - src/share/classes/sun/util/resources/LocaleNames_en.properties - src/share/classes/sun/util/resources/LocaleNames_en_MT.properties - src/share/classes/sun/util/resources/LocaleNames_en_PH.properties - src/share/classes/sun/util/resources/LocaleNames_en_SG.properties - src/share/classes/sun/util/resources/LocaleNames_es.properties - src/share/classes/sun/util/resources/LocaleNames_es_US.properties - src/share/classes/sun/util/resources/LocaleNames_et.properties - src/share/classes/sun/util/resources/LocaleNames_fi.properties - src/share/classes/sun/util/resources/LocaleNames_fr.properties - src/share/classes/sun/util/resources/LocaleNames_ga.properties - src/share/classes/sun/util/resources/LocaleNames_hi.properties - src/share/classes/sun/util/resources/LocaleNames_hr.properties - src/share/classes/sun/util/resources/LocaleNames_hu.properties - src/share/classes/sun/util/resources/LocaleNames_in.properties - src/share/classes/sun/util/resources/LocaleNames_is.properties - src/share/classes/sun/util/resources/LocaleNames_it.properties - src/share/classes/sun/util/resources/LocaleNames_iw.properties - src/share/classes/sun/util/resources/LocaleNames_ja.properties - src/share/classes/sun/util/resources/LocaleNames_ko.properties - src/share/classes/sun/util/resources/LocaleNames_lt.properties - src/share/classes/sun/util/resources/LocaleNames_lv.properties - src/share/classes/sun/util/resources/LocaleNames_mk.properties - src/share/classes/sun/util/resources/LocaleNames_ms.properties - src/share/classes/sun/util/resources/LocaleNames_mt.properties - src/share/classes/sun/util/resources/LocaleNames_nl.properties - src/share/classes/sun/util/resources/LocaleNames_no.properties - src/share/classes/sun/util/resources/LocaleNames_no_NO_NY.properties - src/share/classes/sun/util/resources/LocaleNames_pl.properties - src/share/classes/sun/util/resources/LocaleNames_pt.properties - src/share/classes/sun/util/resources/LocaleNames_pt_BR.properties - src/share/classes/sun/util/resources/LocaleNames_pt_PT.properties - src/share/classes/sun/util/resources/LocaleNames_ro.properties - src/share/classes/sun/util/resources/LocaleNames_ru.properties - src/share/classes/sun/util/resources/LocaleNames_sk.properties - src/share/classes/sun/util/resources/LocaleNames_sl.properties - src/share/classes/sun/util/resources/LocaleNames_sq.properties - src/share/classes/sun/util/resources/LocaleNames_sr.properties - src/share/classes/sun/util/resources/LocaleNames_sr_Latn.properties - src/share/classes/sun/util/resources/LocaleNames_sv.properties - src/share/classes/sun/util/resources/LocaleNames_th.properties - src/share/classes/sun/util/resources/LocaleNames_tr.properties - src/share/classes/sun/util/resources/LocaleNames_uk.properties - src/share/classes/sun/util/resources/LocaleNames_vi.properties - src/share/classes/sun/util/resources/LocaleNames_zh.properties - src/share/classes/sun/util/resources/LocaleNames_zh_HK.java - src/share/classes/sun/util/resources/LocaleNames_zh_SG.properties - src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties ! src/share/classes/sun/util/resources/OpenListResourceBundle.java - src/share/classes/sun/util/resources/TimeZoneNames_de.java - src/share/classes/sun/util/resources/TimeZoneNames_en.java - src/share/classes/sun/util/resources/TimeZoneNames_en_CA.java - src/share/classes/sun/util/resources/TimeZoneNames_en_GB.java - src/share/classes/sun/util/resources/TimeZoneNames_en_IE.java - src/share/classes/sun/util/resources/TimeZoneNames_es.java - src/share/classes/sun/util/resources/TimeZoneNames_fr.java - src/share/classes/sun/util/resources/TimeZoneNames_hi.java - src/share/classes/sun/util/resources/TimeZoneNames_it.java - src/share/classes/sun/util/resources/TimeZoneNames_ja.java - src/share/classes/sun/util/resources/TimeZoneNames_ko.java - src/share/classes/sun/util/resources/TimeZoneNames_pt_BR.java - src/share/classes/sun/util/resources/TimeZoneNames_sv.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_HK.java - src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java + src/share/classes/sun/util/resources/ar/CalendarData_ar.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_AE.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_BH.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_DZ.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_EG.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_IQ.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_JO.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_KW.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LB.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LY.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_MA.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_OM.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_QA.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SA.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SD.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SY.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_TN.properties + src/share/classes/sun/util/resources/ar/CurrencyNames_ar_YE.properties + src/share/classes/sun/util/resources/ar/LocaleNames_ar.properties + src/share/classes/sun/util/resources/be/CalendarData_be.properties + src/share/classes/sun/util/resources/be/CurrencyNames_be_BY.properties + src/share/classes/sun/util/resources/be/LocaleNames_be.properties + src/share/classes/sun/util/resources/bg/CalendarData_bg.properties + src/share/classes/sun/util/resources/bg/CurrencyNames_bg_BG.properties + src/share/classes/sun/util/resources/bg/LocaleNames_bg.properties + src/share/classes/sun/util/resources/ca/CalendarData_ca.properties + src/share/classes/sun/util/resources/ca/CurrencyNames_ca_ES.properties + src/share/classes/sun/util/resources/ca/LocaleNames_ca.properties + src/share/classes/sun/util/resources/cs/CalendarData_cs.properties + src/share/classes/sun/util/resources/cs/CurrencyNames_cs_CZ.properties + src/share/classes/sun/util/resources/cs/LocaleNames_cs.properties + src/share/classes/sun/util/resources/da/CalendarData_da.properties + src/share/classes/sun/util/resources/da/CurrencyNames_da_DK.properties + src/share/classes/sun/util/resources/da/LocaleNames_da.properties + src/share/classes/sun/util/resources/de/CalendarData_de.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_AT.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_CH.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_DE.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_GR.properties + src/share/classes/sun/util/resources/de/CurrencyNames_de_LU.properties + src/share/classes/sun/util/resources/de/LocaleNames_de.properties + src/share/classes/sun/util/resources/de/TimeZoneNames_de.java + src/share/classes/sun/util/resources/el/CalendarData_el.properties + src/share/classes/sun/util/resources/el/CalendarData_el_CY.properties + src/share/classes/sun/util/resources/el/CurrencyNames_el_CY.properties + src/share/classes/sun/util/resources/el/CurrencyNames_el_GR.properties + src/share/classes/sun/util/resources/el/LocaleNames_el.properties + src/share/classes/sun/util/resources/el/LocaleNames_el_CY.properties + src/share/classes/sun/util/resources/en/CalendarData_en.properties + src/share/classes/sun/util/resources/en/CalendarData_en_GB.properties + src/share/classes/sun/util/resources/en/CalendarData_en_IE.properties + src/share/classes/sun/util/resources/en/CalendarData_en_MT.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_AU.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_CA.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_GB.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_IE.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_IN.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_MT.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_NZ.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_PH.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_SG.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_US.properties + src/share/classes/sun/util/resources/en/CurrencyNames_en_ZA.properties + src/share/classes/sun/util/resources/en/LocaleNames_en.properties + src/share/classes/sun/util/resources/en/LocaleNames_en_MT.properties + src/share/classes/sun/util/resources/en/LocaleNames_en_PH.properties + src/share/classes/sun/util/resources/en/LocaleNames_en_SG.properties + src/share/classes/sun/util/resources/en/TimeZoneNames_en.java + src/share/classes/sun/util/resources/en/TimeZoneNames_en_CA.java + src/share/classes/sun/util/resources/en/TimeZoneNames_en_GB.java + src/share/classes/sun/util/resources/en/TimeZoneNames_en_IE.java + src/share/classes/sun/util/resources/es/CalendarData_es.properties + src/share/classes/sun/util/resources/es/CalendarData_es_ES.properties + src/share/classes/sun/util/resources/es/CalendarData_es_US.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_AR.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_BO.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CL.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CO.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CR.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_CU.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_DO.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_EC.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_ES.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_GT.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_HN.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_MX.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_NI.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PA.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PE.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PR.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_PY.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_SV.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_US.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_UY.properties + src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties + src/share/classes/sun/util/resources/es/LocaleNames_es.properties + src/share/classes/sun/util/resources/es/LocaleNames_es_US.properties + src/share/classes/sun/util/resources/es/TimeZoneNames_es.java + src/share/classes/sun/util/resources/et/CalendarData_et.properties + src/share/classes/sun/util/resources/et/CurrencyNames_et_EE.properties + src/share/classes/sun/util/resources/et/LocaleNames_et.properties + src/share/classes/sun/util/resources/fi/CalendarData_fi.properties + src/share/classes/sun/util/resources/fi/CurrencyNames_fi_FI.properties + src/share/classes/sun/util/resources/fi/LocaleNames_fi.properties + src/share/classes/sun/util/resources/fr/CalendarData_fr.properties + src/share/classes/sun/util/resources/fr/CalendarData_fr_CA.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_BE.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CA.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CH.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_FR.properties + src/share/classes/sun/util/resources/fr/CurrencyNames_fr_LU.properties + src/share/classes/sun/util/resources/fr/LocaleNames_fr.properties + src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java + src/share/classes/sun/util/resources/ga/CurrencyNames_ga_IE.properties + src/share/classes/sun/util/resources/ga/LocaleNames_ga.properties + src/share/classes/sun/util/resources/hi/CalendarData_hi.properties + src/share/classes/sun/util/resources/hi/CurrencyNames_hi_IN.properties + src/share/classes/sun/util/resources/hi/LocaleNames_hi.properties + src/share/classes/sun/util/resources/hi/TimeZoneNames_hi.java + src/share/classes/sun/util/resources/hr/CalendarData_hr.properties + src/share/classes/sun/util/resources/hr/CurrencyNames_hr_HR.properties + src/share/classes/sun/util/resources/hr/LocaleNames_hr.properties + src/share/classes/sun/util/resources/hu/CalendarData_hu.properties + src/share/classes/sun/util/resources/hu/CurrencyNames_hu_HU.properties + src/share/classes/sun/util/resources/hu/LocaleNames_hu.properties + src/share/classes/sun/util/resources/in/CalendarData_in_ID.properties + src/share/classes/sun/util/resources/in/CurrencyNames_in_ID.properties + src/share/classes/sun/util/resources/in/LocaleNames_in.properties + src/share/classes/sun/util/resources/is/CalendarData_is.properties + src/share/classes/sun/util/resources/is/CurrencyNames_is_IS.properties + src/share/classes/sun/util/resources/is/LocaleNames_is.properties + src/share/classes/sun/util/resources/it/CalendarData_it.properties + src/share/classes/sun/util/resources/it/CurrencyNames_it.properties + src/share/classes/sun/util/resources/it/CurrencyNames_it_CH.properties + src/share/classes/sun/util/resources/it/CurrencyNames_it_IT.properties + src/share/classes/sun/util/resources/it/LocaleNames_it.properties + src/share/classes/sun/util/resources/it/TimeZoneNames_it.java + src/share/classes/sun/util/resources/iw/CalendarData_iw.properties + src/share/classes/sun/util/resources/iw/CurrencyNames_iw_IL.properties + src/share/classes/sun/util/resources/iw/LocaleNames_iw.properties + src/share/classes/sun/util/resources/ja/CalendarData_ja.properties + src/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties + src/share/classes/sun/util/resources/ja/CurrencyNames_ja_JP.properties + src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties + src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java + src/share/classes/sun/util/resources/ko/CalendarData_ko.properties + src/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties + src/share/classes/sun/util/resources/ko/CurrencyNames_ko_KR.properties + src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties + src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java + src/share/classes/sun/util/resources/lt/CalendarData_lt.properties + src/share/classes/sun/util/resources/lt/CurrencyNames_lt_LT.properties + src/share/classes/sun/util/resources/lt/LocaleNames_lt.properties + src/share/classes/sun/util/resources/lv/CalendarData_lv.properties + src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties + src/share/classes/sun/util/resources/lv/LocaleNames_lv.properties + src/share/classes/sun/util/resources/mk/CalendarData_mk.properties + src/share/classes/sun/util/resources/mk/CurrencyNames_mk_MK.properties + src/share/classes/sun/util/resources/mk/LocaleNames_mk.properties + src/share/classes/sun/util/resources/ms/CalendarData_ms_MY.properties + src/share/classes/sun/util/resources/ms/CurrencyNames_ms_MY.properties + src/share/classes/sun/util/resources/ms/LocaleNames_ms.properties + src/share/classes/sun/util/resources/mt/CalendarData_mt.properties + src/share/classes/sun/util/resources/mt/CalendarData_mt_MT.properties + src/share/classes/sun/util/resources/mt/CurrencyNames_mt_MT.properties + src/share/classes/sun/util/resources/mt/LocaleNames_mt.properties + src/share/classes/sun/util/resources/nl/CalendarData_nl.properties + src/share/classes/sun/util/resources/nl/CurrencyNames_nl_BE.properties + src/share/classes/sun/util/resources/nl/CurrencyNames_nl_NL.properties + src/share/classes/sun/util/resources/nl/LocaleNames_nl.properties + src/share/classes/sun/util/resources/no/CalendarData_no.properties + src/share/classes/sun/util/resources/no/CurrencyNames_no_NO.properties + src/share/classes/sun/util/resources/no/LocaleNames_no.properties + src/share/classes/sun/util/resources/no/LocaleNames_no_NO_NY.properties + src/share/classes/sun/util/resources/pl/CalendarData_pl.properties + src/share/classes/sun/util/resources/pl/CurrencyNames_pl_PL.properties + src/share/classes/sun/util/resources/pl/LocaleNames_pl.properties + src/share/classes/sun/util/resources/pt/CalendarData_pt.properties + src/share/classes/sun/util/resources/pt/CalendarData_pt_PT.properties + src/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties + src/share/classes/sun/util/resources/pt/CurrencyNames_pt_BR.properties + src/share/classes/sun/util/resources/pt/CurrencyNames_pt_PT.properties + src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties + src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties + src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties + src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java + src/share/classes/sun/util/resources/ro/CalendarData_ro.properties + src/share/classes/sun/util/resources/ro/CurrencyNames_ro_RO.properties + src/share/classes/sun/util/resources/ro/LocaleNames_ro.properties + src/share/classes/sun/util/resources/ru/CalendarData_ru.properties + src/share/classes/sun/util/resources/ru/CurrencyNames_ru_RU.properties + src/share/classes/sun/util/resources/ru/LocaleNames_ru.properties + src/share/classes/sun/util/resources/sk/CalendarData_sk.properties + src/share/classes/sun/util/resources/sk/CurrencyNames_sk_SK.properties + src/share/classes/sun/util/resources/sk/LocaleNames_sk.properties + src/share/classes/sun/util/resources/sl/CalendarData_sl.properties + src/share/classes/sun/util/resources/sl/CurrencyNames_sl_SI.properties + src/share/classes/sun/util/resources/sl/LocaleNames_sl.properties + src/share/classes/sun/util/resources/sq/CalendarData_sq.properties + src/share/classes/sun/util/resources/sq/CurrencyNames_sq_AL.properties + src/share/classes/sun/util/resources/sq/LocaleNames_sq.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_BA.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_ME.properties + src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_RS.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_BA.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_CS.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_BA.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_ME.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_RS.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_ME.properties + src/share/classes/sun/util/resources/sr/CurrencyNames_sr_RS.properties + src/share/classes/sun/util/resources/sr/LocaleNames_sr.properties + src/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties + src/share/classes/sun/util/resources/sv/CalendarData_sv.properties + src/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties + src/share/classes/sun/util/resources/sv/CurrencyNames_sv_SE.properties + src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties + src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java + src/share/classes/sun/util/resources/th/CalendarData_th.properties + src/share/classes/sun/util/resources/th/CurrencyNames_th_TH.properties + src/share/classes/sun/util/resources/th/LocaleNames_th.properties + src/share/classes/sun/util/resources/tr/CalendarData_tr.properties + src/share/classes/sun/util/resources/tr/CurrencyNames_tr_TR.properties + src/share/classes/sun/util/resources/tr/LocaleNames_tr.properties + src/share/classes/sun/util/resources/uk/CalendarData_uk.properties + src/share/classes/sun/util/resources/uk/CurrencyNames_uk_UA.properties + src/share/classes/sun/util/resources/uk/LocaleNames_uk.properties + src/share/classes/sun/util/resources/vi/CalendarData_vi.properties + src/share/classes/sun/util/resources/vi/CurrencyNames_vi_VN.properties + src/share/classes/sun/util/resources/vi/LocaleNames_vi.properties + src/share/classes/sun/util/resources/zh/CalendarData_zh.properties + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_CN.properties + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java + src/share/classes/sun/util/resources/zh/CurrencyNames_zh_TW.properties + src/share/classes/sun/util/resources/zh/LocaleNames_zh.properties + src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java + src/share/classes/sun/util/resources/zh/LocaleNames_zh_SG.properties + src/share/classes/sun/util/resources/zh/LocaleNames_zh_TW.properties + src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java + src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java + src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java + src/solaris/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/solaris/native/java/lang/java_props_macosx.c + src/solaris/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c + src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java + src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c + test/java/text/Format/DateFormat/ContextMonthNamesTest.java + test/java/text/Format/NumberFormat/MultipleNumberScriptTest.java + test/java/util/Calendar/CalendarTypeTest.java ! test/java/util/Locale/Bug6989440.java + test/java/util/Locale/ExtensionsTest.java ! test/java/util/Locale/LocaleCategory.sh + test/java/util/Locale/LocaleProviders.java + test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java + test/java/util/PluggableLocale/CalendarDataProviderTest.java + test/java/util/PluggableLocale/CalendarDataProviderTest.sh ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/ProviderTest.java + test/java/util/PluggableLocale/SupportedLocalesTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java ! test/java/util/PluggableLocale/providersrc/Makefile + test/java/util/PluggableLocale/providersrc/java.util.spi.CalendarDataProvider ! test/java/util/PluggableLocale/providersrc/java.util.spi.TimeZoneNameProvider ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java From fuyou001 at gmail.com Tue Aug 21 20:25:21 2012 From: fuyou001 at gmail.com (Fuyou001) Date: Wed, 22 Aug 2012 04:25:21 +0800 Subject: rmi network traffic In-Reply-To: <5033B93D.8030403@oracle.com> References: <75C65AFC-A14B-4C77-8702-27E8E08DB829@gmail.com> <8CCADD03-03ED-4B29-8136-81626E607B46@gmail.com> <5033B93D.8030403@oracle.com> Message-ID: <1E892AE9-4968-465C-A5CB-F0831C88B156@gmail.com> jdk6u33. ???? iPhone ? 2012-8-22?0:37?Darryl Mocek ??? > Fuyou001, > > the problem was fixed in Java 6u10. Which version of Java are you using? If you upgrade to 6u10 or later, the problem should be solved. > > Darryl > > On 08/21/2012 09:04 AM, Fuyou001 wrote: >>>> Hi all >>>> I deploy a RMI Service ,write a RMI Client(J2SE project) to access it and is ok .but the some code in web project,I use wireshark to find that every RMI request sent from our client to our server containing the list of all jars in the classpath for the application, My problem is similar to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6664389 >>>> How to slove it ? >>>> Thanks a lot >>>> >>>> -- >>>> ============================================= >>>> fuyou001 >>>> Best Regards >>>> > From jim.gish at oracle.com Tue Aug 21 20:45:49 2012 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 21 Aug 2012 16:45:49 -0400 Subject: Please Review: 6984084 (str) n times repetition of character constructor for java.lang.String Message-ID: <5033F37D.7060204@oracle.com> Please review http://cr.openjdk.java.net/~jgish/6984084-jdk8-StringRepeat/ This started in lambda, making changes to both StringJoiner and String. However, the dependence of String.repeat() on StringJoiner has been removed and the resulting non-lambda classes moved here for review. There will be a separate change and review for the StringJoiner changes in lamda-dev. Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From forax at univ-mlv.fr Tue Aug 21 21:59:03 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 21 Aug 2012 23:59:03 +0200 Subject: Please Review: 6984084 (str) n times repetition of character constructor for java.lang.String In-Reply-To: <5033F37D.7060204@oracle.com> References: <5033F37D.7060204@oracle.com> Message-ID: <503404A7.9060907@univ-mlv.fr> On 08/21/2012 10:45 PM, Jim Gish wrote: > Please review > http://cr.openjdk.java.net/~jgish/6984084-jdk8-StringRepeat/ > > > This started in lambda, making changes to both StringJoiner and > String. However, the dependence of String.repeat() on StringJoiner > has been removed and the resulting non-lambda classes moved here for > review. There will be a separate change and review for the > StringJoiner changes in lamda-dev. > > Thanks, > Jim > Hi Jim, I think you should remove the line If {@code n == 1}, then the current {@code String} is returned. from the javadoc of String because implementations should be free to use a StringBuilder, so it's more a comment of the current implementation than a specification. and nitpicking, throw new IllegalArgumentException( "n < 0"); should be (without the space) throw new IllegalArgumentException("n < 0"); otherwise, thumb up. cheers, R?mi From mike.duigou at oracle.com Tue Aug 21 22:04:00 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 21 Aug 2012 15:04:00 -0700 Subject: Please Review: 6984084 (str) n times repetition of character constructor for java.lang.String In-Reply-To: <5033F37D.7060204@oracle.com> References: <5033F37D.7060204@oracle.com> Message-ID: I'm still wondering if this functionality is really needed. AbstractStringBuilder/String/StringBuffer/StringBuilder:: - You'll need to escape the "<" in the javadoc as either < or {@literal <}. StringBuffer/StringBuilder:: - Is an additional {@inheritDoc} not needed? Repeat/AppendIntCharSequence:: - Tests should not have the classpatch exception license. Mike On Aug 21 2012, at 13:45 , Jim Gish wrote: > Please review http://cr.openjdk.java.net/~jgish/6984084-jdk8-StringRepeat/ > > This started in lambda, making changes to both StringJoiner and String. However, the dependence of String.repeat() on StringJoiner has been removed and the resulting non-lambda classes moved here for review. There will be a separate change and review for the StringJoiner changes in lamda-dev. > > Thanks, > Jim From fuyou001 at gmail.com Tue Aug 21 22:05:13 2012 From: fuyou001 at gmail.com (Fuyou001) Date: Wed, 22 Aug 2012 06:05:13 +0800 Subject: rmi network traffic In-Reply-To: <1E892AE9-4968-465C-A5CB-F0831C88B156@gmail.com> References: <75C65AFC-A14B-4C77-8702-27E8E08DB829@gmail.com> <8CCADD03-03ED-4B29-8136-81626E607B46@gmail.com> <5033B93D.8030403@oracle.com> <1E892AE9-4968-465C-A5CB-F0831C88B156@gmail.com> Message-ID: <19F99D7F-7FB0-4758-9699-4097A382B150@gmail.com> but jdk6u33 still have the problem.if in web project ,rmi request send to rmi service contains list jars of classpath for the web project.the problem may be caused by servelt container classload?but how to solve it? ? 2012-8-22?4:25?Fuyou001 ??? > > > ? 2012-8-22?0:37?Darryl Mocek ??? > >> Fuyou001, >> >> the problem was fixed in Java 6u10. Which version of Java are you using? If you upgrade to 6u10 or later, the problem should be solved. >> >> Darryl >> >> On 08/21/2012 09:04 AM, Fuyou001 wrote: >>>>> Hi all >>>>> I deploy a RMI Service ,write a RMI Client(J2SE project) to access it and is ok .but the some code in web project,I use wireshark to find that every RMI request sent from our client to our server containing the list of all jars in the classpath for the application, My problem is similar to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6664389 >>>>> How to slove it ? >>>>> Thanks a lot >>>>> >>>>> -- >>>>> ============================================= >>>>> fuyou001 >>>>> Best Regards >>>>> >> From david.holmes at oracle.com Wed Aug 22 01:52:12 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2012 11:52:12 +1000 Subject: Please Review: 6984084 (str) n times repetition of character constructor for java.lang.String In-Reply-To: <5033F37D.7060204@oracle.com> References: <5033F37D.7060204@oracle.com> Message-ID: <50343B4C.4080406@oracle.com> Hi Jim, On 22/08/2012 6:45 AM, Jim Gish wrote: > Please review > http://cr.openjdk.java.net/~jgish/6984084-jdk8-StringRepeat/ > > > This started in lambda, making changes to both StringJoiner and String. > However, the dependence of String.repeat() on StringJoiner has been > removed and the resulting non-lambda classes moved here for review. > There will be a separate change and review for the StringJoiner changes > in lamda-dev. AbstractStringBuilder.java: "If {@code n == 0}, then adds the empty string." It doesn't - if n == 0 nothing happens (which seems the right thing to me). "If @{code cs} is {@code null}, then adds {@code "null"} {@code n} times." That seems questionable semantics to me. What is the motivation for this? --- String.java Does repeat() really carry its own weight? The 0 and 1 cases are uninteresting and for anything else StringBuilder can be used directly. --- StringBuilder.java /** + * @throws IllegalArgumentException if n < 0 {@inheritDoc} This is wrong as you've already written the inherited doc "if n < 0". + * @since 1.8 + */ + public StringBuilder append(int n, CharSequence cs) { + super.append(n, cs); + return this; + } But why are you overriding this in the first place ??? There seems to be no change in functionality or specification. David ----- > Thanks, > Jim > From dingxmin at linux.vnet.ibm.com Wed Aug 22 02:11:54 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Wed, 22 Aug 2012 10:11:54 +0800 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <502E079F.1080706@oracle.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> <1344362827.27351.22.camel@chalkhill> <50225B8B.4040307@oracle.com> <1344442209.23350.232.camel@chalkhill> <50237AA8.1040801@oracle.com> <1345131152.2980.302.camel@chalkhill> <502E079F.1080706@oracle.com> Message-ID: <50343FEA.4060700@linux.vnet.ibm.com> Hi Alan and David, So is it OK to commit the patch in Terminator class? I think Neil will continue proposing the change in cvmi mailing list. Many thanks to all. Best regards, Frank On 8/17/2012 4:58 PM, Alan Bateman wrote: > On 16/08/2012 16:32, Neil Richards wrote: >> : >> >> However, I still consider that VM modification would be logically >> orthogonal to Frank's suggested change, and suggest that his change >> could continue to be approved for contribution at this point, regardless >> of the separate VM-related discussion in this area. >> > Both David and I have already reviewed Frank's change and okay with it. > > I'll leave it to you whether you want to propose a change to > JVM_RegisterSignal. > > -Alan > From david.holmes at oracle.com Wed Aug 22 02:13:38 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2012 12:13:38 +1000 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <50343FEA.4060700@linux.vnet.ibm.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> <1344362827.27351.22.camel@chalkhill> <50225B8B.4040307@oracle.com> <1344442209.23350.232.camel@chalkhill> <50237AA8.1040801@oracle.com> <1345131152.2980.302.camel@chalkhill> <502E079F.1080706@oracle.com> <50343FEA.4060700@linux.vnet.ibm.com> Message-ID: <50344052.1040200@oracle.com> On 22/08/2012 12:11 PM, Frank Ding wrote: > Hi Alan and David, > So is it OK to commit the patch in Terminator class? I think Neil will > continue proposing the change in cvmi mailing list. As Alan already said: "Both David and I have already reviewed Frank's change and okay with it." Cheers, David > Many thanks to all. > > Best regards, > Frank > > On 8/17/2012 4:58 PM, Alan Bateman wrote: >> On 16/08/2012 16:32, Neil Richards wrote: >>> : >>> >>> However, I still consider that VM modification would be logically >>> orthogonal to Frank's suggested change, and suggest that his change >>> could continue to be approved for contribution at this point, regardless >>> of the separate VM-related discussion in this area. >>> >> Both David and I have already reviewed Frank's change and okay with it. >> >> I'll leave it to you whether you want to propose a change to >> JVM_RegisterSignal. >> >> -Alan >> > From fuyou001 at gmail.com Wed Aug 22 02:23:49 2012 From: fuyou001 at gmail.com (fuyou) Date: Wed, 22 Aug 2012 10:23:49 +0800 Subject: rmi network traffic Message-ID: Hi all I deploy a RMI Service ,write a RMI Client(J2SE project) to access it and is ok .but the some code in web project,I use wireshark to find that every RMI request sent from our client to our server containing the list of all jars in the classpath for the application, My problem is similar to bugs.sun.com java -version java version "1.6.0_33" Java(TM) SE Runtime Environment (build 1.6.0_33-b03) Java HotSpot(TM) Server VM (build 20.8-b03, mixed mode) This issues may be caused by Servlet Container(etc Jetty/Resin) classloader How to slove it ? Sorry for disturbing again. Thanks a lot! -- ============================================= fuyou001 Best Regards From fuyou001 at gmail.com Wed Aug 22 02:35:20 2012 From: fuyou001 at gmail.com (fuyou) Date: Wed, 22 Aug 2012 10:35:20 +0800 Subject: rmi network traffic In-Reply-To: References: Message-ID: spell error: slove should be solve. 2012/8/22 fuyou > Hi all > > I deploy a RMI Service ,write a RMI Client(J2SE project) to access it > and is ok .but the some code in web project,I use wireshark to find that > every RMI request sent from our client to our server containing the list of > all jars in the classpath for the application, My problem is similar to > bugs.sun.com > > java -version > java version "1.6.0_33" > Java(TM) SE Runtime Environment (build 1.6.0_33-b03) > Java HotSpot(TM) Server VM (build 20.8-b03, mixed mode) > > This issues may be caused by Servlet Container(etc Jetty/Resin) > classloader > How to slove it ? > > Sorry for disturbing again. > Thanks a lot! > > -- > ============================================= > > fuyou001 > Best Regards > > > -- ============================================= fuyou001 Best Regards From yiming.wang at oracle.com Wed Aug 22 07:54:03 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 22 Aug 2012 15:54:03 +0800 Subject: [PATCH] Review request: 6962637 TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system Message-ID: <5034901B.1060103@oracle.com> Hi, Please help to review the fix below for bug **6962637 TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html Root cause is the test is not reliable when system is busy, if disk space is changed by some other program, test can fail. so the fix is to check file.length() instead of disk space. Regards, Eric From david.holmes at oracle.com Wed Aug 22 08:02:39 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2012 18:02:39 +1000 Subject: [PATCH] Review request: 6962637 TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system In-Reply-To: <5034901B.1060103@oracle.com> References: <5034901B.1060103@oracle.com> Message-ID: <5034921F.8080002@oracle.com> Hi Eric, On 22/08/2012 5:54 PM, Eric Wang wrote: > Please help to review the fix below for bug **6962637 > TEST_BUG: > java/io/File/MaxPathLength.java may fail in busy system > http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html > > Root cause is the test is not reliable when system is busy, if disk > space is changed by some other program, test can fail. so the fix is to > check file.length() instead of disk space. I can not figure out what the original version of the test was doing with the disk space measurements but I can certainly appreciate that they could be changing dynamically while the test is running. But I don't really understand why dirFile is expected to have a zero length ??? David > Regards, > Eric From yiming.wang at oracle.com Wed Aug 22 08:10:24 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 22 Aug 2012 16:10:24 +0800 Subject: [PATCH] Review request: 6962637 TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system In-Reply-To: <5034921F.8080002@oracle.com> References: <5034901B.1060103@oracle.com> <5034921F.8080002@oracle.com> Message-ID: <503493F0.30708@oracle.com> Hi David, To use dirFile.length() == 0 to replace the disk space measurement as guess the original test tries to prove that there's no extra disk spent when creating empty folders. Regards, Eric On 2012/8/22 16:02, David Holmes wrote: > Hi Eric, > > On 22/08/2012 5:54 PM, Eric Wang wrote: >> Please help to review the fix below for bug **6962637 >> TEST_BUG: >> java/io/File/MaxPathLength.java may fail in busy system >> http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html >> >> Root cause is the test is not reliable when system is busy, if disk >> space is changed by some other program, test can fail. so the fix is to >> check file.length() instead of disk space. > > I can not figure out what the original version of the test was doing > with the disk space measurements but I can certainly appreciate that > they could be changing dynamically while the test is running. > > But I don't really understand why dirFile is expected to have a zero > length ??? > > David > >> Regards, >> Eric From amy.lu at oracle.com Wed Aug 22 09:07:25 2012 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 22 Aug 2012 17:07:25 +0800 Subject: [PATCH] Review request: 6962637 TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system In-Reply-To: <503493F0.30708@oracle.com> References: <5034901B.1060103@oracle.com> <5034921F.8080002@oracle.com> <503493F0.30708@oracle.com> Message-ID: <5034A14D.9050801@oracle.com> Hi, Eric I'm a little confused about on which platform should this test run? In the old code, the test should run: i = 4,5,6 on all platforms except win_9 win_me ( and solaris due to machine issue(?)) i = 20 on windows only Now in new code, the whole test will only run on windows. Thanks, Amy On 8/22/12 4:10 PM, Eric Wang wrote: > Hi David, > > To use dirFile.length() == 0 to replace the disk space measurement as > guess the original test tries to prove that there's no extra disk > spent when creating empty folders. > > Regards, > Eric > > On 2012/8/22 16:02, David Holmes wrote: >> Hi Eric, >> >> On 22/08/2012 5:54 PM, Eric Wang wrote: >>> Please help to review the fix below for bug **6962637 >>> TEST_BUG: >>> java/io/File/MaxPathLength.java may fail in busy system >>> http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html >>> >>> Root cause is the test is not reliable when system is busy, if disk >>> space is changed by some other program, test can fail. so the fix is to >>> check file.length() instead of disk space. >> >> I can not figure out what the original version of the test was doing >> with the disk space measurements but I can certainly appreciate that >> they could be changing dynamically while the test is running. >> >> But I don't really understand why dirFile is expected to have a zero >> length ??? >> >> David >> >>> Regards, >>> Eric > From david.holmes at oracle.com Wed Aug 22 09:27:38 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2012 19:27:38 +1000 Subject: [PATCH] Review request: 6962637 TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system In-Reply-To: <503493F0.30708@oracle.com> References: <5034901B.1060103@oracle.com> <5034921F.8080002@oracle.com> <503493F0.30708@oracle.com> Message-ID: <5034A60A.9070103@oracle.com> On 22/08/2012 6:10 PM, Eric Wang wrote: > Hi David, > > To use dirFile.length() == 0 to replace the disk space measurement as > guess the original test tries to prove that there's no extra disk spent > when creating empty folders. Sorry I don't understand. File.length() says: public long length() Returns the length of the file denoted by this abstract pathname. The return value is unspecified if this pathname denotes a directory. Where it is required to distinguish an I/O exception from the case that 0L is returned, or where several attributes of the same file are required at the same time, then the Files.readAttributes method may be used. Returns: The length, in bytes, of the file denoted by this abstract pathname, or 0L if the file does not exist. Some operating systems may return 0L for pathnames denoting system-dependent entities such as devices or pipes. ---- In this case we verify we have a directory before we do the length() test, which means the return value from length is unspecified. So I don't understand how length() is being used here. David ----- > Regards, > Eric > > On 2012/8/22 16:02, David Holmes wrote: >> Hi Eric, >> >> On 22/08/2012 5:54 PM, Eric Wang wrote: >>> Please help to review the fix below for bug **6962637 >>> TEST_BUG: >>> java/io/File/MaxPathLength.java may fail in busy system >>> http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html >>> >>> Root cause is the test is not reliable when system is busy, if disk >>> space is changed by some other program, test can fail. so the fix is to >>> check file.length() instead of disk space. >> >> I can not figure out what the original version of the test was doing >> with the disk space measurements but I can certainly appreciate that >> they could be changing dynamically while the test is running. >> >> But I don't really understand why dirFile is expected to have a zero >> length ??? >> >> David >> >>> Regards, >>> Eric > From Alan.Bateman at oracle.com Wed Aug 22 09:46:49 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Aug 2012 10:46:49 +0100 Subject: Please Review: 6984084 (str) n times repetition of character constructor for java.lang.String In-Reply-To: <5033F37D.7060204@oracle.com> References: <5033F37D.7060204@oracle.com> Message-ID: <5034AA89.5010609@oracle.com> On 21/08/2012 21:45, Jim Gish wrote: > Please review > http://cr.openjdk.java.net/~jgish/6984084-jdk8-StringRepeat/ > > > This started in lambda, making changes to both StringJoiner and > String. However, the dependence of String.repeat() on StringJoiner > has been removed and the resulting non-lambda classes moved here for > review. There will be a separate change and review for the > StringJoiner changes in lamda-dev. On the surface then String s = "foo".repeat(5); seems nice. I just wonder whether we can get any data on usage of similar methods in commonly used libraries. Some languages such as Python have a built-ins for this, and I think C# has a ctor, just not clear (to me anyway) how often the latter or equivalent it used. Folks here might be able to jump in to indicate how often they've needed to do this and whether the common-case is a repeated char rather than String (or CharSequence). Folks here might also have ideas on getting some usage data in other libraries or languages. I'm less sure about StringBuilder.append(int,CharSequence) as sb.append(5,cs) is not much less than "for (int i=0; i<5; i++) sb.append(cs);". I also wonder whether it may be more common to want to appear a number of chars, sb.append(5, '-') for example. Anyway, on the javadoc then AbstractStringBuilder.append suggests special hanging for n==1 but I think that can be dropped the javadoc. On the implementation then it would be good to make the style consistent with the existing code (4 spaces for indent, etc.). Otherwise it seems okay. I assume the update to test/Makefile is just for your own local usage and that you aren't planning to include this (the jdk_lang target already runs the tests in test/java/lang/**). In Repeat.java (same thing in AppendIntCharSequence.java) then I think the -1 test can be simplified to: try { "c".repeat(-1); throw new RuntimeException(...); } catch (IllegalArgumenetException expected) { } We use GPL on the tests so you need to check AppendIntCharSequence.java. On test coverage then it looks like StringBuffer is missed. Also the assertion that appending null will append "null". -Alan. From Alan.Bateman at oracle.com Wed Aug 22 10:01:23 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Aug 2012 11:01:23 +0100 Subject: [PATCH] Review request: 6962637 TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system In-Reply-To: <5034901B.1060103@oracle.com> References: <5034901B.1060103@oracle.com> Message-ID: <5034ADF3.4040200@oracle.com> On 22/08/2012 08:54, Eric Wang wrote: > Hi, > > Please help to review the fix below for bug 6962637 > TEST_BUG: > java/io/File/MaxPathLength.java may fail in busy system > http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html > > Root cause is the test is not reliable when system is busy, if disk > space is changed by some other program, test can fail. so the fix is > to check file.length() instead of disk space. Thanks for liberating another test, I remember that used to fail regularly when there was other activity on the system (or when running with -concurrency:auto where there are tests running concurrently). I see you are exchanges mails with David about the dir.length check that you have added. I don't think it make sense and that check should be removed. -Alan. From vitalyd at gmail.com Wed Aug 22 12:34:46 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 22 Aug 2012 08:34:46 -0400 Subject: Please Review: 6984084 (str) n times repetition of character constructor for java.lang.String In-Reply-To: <5034AA89.5010609@oracle.com> References: <5033F37D.7060204@oracle.com> <5034AA89.5010609@oracle.com> Message-ID: FWIW, the few times I "needed" a repeat operation it's always been with a char, not a string. I think a common use case for this to create some layout in the printed string, such as adding a separator (e.g. "*********", "---------", etc) or adding white space padding (could also be something like "..........") to align output - both are just chars. Sent from my phone On Aug 22, 2012 5:47 AM, "Alan Bateman" wrote: > On 21/08/2012 21:45, Jim Gish wrote: > >> Please review http://cr.openjdk.java.net/~**jgish/6984084-jdk8-** >> StringRepeat/< >> http://cr.openjdk.java.net/%**7Ejgish/6984084-jdk8-**StringRepeat/ >> > >> >> This started in lambda, making changes to both StringJoiner and String. >> However, the dependence of String.repeat() on StringJoiner has been >> removed and the resulting non-lambda classes moved here for review. There >> will be a separate change and review for the StringJoiner changes in >> lamda-dev. >> > On the surface then String s = "foo".repeat(5); seems nice. I just wonder > whether we can get any data on usage of similar methods in commonly used > libraries. Some languages such as Python have a built-ins for this, and I > think C# has a ctor, just not clear (to me anyway) how often the latter or > equivalent it used. Folks here might be able to jump in to indicate how > often they've needed to do this and whether the common-case is a repeated > char rather than String (or CharSequence). Folks here might also have ideas > on getting some usage data in other libraries or languages. > > I'm less sure about StringBuilder.append(int,**CharSequence) as > sb.append(5,cs) is not much less than "for (int i=0; i<5; i++) > sb.append(cs);". I also wonder whether it may be more common to want to > appear a number of chars, sb.append(5, '-') for example. > > Anyway, on the javadoc then AbstractStringBuilder.append suggests special > hanging for n==1 but I think that can be dropped the javadoc. > > On the implementation then it would be good to make the style consistent > with the existing code (4 spaces for indent, etc.). Otherwise it seems okay. > > I assume the update to test/Makefile is just for your own local usage and > that you aren't planning to include this (the jdk_lang target already runs > the tests in test/java/lang/**). > > In Repeat.java (same thing in AppendIntCharSequence.java) then I think the > -1 test can be simplified to: > > try { > "c".repeat(-1); > throw new RuntimeException(...); > } catch (IllegalArgumenetException expected) { } > > We use GPL on the tests so you need to check AppendIntCharSequence.java. > > On test coverage then it looks like StringBuffer is missed. Also the > assertion that appending null will append "null". > > -Alan. > > > From scolebourne at joda.org Wed Aug 22 14:08:17 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 22 Aug 2012 15:08:17 +0100 Subject: Please Review: 6984084 (str) n times repetition of character constructor for java.lang.String In-Reply-To: <5034AA89.5010609@oracle.com> References: <5033F37D.7060204@oracle.com> <5034AA89.5010609@oracle.com> Message-ID: On 22 August 2012 10:46, Alan Bateman wrote: > On 21/08/2012 21:45, Jim Gish wrote: >> Please review http://cr.openjdk.java.net/~jgish/6984084-jdk8-StringRepeat/ >> >> >> This started in lambda, making changes to both StringJoiner and String. >> However, the dependence of String.repeat() on StringJoiner has been removed >> and the resulting non-lambda classes moved here for review. There will be a >> separate change and review for the StringJoiner changes in lamda-dev. > > On the surface then String s = "foo".repeat(5); seems nice. I just wonder > whether we can get any data on usage of similar methods in commonly used > libraries. Some languages such as Python have a built-ins for this, and I > think C# has a ctor, just not clear (to me anyway) how often the latter or > equivalent it used. Folks here might be able to jump in to indicate how > often they've needed to do this and whether the common-case is a repeated > char rather than String (or CharSequence). Folks here might also have ideas > on getting some usage data in other libraries or languages. I don't think this is used that often and of marginal value in the JDK. If added, perhaps it should go in the buffer/builder only. By comparison, padding is a much useful missing JDK feature: https://github.com/apache/commons-lang/blob/trunk/src/main/java/org/apache/commons/lang3/StringUtils.java#L4451 Stephen From david.holmes at oracle.com Thu Aug 23 00:35:44 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Aug 2012 10:35:44 +1000 Subject: Please Review: 6984084 (str) n times repetition of character constructor for java.lang.String In-Reply-To: <50343B4C.4080406@oracle.com> References: <5033F37D.7060204@oracle.com> <50343B4C.4080406@oracle.com> Message-ID: <50357AE0.4090502@oracle.com> On 22/08/2012 11:52 AM, David Holmes wrote: > StringBuilder.java > > /** > + * @throws IllegalArgumentException if n < 0 {@inheritDoc} > > This is wrong as you've already written the inherited doc "if n < 0". > > + * @since 1.8 > + */ > + public StringBuilder append(int n, CharSequence cs) { > + super.append(n, cs); > + return this; > + } > > But why are you overriding this in the first place ??? There seems to be > no change in functionality or specification. I missed the covariant change to the return type from AbstractStringBuilder to StringBuilder. I also suggested in email that the above could simply be: return super.append(n, cs); but that would also need a cast to StringBuilder. So what Jim has is fine. David ----- > David > ----- > >> Thanks, >> Jim >> From dingxmin at linux.vnet.ibm.com Thu Aug 23 08:05:13 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Thu, 23 Aug 2012 16:05:13 +0800 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <50344052.1040200@oracle.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> <1344362827.27351.22.camel@chalkhill> <50225B8B.4040307@oracle.com> <1344442209.23350.232.camel@chalkhill> <50237AA8.1040801@oracle.com> <1345131152.2980.302.camel@chalkhill> <502E079F.1080706@oracle.com> <50343FEA.4060700@linux.vnet.ibm.com> <50344052.1040200@oracle.com> Message-ID: <5035E439.50402@linux.vnet.ibm.com> Thanks all. I created sun bug 7193463 to track the code change. Best regards, Frank On 8/22/2012 10:13 AM, David Holmes wrote: > On 22/08/2012 12:11 PM, Frank Ding wrote: >> Hi Alan and David, >> So is it OK to commit the patch in Terminator class? I think Neil will >> continue proposing the change in cvmi mailing list. > > As Alan already said: > > "Both David and I have already reviewed Frank's change and okay with it." > > Cheers, > David > >> Many thanks to all. >> >> Best regards, >> Frank >> >> On 8/17/2012 4:58 PM, Alan Bateman wrote: >>> On 16/08/2012 16:32, Neil Richards wrote: >>>> : >>>> >>>> However, I still consider that VM modification would be logically >>>> orthogonal to Frank's suggested change, and suggest that his change >>>> could continue to be approved for contribution at this point, >>>> regardless >>>> of the separate VM-related discussion in this area. >>>> >>> Both David and I have already reviewed Frank's change and okay with it. >>> >>> I'll leave it to you whether you want to propose a change to >>> JVM_RegisterSignal. >>> >>> -Alan >>> >> > From david.holmes at oracle.com Thu Aug 23 08:27:58 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Aug 2012 18:27:58 +1000 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <5035E439.50402@linux.vnet.ibm.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> <1344362827.27351.22.camel@chalkhill> <50225B8B.4040307@oracle.com> <1344442209.23350.232.camel@chalkhill> <50237AA8.1040801@oracle.com> <1345131152.2980.302.camel@chalkhill> <502E079F.1080706@oracle.com> <50343FEA.4060700@linux.vnet.ibm.com> <50344052.1040200@oracle.com> <5035E439.50402@linux.vnet.ibm.com> Message-ID: <5035E98E.1050303@oracle.com> On 23/08/2012 6:05 PM, Frank Ding wrote: > Thanks all. I created sun bug 7193463 to track the code change. We already have 7189865 for this. David > Best regards, > Frank > > On 8/22/2012 10:13 AM, David Holmes wrote: >> On 22/08/2012 12:11 PM, Frank Ding wrote: >>> Hi Alan and David, >>> So is it OK to commit the patch in Terminator class? I think Neil will >>> continue proposing the change in cvmi mailing list. >> >> As Alan already said: >> >> "Both David and I have already reviewed Frank's change and okay with it." >> >> Cheers, >> David >> >>> Many thanks to all. >>> >>> Best regards, >>> Frank >>> >>> On 8/17/2012 4:58 PM, Alan Bateman wrote: >>>> On 16/08/2012 16:32, Neil Richards wrote: >>>>> : >>>>> >>>>> However, I still consider that VM modification would be logically >>>>> orthogonal to Frank's suggested change, and suggest that his change >>>>> could continue to be approved for contribution at this point, >>>>> regardless >>>>> of the separate VM-related discussion in this area. >>>>> >>>> Both David and I have already reviewed Frank's change and okay with it. >>>> >>>> I'll leave it to you whether you want to propose a change to >>>> JVM_RegisterSignal. >>>> >>>> -Alan >>>> >>> >> > From luchsh at linux.vnet.ibm.com Thu Aug 23 08:30:01 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Thu, 23 Aug 2012 08:30:01 +0000 Subject: hg: jdk8/tl/jdk: 7193463: Improve registering signal handlers in java.lang.Terminator.setup() Message-ID: <20120823083029.3251A476A8@hg.openjdk.java.net> Changeset: e7b53fe85540 Author: dingxmin Date: 2012-08-23 16:28 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7b53fe85540 7193463: Improve registering signal handlers in java.lang.Terminator.setup() Reviewed-by: dholmes, alanb ! src/solaris/classes/java/lang/Terminator.java ! src/windows/classes/java/lang/Terminator.java From dingxmin at linux.vnet.ibm.com Thu Aug 23 08:37:32 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Thu, 23 Aug 2012 16:37:32 +0800 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <5035E98E.1050303@oracle.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> <1344362827.27351.22.camel@chalkhill> <50225B8B.4040307@oracle.com> <1344442209.23350.232.camel@chalkhill> <50237AA8.1040801@oracle.com> <1345131152.2980.302.camel@chalkhill> <502E079F.1080706@oracle.com> <50343FEA.4060700@linux.vnet.ibm.com> <50344052.1040200@oracle.com> <5035E439.50402@linux.vnet.ibm.com> <5035E98E.1050303@oracle.com> Message-ID: <5035EBCC.7060502@linux.vnet.ibm.com> Hi David, Sorry that Jonathan has already committed the code with bug id 7193463. Could you please dup the 2 bugs? Best regards, Frank On 8/23/2012 4:27 PM, David Holmes wrote: > On 23/08/2012 6:05 PM, Frank Ding wrote: >> Thanks all. I created sun bug 7193463 to track the code change. > > We already have 7189865 for this. > > David > >> Best regards, >> Frank >> >> On 8/22/2012 10:13 AM, David Holmes wrote: >>> On 22/08/2012 12:11 PM, Frank Ding wrote: >>>> Hi Alan and David, >>>> So is it OK to commit the patch in Terminator class? I think Neil will >>>> continue proposing the change in cvmi mailing list. >>> >>> As Alan already said: >>> >>> "Both David and I have already reviewed Frank's change and okay with >>> it." >>> >>> Cheers, >>> David >>> >>>> Many thanks to all. >>>> >>>> Best regards, >>>> Frank >>>> >>>> On 8/17/2012 4:58 PM, Alan Bateman wrote: >>>>> On 16/08/2012 16:32, Neil Richards wrote: >>>>>> : >>>>>> >>>>>> However, I still consider that VM modification would be logically >>>>>> orthogonal to Frank's suggested change, and suggest that his change >>>>>> could continue to be approved for contribution at this point, >>>>>> regardless >>>>>> of the separate VM-related discussion in this area. >>>>>> >>>>> Both David and I have already reviewed Frank's change and okay >>>>> with it. >>>>> >>>>> I'll leave it to you whether you want to propose a change to >>>>> JVM_RegisterSignal. >>>>> >>>>> -Alan >>>>> >>>> >>> >> > From david.holmes at oracle.com Thu Aug 23 10:38:46 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Aug 2012 20:38:46 +1000 Subject: Improve registering signal handlers in java.lang.Terminator.setup() In-Reply-To: <5035EBCC.7060502@linux.vnet.ibm.com> References: <501B8049.2020705@linux.vnet.ibm.com> <501F231C.9050300@oracle.com> <501F86FD.9040801@linux.vnet.ibm.com> <501FA5C3.6040706@oracle.com> <5020857A.30509@linux.vnet.ibm.com> <50208D13.2090006@oracle.com> <5020DCB8.4010609@oracle.com> <1344348131.28663.42.camel@chalkhill> <502149D9.6060304@oracle.com> <1344362827.27351.22.camel@chalkhill> <50225B8B.4040307@oracle.com> <1344442209.23350.232.camel@chalkhill> <50237AA8.1040801@oracle.com> <1345131152.2980.302.camel@chalkhill> <502E079F.1080706@oracle.com> <50343FEA.4060700@linux.vnet.ibm.com> <50344052.1040200@oracle.com> <5035E439.50402@linux.vnet.ibm.com> <5035E98E.1050303@oracle.com> <5035EBCC.7060502@linux.vnet.ibm.com> Message-ID: <50360835.5010106@oracle.com> On 23/08/2012 6:37 PM, Frank Ding wrote: > Hi David, > Sorry that Jonathan has already committed the code with bug id 7193463. > Could you please dup the 2 bugs? Alan has already taken care of it. David > Best regards, > Frank > > On 8/23/2012 4:27 PM, David Holmes wrote: >> On 23/08/2012 6:05 PM, Frank Ding wrote: >>> Thanks all. I created sun bug 7193463 to track the code change. >> >> We already have 7189865 for this. >> >> David >> >>> Best regards, >>> Frank >>> >>> On 8/22/2012 10:13 AM, David Holmes wrote: >>>> On 22/08/2012 12:11 PM, Frank Ding wrote: >>>>> Hi Alan and David, >>>>> So is it OK to commit the patch in Terminator class? I think Neil will >>>>> continue proposing the change in cvmi mailing list. >>>> >>>> As Alan already said: >>>> >>>> "Both David and I have already reviewed Frank's change and okay with >>>> it." >>>> >>>> Cheers, >>>> David >>>> >>>>> Many thanks to all. >>>>> >>>>> Best regards, >>>>> Frank >>>>> >>>>> On 8/17/2012 4:58 PM, Alan Bateman wrote: >>>>>> On 16/08/2012 16:32, Neil Richards wrote: >>>>>>> : >>>>>>> >>>>>>> However, I still consider that VM modification would be logically >>>>>>> orthogonal to Frank's suggested change, and suggest that his change >>>>>>> could continue to be approved for contribution at this point, >>>>>>> regardless >>>>>>> of the separate VM-related discussion in this area. >>>>>>> >>>>>> Both David and I have already reviewed Frank's change and okay >>>>>> with it. >>>>>> >>>>>> I'll leave it to you whether you want to propose a change to >>>>>> JVM_RegisterSignal. >>>>>> >>>>>> -Alan >>>>>> >>>>> >>>> >>> >> > From alan.bateman at oracle.com Thu Aug 23 12:08:02 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 23 Aug 2012 12:08:02 +0000 Subject: hg: jdk8/tl/jdk: 7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx] Message-ID: <20120823120831.28817476AC@hg.openjdk.java.net> Changeset: de5a85353f4d Author: alanb Date: 2012-08-23 13:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de5a85353f4d 7191587: (se) SelectionKey.interestOps does not defer changing the interest set to the next select [macosx] Reviewed-by: alanb Contributed-by: Jason T Greene ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java From Ulf.Zibis at gmx.de Thu Aug 23 12:45:58 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 23 Aug 2012 14:45:58 +0200 Subject: Please Review: 6984084 (str) n times repetition of character constructor for java.lang.String In-Reply-To: <50357AE0.4090502@oracle.com> References: <5033F37D.7060204@oracle.com> <50343B4C.4080406@oracle.com> <50357AE0.4090502@oracle.com> Message-ID: <50362606.6080103@gmx.de> Hopefully some day we would have fixed: Bug 6373386 - Method chaining for instance methods that return void That would prevent us from such bloated sub classes. Hopefully such "workarounds" would not force later incompatibilities -Ulf Am 23.08.2012 02:35, schrieb David Holmes: > On 22/08/2012 11:52 AM, David Holmes wrote: >> StringBuilder.java >> >> /** >> + * @throws IllegalArgumentException if n < 0 {@inheritDoc} >> >> This is wrong as you've already written the inherited doc "if n < 0". >> >> + * @since 1.8 >> + */ >> + public StringBuilder append(int n, CharSequence cs) { >> + super.append(n, cs); >> + return this; >> + } >> >> But why are you overriding this in the first place ??? There seems to be >> no change in functionality or specification. > > I missed the covariant change to the return type from AbstractStringBuilder to StringBuilder. > > I also suggested in email that the above could simply be: > > return super.append(n, cs); > > but that would also need a cast to StringBuilder. So what Jim has is fine. > > David > ----- From mandy.chung at oracle.com Thu Aug 23 17:43:23 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Aug 2012 10:43:23 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader Message-ID: <50366BBB.2060406@oracle.com> This change is to bring the jdk modularization changes from jigsaw repo [1] to jdk8. This allows the jdk modularization changes to be exposed for testing as early as possible and minimize the amount of changes carried in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ Summary: The VM bootstrap class loader (null) has been the defining class loader for all system classes (i.e. rt.jar and any classes on the bootclasspath). In modular world, the system classes are going to be modularized into multiple modulesand and many of which will be loaded by its own (non-null) module loader. The JDK implementation has the assumption that the defining class loader of system classes is null and it'll no longer be true when running as modules. Typical patterns in the JDK code include: Class.forName(classname, false, null) should be changed to: Class.forName(classname, false,) if (loader == null) condition check should be modified to check if the loader is responsible for loading system classes. This is the first set of change for this problem we identified. Similar change in other components will be made in the future. Testing: run all jdk core test targets on all platforms. Thanks Mandy P.S. I'm cc'ing servicebility-dev as this patch modifies 2 files in the java.lang.management. From Alan.Bateman at oracle.com Thu Aug 23 18:58:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Aug 2012 19:58:25 +0100 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <50366BBB.2060406@oracle.com> References: <50366BBB.2060406@oracle.com> Message-ID: <50367D51.90506@oracle.com> On 23/08/2012 18:43, Mandy Chung wrote: > This change is to bring the jdk modularization changes from jigsaw > repo [1] > to jdk8. This allows the jdk modularization changes to be exposed for > testing as early as possible and minimize the amount of changes carried > in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ > This looks good to me and it's good to have these changes in jdk8. One suggestion for ReflectUtil is to add a private static boolean isAncestor method as I think that would make the checks in needsPackageAccessCheck easier to read. Also in ClassLoader you could use just use needsClassLoaderPermissionCheck(from,to). -Alan. From mandy.chung at oracle.com Thu Aug 23 19:33:48 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Aug 2012 12:33:48 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <50367D51.90506@oracle.com> References: <50366BBB.2060406@oracle.com> <50367D51.90506@oracle.com> Message-ID: <5036859C.3020801@oracle.com> On 8/23/2012 11:58 AM, Alan Bateman wrote: > On 23/08/2012 18:43, Mandy Chung wrote: >> This change is to bring the jdk modularization changes from jigsaw >> repo [1] >> to jdk8. This allows the jdk modularization changes to be exposed for >> testing as early as possible and minimize the amount of changes carried >> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ >> > This looks good to me and it's good to have these changes in jdk8. > > One suggestion for ReflectUtil is to add a private static boolean > isAncestor method as I think that would make the checks in > needsPackageAccessCheck easier to read. Also in ClassLoader you could > use just use needsClassLoaderPermissionCheck(from,to). > Done. This is a good cleanup I considered to do too but missed in the previous webrev. http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/ Thanks for the review. Mandy From serguei.spitsyn at oracle.com Thu Aug 23 19:48:11 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Aug 2012 12:48:11 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <50366BBB.2060406@oracle.com> References: <50366BBB.2060406@oracle.com> Message-ID: <503688FB.4050205@oracle.com> Mandy, It looks good. Just a question below. || *src/share/classes/java/lang/management/ManagementFactory.java* 596 String intfName = mxbeanInterface.getName(); 599 " is not an instance of " + mxbeanInterface); Did you want this?: 596 String intfName = cls.getName(); 599 " is not an instance of " + cls); Thanks, Serguei On 8/23/12 10:43 AM, Mandy Chung wrote: > This change is to bring the jdk modularization changes from jigsaw > repo [1] > to jdk8. This allows the jdk modularization changes to be exposed for > testing as early as possible and minimize the amount of changes carried > in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ > > Summary: > The VM bootstrap class loader (null) has been the defining class loader > for all system classes (i.e. rt.jar and any classes on the > bootclasspath). > > In modular world, the system classes are going to be modularized into > multiple modulesand and many of which will be loaded by its own > (non-null) module loader. > > The JDK implementation has the assumption that the defining class loader > of system classes is null and it'll no longer be true when running as > modules. Typical patterns in the JDK code include: > > Class.forName(classname, false, null) should be changed to: > Class.forName(classname, false,) > > if (loader == null) condition check should be modified to check if the > loader > is responsible for loading system classes. > > This is the first set of change for this problem we identified. Similar > change in other components will be made in the future. > > Testing: run all jdk core test targets on all platforms. > > Thanks > Mandy > P.S. I'm cc'ing servicebility-dev as this patch modifies 2 files in > the java.lang.management. > From mandy.chung at oracle.com Thu Aug 23 19:51:08 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Aug 2012 12:51:08 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <503688FB.4050205@oracle.com> References: <50366BBB.2060406@oracle.com> <503688FB.4050205@oracle.com> Message-ID: <503689AC.20301@oracle.com> On 8/23/2012 12:48 PM, serguei.spitsyn at oracle.com wrote: > Mandy, > > It looks good. Thanks. > Just a question below. > > || *src/share/classes/java/lang/management/ManagementFactory.java* > 596 String intfName = mxbeanInterface.getName(); > 599 " is not an instance of " + mxbeanInterface); > > Did you want this?: > 596 String intfName = cls.getName(); > 599 " is not an instance of " + cls); It doesn't make any difference and so leave it as it is will be fine. Mandy From Alan.Bateman at oracle.com Thu Aug 23 20:49:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 23 Aug 2012 21:49:59 +0100 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036859C.3020801@oracle.com> References: <50366BBB.2060406@oracle.com> <50367D51.90506@oracle.com> <5036859C.3020801@oracle.com> Message-ID: <50369777.5080205@oracle.com> On 23/08/2012 20:33, Mandy Chung wrote: > : > > Done. This is a good cleanup I considered to do too but missed in the > previous webrev. > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/ > > Thanks for the review. > Mandy That looks much better, so looks good to me. -Alan From Dmitry.Samersoff at oracle.com Thu Aug 23 21:26:36 2012 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 24 Aug 2012 01:26:36 +0400 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036859C.3020801@oracle.com> References: <50366BBB.2060406@oracle.com> <50367D51.90506@oracle.com> <5036859C.3020801@oracle.com> Message-ID: <5036A00C.10000@oracle.com> Mandy, 1. You replace null with getClassLoader() calls in couple of places. getClassLoader requires special permissions - RuntimePermission("getClassLoader") so probably you need to use doPrivileget() there. Did you test your changes with SecurityManager/No permissions for the test ? 2. Did you consider moving sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION); inside ClassLoader.needsClassLoaderPermissionCheck(ccl, cl); ? 3. ManagementFactory.java Could you explain the reason of changes (except 588) ? -Dmitry On 2012-08-23 23:33, Mandy Chung wrote: > On 8/23/2012 11:58 AM, Alan Bateman wrote: >> On 23/08/2012 18:43, Mandy Chung wrote: >>> This change is to bring the jdk modularization changes from jigsaw >>> repo [1] >>> to jdk8. This allows the jdk modularization changes to be exposed for >>> testing as early as possible and minimize the amount of changes carried >>> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ >>> >> This looks good to me and it's good to have these changes in jdk8. >> >> One suggestion for ReflectUtil is to add a private static boolean >> isAncestor method as I think that would make the checks in >> needsPackageAccessCheck easier to read. Also in ClassLoader you could >> use just use needsClassLoaderPermissionCheck(from,to). >> > > Done. This is a good cleanup I considered to do too but missed in the > previous webrev. > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/ > > Thanks for the review. > Mandy -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From dan.xu at oracle.com Thu Aug 23 21:46:44 2012 From: dan.xu at oracle.com (Dan Xu) Date: Thu, 23 Aug 2012 14:46:44 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io Message-ID: <5036A4C4.5040709@oracle.com> Please review the fix of CR 7193406 at http://cr.openjdk.java.net/~dxu/7193406/webrev/. It cleans up warnings in the following java files. src/share/classes/java/io/FilePermission.java src/share/classes/java/util/ArrayDeque.java src/share/classes/java/util/Arrays.java src/share/classes/java/util/Collections.java src/share/classes/java/util/HashMap.java src/share/classes/java/util/JumboEnumSet.java src/share/classes/java/util/PriorityQueue.java src/share/classes/java/util/PropertyResourceBundle.java src/share/classes/java/util/jar/JarVerifier.java src/share/classes/java/util/jar/Pack200.java src/share/classes/sun/util/PreHashedMap.java And it enables fatal warning flag in the following make file. make/java/jar/Makefile In FilePermission.java file, I make one change to its method signature, public Enumeration elements() ==> public Enumeration elements() I am not sure whether it will cause an issue of backward compatibility. Please advise. Thanks! - Dan From serguei.spitsyn at oracle.com Thu Aug 23 21:54:43 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Aug 2012 14:54:43 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036859C.3020801@oracle.com> References: <50366BBB.2060406@oracle.com> <50367D51.90506@oracle.com> <5036859C.3020801@oracle.com> Message-ID: <5036A6A3.60401@oracle.com> Looks good. Thanks, Serguei On 8/23/12 12:33 PM, Mandy Chung wrote: > On 8/23/2012 11:58 AM, Alan Bateman wrote: >> On 23/08/2012 18:43, Mandy Chung wrote: >>> This change is to bring the jdk modularization changes from jigsaw >>> repo [1] >>> to jdk8. This allows the jdk modularization changes to be exposed for >>> testing as early as possible and minimize the amount of changes carried >>> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ >>> >> This looks good to me and it's good to have these changes in jdk8. >> >> One suggestion for ReflectUtil is to add a private static boolean >> isAncestor method as I think that would make the checks in >> needsPackageAccessCheck easier to read. Also in ClassLoader you could >> use just use needsClassLoaderPermissionCheck(from,to). >> > > Done. This is a good cleanup I considered to do too but missed in the > previous webrev. > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/ > > Thanks for the review. > Mandy From mandy.chung at oracle.com Thu Aug 23 23:22:56 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 23 Aug 2012 16:22:56 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036A00C.10000@oracle.com> References: <50366BBB.2060406@oracle.com> <50367D51.90506@oracle.com> <5036859C.3020801@oracle.com> <5036A00C.10000@oracle.com> Message-ID: <5036BB50.7010906@oracle.com> On 8/23/2012 2:26 PM, Dmitry Samersoff wrote: > Mandy, > > 1. You replace null with getClassLoader() calls in couple of places. > getClassLoader requires special permissions - > RuntimePermission("getClassLoader") > > so probably you need to use doPrivileget() there. No, the caller's class loader (all are system classes) is null and so no permission check is required [1]. > Did you test your changes with SecurityManager/No permissions > for the test ? I ran the jck tests that cover this permission check. The jck tests uncovered these classes to be fixed during jigsaw development. > > 2. Did you consider moving > > sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION); > > inside ClassLoader.needsClassLoaderPermissionCheck(ccl, cl); ? Yes I did and I decide to leave this sm.checkPermission call in the method body as it's closer to the spec and more readable. > > 3. ManagementFactory.java > > Could you explain the reason of changes (except 588) ? The platform MXBeans (java.lang.management) are currently on the bootclasspath loaded by the null loader. In the modular world, j.l.m. will possibly be put in the "management" module along with JMX so that an application only requires the management module to be present when it uses JMX and platform MXBean. In that case, the management module will be loaded by a non-null module loader. This check (loader != null) would fail in the modular world even loading platform MXBeans. We changed this check and other places in the JDK to call VM.isSystemDomainLoader method and the real check for modules can be made in this single convenient method in the jigsaw repo. > -Dmitry Thanks Mandy [1] http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getClassLoader() > > On 2012-08-23 23:33, Mandy Chung wrote: >> On 8/23/2012 11:58 AM, Alan Bateman wrote: >>> On 23/08/2012 18:43, Mandy Chung wrote: >>>> This change is to bring the jdk modularization changes from jigsaw >>>> repo [1] >>>> to jdk8. This allows the jdk modularization changes to be exposed for >>>> testing as early as possible and minimize the amount of changes carried >>>> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. >>>> >>>> Webrev at: >>>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ >>>> >>> This looks good to me and it's good to have these changes in jdk8. >>> >>> One suggestion for ReflectUtil is to add a private static boolean >>> isAncestor method as I think that would make the checks in >>> needsPackageAccessCheck easier to read. Also in ClassLoader you could >>> use just use needsClassLoaderPermissionCheck(from,to). >>> >> Done. This is a good cleanup I considered to do too but missed in the >> previous webrev. >> >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/ >> >> Thanks for the review. >> Mandy > From ahughes at redhat.com Fri Aug 24 00:12:43 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 23 Aug 2012 20:12:43 -0400 (EDT) Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <5036A4C4.5040709@oracle.com> Message-ID: <1752716260.10040789.1345767163342.JavaMail.root@redhat.com> ----- Original Message ----- > Please review the fix of CR 7193406 at > http://cr.openjdk.java.net/~dxu/7193406/webrev/. > snip... > And it enables fatal warning flag in the following make file. > > make/java/jar/Makefile > Please don't do this, at least not unconditionally. At the very least, these should not be forced on if the user has explicitly built with them set to false. If I set JAVAC_WARNINGS_FATAL=false, I don't expect part of the build to ignore this and use -Werror, possibly then causing build failures. This is especially bad with both on as a new warning may be introduced into javac which then breaks everyone's build. I already have a patch I intend to upstream which fixes the other cases of this I found. I'd prefer we didn't have another. > > In FilePermission.java file, I make one change to its method > signature, > > public Enumeration elements() ==> public Enumeration > elements() > > > I am not sure whether it will cause an issue of backward > compatibility. > Please advise. Thanks! > It's in a package-private class so I doubt it. Even if it wasn't, a new major release is the perfect time to fix these issues. > - Dan > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From darryl.mocek at oracle.com Fri Aug 24 00:15:43 2012 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Thu, 23 Aug 2012 17:15:43 -0700 Subject: rmi network traffic In-Reply-To: References: Message-ID: <5036C7AF.2090805@oracle.com> Hi fuyou001, if you're using RMI in a J2SE project and it is OK, but it isn't when you use the web project, then I suggest you look at the Jetty/Resin implementation as it may be the culprit. Specifically, I'd look at the ClassLoader in use. See this URL (http://java.sun.com/javase/6/docs/api/java/rmi/server/RMIClassLoader.html#getDefaultProviderInstance()). If the ClassLoader is a URLClassLoader, then the loader's |getURLs| method may be called, which may return a list of URls of the application's class path. It may also be that the value of the |java.rmi.server.codebase property is being returned, so you should look at that as well. The URL gives more details on the issue. ||See below for information from the bug report. Darryl | RMI's marshalling format annotates serialized class descriptors with a "codebase URL path" in case the class needs to be dynamically loaded by the receiving party. ... The value used for this annotation is controlled by the RMIClassLoader provider's getClassAnotation method: http://java.sun.com/javase/6/docs/api/java/rmi/server/RMIClassLoader.html#getClassAnnotation(java.lang.Class) which the default provider implements as described here: http://java.sun.com/javase/6/docs/api/java/rmi/server/RMIClassLoader.html#getDefaultProviderInstance() *Basically, if the class's defining loader is the system class loader or one of its ancestors, or if it is not a URLClassLoader, then the value of the "java.rmi.server.codebase" system property is used; otherwise, a string form of the result of invoking URLClassLoader.getURLs on the loader is used.* In this case, I gather that the ClassLoader is not configured to be considered the system class loader, but it is a URLClassLoader whose getURLs method returns the URLs of the application's class path, which in this case is quite lengthy. On 08/21/2012 07:23 PM, fuyou wrote: > Hi all > > I deploy a RMI Service ,write a RMI Client(J2SE project) to access it > and is ok .but the some code in web project,I use wireshark to find that > every RMI request sent from our client to our server containing the list of > all jars in the classpath for the application, My problem is similar to > bugs.sun.com > > java -version > java version "1.6.0_33" > Java(TM) SE Runtime Environment (build 1.6.0_33-b03) > Java HotSpot(TM) Server VM (build 20.8-b03, mixed mode) > > This issues may be caused by Servlet Container(etc Jetty/Resin) > classloader > How to slove it ? > > Sorry for disturbing again. > Thanks a lot! > From ahughes at redhat.com Fri Aug 24 00:17:07 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Thu, 23 Aug 2012 20:17:07 -0400 (EDT) Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <1752716260.10040789.1345767163342.JavaMail.root@redhat.com> Message-ID: <1261180730.10041364.1345767427410.JavaMail.root@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > Please review the fix of CR 7193406 at > > http://cr.openjdk.java.net/~dxu/7193406/webrev/. > > > > snip... > > > And it enables fatal warning flag in the following make file. > > > > make/java/jar/Makefile > > > > Please don't do this, at least not unconditionally. > > At the very least, these should not be forced on if the user > has explicitly built with them set to false. If I set > JAVAC_WARNINGS_FATAL=false, I don't expect part of the build > to ignore this and use -Werror, possibly then causing build > failures. > > This is especially bad with both on as a new warning may be > introduced into javac which then breaks everyone's build. > > I already have a patch I intend to upstream which fixes the > other cases of this I found. I'd prefer we didn't have another. > > > > > In FilePermission.java file, I make one change to its method > > signature, > > > > public Enumeration elements() ==> public > > Enumeration > > elements() > > > > > > I am not sure whether it will cause an issue of backward > > compatibility. > > Please advise. Thanks! > > > > It's in a package-private class so I doubt it. > > Even if it wasn't, a new major release is the perfect time to fix > these issues. > > > - Dan > > > I should also point out that the annotation: @SuppressWarnings("unchecked") private void readObject(ObjectInputStream in) throws IOException, could be moved down to the actual problematic assignment: Vector permissions = (Vector)gfields.get("permissions", null); so that warnings aren't suppressed throughout the method. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Fri Aug 24 01:27:01 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Aug 2012 11:27:01 +1000 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <50366BBB.2060406@oracle.com> References: <50366BBB.2060406@oracle.com> Message-ID: <5036D865.5020704@oracle.com> Hi Mandy, While I understand what you are doing and that it "works" it is far from obvious upon code inspection that where you replace null with Foo.class.getClassLoader(), that the result would always be null. Another way to simplify this would be to add a new overload of Class.forName(): public static Class forName(String name, boolean initialize) That way the loader argument could be dropped completely from a number of the use-cases. David On 24/08/2012 3:43 AM, Mandy Chung wrote: > This change is to bring the jdk modularization changes from jigsaw repo [1] > to jdk8. This allows the jdk modularization changes to be exposed for > testing as early as possible and minimize the amount of changes carried > in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ > > Summary: > The VM bootstrap class loader (null) has been the defining class loader > for all system classes (i.e. rt.jar and any classes on the bootclasspath). > > In modular world, the system classes are going to be modularized into > multiple modulesand and many of which will be loaded by its own > (non-null) module loader. > > The JDK implementation has the assumption that the defining class loader > of system classes is null and it'll no longer be true when running as > modules. Typical patterns in the JDK code include: > > Class.forName(classname, false, null) should be changed to: > Class.forName(classname, false,) > > if (loader == null) condition check should be modified to check if the > loader > is responsible for loading system classes. > > This is the first set of change for this problem we identified. Similar > change in other components will be made in the future. > > Testing: run all jdk core test targets on all platforms. > > Thanks > Mandy > P.S. I'm cc'ing servicebility-dev as this patch modifies 2 files in > the java.lang.management. > From stuart.marks at oracle.com Fri Aug 24 01:43:35 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 23 Aug 2012 18:43:35 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <1752716260.10040789.1345767163342.JavaMail.root@redhat.com> References: <1752716260.10040789.1345767163342.JavaMail.root@redhat.com> Message-ID: <5036DC47.6000008@oracle.com> On 8/23/12 5:12 PM, Andrew Hughes wrote: > Dan Xu wrote: >> Please review the fix of CR 7193406 at >> http://cr.openjdk.java.net/~dxu/7193406/webrev/. >> And it enables fatal warning flag in the following make file. >> >> make/java/jar/Makefile > > Please don't do this, at least not unconditionally. Right, we had been enabling fatal warnings in the various makefiles but we've stopped doing so since it has started to cause problems. The intent was to enable fatal warnings by default in individual makefiles, as those areas of the build were cleared of warnings. That way, the introduction of a new warning into a warnings-free area **would** break the build. The problem is that because of implicit compilation, as code is modified, files can shift around being compiled by different Makefiles. Thus an apparently innocuous change might cause a file with warnings to be built by a different javac run from a makefile that has fatal warnings enabled, causing an unexpected build breakage. Anyway, Dan, please don't enable this flag in this (or any other) Makefile. Sorry, I thought I had mentioned this to you before. > At the very least, these should not be forced on if the user > has explicitly built with them set to false. If I set > JAVAC_WARNINGS_FATAL=false, I don't expect part of the build > to ignore this and use -Werror, possibly then causing build > failures. Yes, it should always be possible to override this by specifying JAVAC_WARNINGS_FATAL=false on the make command line. This overriding should work if the value is specified directly in a Makefile, e.g. JAVAC_WARNINGS_FATAL = true However, there are several cases where the following occurs: SUBDIRS_MAKEFLAGS += JAVAC_WARNINGS_FATAL=true and this is **not** overridable on the command line. That's wrong. If these are causing problems for you, please do submit patches. Although we still occasionally run into problems with implicit compilation causing unexpected build failures, I don't want to remove the fatal warnings settings wholesale. The settings in place now do seem to be keeping at least some parts of the build warning-free. The new build system will change all of this completely, of course. I don't think they have a solution yet for applying different flags to different parts of the build. >> In FilePermission.java file, I make one change to its method >> signature, >> >> public Enumeration elements() ==> public Enumeration >> elements() > > It's in a package-private class so I doubt it. > > Even if it wasn't, a new major release is the perfect time to fix these issues. Yes, this one is fine because it's a private class. For warnings fixes we're trying to avoid making any API changes, since those have to go through some additional process steps. s'marks From david.holmes at oracle.com Fri Aug 24 01:53:41 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Aug 2012 11:53:41 +1000 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <5036A4C4.5040709@oracle.com> References: <5036A4C4.5040709@oracle.com> Message-ID: <5036DEA5.1020100@oracle.com> Hi Dan, On 24/08/2012 7:46 AM, Dan Xu wrote: > Please review the fix of CR 7193406 at > http://cr.openjdk.java.net/~dxu/7193406/webrev/. > > It cleans up warnings in the following java files. > > src/share/classes/java/io/FilePermission.java I'm surprised that you need this: 426 @SuppressWarnings("fallthrough") ... 436 switch (actions) { 437 case SecurityConstants.FILE_READ_ACTION: 438 return READ; If this generates a fallthrough warning then I think whatever tool generates that warning needs fixing! > src/share/classes/java/util/ArrayDeque.java > src/share/classes/java/util/Arrays.java > src/share/classes/java/util/Collections.java > src/share/classes/java/util/HashMap.java > src/share/classes/java/util/JumboEnumSet.java > src/share/classes/java/util/PriorityQueue.java > src/share/classes/java/util/PropertyResourceBundle.java Here: ! @SuppressWarnings({ "unchecked", "rawtypes" }) ! Map result = new HashMap(properties); ! lookup = result; why do you keep the raw type instead of using HashMap<>(properties) ? > src/share/classes/java/util/jar/JarVerifier.java > src/share/classes/java/util/jar/Pack200.java > src/share/classes/sun/util/PreHashedMap.java > > > > And it enables fatal warning flag in the following make file. > > make/java/jar/Makefile I'm not sure what Andrew's objection is to this change as it only affects how java/util/jar classes get compiled and is consistent with the usage in all the other Makefiles. As far as I can see you can override this on the make invocation anyway. I'm unclear how this is handled in the new build. > In FilePermission.java file, I make one change to its method signature, > > public Enumeration elements() ==> public Enumeration > elements() > > > I am not sure whether it will cause an issue of backward compatibility. > Please advise. Thanks! As Andrew stated this is a package-private class so I don't see any issue. Cheers, David > - Dan From serguei.spitsyn at oracle.com Fri Aug 24 05:21:45 2012 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Aug 2012 22:21:45 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036D865.5020704@oracle.com> References: <50366BBB.2060406@oracle.com> <5036D865.5020704@oracle.com> Message-ID: <50370F69.8030703@oracle.com> I was thinking about the same. But a CCC request is needed for such a change in public API. It can be done separately if any other API changes are necessary. Thanks, Serguei On 8/23/12 6:27 PM, David Holmes wrote: > Hi Mandy, > > While I understand what you are doing and that it "works" it is far > from obvious upon code inspection that where you replace null with > Foo.class.getClassLoader(), that the result would always be null. > > Another way to simplify this would be to add a new overload of > Class.forName(): > > public static Class forName(String name, boolean initialize) > > That way the loader argument could be dropped completely from a number > of the use-cases. > > David > > On 24/08/2012 3:43 AM, Mandy Chung wrote: >> This change is to bring the jdk modularization changes from jigsaw >> repo [1] >> to jdk8. This allows the jdk modularization changes to be exposed for >> testing as early as possible and minimize the amount of changes carried >> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ >> >> Summary: >> The VM bootstrap class loader (null) has been the defining class loader >> for all system classes (i.e. rt.jar and any classes on the >> bootclasspath). >> >> In modular world, the system classes are going to be modularized into >> multiple modulesand and many of which will be loaded by its own >> (non-null) module loader. >> >> The JDK implementation has the assumption that the defining class loader >> of system classes is null and it'll no longer be true when running as >> modules. Typical patterns in the JDK code include: >> >> Class.forName(classname, false, null) should be changed to: >> Class.forName(classname, false,) >> >> if (loader == null) condition check should be modified to check if the >> loader >> is responsible for loading system classes. >> >> This is the first set of change for this problem we identified. Similar >> change in other components will be made in the future. >> >> Testing: run all jdk core test targets on all platforms. >> >> Thanks >> Mandy >> P.S. I'm cc'ing servicebility-dev as this patch modifies 2 files in >> the java.lang.management. >> From ahughes at redhat.com Fri Aug 24 09:42:43 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 24 Aug 2012 05:42:43 -0400 (EDT) Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <5036DC47.6000008@oracle.com> Message-ID: <1881758767.10314924.1345801363355.JavaMail.root@redhat.com> ----- Original Message ----- > On 8/23/12 5:12 PM, Andrew Hughes wrote: > > Dan Xu wrote: > >> Please review the fix of CR 7193406 at > >> http://cr.openjdk.java.net/~dxu/7193406/webrev/. > >> And it enables fatal warning flag in the following make file. > >> > >> make/java/jar/Makefile > > > > Please don't do this, at least not unconditionally. > > Right, we had been enabling fatal warnings in the various makefiles > but we've > stopped doing so since it has started to cause problems. The intent > was to > enable fatal warnings by default in individual makefiles, as those > areas of the > build were cleared of warnings. That way, the introduction of a new > warning > into a warnings-free area **would** break the build. I understand the motivation and why the current setup would be needed in transition. However, once the whole build is warning free, would it not be preferable to remove these and just set JAVAC_WARNINGS_FATAL=true when doing development builds? The problem I see is someone new coming to OpenJDK and not being able to simply build it (with no changes) because a new warnings has appeared and is being treated as an error. This is less of a problem with javac as we control its development, and the JDK will use the javac built in the langtools step in most cases. But, generally, -Werror is something you should choose to enable, with the intention of fixing failures, not something that should be forced on everyone building the code. On a related topic, it would be nice if javadoc could also support -Werror as I constantly see warnings reappearing in the documentation. > > The problem is that because of implicit compilation, as code is > modified, files > can shift around being compiled by different Makefiles. Thus an > apparently > innocuous change might cause a file with warnings to be built by a > different > javac run from a makefile that has fatal warnings enabled, causing an > unexpected build breakage. > > Anyway, Dan, please don't enable this flag in this (or any other) > Makefile. > Sorry, I thought I had mentioned this to you before. > > > At the very least, these should not be forced on if the user > > has explicitly built with them set to false. If I set > > JAVAC_WARNINGS_FATAL=false, I don't expect part of the build > > to ignore this and use -Werror, possibly then causing build > > failures. > > Yes, it should always be possible to override this by specifying > JAVAC_WARNINGS_FATAL=false on the make command line. This overriding > should > work if the value is specified directly in a Makefile, e.g. > > JAVAC_WARNINGS_FATAL = true > > However, there are several cases where the following occurs: > > SUBDIRS_MAKEFLAGS += JAVAC_WARNINGS_FATAL=true > > and this is **not** overridable on the command line. That's wrong. If > these are > causing problems for you, please do submit patches. Yes, that's what we have in java/tools and is why JAVAC_WARNINGS_FATAL=false doesn't completely remove -Werror at present. I'll post a webrev of the change I have for this. > > Although we still occasionally run into problems with implicit > compilation > causing unexpected build failures, I don't want to remove the fatal > warnings > settings wholesale. The settings in place now do seem to be keeping > at least > some parts of the build warning-free. > > The new build system will change all of this completely, of course. I > don't > think they have a solution yet for applying different flags to > different parts > of the build. > > >> In FilePermission.java file, I make one change to its method > >> signature, > >> > >> public Enumeration elements() ==> public > >> Enumeration > >> elements() > > > > It's in a package-private class so I doubt it. > > > > Even if it wasn't, a new major release is the perfect time to fix > > these issues. > > Yes, this one is fine because it's a private class. > > For warnings fixes we're trying to avoid making any API changes, > since those > have to go through some additional process steps. > > s'marks > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From ahughes at redhat.com Fri Aug 24 09:49:30 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Fri, 24 Aug 2012 05:49:30 -0400 (EDT) Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <5036DEA5.1020100@oracle.com> Message-ID: <334327608.10320416.1345801770222.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Dan, > > On 24/08/2012 7:46 AM, Dan Xu wrote: > > Please review the fix of CR 7193406 at > > http://cr.openjdk.java.net/~dxu/7193406/webrev/. > > > > It cleans up warnings in the following java files. > > > > src/share/classes/java/io/FilePermission.java > > I'm surprised that you need this: > > 426 @SuppressWarnings("fallthrough") > ... > 436 switch (actions) { > 437 case SecurityConstants.FILE_READ_ACTION: > 438 return READ; > > If this generates a fallthrough warning then I think whatever tool > generates that warning needs fixing! > > > src/share/classes/java/util/ArrayDeque.java > > src/share/classes/java/util/Arrays.java > > src/share/classes/java/util/Collections.java > > src/share/classes/java/util/HashMap.java > > src/share/classes/java/util/JumboEnumSet.java > > src/share/classes/java/util/PriorityQueue.java > > src/share/classes/java/util/PropertyResourceBundle.java > > Here: > > ! @SuppressWarnings({ "unchecked", "rawtypes" }) > ! Map result = new HashMap(properties); > ! lookup = result; > > why do you keep the raw type instead of using HashMap<>(properties) ? > > > src/share/classes/java/util/jar/JarVerifier.java > > src/share/classes/java/util/jar/Pack200.java > > src/share/classes/sun/util/PreHashedMap.java > > > > > > > > And it enables fatal warning flag in the following make file. > > > > make/java/jar/Makefile > > I'm not sure what Andrew's objection is to this change as it only > affects how java/util/jar classes get compiled and is consistent with > the usage in all the other Makefiles. As far as I can see you can > override this on the make invocation anyway. Well, it's a bigger problem with HotSpot where the compiler is outside the remit of the OpenJDK build, but enabling -Werror by default increases the chance of build breakage when no changes have even been made to the source code. I've lost count of the number of times we've had to patch HotSpot due to -Werror failures. It's happened twice this summer alone. I'm not so much worried about us encountering failures (we'd probably still turn it on during development anyway), but it makes OpenJDK less approachable and puts off potential new developers. With javac, as the compiler is usually built prior to the jdk build, it's less this issue and more the implicit compilation issue Stuart mentioned i.e. javac tries to compile a file outside util/jar which has not yet been declared "warning free". This problem will disappear as the entire source code base is cleaned up. > > I'm unclear how this is handled in the new build. > > > In FilePermission.java file, I make one change to its method > > signature, > > > > public Enumeration elements() ==> public Enumeration > > elements() > > > > > > I am not sure whether it will cause an issue of backward > > compatibility. > > Please advise. Thanks! > > As Andrew stated this is a package-private class so I don't see any > issue. > > Cheers, > David > > > - Dan > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From paul.sandoz at oracle.com Fri Aug 24 09:57:26 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 24 Aug 2012 11:57:26 +0200 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036859C.3020801@oracle.com> References: <50366BBB.2060406@oracle.com> <50367D51.90506@oracle.com> <5036859C.3020801@oracle.com> Message-ID: <6C0C79F8-7344-4730-92FF-8051291B2793@oracle.com> Hi Mandy, --- old/src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java Thu Aug 23 12:29:01 2012 +++ new/src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java Thu Aug 23 12:29:00 2012 @@ -52,7 +52,7 @@ AccessController.doPrivileged(new PrivilegedAction() { public IIOPProxy run() { try { - Class c = Class.forName(IMPL_CLASS, true, null); + Class c = Class.forName(IMPL_CLASS); Why not: Class c = Class.forName(IMPL_CLASS, true, IIOPHelper.class.getClassLoader()); to avoid traversing up the call stack to obtain the calling class. Paul. On Aug 23, 2012, at 9:33 PM, Mandy Chung wrote: > On 8/23/2012 11:58 AM, Alan Bateman wrote: >> On 23/08/2012 18:43, Mandy Chung wrote: >>> This change is to bring the jdk modularization changes from jigsaw repo [1] >>> to jdk8. This allows the jdk modularization changes to be exposed for >>> testing as early as possible and minimize the amount of changes carried >>> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ >>> >> This looks good to me and it's good to have these changes in jdk8. >> >> One suggestion for ReflectUtil is to add a private static boolean isAncestor method as I think that would make the checks in needsPackageAccessCheck easier to read. Also in ClassLoader you could use just use needsClassLoaderPermissionCheck(from,to). >> > > Done. This is a good cleanup I considered to do too but missed in the previous webrev. > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.01/ > > Thanks for the review. > Mandy From forax at univ-mlv.fr Fri Aug 24 10:17:13 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 24 Aug 2012 12:17:13 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <5036A4C4.5040709@oracle.com> References: <5036A4C4.5040709@oracle.com> Message-ID: <503754A9.7010708@univ-mlv.fr> On 08/23/2012 11:46 PM, Dan Xu wrote: > Please review the fix of CR 7193406 at > http://cr.openjdk.java.net/~dxu/7193406/webrev/. > > It cleans up warnings in the following java files. > > src/share/classes/java/io/FilePermission.java > src/share/classes/java/util/ArrayDeque.java > src/share/classes/java/util/Arrays.java > src/share/classes/java/util/Collections.java > src/share/classes/java/util/HashMap.java > src/share/classes/java/util/JumboEnumSet.java > src/share/classes/java/util/PriorityQueue.java > src/share/classes/java/util/PropertyResourceBundle.java > src/share/classes/java/util/jar/JarVerifier.java > src/share/classes/java/util/jar/Pack200.java > src/share/classes/sun/util/PreHashedMap.java > > > > And it enables fatal warning flag in the following make file. > > make/java/jar/Makefile > > > In FilePermission.java file, I make one change to its method signature, > > public Enumeration elements() ==> public Enumeration > elements() > > > I am not sure whether it will cause an issue of backward > compatibility. Please advise. Thanks! > > - Dan Hi Dan, I'm not sure to like the fact that you introduce some local variables just to get ride of some warnings given that Hotspot compilers are sometimes sensitive to that. I think this practice should be discussed on this list before committing this changeset. so is it a good idea to add a temporary local variable to fix a generics warning or should @SuppressWarnings should be set on the whole method ? R?mi From martijnverburg at gmail.com Fri Aug 24 10:19:28 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 24 Aug 2012 11:19:28 +0100 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503754A9.7010708@univ-mlv.fr> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> Message-ID: Hi all, > On 08/23/2012 11:46 PM, Dan Xu wrote: >> >> Please review the fix of CR 7193406 at >> http://cr.openjdk.java.net/~dxu/7193406/webrev/. >> >> It cleans up warnings in the following java files. >> >> src/share/classes/java/io/FilePermission.java >> src/share/classes/java/util/ArrayDeque.java >> src/share/classes/java/util/Arrays.java >> src/share/classes/java/util/Collections.java >> src/share/classes/java/util/HashMap.java >> src/share/classes/java/util/JumboEnumSet.java >> src/share/classes/java/util/PriorityQueue.java >> src/share/classes/java/util/PropertyResourceBundle.java >> src/share/classes/java/util/jar/JarVerifier.java >> src/share/classes/java/util/jar/Pack200.java >> src/share/classes/sun/util/PreHashedMap.java >> >> >> >> And it enables fatal warning flag in the following make file. >> >> make/java/jar/Makefile >> >> >> In FilePermission.java file, I make one change to its method signature, >> >> public Enumeration elements() ==> public Enumeration >> elements() >> >> >> I am not sure whether it will cause an issue of backward compatibility. >> Please advise. Thanks! >> >> - Dan > > > Hi Dan, > I'm not sure to like the fact that you introduce some local variables just > to get ride of some warnings given that Hotspot compilers are sometimes > sensitive to that. > I think this practice should be discussed on this list before committing > this changeset. > > so is it a good idea to add a temporary local variable to fix a generics > warning or should @SuppressWarnings should be set on the whole method ? > > R?mi Is it worth analysing the byte code to see the potential impact of this extra local variable? We did that for a bunch of the javac warnings cleanup in London and had a defacto rule of 'no byte code changes' or if there was one we'd get a few Hotspot enthusiasts to analyse it. Cheers, Martijn From forax at univ-mlv.fr Fri Aug 24 10:25:42 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Fri, 24 Aug 2012 12:25:42 +0200 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <50370F69.8030703@oracle.com> References: <50366BBB.2060406@oracle.com> <5036D865.5020704@oracle.com> <50370F69.8030703@oracle.com> Message-ID: <503756A6.3050900@univ-mlv.fr> I also vote for adding this overload, a lot of the usage of Class.forName with three parameters are in fact just a way to load a class without initialize it. R?mi On 08/24/2012 07:21 AM, serguei.spitsyn at oracle.com wrote: > I was thinking about the same. > But a CCC request is needed for such a change in public API. > It can be done separately if any other API changes are necessary. > > Thanks, > Serguei > > > On 8/23/12 6:27 PM, David Holmes wrote: >> Hi Mandy, >> >> While I understand what you are doing and that it "works" it is far >> from obvious upon code inspection that where you replace null with >> Foo.class.getClassLoader(), that the result would always be null. >> >> Another way to simplify this would be to add a new overload of >> Class.forName(): >> >> public static Class forName(String name, boolean initialize) >> >> That way the loader argument could be dropped completely from a >> number of the use-cases. >> >> David >> >> On 24/08/2012 3:43 AM, Mandy Chung wrote: >>> This change is to bring the jdk modularization changes from jigsaw >>> repo [1] >>> to jdk8. This allows the jdk modularization changes to be exposed for >>> testing as early as possible and minimize the amount of changes carried >>> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/ >>> >>> Summary: >>> The VM bootstrap class loader (null) has been the defining class loader >>> for all system classes (i.e. rt.jar and any classes on the >>> bootclasspath). >>> >>> In modular world, the system classes are going to be modularized into >>> multiple modulesand and many of which will be loaded by its own >>> (non-null) module loader. >>> >>> The JDK implementation has the assumption that the defining class >>> loader >>> of system classes is null and it'll no longer be true when running as >>> modules. Typical patterns in the JDK code include: >>> >>> Class.forName(classname, false, null) should be changed to: >>> Class.forName(classname, false,) >>> >>> if (loader == null) condition check should be modified to check if the >>> loader >>> is responsible for loading system classes. >>> >>> This is the first set of change for this problem we identified. Similar >>> change in other components will be made in the future. >>> >>> Testing: run all jdk core test targets on all platforms. >>> >>> Thanks >>> Mandy >>> P.S. I'm cc'ing servicebility-dev as this patch modifies 2 files in >>> the java.lang.management. >>> > From dl at cs.oswego.edu Fri Aug 24 10:45:13 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 24 Aug 2012 06:45:13 -0400 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503754A9.7010708@univ-mlv.fr> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> Message-ID: <50375B39.9080805@cs.oswego.edu> R?mi Forax wrote: > Hi Dan, > I'm not sure to like the fact that you introduce some local variables > just to get ride of some warnings given that Hotspot compilers are > sometimes sensitive to that. > I think this practice should be discussed on this list before committing > this changeset. > Yes. We discussed this during the last warnings cleanup. If javac cannot provide a means of shutting up these kinds of warnings without changing the emitted bytecode, then warning-free-compiles should not be required within JDK. (We hit a lot of warnings in j.u.c anyway because of uses of Unsafe that have no pure-java equivalents.) > so is it a good idea to add a temporary local variable to fix a generics > warning or should @SuppressWarnings should be set on the whole method ? > We end up doing this this too often as a workaround. -Doug From vitalyd at gmail.com Fri Aug 24 12:53:51 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 24 Aug 2012 08:53:51 -0400 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <50375B39.9080805@cs.oswego.edu> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> Message-ID: In response to a similar question a few months ago, Tom Rodriguez mentioned that c2 is not really susceptible to these redundant stores when making inlining decisions. I guess c1 (and interpreter of course) might be but then in those cases one's not getting max optimization anyway. John Rose mentioned that the inlining decision making should be fixed for cases where it's susceptible to these types of bytecodes (presumably c1). So it sounds like avoiding these locals is basically trying to work around current compiler limitations, rather than something more fundamental. I'm also curious if someone has actually noticed any perf degradation in hot code when adding locals like this (Doug? :)). If not (but perf tests were done), then I'm not sure it's worth worrying about. Sent from my phone On Aug 24, 2012 6:45 AM, "Doug Lea"
wrote: > R?mi Forax wrote: > > Hi Dan, >> I'm not sure to like the fact that you introduce some local variables >> just to get ride of some warnings given that Hotspot compilers are >> sometimes sensitive to that. >> I think this practice should be discussed on this list before committing >> this changeset. >> >> > Yes. We discussed this during the last warnings cleanup. > If javac cannot provide a means of shutting up these kinds > of warnings without changing the emitted bytecode, then > warning-free-compiles should not be required within JDK. > (We hit a lot of warnings in j.u.c anyway because of uses > of Unsafe that have no pure-java equivalents.) > > so is it a good idea to add a temporary local variable to fix a generics >> warning or should @SuppressWarnings should be set on the whole method ? >> >> > We end up doing this this too often as a workaround. > > -Doug > > > > From dl at cs.oswego.edu Fri Aug 24 13:02:23 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 24 Aug 2012 09:02:23 -0400 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> Message-ID: <50377B5F.4050803@cs.oswego.edu> Vitaly Davidovich wrote: > So it sounds like avoiding these locals is basically trying to work > around current compiler limitations, rather than something more fundamental. If javac did even a smidgen of optimization, this problem would also go away. > > I'm also curious if someone has actually noticed any perf degradation in > hot code when adding locals like this (Doug? :)). If not (but perf > tests were done), then I'm not sure it's worth worrying about. Of course, I have measured actual performance problems -- otherwise I would not be bringing up this issue :-) Not every case is a problem, but there are some cases that matter, and it is not a good idea to invite people to rewrite, just for the sake of warning suppression, code that explicitly chose not to introduce redundant locals. -Doug From vitalyd at gmail.com Fri Aug 24 13:11:25 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 24 Aug 2012 09:11:25 -0400 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <50377B5F.4050803@cs.oswego.edu> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> Message-ID: I figured you did, but wanted to check. :) So the perf hit was with c2 compilation? Were you able to check the assembly (or enable inlining printing in hotspot) and see that lack of inlining (and whatever further opto that enabled) was the difference by simply adding a local or two? I'm legitimately curious here because if that's the case and this was on a somewhat recent hotspot build, it sort of goes against what TomR seemed to have been saying. I agree with you that even javac should be able to remove this code, but it's disappointing if an optimizing JIT cannot handle it. Thanks Sent from my phone On Aug 24, 2012 9:02 AM, "Doug Lea"
wrote: > Vitaly Davidovich wrote: > > So it sounds like avoiding these locals is basically trying to work >> around current compiler limitations, rather than something more fundamental. >> > > If javac did even a smidgen of optimization, this problem would > also go away. > > > >> I'm also curious if someone has actually noticed any perf degradation in >> hot code when adding locals like this (Doug? :)). If not (but perf tests >> were done), then I'm not sure it's worth worrying about. >> > > Of course, I have measured actual performance problems -- otherwise > I would not be bringing up this issue :-) Not every case is a > problem, but there are some cases that matter, and it is not a > good idea to invite people to rewrite, just for the sake of warning > suppression, code that explicitly chose not to introduce redundant locals. > > -Doug > From Alan.Bateman at oracle.com Fri Aug 24 13:47:23 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Aug 2012 14:47:23 +0100 Subject: More updates to the ProblemList Message-ID: <503785EB.3040709@oracle.com> I need a reviewer to update the ProblemList to exclude a number of tests, see attached. Minimally I'd like to get sun/management/jmxremote/startstop/JMXStartStopTest.sh excluded. It was removed from the exclude list recently [1] but has been causing havoc on Windows since its release. I believe Dmitry Samersoff is working on this. A number of tests are excluded on Mac because they don't run headless, they seem to have been missed when other tests were added for the same reason. Jason Uh had an initial patch to fix a couple of these but I think it has been pushed yet. The others are intermittent failures with bugs tracking the issues. -Alan. [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fb8792725d5 diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -141,6 +141,9 @@ javax/management/loading/LibraryLoader/L # 7144846 javax/management/remote/mandatory/connection/ReconnectTest.java generic-all +# 7158614, locks up Windows machines at least +sun/management/jmxremote/startstop/JMXStartStopTest.sh windows-all + ############################################################################ # jdk_math @@ -222,8 +225,10 @@ java/net/URLClassLoader/closetest/CloseT # 6962637 java/io/File/MaxPathLength.java windows-all -# 7145435 - Test needs AWT window server, does not work headless +# 7162111 - these tests need to be updated to run headless java/io/Serializable/resolveClass/deserializeButton/run.sh macosx-all +java/io/Serializable/serialver/classpath/run.sh macosx-all +java/io/Serializable/serialver/nested/run.sh macosx-all ############################################################################ @@ -246,6 +251,9 @@ java/nio/channels/DatagramChannel/Changi # 7132677 java/nio/channels/Selector/OutOfBand.java macosx-all +# 7142919 +java/nio/channels/AsyncCloseAndInterrupt.java solaris-all + ############################################################################ # jdk_rmi @@ -257,6 +265,13 @@ java/rmi/transport/rapidExportUnexport/R # jdk_security +# 7193792 +sun/security/pkcs11/ec/TestECDSA.java solaris-all +sun/security/pkcs11/ec/TestECDSA.java linux-all + +# 7193793 +sun/security/pkcs11/ec/TestECDH.java linux-all + # 7147060 com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java generic-all @@ -265,7 +280,6 @@ sun/security/pkcs11/ec/ReadCertificates. sun/security/pkcs11/ec/ReadCertificates.java generic-all sun/security/pkcs11/ec/ReadPKCS12.java generic-all sun/security/pkcs11/ec/TestCurves.java solaris-i586 -sun/security/pkcs11/ec/TestECDSA.java solaris-i586 #sun/security/pkcs11/ec/TestECGenSpec.java solaris-i586 #sun/security/pkcs11/ec/TestKeyFactory.java solaris-i586 sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java generic-all @@ -362,6 +376,9 @@ tools/launcher/UnicodeTest.java # jdk_util +# 7162111 - test needs to be changed to run headless +java/util/ResourceBundle/Control/Bug6530694.java macosx-all + # Filed 6933803 java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java generic-all From Alan.Bateman at oracle.com Fri Aug 24 15:28:36 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 24 Aug 2012 16:28:36 +0100 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <503756A6.3050900@univ-mlv.fr> References: <50366BBB.2060406@oracle.com> <5036D865.5020704@oracle.com> <50370F69.8030703@oracle.com> <503756A6.3050900@univ-mlv.fr> Message-ID: <50379DA4.7050508@oracle.com> On 24/08/2012 11:25, R?mi Forax wrote: > I also vote for adding this overload, a lot of the usage of > Class.forName with three parameters are in fact just a way to load a > class without initialize it. > > R?mi I think this is worth looking at too. It would only change two or three usages in this patch but there likely be a lot more as other areas of the JDK are updated. -Alan. From mandy.chung at oracle.com Fri Aug 24 15:53:09 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 24 Aug 2012 08:53:09 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5036D865.5020704@oracle.com> References: <50366BBB.2060406@oracle.com> <5036D865.5020704@oracle.com> Message-ID: <5037A365.6040708@oracle.com> On 8/23/2012 6:27 PM, David Holmes wrote: > > Another way to simplify this would be to add a new overload of > Class.forName(): > > public static Class forName(String name, boolean initialize) > > That way the loader argument could be dropped completely from a number > of the use-cases. Paul and Remi also suggest that during the jigsaw code review on the jigsaw-dev mailing list. It's worth considering. I plan to look at the usage of Class.forName in the JDK and add this new overload of Class.forName method if there are many use of it but I haven't got to it yet. I prefer to push this changeset as it and file a new CR and target it for JDK 8. Mandy From joe.darcy at oracle.com Fri Aug 24 16:39:20 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 24 Aug 2012 09:39:20 -0700 Subject: More updates to the ProblemList In-Reply-To: <503785EB.3040709@oracle.com> References: <503785EB.3040709@oracle.com> Message-ID: <5037AE38.7040906@oracle.com> Looks good Alan; approved, -Joe On 8/24/2012 6:47 AM, Alan Bateman wrote: > I need a reviewer to update the ProblemList to exclude a number of > tests, see attached. > > Minimally I'd like to get > sun/management/jmxremote/startstop/JMXStartStopTest.sh excluded. It > was removed from the exclude list recently [1] but has been causing > havoc on Windows since its release. I believe Dmitry Samersoff is > working on this. A number of tests are excluded on Mac because they > don't run headless, they seem to have been missed when other tests > were added for the same reason. Jason Uh had an initial patch to fix a > couple of these but I think it has been pushed yet. The others are > intermittent failures with bugs tracking the issues. > > -Alan. > > [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fb8792725d5 > > > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -141,6 +141,9 @@ javax/management/loading/LibraryLoader/L > # 7144846 > javax/management/remote/mandatory/connection/ReconnectTest.java generic-all > > > +# 7158614, locks up Windows machines at least > +sun/management/jmxremote/startstop/JMXStartStopTest.sh > windows-all > + > ############################################################################ > > > # jdk_math > @@ -222,8 +225,10 @@ java/net/URLClassLoader/closetest/CloseT > # 6962637 > java/io/File/MaxPathLength.java > windows-all > > -# 7145435 - Test needs AWT window server, does not work headless > +# 7162111 - these tests need to be updated to run headless > java/io/Serializable/resolveClass/deserializeButton/run.sh > macosx-all > +java/io/Serializable/serialver/classpath/run.sh > macosx-all > +java/io/Serializable/serialver/nested/run.sh > macosx-all > > ############################################################################ > > > @@ -246,6 +251,9 @@ java/nio/channels/DatagramChannel/Changi > # 7132677 > java/nio/channels/Selector/OutOfBand.java > macosx-all > > +# 7142919 > +java/nio/channels/AsyncCloseAndInterrupt.java > solaris-all > + > ############################################################################ > > > # jdk_rmi > @@ -257,6 +265,13 @@ java/rmi/transport/rapidExportUnexport/R > > # jdk_security > > +# 7193792 > +sun/security/pkcs11/ec/TestECDSA.java > solaris-all > +sun/security/pkcs11/ec/TestECDSA.java linux-all > + > +# 7193793 > +sun/security/pkcs11/ec/TestECDH.java linux-all > + > # 7147060 > com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java > generic-all > > @@ -265,7 +280,6 @@ sun/security/pkcs11/ec/ReadCertificates. > sun/security/pkcs11/ec/ReadCertificates.java > generic-all > sun/security/pkcs11/ec/ReadPKCS12.java > generic-all > sun/security/pkcs11/ec/TestCurves.java > solaris-i586 > -sun/security/pkcs11/ec/TestECDSA.java > solaris-i586 > #sun/security/pkcs11/ec/TestECGenSpec.java > solaris-i586 > #sun/security/pkcs11/ec/TestKeyFactory.java > solaris-i586 > sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java > generic-all > @@ -362,6 +376,9 @@ tools/launcher/UnicodeTest.java > > # jdk_util > > +# 7162111 - test needs to be changed to run headless > +java/util/ResourceBundle/Control/Bug6530694.java > macosx-all > + > # Filed 6933803 > java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java > generic-all > > > > > From huizhe.wang at oracle.com Fri Aug 24 16:52:11 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 24 Aug 2012 09:52:11 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <501630CB.8000100@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> Message-ID: <5037B13B.8060206@oracle.com> Hi, Here is a modified patch: http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ The factory finders contain some format changes, a NetBeans format work. The real changes are as the follows: 1) In factory classes: reinstated the implementation resolution mechanism, the 3rd step mainly 2) In factory finders: replaced findJarServiceProvider with findServiceProvider 3) In factory finders: removed ConfigurationError class, using FactoryConfigurationError instead Please review. Thanks, Joe On 7/29/2012 11:59 PM, Joe Wang wrote: > Hi Paul, Alan, > > I'm back on this change. > > On 6/25/2012 12:19 PM, Joe Wang wrote: >> >> >> On 6/25/2012 9:34 AM, Paul Sandoz wrote: >>> H Joe, >>> >>> I just focused on javax.xml.datatype and assumed the rest follows >>> the same pattern :-) >> >> Yeah, they are mostly similar, except Schema and XPath that do a >> little extra check. >> >> > I said too quick. Yes, the steps are the same except for the > validation and XPath. But it happened that DatatypeFactory is the > only one that had defined Exception in the 3rd step. All others were > made to ignore any error, since in the regular JDK, we can always fall > back to the default impl unless requested not to. > > I've made all of the changes as we've discussed, to catch the > ServiceConfigurationError and pass on the cause for all of the > factories/finders. I wanted to post the change so that you could see > them on Mon. But I had to read the definitions again when I got to > the SchemaFactory and noticed that it was the only one that did not > have its own exception. Instead, it was defined to always throw IAE if > no impl is available. > > As I thought through these definitions, I felt I would probably change > them back although I started to hate the tedious duplications as you > expected :) Indeed, I have to argue again, in the regular JDK, > there's no need to catch any errors since they would be considered > abnormal (Windows' blue screen came to my mind). And in jigsaw, we > shall only need to figure out a different error message when no > provider is available, only if we wanted it to be more end-user friendly. > > -Joe > From chris.hegarty at oracle.com Fri Aug 24 17:07:15 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 24 Aug 2012 18:07:15 +0100 Subject: More updates to the ProblemList In-Reply-To: <503785EB.3040709@oracle.com> References: <503785EB.3040709@oracle.com> Message-ID: <5037B4C3.5090409@oracle.com> Looks fine to me. -Chris. On 24/08/12 14:47, Alan Bateman wrote: > I need a reviewer to update the ProblemList to exclude a number of > tests, see attached. > > Minimally I'd like to get > sun/management/jmxremote/startstop/JMXStartStopTest.sh excluded. It was > removed from the exclude list recently [1] but has been causing havoc on > Windows since its release. I believe Dmitry Samersoff is working on > this. A number of tests are excluded on Mac because they don't run > headless, they seem to have been missed when other tests were added for > the same reason. Jason Uh had an initial patch to fix a couple of these > but I think it has been pushed yet. The others are intermittent failures > with bugs tracking the issues. > > -Alan. > > [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fb8792725d5 > > > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -141,6 +141,9 @@ javax/management/loading/LibraryLoader/L > # 7144846 > javax/management/remote/mandatory/connection/ReconnectTest.java > generic-all > > +# 7158614, locks up Windows machines at least > +sun/management/jmxremote/startstop/JMXStartStopTest.sh windows-all > + > ############################################################################ > > # jdk_math > @@ -222,8 +225,10 @@ java/net/URLClassLoader/closetest/CloseT > # 6962637 > java/io/File/MaxPathLength.java windows-all > > -# 7145435 - Test needs AWT window server, does not work headless > +# 7162111 - these tests need to be updated to run headless > java/io/Serializable/resolveClass/deserializeButton/run.sh > macosx-all > +java/io/Serializable/serialver/classpath/run.sh macosx-all > +java/io/Serializable/serialver/nested/run.sh macosx-all > > ############################################################################ > > @@ -246,6 +251,9 @@ java/nio/channels/DatagramChannel/Changi > # 7132677 > java/nio/channels/Selector/OutOfBand.java > macosx-all > > +# 7142919 > +java/nio/channels/AsyncCloseAndInterrupt.java solaris-all > + > ############################################################################ > > # jdk_rmi > @@ -257,6 +265,13 @@ java/rmi/transport/rapidExportUnexport/R > > # jdk_security > > +# 7193792 > +sun/security/pkcs11/ec/TestECDSA.java solaris-all > +sun/security/pkcs11/ec/TestECDSA.java linux-all > + > +# 7193793 > +sun/security/pkcs11/ec/TestECDH.java linux-all > + > # 7147060 > com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java generic-all > > @@ -265,7 +280,6 @@ sun/security/pkcs11/ec/ReadCertificates. > sun/security/pkcs11/ec/ReadCertificates.java generic-all > sun/security/pkcs11/ec/ReadPKCS12.java generic-all > sun/security/pkcs11/ec/TestCurves.java solaris-i586 > -sun/security/pkcs11/ec/TestECDSA.java solaris-i586 > #sun/security/pkcs11/ec/TestECGenSpec.java solaris-i586 > #sun/security/pkcs11/ec/TestKeyFactory.java solaris-i586 > sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java generic-all > @@ -362,6 +376,9 @@ tools/launcher/UnicodeTest.java > > # jdk_util > > +# 7162111 - test needs to be changed to run headless > +java/util/ResourceBundle/Control/Bug6530694.java macosx-all > + > # Filed 6933803 > java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java > generic-all > > > > > From naoto.sato at oracle.com Fri Aug 24 17:15:54 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 24 Aug 2012 17:15:54 +0000 Subject: hg: jdk8/tl/jdk: 7193601: Build breakage with the fix to 6336885 (build-infra build) Message-ID: <20120824171623.E1F28476EB@hg.openjdk.java.net> Changeset: faf4528aea4e Author: naoto Date: 2012-08-24 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/faf4528aea4e 7193601: Build breakage with the fix to 6336885 (build-infra build) Reviewed-by: mduigou ! makefiles/CompileJavaClasses.gmk From alan.bateman at oracle.com Fri Aug 24 18:39:02 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 24 Aug 2012 18:39:02 +0000 Subject: hg: jdk8/tl/jdk: 7193933: More ProblemList.txt updates (8/2012) Message-ID: <20120824183925.8B920476EC@hg.openjdk.java.net> Changeset: a7cdfd16e36e Author: alanb Date: 2012-08-24 19:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7cdfd16e36e 7193933: More ProblemList.txt updates (8/2012) Reviewed-by: darcy, chegar ! test/ProblemList.txt From kurchi.subhra.hazra at oracle.com Fri Aug 24 18:49:30 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Fri, 24 Aug 2012 18:49:30 +0000 Subject: hg: jdk8/tl/jdk: 7168172: (fs) Files.isReadable slow on Windows Message-ID: <20120824184950.4B799476ED@hg.openjdk.java.net> Changeset: bd91a601265c Author: khazra Date: 2012-08-24 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd91a601265c 7168172: (fs) Files.isReadable slow on Windows Summary: Remove DACL checking for read access, also reviewed by Ulf.Zibis at CoSoCo.de, zhong.j.yu at gmail.com Reviewed-by: alanb ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java From dan.xu at oracle.com Fri Aug 24 18:52:50 2012 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 24 Aug 2012 11:52:50 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <1261180730.10041364.1345767427410.JavaMail.root@redhat.com> References: <1261180730.10041364.1345767427410.JavaMail.root@redhat.com> Message-ID: <5037CD82.3030602@oracle.com> On 08/23/2012 05:17 PM, Andrew Hughes wrote: > > ----- Original Message ----- >> >> ----- Original Message ----- >>> Please review the fix of CR 7193406 at >>> http://cr.openjdk.java.net/~dxu/7193406/webrev/. >>> >> snip... >> >>> And it enables fatal warning flag in the following make file. >>> >>> make/java/jar/Makefile >>> >> Please don't do this, at least not unconditionally. >> >> At the very least, these should not be forced on if the user >> has explicitly built with them set to false. If I set >> JAVAC_WARNINGS_FATAL=false, I don't expect part of the build >> to ignore this and use -Werror, possibly then causing build >> failures. >> >> This is especially bad with both on as a new warning may be >> introduced into javac which then breaks everyone's build. >> >> I already have a patch I intend to upstream which fixes the >> other cases of this I found. I'd prefer we didn't have another. >> >>> In FilePermission.java file, I make one change to its method >>> signature, >>> >>> public Enumeration elements() ==> public >>> Enumeration >>> elements() >>> >>> >>> I am not sure whether it will cause an issue of backward >>> compatibility. >>> Please advise. Thanks! >>> >> It's in a package-private class so I doubt it. >> >> Even if it wasn't, a new major release is the perfect time to fix >> these issues. >> >>> - Dan >>> > I should also point out that the annotation: > > @SuppressWarnings("unchecked") > private void readObject(ObjectInputStream in) throws IOException, > > could be moved down to the actual problematic assignment: > > Vector permissions = (Vector)gfields.get("permissions", null); > > so that warnings aren't suppressed throughout the method. > Andrew, Thanks for your suggestions. I have revoked the change to the make file and added the changes to readObject method, which did not draw my attention as it already suppresses all warnings inside the method. And we should place @SuppressWarnings at narrowest possible scope. Thanks! -Dan From dan.xu at oracle.com Fri Aug 24 19:07:04 2012 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 24 Aug 2012 12:07:04 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <5036DEA5.1020100@oracle.com> References: <5036A4C4.5040709@oracle.com> <5036DEA5.1020100@oracle.com> Message-ID: <5037D0D8.3030307@oracle.com> Hi David, Please see my response below. Thanks! On 08/23/2012 06:53 PM, David Holmes wrote: > Hi Dan, > > On 24/08/2012 7:46 AM, Dan Xu wrote: >> Please review the fix of CR 7193406 at >> http://cr.openjdk.java.net/~dxu/7193406/webrev/. >> >> It cleans up warnings in the following java files. >> >> src/share/classes/java/io/FilePermission.java > > I'm surprised that you need this: > > 426 @SuppressWarnings("fallthrough") > ... > 436 switch (actions) { > 437 case SecurityConstants.FILE_READ_ACTION: > 438 return READ; > > If this generates a fallthrough warning then I think whatever tool > generates that warning needs fixing! @SuppressWarnings("fallthrough") is put to suppress warnings generated by another switch/case statements while (i >= matchlen && !seencomma) { switch(a[i-matchlen]) { case ',': seencomma = true; /*FALLTHROUGH*/ case ' ': case '\r': case '\n': case '\f': case '\t': break; default: throw new IllegalArgumentException( "invalid permission: " + actions); } i--; } It is at the end of this method, getMask(String). The change of switch/case statements starting from line 436, as you pointed out, does not generate a fallthrough warning. > >> src/share/classes/java/util/ArrayDeque.java >> src/share/classes/java/util/Arrays.java >> src/share/classes/java/util/Collections.java >> src/share/classes/java/util/HashMap.java >> src/share/classes/java/util/JumboEnumSet.java >> src/share/classes/java/util/PriorityQueue.java >> src/share/classes/java/util/PropertyResourceBundle.java > > Here: > > ! @SuppressWarnings({ "unchecked", "rawtypes" }) > ! Map result = new HashMap(properties); > ! lookup = result; > > why do you keep the raw type instead of using HashMap<>(properties) ? If I change to use diamond operator, the compiler will give me the following error, ../../../src/share/classes/java/util/PropertyResourceBundle.java:132: error: incompatible types: HashMap cannot be converted to Map Map result = new HashMap<>(properties); ^ 1 error I think it is because the type of properties is Hashtable, which does not fit into new HashMap() constructor. > >> src/share/classes/java/util/jar/JarVerifier.java >> src/share/classes/java/util/jar/Pack200.java >> src/share/classes/sun/util/PreHashedMap.java >> >> >> >> And it enables fatal warning flag in the following make file. >> >> make/java/jar/Makefile > > I'm not sure what Andrew's objection is to this change as it only > affects how java/util/jar classes get compiled and is consistent with > the usage in all the other Makefiles. As far as I can see you can > override this on the make invocation anyway. > > I'm unclear how this is handled in the new build. > >> In FilePermission.java file, I make one change to its method signature, >> >> public Enumeration elements() ==> public Enumeration >> elements() >> >> >> I am not sure whether it will cause an issue of backward compatibility. >> Please advise. Thanks! > > As Andrew stated this is a package-private class so I don't see any > issue. > > Cheers, > David > >> - Dan Thanks for your comments. -Dan From Ulf.Zibis at CoSoCo.de Fri Aug 24 19:20:44 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 24 Aug 2012 21:20:44 +0200 Subject: hg: jdk8/tl/jdk: 7168172: (fs) Files.isReadable slow on Windows In-Reply-To: <20120824184950.4B799476ED@hg.openjdk.java.net> References: <20120824184950.4B799476ED@hg.openjdk.java.net> Message-ID: <5037D40C.3050302@CoSoCo.de> Kurchi, thanks for listing me. BTW, my official openJDK ID is ulfzibis -Ulf Am 24.08.2012 20:49, schrieb kurchi.subhra.hazra at oracle.com: > Changeset: bd91a601265c > Author: khazra > Date: 2012-08-24 11:48 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd91a601265c > > 7168172: (fs) Files.isReadable slow on Windows > Summary: Remove DACL checking for read access, also reviewed by Ulf.Zibis at CoSoCo.de, zhong.j.yu at gmail.com > Reviewed-by: alanb > > ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java > > From philip.race at oracle.com Fri Aug 24 19:40:57 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 24 Aug 2012 12:40:57 -0700 Subject: hg: jdk8/tl/jdk: 7168172: (fs) Files.isReadable slow on Windows In-Reply-To: <5037D40C.3050302@CoSoCo.de> References: <20120824184950.4B799476ED@hg.openjdk.java.net> <5037D40C.3050302@CoSoCo.de> Message-ID: <5037D8C9.5090800@oracle.com> It may not be enforced by tools, but I don't think you can be listed as a reviewer there unless you have the JDK 8 project reviewer attribute :- Alan does - http://openjdk.java.net/census#alanb but you don't - http://openjdk.java.net/census#ulfzibis Now maybe you should ask if you can be .. -phil. On 8/24/2012 12:20 PM, Ulf Zibis wrote: > Kurchi, > > thanks for listing me. > > BTW, my official openJDK ID is ulfzibis > > -Ulf > > Am 24.08.2012 20:49, schrieb kurchi.subhra.hazra at oracle.com: >> Changeset: bd91a601265c >> Author: khazra >> Date: 2012-08-24 11:48 -0700 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd91a601265c >> >> 7168172: (fs) Files.isReadable slow on Windows >> Summary: Remove DACL checking for read access, also reviewed by >> Ulf.Zibis at CoSoCo.de, zhong.j.yu at gmail.com >> Reviewed-by: alanb >> >> ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java >> >> > From Ulf.Zibis at CoSoCo.de Fri Aug 24 19:42:03 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 24 Aug 2012 21:42:03 +0200 Subject: hg: jdk8/tl/jdk: 7168172: (fs) Files.isReadable slow on Windows In-Reply-To: <5037D8C9.5090800@oracle.com> References: <20120824184950.4B799476ED@hg.openjdk.java.net> <5037D40C.3050302@CoSoCo.de> <5037D8C9.5090800@oracle.com> Message-ID: <5037D90B.7070704@CoSoCo.de> Oops, thanks for your correction, Phil. Sorry, I wasn't aware about that difference. -Ulf Am 24.08.2012 21:40, schrieb Phil Race: > It may not be enforced by tools, but I don't think you can be listed as > a reviewer there unless you have the JDK 8 project reviewer attribute :- > > Alan does - http://openjdk.java.net/census#alanb > > but you don't - http://openjdk.java.net/census#ulfzibis > > Now maybe you should ask if you can be .. > > -phil. > > On 8/24/2012 12:20 PM, Ulf Zibis wrote: >> Kurchi, >> >> thanks for listing me. >> >> BTW, my official openJDK ID is ulfzibis >> >> -Ulf >> >> Am 24.08.2012 20:49, schrieb kurchi.subhra.hazra at oracle.com: >>> Changeset: bd91a601265c >>> Author: khazra >>> Date: 2012-08-24 11:48 -0700 >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd91a601265c >>> >>> 7168172: (fs) Files.isReadable slow on Windows >>> Summary: Remove DACL checking for read access, also reviewed by Ulf.Zibis at CoSoCo.de, >>> zhong.j.yu at gmail.com >>> Reviewed-by: alanb >>> >>> ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java >>> >>> >> > > From stuart.marks at oracle.com Fri Aug 24 20:58:30 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 24 Aug 2012 13:58:30 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <1881758767.10314924.1345801363355.JavaMail.root@redhat.com> References: <1881758767.10314924.1345801363355.JavaMail.root@redhat.com> Message-ID: <5037EAF6.5050907@oracle.com> On 8/24/12 2:42 AM, Andrew Hughes wrote: > However, once the whole build is warning free, would it not be preferable > to remove these and just set JAVAC_WARNINGS_FATAL=true when doing development > builds? > > The problem I see is someone new coming to OpenJDK and not being able to > simply build it (with no changes) because a new warnings has appeared > and is being treated as an error. This is less of a problem with javac > as we control its development, and the JDK will use the javac built in the > langtools step in most cases. But, generally, -Werror is something you > should choose to enable, with the intention of fixing failures, not something > that should be forced on everyone building the code. Our experience is that when -Werror is off by default, warnings tend to be introduced inadvertently. In the time we've been working on warnings cleanup, I've noticed the warnings count creeping up in areas of the build that don't have -Werror enabled. If it weren't for the implicit compilation issue, enabling -Werror incrementally as areas of the build are cleared would have been a good way to ensure that we make steady progress without any backsliding. > On a related topic, it would be nice if javadoc could also support -Werror > as I constantly see warnings reappearing in the documentation. Yes, javadoc warnings are another *huge* problem. >> SUBDIRS_MAKEFLAGS += JAVAC_WARNINGS_FATAL=true >> >> and this is **not** overridable on the command line. That's wrong. If >> these are >> causing problems for you, please do submit patches. > > Yes, that's what we have in java/tools and is why JAVAC_WARNINGS_FATAL=false > doesn't completely remove -Werror at present. I'll post a webrev of the change > I have for this. Great, looking forward to this. s'marks From omajid at redhat.com Fri Aug 24 22:05:38 2012 From: omajid at redhat.com (Omair Majid) Date: Fri, 24 Aug 2012 18:05:38 -0400 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <5036DC47.6000008@oracle.com> References: <1752716260.10040789.1345767163342.JavaMail.root@redhat.com> <5036DC47.6000008@oracle.com> Message-ID: <5037FAB2.1060903@redhat.com> On 08/23/2012 09:43 PM, Stuart Marks wrote: > However, there are several cases where the following occurs: > > SUBDIRS_MAKEFLAGS += JAVAC_WARNINGS_FATAL=true > > and this is **not** overridable on the command line. But it is! Use: make SUBDIRS_MAKEFLAGS="" instead of SUBDIRS_MAKEFLAGS="" make See: http://www.gnu.org/software/make/manual/html_node/Overriding.html http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_66.html http://stackoverflow.com/a/2826178 Cheers, Omair From david.holmes at oracle.com Fri Aug 24 22:44:36 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 25 Aug 2012 08:44:36 +1000 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <5037A365.6040708@oracle.com> References: <50366BBB.2060406@oracle.com> <5036D865.5020704@oracle.com> <5037A365.6040708@oracle.com> Message-ID: <503803D4.10604@oracle.com> On 25/08/2012 1:53 AM, Mandy Chung wrote: > On 8/23/2012 6:27 PM, David Holmes wrote: >> >> Another way to simplify this would be to add a new overload of >> Class.forName(): >> >> public static Class forName(String name, boolean initialize) >> >> That way the loader argument could be dropped completely from a number >> of the use-cases. > > Paul and Remi also suggest that during the jigsaw code review on the > jigsaw-dev mailing list. It's worth considering. I plan to look at the > usage of Class.forName in the JDK and add this new overload of > Class.forName method if there are many use of it but I haven't got to it > yet. I prefer to push this changeset as it and file a new CR and target > it for JDK 8. My other query with these changes is whether we are certain that using the specified loader rather than the boot loader will always be correct. David > Mandy From mandy.chung at oracle.com Fri Aug 24 22:57:48 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 24 Aug 2012 15:57:48 -0700 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <503803D4.10604@oracle.com> References: <50366BBB.2060406@oracle.com> <5036D865.5020704@oracle.com> <5037A365.6040708@oracle.com> <503803D4.10604@oracle.com> Message-ID: <503806EC.8070207@oracle.com> On 8/24/2012 3:44 PM, David Holmes wrote: > My other query with these changes is whether we are certain that using > the specified loader rather than the boot loader will always be correct. Yes I'm to my best knowledge but I'm looking to the reviewers to tell me otherwise :) The class being loaded is either part of the same module or expressed in its module dependency. I ran the JCK tests in module mode with the jigsaw modular JDK that uncovered these files to be changed. There are other places in the JDK that I didn't touch since they were not found by my testing. BTW, I have created a new CR: 7194006: A new Class.forName(String cn, boolean initialize) method http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.02/ This include Paul's suggestion and slightly improved the javadoc for Class.forName you suggested [1]: - * @param initialize whether the class must be initialized + * @param initialize if {@code true} the class will be initialized. + * See Section 12 of The Java Language Specification. Thanks Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-May/002534.html From jonathan.gibbons at oracle.com Fri Aug 24 23:48:05 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 24 Aug 2012 16:48:05 -0700 Subject: [PATCH FOR REVIEW] 7194032: update tests for upcoming changes for jtreg Message-ID: <503812B5.9040701@oracle.com> Currently, jtreg incorrectly confuses the concept of the /directory/ in which the test's class will be written with the /classpath/ used to locate all of the test's classes, including any library classes. It provides env variable TESTCLASSES and system property test.classes, and tests use these in different contexts to mean both a directory and a classpath. jtreg will be fixed to separate the two concepts, such that TESTCLASSES/test.classes will continue to mean the /directory/ in which the test's class will the written, and will introduce TESTCLASSPATH/test.class.path for the classpath used to locate all the test's classes. This change only affects a small number of tests, which use @library and TESTCLASSES. Two RMI tests are affected. FAILED: java/rmi/activation/Activatable/extLoadedImpl/ext.sh FAILED: java/rmi/registry/readTest/readTest.sh The fix is to update the tests where they are using TESTCLASSES/test.classes as a classpath. To ease migration onto the new jtreg, it is suggested that the tests check to see if the new variables are defined (i.e. new jtreg) and to fall back on the old variables if they are not defined (i.e. old jtreg). In shell terms, this can be written ${TESTCLASSPATH:-${TESTCLASSES}} The patch can be seen here: http://cr.openjdk.java.net/~jjg/7194032/webrev.00/ See also http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7194032 From mandy.chung at oracle.com Sat Aug 25 05:56:21 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 25 Aug 2012 05:56:21 +0000 Subject: hg: jdk8/tl/jdk: 7193339: Prepare system classes be defined by a non-null module loader Message-ID: <20120825055642.94E6447702@hg.openjdk.java.net> Changeset: d52081a08d11 Author: mchung Date: 2012-08-24 22:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d52081a08d11 7193339: Prepare system classes be defined by a non-null module loader Reviewed-by: alanb, dholmes, dsamersoff, sspitsyn, psandoz ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanMapping.java ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/util/prefs/Preferences.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java From Alan.Bateman at oracle.com Sat Aug 25 11:32:31 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 25 Aug 2012 12:32:31 +0100 Subject: [PATCH FOR REVIEW] 7194032: update tests for upcoming changes for jtreg In-Reply-To: <503812B5.9040701@oracle.com> References: <503812B5.9040701@oracle.com> Message-ID: <5038B7CF.4000105@oracle.com> On 25/08/2012 00:48, Jonathan Gibbons wrote: > Currently, jtreg incorrectly confuses the concept of the /directory/ > in which the test's class will be written with the /classpath/ used to > locate all of the test's classes, including any library classes. It > provides env variable TESTCLASSES and system property test.classes, > and tests use these in different contexts to mean both a directory and > a classpath. > > jtreg will be fixed to separate the two concepts, such that > TESTCLASSES/test.classes will continue to mean the /directory/ in > which the test's class will the written, and will introduce > TESTCLASSPATH/test.class.path for the classpath used to locate all the > test's classes. > > This change only affects a small number of tests, which use @library > and TESTCLASSES. Two RMI tests are affected. > > FAILED: java/rmi/activation/Activatable/extLoadedImpl/ext.sh > FAILED: java/rmi/registry/readTest/readTest.sh > > The fix is to update the tests where they are using > TESTCLASSES/test.classes as a classpath. > > To ease migration onto the new jtreg, it is suggested that the tests > check to see if the new variables are defined (i.e. new jtreg) and to > fall back on the old variables if they are not defined (i.e. old > jtreg). In shell terms, this can be written > ${TESTCLASSPATH:-${TESTCLASSES}} > > The patch can be seen here: > http://cr.openjdk.java.net/~jjg/7194032/webrev.00/ This looks fine to me. -Alan. From david.holmes at oracle.com Mon Aug 27 00:20:09 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Aug 2012 10:20:09 +1000 Subject: hg: jdk8/tl/jdk: 7168172: (fs) Files.isReadable slow on Windows In-Reply-To: <5037D8C9.5090800@oracle.com> References: <20120824184950.4B799476ED@hg.openjdk.java.net> <5037D40C.3050302@CoSoCo.de> <5037D8C9.5090800@oracle.com> Message-ID: <503ABD39.1070107@oracle.com> Phil, On 25/08/2012 5:40 AM, Phil Race wrote: > It may not be enforced by tools, but I don't think you can be listed as > a reviewer there unless you have the JDK 8 project reviewer attribute :- That is not the case. While you may require a JDK 8 Reviewer (capital R) to approve a changset, additional authors (anyone with an openjdk username) can provide reviews and be listed on the Reviewed-by line. http://openjdk.java.net/guide/producingChangeset.html "A reviewed-by line is required. Reviewers must have the ability to deal with any adverse consequences of the change, and so must themselves be authors. They are therefore identified by their OpenJDK usernames rather than full e-mail addresses." This happens all the time. David > Alan does - http://openjdk.java.net/census#alanb > > but you don't - http://openjdk.java.net/census#ulfzibis > > Now maybe you should ask if you can be .. > > -phil. > > On 8/24/2012 12:20 PM, Ulf Zibis wrote: >> Kurchi, >> >> thanks for listing me. >> >> BTW, my official openJDK ID is ulfzibis >> >> -Ulf >> >> Am 24.08.2012 20:49, schrieb kurchi.subhra.hazra at oracle.com: >>> Changeset: bd91a601265c >>> Author: khazra >>> Date: 2012-08-24 11:48 -0700 >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bd91a601265c >>> >>> 7168172: (fs) Files.isReadable slow on Windows >>> Summary: Remove DACL checking for read access, also reviewed by >>> Ulf.Zibis at CoSoCo.de, zhong.j.yu at gmail.com >>> Reviewed-by: alanb >>> >>> ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java >>> >>> >> > From david.holmes at oracle.com Mon Aug 27 01:15:41 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 Aug 2012 11:15:41 +1000 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <5037FAB2.1060903@redhat.com> References: <1752716260.10040789.1345767163342.JavaMail.root@redhat.com> <5036DC47.6000008@oracle.com> <5037FAB2.1060903@redhat.com> Message-ID: <503ACA3D.6020700@oracle.com> On 25/08/2012 8:05 AM, Omair Majid wrote: > On 08/23/2012 09:43 PM, Stuart Marks wrote: >> However, there are several cases where the following occurs: >> >> SUBDIRS_MAKEFLAGS += JAVAC_WARNINGS_FATAL=true >> >> and this is **not** overridable on the command line. > > But it is! Use: > > make SUBDIRS_MAKEFLAGS="" > > instead of > > SUBDIRS_MAKEFLAGS="" make I thnk you are missing the point. The above wipes out all of SUBDIRS_MAKEFLAGS, but all that is desired is to change the component of it that contains JAVAC_WARNINGS_FATAL=true. There is no way to do that from the command-line. David > See: > http://www.gnu.org/software/make/manual/html_node/Overriding.html > http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_66.html > http://stackoverflow.com/a/2826178 > > Cheers, > Omair From weijun.wang at oracle.com Mon Aug 27 02:24:34 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 27 Aug 2012 02:24:34 +0000 Subject: hg: jdk8/tl/jdk: 7152121: Krb5LoginModule no longer handles keyTabNames with "file:" prefix Message-ID: <20120827022448.510724772B@hg.openjdk.java.net> Changeset: 61ddc8ce7f3b Author: weijun Date: 2012-08-27 10:23 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61ddc8ce7f3b 7152121: Krb5LoginModule no longer handles keyTabNames with "file:" prefix Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java + test/sun/security/krb5/auto/FileKeyTab.java From iris.clark at oracle.com Mon Aug 27 03:27:58 2012 From: iris.clark at oracle.com (Iris Clark) Date: Sun, 26 Aug 2012 20:27:58 -0700 (PDT) Subject: [PATCH FOR REVIEW] 7194032: update tests for upcoming changes for jtreg In-Reply-To: <503812B5.9040701@oracle.com> References: <503812B5.9040701@oracle.com> Message-ID: Hi, Jon. > -----Original Message----- > From: Jonathan Gibbons > Sent: Friday, August 24, 2012 4:48 PM > To: Java Core Libs > Subject: [PATCH FOR REVIEW] 7194032: update tests for upcoming changes for jtreg [ ... ] > The patch can be seen here: > http://cr.openjdk.java.net/~jjg/7194032/webrev.00/ Looks good to me. > See also > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7194032 Thanks for discovering this problem in jtreg and fixing it too! iris From paul.sandoz at oracle.com Mon Aug 27 08:40:52 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 27 Aug 2012 10:40:52 +0200 Subject: Review Request: 7193339 Prepare system classes be defined by a non-null module loader In-Reply-To: <503806EC.8070207@oracle.com> References: <50366BBB.2060406@oracle.com> <5036D865.5020704@oracle.com> <5037A365.6040708@oracle.com> <503803D4.10604@oracle.com> <503806EC.8070207@oracle.com> Message-ID: On Aug 25, 2012, at 12:57 AM, Mandy Chung wrote: > On 8/24/2012 3:44 PM, David Holmes wrote: >> My other query with these changes is whether we are certain that using the specified loader rather than the boot loader will always be correct. > > Yes I'm to my best knowledge but I'm looking to the reviewers to tell me otherwise :) > To the best of my knowledge too. > The class being loaded is either part of the same module or expressed in its module dependency. And for that reason it may be best to use the three arg method call [*] as much as possible for code in the JDK code base. If code is shuffled around it then becomes clearer if the constraint, "either part of the same module or expressed in its module dependency", breaks. Paul. [*] That is not a negative on the stuff below. > I ran the JCK tests in module mode with the jigsaw modular JDK that uncovered these files to be changed. There are other places in the JDK that I didn't touch since they were not found by my testing. > > BTW, I have created a new CR: > 7194006: A new Class.forName(String cn, boolean initialize) method > > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.02/ > > This include Paul's suggestion and slightly improved the javadoc > for Class.forName you suggested [1]: > > - * @param initialize whether the class must be initialized > + * @param initialize if {@code true} the class will be initialized. > + * See Section 12 of The Java Language Specification. > > Thanks > Mandy > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-May/002534.html From Ulf.Zibis at CoSoCo.de Mon Aug 27 08:47:11 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 27 Aug 2012 10:47:11 +0200 Subject: A bug in filesystem bootstrap (unix/ linux) prevents In-Reply-To: <4FF547DB.10400@oracle.com> References: <4FF443F1.40502@CoSoCo.de> <4FF4E958.2020103@oracle.com> <4FF547DB.10400@oracle.com> Message-ID: <503B340F.6050007@CoSoCo.de> Hi Sherman, what is "jnu" standing for? You have touched on 3 "classes" of system encodings: - default encoding of the file content - the encoding of the file path - the "text" encoding when use the platform APIs Are there more? > so in theory file.encoding should be used to only for the encoding of "file content", and > the sun.jnu.encoding should be used when you need the encoding to talk to those platform APIs Which property is used for the encoding of the file path? In Charset.defaultCharset() it is not specified, on which of those 3+? "classes" this method refers. IMHO this should be done! Thanks, -Ulf Am 05.07.2012 09:52, schrieb Xueming Shen: > The code cited is a little shortcut, if there is locale over there is indeed using > utf-16, or any encoding that needs to switch/shift into ASCII (or its single byte > charset area) with a shift/in/out character.. So far I'm not aware of any such > a locale on any our supported platform. Historically, this kind of assumption > might run into trouble when being ported to other platform, such as ebcdic > based system (but I don't think it's a problem in this case). Ideally, the code > probably should be coded to be able to deal with a mb type of "/", but obviously > it was decided to take the short-cut for better performance here. > > "We" have been taking the stand that file.encoding is an informative/read-only > system property for a long time, mainly because of two reasons. First this > property is really defined/implemented/used as the default encoding that the jvm > uses to communicated with the underlying platform for local/encoding sensitive > stuff, the default encoding of the file content, the encoding of the file path and > the "text" encoding when use the platform APIs, for example. It's like a "contract" > between the jvm and the underlying platform, it needs to be understood by both > and agreed on by both. So it needs to be set based on what your underlying system > is using, not something you want to set via either -D or System.setProperty. If > your underlying locale is not UTF-16, I don't think you should expect the jvm > could work correctly if it keeps "talking" in UTF-16 to the underlying system, > for example, pass in a file name in utf-16, when your are running on a utf-8 > locale (it is more complicated on a windows platform, when you have system > locale and user locale, and historically file.encoding was used for both, consider > if your system locale and user locale are set differently...). > > The property sun.jnu.encoding introduced in jdk6 (this is mainly > to address the issue we have with file.encoding on windows platform though) > somehow helps remove some "pressure" from the file.encoding, so in theory > file.encoding should be used to only for the encoding of "file content", and > the sun.jnu.encoding should be used when you need the encoding to talk to > those platform APIs, so something might be done here (currently file.encoding > and sun.jnu.encoding are set to the same thing on non-Windows platform). > > The other reason is the timing of how the file.encoding is being initialized and > how it is being used during the "complicated" system initialization stage, almost > everyone touched System. initializeSystemClass() got burned here and there > in the past:-) So sometime you want to ask if it is worth the risk to change > something work for a use scenario that is not "supported". That said, as > I said above, something might be done to address this issue, but obviously > not a priority for now. > > -Sherman > > if you want to do -Dfile.encoding=xyz, you > are on your own, it might work, it might not work. > From dl at cs.oswego.edu Mon Aug 27 10:55:51 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 27 Aug 2012 06:55:51 -0400 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> Message-ID: <503B5237.8000806@cs.oswego.edu> Vitaly Davidovich wrote: > I figured you did, but wanted to check. :) > > So the perf hit was with c2 compilation? Were you able to check the > assembly (or enable inlining printing in hotspot) and see that lack of > inlining (and whatever further opto that enabled) was the difference by > simply adding a local or two? I'm legitimately curious here because if > that's the case and this was on a somewhat recent hotspot build, it sort > of goes against what TomR seemed to have been saying. The underlying issue is that code size is one of the criteria that JITs use to decide to compile/inline etc. So long as they do so, there will be cases here and there where it critically important to keep sizes small in bottleneck code. Not many, but still enough for me to object to efforts that might blindly increase code size for the sake of warnings cleanup. -Doug From Alan.Bateman at oracle.com Mon Aug 27 13:19:22 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 Aug 2012 14:19:22 +0100 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <5037B13B.8060206@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> Message-ID: <503B73DA.4060807@oracle.com> On 24/08/2012 17:52, Joe Wang wrote: > Hi, > > Here is a modified patch: > http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ > > The factory finders contain some format changes, a NetBeans format > work. The real changes are as the follows: > > 1) In factory classes: reinstated the implementation resolution > mechanism, the 3rd step mainly > > 2) In factory finders: replaced findJarServiceProvider with > findServiceProvider > > 3) In factory finders: removed ConfigurationError class, using > FactoryConfigurationError instead I've taken a pass over this, it looks much better now (duplicate FactoryFinders aside). In DocumentBuilderFactory and SAXParserFactory the javadoc reads " Otherwise the default implementation is returned if it is on the classpath or installed as a module". I think this statement needs to be re-worked, first to remove the word "module" as it is not defined here, and also because I don't think it's the classpath. If I read the code correctly then initiating loader may actually be the context class loader and assuming the usual delegation then the default should be loaded by the boot class loader. It may be possible to borrow some of the wording from the ServiceLoader javadoc to help here. In DatatypeFactory.java then it would be good to use {@link ..} or {@code ..} around the error and exception types that are referenced in the javadoc. Same thing in several other classes. In src/javax/xml/datatype/FactoryFinder.java then is there any reason why this class has to use Object? I realize that some of the factory finders are called for several types but there are few (like this one) where there is only one type involved. DocumentBuilderFactory.java it has: catch (FactoryConfigurationError e) { throw e; } I assume the catch is not needed, same thing in a few other places. Also in DocumentBuilderFatcory: " If ServiceConfigurationError is thrown, it is interpreted as an invalid provider is encountered. The process shall continue the search until all are exhausted." I think this could be re-worded, minimally "as an invalid" to "as if an invalid". Also "until all are exhausted" isn't completely clear to me, maybe it needs to re-iterate that it falls back to the system default. Minor nit in src/javax/xml/validation/FactoryConfigurationError.java but it seems to be using 2-space indents rather than 4-space indents. I think one thing that would be really useful here is to get a summary of the behavioral and API changes that this changes brings. SchemeFactory now throws FactoryConfigurationError whereas previously errors were ignored. It would be good to summarize the others. -Alan. From paul.sandoz at oracle.com Mon Aug 27 13:19:55 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 27 Aug 2012 15:19:55 +0200 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <5037B13B.8060206@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> Message-ID: <1F4403CF-F8AD-4FA9-BBCB-E373B5329A2D@oracle.com> Hi Joe, This is starting to look cleaner. -- datatype/FactoryFinder.java: 244 } catch (ServiceConfigurationError e) { 245 throw new DatatypeConfigurationException(e.getMessage(), e.getCause()); You are munging the message of the exception and it's cause. Perhaps it would be better just to pass along the SCE as the cause, that way it is better identified that SL is being used when an error occurs. -- There is inconsistency of the JavaDoc of DocumentBuilderFactory (some others) and DataTypeFactory. The former also makes reference to modules. I guess you just need to sync up the JavaDoc. -- parsers/DocumentBuilderFactory.java 121 public static DocumentBuilderFactory newInstance() { 122 try { 123 return (DocumentBuilderFactory) FactoryFinder.find(DocumentBuilderFactory.class, 124 /* The default property name according to the JAXP spec */ 125 "javax.xml.parsers.DocumentBuilderFactory", 126 /* The fallback implementation class name */ 127 "com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl"); 128 } catch (FactoryConfigurationError e) { 129 throw e; 130 } You are just re-throwing. -- parsers/FactoryFinder.java 280 } catch (ServiceConfigurationError e) { 281 throw new FactoryConfigurationError((Exception) e.getCause(), e.getMessage()); A CCE could occur. Like above i think you are better off passing the SCE as the cause. Same goes for some other factory-based classes. -- parsers/SAXParserFactory.java 125 public static SAXParserFactory newInstance() 126 { 127 try{ 128 return (SAXParserFactory) FactoryFinder.find(SAXParserFactory.class, 129 /* The default property name according to the JAXP spec */ 130 "javax.xml.parsers.SAXParserFactory", 131 /* The fallback implementation class name */ 132 "com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl"); 133 } catch (FactoryConfigurationError e) { 134 throw e; 135 } 136 } You are just re-throwing. -- validation/SchemaFactoryFinder.java 212 SchemaFactory f = null; 213 try { 214 f = new SchemaFactoryFinder(cl).newFactory(schemaLanguage); 215 } catch (FactoryConfigurationError e) { 216 throw e; 217 } You are just re-throwing. -- SchemaFactoryFinder and XPathFactoryFinder It seems the error behaviour has changed. AFAICT previously any exceptions would be swallowed and null would be returned. If there is an SCE then an exception will now be propagated. This may be OK though, just not totally sure. When using SL you are ignoring the classloader passed into the constructor. I think you may have to pass the classloader as an argument to SL because of the selection: 201 public static final SchemaFactory newInstance(String schemaLanguage) 202 { 203 ClassLoader cl; 204 cl = ss.getContextClassLoader(); 205 206 if (cl == null) { 207 //cl = ClassLoader.getSystemClassLoader(); 208 //use the current class loader 209 cl = SchemaFactory.class.getClassLoader(); 210 } Given some of the weird class loader things app servers do i am guessing SchemaFactory may not always be loaded by the system class loader. Paul. On Aug 24, 2012, at 6:52 PM, Joe Wang wrote: > Hi, > > Here is a modified patch: http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ > > The factory finders contain some format changes, a NetBeans format work. The real changes are as the follows: > > 1) In factory classes: reinstated the implementation resolution mechanism, the 3rd step mainly > > 2) In factory finders: replaced findJarServiceProvider with findServiceProvider > > 3) In factory finders: removed ConfigurationError class, using FactoryConfigurationError instead > > Please review. > > Thanks, > Joe From kumar.x.srinivasan at oracle.com Mon Aug 27 14:26:54 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 27 Aug 2012 14:26:54 +0000 Subject: hg: jdk8/tl/langtools: 7192068: (javac) provide a way for IDEs to produce Enclosing Method attributes. Message-ID: <20120827142658.856FA47737@hg.openjdk.java.net> Changeset: c9749226cdde Author: ksrini Date: 2012-08-27 07:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c9749226cdde 7192068: (javac) provide a way for IDEs to produce Enclosing Method attributes. Reviewed-by: jjg Contributed-by: jan.lahoda at oracle.com ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java From lana.steuck at oracle.com Mon Aug 27 18:04:48 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:48 +0000 Subject: hg: jdk8/tl: 2 new changesets Message-ID: <20120827180448.5EB9A47744@hg.openjdk.java.net> Changeset: febd7ff52800 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/febd7ff52800 Added tag jdk8-b52 for changeset 8d24def5ceb3 ! .hgtags Changeset: c1a277c6022a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c1a277c6022a Added tag jdk8-b53 for changeset febd7ff52800 ! .hgtags From lana.steuck at oracle.com Mon Aug 27 18:04:47 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:47 +0000 Subject: hg: jdk8/tl/corba: 3 new changesets Message-ID: <20120827180452.3413047745@hg.openjdk.java.net> Changeset: 63aeb7a2472f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/63aeb7a2472f Added tag jdk8-b52 for changeset 80689ff9cb49 ! .hgtags Changeset: 16c82fc74695 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/16c82fc74695 Added tag jdk8-b53 for changeset 63aeb7a2472f ! .hgtags Changeset: d086e67eb9dd Author: lana Date: 2012-08-27 10:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d086e67eb9dd Merge From lana.steuck at oracle.com Mon Aug 27 18:04:51 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:51 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20120827180459.F101D47746@hg.openjdk.java.net> Changeset: 8a35fd644d3c Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8a35fd644d3c Added tag jdk8-b52 for changeset f62bc618122e ! .hgtags Changeset: 91970935926a Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/91970935926a Added tag jdk8-b53 for changeset 8a35fd644d3c ! .hgtags From lana.steuck at oracle.com Mon Aug 27 18:04:51 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:51 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20120827180500.E86BE47747@hg.openjdk.java.net> Changeset: d3d0b9cd76e0 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d3d0b9cd76e0 Added tag jdk8-b52 for changeset 1d2db0e5eabc ! .hgtags Changeset: 9cf72631baf5 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9cf72631baf5 Added tag jdk8-b53 for changeset d3d0b9cd76e0 ! .hgtags Changeset: 542c87b8ce7f Author: lana Date: 2012-08-27 10:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/542c87b8ce7f Merge From lana.steuck at oracle.com Mon Aug 27 18:04:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:04:54 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20120827180504.56D6B47748@hg.openjdk.java.net> Changeset: 2c566f25c39f Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2c566f25c39f Added tag jdk8-b52 for changeset bd3c00d57614 ! .hgtags Changeset: 7dd81ccb7c11 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7dd81ccb7c11 Added tag jdk8-b53 for changeset 2c566f25c39f ! .hgtags Changeset: 933d0234670f Author: lana Date: 2012-08-27 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/933d0234670f Merge From lana.steuck at oracle.com Mon Aug 27 18:05:02 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:05:02 +0000 Subject: hg: jdk8/tl/hotspot: 12 new changesets Message-ID: <20120827180527.BE26B47749@hg.openjdk.java.net> Changeset: ef437ea56651 Author: amurillo Date: 2012-08-03 13:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ef437ea56651 7189086: new hotspot build - hs24-b20 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1d7922586cf6 Author: twisti Date: 2012-07-24 10:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1d7922586cf6 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, kvn, mhaupt Contributed-by: John Rose , Christian Thalinger , Michael Haupt ! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreterGenerator_x86.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.hpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/interpreterGenerator_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/register.hpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/c1/c1_ValueType.hpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp + src/share/vm/ci/ciMemberName.cpp + src/share/vm/ci/ciMemberName.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciStreams.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/vtableStubs.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/prims/jvmtiTagMap.cpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/exceptions.hpp Changeset: 977007096840 Author: twisti Date: 2012-07-27 16:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/977007096840 7187290: nightly failures after JSR 292 lazy method handle update Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/opto/doCall.cpp Changeset: 6c5b7a6becc8 Author: kvn Date: 2012-07-30 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c5b7a6becc8 7187454: stack overflow in C2 compiler thread on Solaris x86 Summary: Added new FormatBufferResource class to use thread's resource area for error message buffer. Reviewed-by: twisti ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp Changeset: 8cb110fd7627 Author: kvn Date: 2012-08-01 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8cb110fd7627 7188227: VM should recognize M-series SPARC Summary: Check kstat data for SPARC-M. Reviewed-by: roland ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp Changeset: b72784e722ff Author: twisti Date: 2012-08-01 14:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b72784e722ff 7188276: JSR 292: assert(ct == T_OBJECT) failed: rt=T_OBJECT, ct=13 Reviewed-by: kvn, jrose ! src/share/vm/opto/doCall.cpp Changeset: 93c71eb28866 Author: twisti Date: 2012-08-07 14:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/93c71eb28866 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: ee7edf31f688 Author: twisti Date: 2012-08-10 15:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ee7edf31f688 Merge - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java ! make/solaris/makefiles/fastdebug.make ! src/share/vm/opto/phaseX.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp Changeset: 4c8f2a12e757 Author: twisti Date: 2012-08-10 17:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4c8f2a12e757 Merge Changeset: 6d0436885201 Author: amurillo Date: 2012-08-10 23:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d0436885201 Added tag hs24-b20 for changeset 4c8f2a12e757 ! .hgtags Changeset: 54240c1b8e87 Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/54240c1b8e87 Added tag jdk8-b52 for changeset 6d0436885201 ! .hgtags Changeset: de2aa86e037d Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de2aa86e037d Added tag jdk8-b53 for changeset 54240c1b8e87 ! .hgtags From lana.steuck at oracle.com Mon Aug 27 18:05:06 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 27 Aug 2012 18:05:06 +0000 Subject: hg: jdk8/tl/jdk: 14 new changesets Message-ID: <20120827180731.A21BC4774A@hg.openjdk.java.net> Changeset: 05e5ce861a58 Author: jrose Date: 2012-07-12 00:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/05e5ce861a58 7153157: ClassValue.get does not return if computeValue calls remove Summary: Track intermediate states more precisely, according to spec. Reviewed-by: twisti, forax ! src/share/classes/java/lang/ClassValue.java Changeset: beeb1d5ecd9e Author: jrose Date: 2012-07-12 00:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/beeb1d5ecd9e 7129034: VM crash with a field setter method with a filterArguments Summary: add null checks before unsafe calls that take a variable base reference; update unit tests Reviewed-by: kvn, twisti ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! test/java/lang/invoke/MethodHandlesTest.java Changeset: 556141c6326c Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/556141c6326c 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited Reviewed-by: twisti ! src/share/classes/java/lang/invoke/MemberName.java Changeset: 78f1f4e4e9c7 Author: jrose Date: 2012-07-12 00:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78f1f4e4e9c7 7127687: MethodType leaks memory due to interning Summary: Replace internTable with a weak-reference version. Reviewed-by: sundar, forax, brutisso Contributed-by: james.laskey at oracle.com ! src/share/classes/java/lang/invoke/MethodType.java Changeset: 050116960e99 Author: twisti Date: 2012-07-24 10:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/050116960e99 7023639: JSR 292 method handle invocation needs a fast path for compiled code 6984705: JSR 292 method handle creation should not go through JNI Summary: remove assembly code for JDK 7 chained method handles Reviewed-by: jrose, twisti, mhaupt, forax Contributed-by: John Rose , Christian Thalinger , Michael Haupt - src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java + src/share/classes/java/lang/invoke/DontInline.java + src/share/classes/java/lang/invoke/ForceInline.java + src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/Invokers.java + src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java + src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java + src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! src/share/classes/sun/invoke/util/Wrapper.java ! src/share/classes/sun/misc/Unsafe.java + test/java/lang/invoke/7157574/Test7157574.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java + test/java/lang/invoke/MaxTest.java ! test/java/lang/invoke/MethodHandlesTest.java + test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java + test/java/lang/invoke/remote/RemoteExample.java ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 64e24cc8e009 Author: twisti Date: 2012-08-07 14:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64e24cc8e009 7188911: nightly failures after JSR 292 lazy method handle update (round 2) Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/MemberName.java Changeset: e1d063685dc8 Author: twisti Date: 2012-08-09 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e1d063685dc8 7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize Reviewed-by: jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: 865c411ebcae Author: twisti Date: 2012-08-10 16:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/865c411ebcae Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java Changeset: 93ddd9560751 Author: youdwei Date: 2012-08-13 10:45 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93ddd9560751 7189611: Venezuela current Currency should be Bs.F. Reviewed-by: okutsu ! src/share/classes/sun/util/resources/CurrencyNames_es_VE.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 90a9acfde9e6 Author: mfang Date: 2012-08-13 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90a9acfde9e6 Merge Changeset: e8569a473cee Author: katleman Date: 2012-08-15 18:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8569a473cee Merge Changeset: 2c6933c5106b Author: katleman Date: 2012-08-16 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c6933c5106b Added tag jdk8-b52 for changeset e8569a473cee ! .hgtags Changeset: 156ab3c38556 Author: katleman Date: 2012-08-23 12:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/156ab3c38556 Added tag jdk8-b53 for changeset 2c6933c5106b ! .hgtags Changeset: 96990c9da294 Author: lana Date: 2012-08-27 10:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96990c9da294 Merge - src/share/classes/java/lang/invoke/AdapterMethodHandle.java - src/share/classes/java/lang/invoke/CountingMethodHandle.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java From dan.xu at oracle.com Mon Aug 27 20:48:09 2012 From: dan.xu at oracle.com (Dan Xu) Date: Mon, 27 Aug 2012 13:48:09 -0700 Subject: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed element Message-ID: <503BDD09.80006@oracle.com> This change is to fix the java doc font issue for ByteArrayOutputStream class. In current javadoc, contents change to the wrong font starting from toString(String charsetName) in ByteArrayOutputStream.html, which can be viewed at http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html. The issue is caused by the unclosed tag. The webrev is at http://cr.openjdk.java.net/~dxu/7193710/webrev/. And I also generated new javadoc basing on my fix, which can be looked at http://act.us.oracle.com/~danxu/javadoc/java/io/ByteArrayOutputStream.html. Thanks! -Dan From stuart.marks at oracle.com Mon Aug 27 23:33:25 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 27 Aug 2012 16:33:25 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503B5237.8000806@cs.oswego.edu> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> Message-ID: <503C03C5.8010907@oracle.com> On 8/27/12 3:55 AM, Doug Lea wrote: > The underlying issue is that code size is one of the criteria > that JITs use to decide to compile/inline etc. So long as they do > so, there will be cases here and there where it critically > important to keep sizes small in bottleneck code. Not many, > but still enough for me to object to efforts that might > blindly increase code size for the sake of warnings cleanup. I'm pleased that warnings cleanup has attracted this much attention. :-) I was wondering where rule about @SuppressWarnings and local variables originally came from, and I tracked this back to Effective Java, Item 24, which says (as part of a fairly long discussion) If you find yourself using the SuppressWarnings annotation on a method or constructor that's more than one line long, you may be able to move it onto a local variable declaration. You may have to declare a new local variable, but it's worth it. Aha! So it's all Josh Bloch's fault! :-) In the warnings cleanup thus far, and in Dan's webrev, we've followed this rule fairly strictly. But since we seem to have evidence that this change isn't worth it, we should consider relaxing the rule for performance-critical code. How about adding a local variable for @SuppressWarnings only if the method is, say, longer than ten lines? (Or some other suitable threshold.) For short methods the annotation should be placed on the method itself. The risk of suppressing other warnings inadvertently is pretty small in a short method, and short methods are the ones most likely to be impacted by the addition of a local variable affecting compilation/inlining decisions. Right? (Also, while I've recommended that people follow the local variable rule fairly strictly, I think it tends to garbage up short methods. So I wouldn't mind seeing the rule relaxed on readability grounds as well.) s'marks From david.holmes at oracle.com Tue Aug 28 00:16:10 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Aug 2012 10:16:10 +1000 Subject: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed element In-Reply-To: <503BDD09.80006@oracle.com> References: <503BDD09.80006@oracle.com> Message-ID: <503C0DCA.4050004@oracle.com> Hi Dan, On 28/08/2012 6:48 AM, Dan Xu wrote: > This change is to fix the java doc font issue for ByteArrayOutputStream > class. In current javadoc, contents change to the wrong font starting > from toString(String charsetName) in ByteArrayOutputStream.html, which > can be viewed at > http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html. > The issue is caused by the unclosed tag. > > The webrev is at http://cr.openjdk.java.net/~dxu/7193710/webrev/. I think the current trend is to move away from etc and use {@code}, but your fix is correct and in-style with the rest of the file. Not sure if this is an opportunity to upgrade the file to using {@code} ? > And I also generated new javadoc basing on my fix, which can be looked > at > http://act.us.oracle.com/~danxu/javadoc/java/io/ByteArrayOutputStream.html. That's not accessible to non-Oracle folk. David > Thanks! > > -Dan From kurchi.subhra.hazra at oracle.com Tue Aug 28 00:22:44 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 27 Aug 2012 17:22:44 -0700 Subject: [7u8] Request for approval: 7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node In-Reply-To: <503BBEC0.20105@oracle.com> References: <503BBEC0.20105@oracle.com> Message-ID: <503C0F54.2080308@oracle.com> This is a request for approval to backport the fix for 7160252 from 8 to 7u8. Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160252 Webrev:http://cr.openjdk.java.net/~khazra/7160252/7u8/webrev.00/ This had been reviewed by Alan Bateman and Chris Hegarty. [1] This fix has been pushed into jdk8 [2]. Thanks, Kurchi [1]http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010823.html [2]http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9461aeff91f From kurchi.subhra.hazra at oracle.com Tue Aug 28 00:32:09 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Mon, 27 Aug 2012 17:32:09 -0700 Subject: [7u8] Request for approval: 7184287: (prefs) BackingStoreException when calling flush on root node[macosx] In-Reply-To: <503C0F54.2080308@oracle.com> References: <503BBEC0.20105@oracle.com> <503C0F54.2080308@oracle.com> Message-ID: <503C1189.8000803@oracle.com> This is a request for approval to backport the fix for 7184287 rom 8 to 7u8. Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184287 Webrev:http://cr.openjdk.java.net/~khazra/7184287/7u8/webrev.00/ This had been reviewed by Alan Bateman. [1] This fix has been pushed into jdk8 [2]. The fix for 7u8 is identical, but for the changes in test/ProblemList.txt. The ProblemList in jdk7u does not enlist these tests. Thanks, Kurchi [1]http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010918.html [2]http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74ceda3a98a0 From yiming.wang at oracle.com Tue Aug 28 02:52:22 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 28 Aug 2012 10:52:22 +0800 Subject: [PATCH] Review request: 6962637 TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system In-Reply-To: <5034A60A.9070103@oracle.com> References: <5034901B.1060103@oracle.com> <5034921F.8080002@oracle.com> <503493F0.30708@oracle.com> <5034A60A.9070103@oracle.com> Message-ID: <503C3266.7010402@oracle.com> Hi David, Amy & Alan Thanks for your review, Based on your comments I have updated the fix again, Can you please review again? http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html Thanks, Eric On 2012/8/22 17:27, David Holmes wrote: > On 22/08/2012 6:10 PM, Eric Wang wrote: >> Hi David, >> >> To use dirFile.length() == 0 to replace the disk space measurement as >> guess the original test tries to prove that there's no extra disk spent >> when creating empty folders. > > Sorry I don't understand. File.length() says: > > public long length() > > Returns the length of the file denoted by this abstract pathname. The > return value is unspecified if this pathname denotes a directory. > > Where it is required to distinguish an I/O exception from the case > that 0L is returned, or where several attributes of the same file are > required at the same time, then the Files.readAttributes method may be > used. > > Returns: > The length, in bytes, of the file denoted by this abstract > pathname, or 0L if the file does not exist. Some operating systems may > return 0L for pathnames denoting system-dependent entities such as > devices or pipes. > > ---- > > In this case we verify we have a directory before we do the length() > test, which means the return value from length is unspecified. > > So I don't understand how length() is being used here. > > David > ----- > > >> Regards, >> Eric >> >> On 2012/8/22 16:02, David Holmes wrote: >>> Hi Eric, >>> >>> On 22/08/2012 5:54 PM, Eric Wang wrote: >>>> Please help to review the fix below for bug **6962637 >>>> TEST_BUG: >>>> java/io/File/MaxPathLength.java may fail in busy system >>>> http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html >>>> >>>> Root cause is the test is not reliable when system is busy, if disk >>>> space is changed by some other program, test can fail. so the fix >>>> is to >>>> check file.length() instead of disk space. >>> >>> I can not figure out what the original version of the test was doing >>> with the disk space measurements but I can certainly appreciate that >>> they could be changing dynamically while the test is running. >>> >>> But I don't really understand why dirFile is expected to have a zero >>> length ??? >>> >>> David >>> >>>> Regards, >>>> Eric >> From david.holmes at oracle.com Tue Aug 28 03:06:12 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Aug 2012 13:06:12 +1000 Subject: [PATCH] Review request: 6962637 TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system In-Reply-To: <503C3266.7010402@oracle.com> References: <5034901B.1060103@oracle.com> <5034921F.8080002@oracle.com> <503493F0.30708@oracle.com> <5034A60A.9070103@oracle.com> <503C3266.7010402@oracle.com> Message-ID: <503C35A4.10105@oracle.com> Hi Eric, So removing the disk space stuff seems fine. Regarding which platform this will run on you have: - removed checks for obsolete windows platforms - enabled the general test to now run on Solaris - changed the test that would only run on windows if -extra was specified to now always run on windows Does that sum it up? The last part makes me wonder when we would run the test with -extra, as we will now always exercise this part on windows. And are we sure the Solaris issues are no longer a concern? I assume the problem was doing the disk space checks on remote filesystems. Thanks, David On 28/08/2012 12:52 PM, Eric Wang wrote: > Hi David, Amy & Alan > > Thanks for your review, Based on your comments I have updated the fix > again, Can you please review again? > http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html > > Thanks, > Eric > > > On 2012/8/22 17:27, David Holmes wrote: >> On 22/08/2012 6:10 PM, Eric Wang wrote: >>> Hi David, >>> >>> To use dirFile.length() == 0 to replace the disk space measurement as >>> guess the original test tries to prove that there's no extra disk spent >>> when creating empty folders. >> >> Sorry I don't understand. File.length() says: >> >> public long length() >> >> Returns the length of the file denoted by this abstract pathname. The >> return value is unspecified if this pathname denotes a directory. >> >> Where it is required to distinguish an I/O exception from the case >> that 0L is returned, or where several attributes of the same file are >> required at the same time, then the Files.readAttributes method may be >> used. >> >> Returns: >> The length, in bytes, of the file denoted by this abstract pathname, >> or 0L if the file does not exist. Some operating systems may return 0L >> for pathnames denoting system-dependent entities such as devices or >> pipes. >> >> ---- >> >> In this case we verify we have a directory before we do the length() >> test, which means the return value from length is unspecified. >> >> So I don't understand how length() is being used here. >> >> David >> ----- >> >> >>> Regards, >>> Eric >>> >>> On 2012/8/22 16:02, David Holmes wrote: >>>> Hi Eric, >>>> >>>> On 22/08/2012 5:54 PM, Eric Wang wrote: >>>>> Please help to review the fix below for bug **6962637 >>>>> TEST_BUG: >>>>> java/io/File/MaxPathLength.java may fail in busy system >>>>> http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html >>>>> >>>>> Root cause is the test is not reliable when system is busy, if disk >>>>> space is changed by some other program, test can fail. so the fix >>>>> is to >>>>> check file.length() instead of disk space. >>>> >>>> I can not figure out what the original version of the test was doing >>>> with the disk space measurements but I can certainly appreciate that >>>> they could be changing dynamically while the test is running. >>>> >>>> But I don't really understand why dirFile is expected to have a zero >>>> length ??? >>>> >>>> David >>>> >>>>> Regards, >>>>> Eric >>> > From yiming.wang at oracle.com Tue Aug 28 03:37:41 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 28 Aug 2012 11:37:41 +0800 Subject: [PATCH] Review request: 6962637 TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system In-Reply-To: <503C35A4.10105@oracle.com> References: <5034901B.1060103@oracle.com> <5034921F.8080002@oracle.com> <503493F0.30708@oracle.com> <5034A60A.9070103@oracle.com> <503C3266.7010402@oracle.com> <503C35A4.10105@oracle.com> Message-ID: <503C3D05.4030102@oracle.com> Hi David, Yes, the 3 items are all the changes. For the -extra option, I also don't know when it should be used, so i prefer to remove it to make sure the long path test on windows could be always executed in Nightly. For the Solaris issue, I have executed the test on several Solaris machines, but didn't get the timeout issue. Not sure whether the issue still exists, so remove it to see if it would be failed in Nightly. Thanks, Eric On 2012/8/28 11:06, David Holmes wrote: > Hi Eric, > > So removing the disk space stuff seems fine. > > Regarding which platform this will run on you have: > > - removed checks for obsolete windows platforms > - enabled the general test to now run on Solaris > - changed the test that would only run on windows if -extra was > specified to now always run on windows > > Does that sum it up? The last part makes me wonder when we would run > the test with -extra, as we will now always exercise this part on > windows. > > And are we sure the Solaris issues are no longer a concern? I assume > the problem was doing the disk space checks on remote filesystems. > > Thanks, > David > > On 28/08/2012 12:52 PM, Eric Wang wrote: >> Hi David, Amy & Alan >> >> Thanks for your review, Based on your comments I have updated the fix >> again, Can you please review again? >> http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html >> >> Thanks, >> Eric >> >> >> On 2012/8/22 17:27, David Holmes wrote: >>> On 22/08/2012 6:10 PM, Eric Wang wrote: >>>> Hi David, >>>> >>>> To use dirFile.length() == 0 to replace the disk space measurement as >>>> guess the original test tries to prove that there's no extra disk >>>> spent >>>> when creating empty folders. >>> >>> Sorry I don't understand. File.length() says: >>> >>> public long length() >>> >>> Returns the length of the file denoted by this abstract pathname. The >>> return value is unspecified if this pathname denotes a directory. >>> >>> Where it is required to distinguish an I/O exception from the case >>> that 0L is returned, or where several attributes of the same file are >>> required at the same time, then the Files.readAttributes method may be >>> used. >>> >>> Returns: >>> The length, in bytes, of the file denoted by this abstract pathname, >>> or 0L if the file does not exist. Some operating systems may return 0L >>> for pathnames denoting system-dependent entities such as devices or >>> pipes. >>> >>> ---- >>> >>> In this case we verify we have a directory before we do the length() >>> test, which means the return value from length is unspecified. >>> >>> So I don't understand how length() is being used here. >>> >>> David >>> ----- >>> >>> >>>> Regards, >>>> Eric >>>> >>>> On 2012/8/22 16:02, David Holmes wrote: >>>>> Hi Eric, >>>>> >>>>> On 22/08/2012 5:54 PM, Eric Wang wrote: >>>>>> Please help to review the fix below for bug **6962637 >>>>>> TEST_BUG: >>>>>> java/io/File/MaxPathLength.java may fail in busy system >>>>>> http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html >>>>>> >>>>>> Root cause is the test is not reliable when system is busy, if disk >>>>>> space is changed by some other program, test can fail. so the fix >>>>>> is to >>>>>> check file.length() instead of disk space. >>>>> >>>>> I can not figure out what the original version of the test was doing >>>>> with the disk space measurements but I can certainly appreciate that >>>>> they could be changing dynamically while the test is running. >>>>> >>>>> But I don't really understand why dirFile is expected to have a zero >>>>> length ??? >>>>> >>>>> David >>>>> >>>>>> Regards, >>>>>> Eric >>>> >> From huizhe.wang at oracle.com Tue Aug 28 04:57:06 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 27 Aug 2012 21:57:06 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <503B73DA.4060807@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <503B73DA.4060807@oracle.com> Message-ID: <503C4FA2.5050001@oracle.com> On 8/27/2012 6:19 AM, Alan Bateman wrote: > On 24/08/2012 17:52, Joe Wang wrote: >> Hi, >> >> Here is a modified patch: >> http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ >> >> The factory finders contain some format changes, a NetBeans format >> work. The real changes are as the follows: >> >> 1) In factory classes: reinstated the implementation resolution >> mechanism, the 3rd step mainly >> >> 2) In factory finders: replaced findJarServiceProvider with >> findServiceProvider >> >> 3) In factory finders: removed ConfigurationError class, using >> FactoryConfigurationError instead > I've taken a pass over this, it looks much better now (duplicate > FactoryFinders aside). Duplicate indeed. The original designers were in the same team, but somehow they decided the wordings, class names (exception/error classes) could be different. I guess we have to live with it, just a bit more tedious work. > > In DocumentBuilderFactory and SAXParserFactory the javadoc reads " > Otherwise the default implementation is returned if it is on the > classpath or installed as a module". I think this statement needs to > be re-worked, first to remove the word "module" as it is not defined > here, and also because I don't think it's the classpath. If I read the > code correctly then initiating loader may actually be the context > class loader and assuming the usual delegation then the default should > be loaded by the boot class loader. It may be possible to borrow some > of the wording from the ServiceLoader javadoc to help here. It seems we need to go over this again since it was intended for jdk8/jigsaw. Without modules, we don't really need to put other implementations over the default. How about change it to the following: * Uses the service-provider loading facilities, defined by the {@link java.util.ServiceLoader} class, to attempt * to locate and load an implementation of the service. If there are multiple providers, the first one returned * by the {@link java.util.ServiceLoader} will be instantiated and returned. * * If a misconfigured provider is encountered and {@link java.util.ServiceConfigurationError} is thrown, the error will be wrapped * in a {@link javax.xml.parsers.FactoryConfigurationException}.

> > In DatatypeFactory.java then it would be good to use {@link ..} or > {@code ..} around the error and exception types that are referenced in > the javadoc. Same thing in several other classes. All updated. > > In src/javax/xml/datatype/FactoryFinder.java then is there any reason > why this class has to use Object? I realize that some of the factory > finders are called for several types but there are few (like this one) > where there is only one type involved. No, it doesn't. FactoryFinder for datatype and transform can be dedicated. It was believed that it and SecuritySupport should be copied for each package, I think we touched this before. I left it alone, or otherwise we'd need to change all other methods in the class and also the transformer factory finder, for not much performance gain. > > DocumentBuilderFactory.java it has: > catch (FactoryConfigurationError e) { throw e; } > I assume the catch is not needed, same thing in a few other places. It's not. But since the javadoc for the method defined throws, I thought it's good to re-throw it within the method rather than going into the finder class to know that the Error will be thrown. > > Also in DocumentBuilderFatcory: " If ServiceConfigurationError is > thrown, it is interpreted as an invalid provider is encountered. The > process shall continue the search until all are exhausted." > I think this could be re-worded, minimally "as an invalid" to "as if > an invalid". Also "until all are exhausted" isn't completely clear to > me, maybe it needs to re-iterate that it falls back to the system default. Somehow I managed missing these two factories when I made the changes as we discussed. I actually went through all of the changes one more time, but still missed them. Corrected now. > > Minor nit in src/javax/xml/validation/FactoryConfigurationError.java > but it seems to be using 2-space indents rather than 4-space indents. Fixed. I guess I need to re-format every time I make a copy of an existing class :) > > I think one thing that would be really useful here is to get a summary > of the behavioral and API changes that this changes brings. > SchemeFactory now throws FactoryConfigurationError whereas previously > errors were ignored. It would be good to summarize the others. Yes, I think we'll do that in the MR. There isn't a general place in the Javadoc for us to do that. --Joe > > -Alan. > > > From huizhe.wang at oracle.com Tue Aug 28 05:35:45 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 27 Aug 2012 22:35:45 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <1F4403CF-F8AD-4FA9-BBCB-E373B5329A2D@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <1F4403CF-F8AD-4FA9-BBCB-E373B5329A2D@oracle.com> Message-ID: <503C58B1.6080502@oracle.com> On 8/27/2012 6:19 AM, Paul Sandoz wrote: > Hi Joe, > > This is starting to look cleaner. Yeah, if Alan hasn't asked, I'd sooner keep them as they were :) JAXP is old, I never fancied getting those formats corrected. But I can't do this much to classes I'd update, but probably not to the impl classes in sync with Apache, even if it might mean poor format. > > -- > > datatype/FactoryFinder.java: > > 244 } catch (ServiceConfigurationError e) { > 245 throw new DatatypeConfigurationException(e.getMessage(), e.getCause()); > > You are munging the message of the exception and it's cause. Perhaps it would be better just to pass along the SCE as the cause, that way it is better identified that SL is being used when an error occurs. None of the ConfigureError classes in other packages accept Error or Throwable as did DataType (and this one is an Exception!) So instead of making changes to the ConfigureError classes, I wrapped the ServiceConfigurationError in jaxp configuration errors, and in this case (Datatype), a datatype configuration exception It should be very rare to get a ServiceConfigurationError that would indicate a serious error in a jar configuration, basically, a non-usable implementation. So I think we don't have to stick with the ServiceConfigurationError. > > -- > > There is inconsistency of the JavaDoc of DocumentBuilderFactory (some others) and DataTypeFactory. The former also makes reference to modules. I guess you just need to sync up the JavaDoc. Updated. > > -- > > parsers/DocumentBuilderFactory.java > > 121 public static DocumentBuilderFactory newInstance() { > 122 try { > 123 return (DocumentBuilderFactory) FactoryFinder.find(DocumentBuilderFactory.class, > 124 /* The default property name according to the JAXP spec */ > 125 "javax.xml.parsers.DocumentBuilderFactory", > 126 /* The fallback implementation class name */ > 127 "com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl"); > 128 } catch (FactoryConfigurationError e) { > 129 throw e; > > 130 } > > You are just re-throwing. I did. It's not necessary technically. But since the javadoc for the method defined it, I thought it's good to re-throw it within the method, or repeat it, it's also making sure FactoryFinder indeed throw the error. > -- > > SchemaFactoryFinder and XPathFactoryFinder > > It seems the error behaviour has changed. AFAICT previously any exceptions would be swallowed and null would be returned. If there is an SCE then an exception will now be propagated. This may be OK though, just not totally sure. Yes, it's changed. We discussed this issue before, all but Datatype swallowed any error out of the 3rd step and they all fall back to the default impl in the 4th step. In a recent conversation with Alan, he wanted to see the error caught, and I believe you did too. I didn't think we needed to, but I'm okay both ways since it shall very rarely happen. Even if it does, it should have been fixed by an impl developer long before it's out. This is also one of those 'differences' in the api impl that kept troubling us :) > > When using SL you are ignoring the classloader passed into the constructor. I think you may have to pass the classloader as an argument to SL because of the selection: > > 201 public static final SchemaFactory newInstance(String schemaLanguage) > 202 { > 203 ClassLoader cl; > 204 cl = ss.getContextClassLoader(); > 205 > 206 if (cl == null) { > 207 //cl = ClassLoader.getSystemClassLoader(); > 208 //use the current class loader > 209 cl = SchemaFactory.class.getClassLoader(); > 210 } > > Given some of the weird class loader things app servers do i am guessing SchemaFactory may not always be loaded by the system class loader. I did. This is the same order as in the ServiceLoader. So I thought it didn't really make any difference. The only case where a user supplied classloader may be used is when a factory class name is also explicitly specified. -Joe > > Paul. > > > On Aug 24, 2012, at 6:52 PM, Joe Wang wrote: > >> Hi, >> >> Here is a modified patch: http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ >> >> The factory finders contain some format changes, a NetBeans format work. The real changes are as the follows: >> >> 1) In factory classes: reinstated the implementation resolution mechanism, the 3rd step mainly >> >> 2) In factory finders: replaced findJarServiceProvider with findServiceProvider >> >> 3) In factory finders: removed ConfigurationError class, using FactoryConfigurationError instead >> >> Please review. >> >> Thanks, >> Joe From sean.coffey at oracle.com Tue Aug 28 08:09:46 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 28 Aug 2012 09:09:46 +0100 Subject: [7u8] Request for approval: 7184287: (prefs) BackingStoreException when calling flush on root node[macosx] In-Reply-To: <503C1189.8000803@oracle.com> References: <503BBEC0.20105@oracle.com> <503C0F54.2080308@oracle.com> <503C1189.8000803@oracle.com> Message-ID: <503C7CCA.3060201@oracle.com> Approved. regards, Sean. On 28/08/2012 01:32, Kurchi Hazra wrote: > > This is a request for approval to backport the fix for 7184287 rom 8 > to 7u8. > > Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7184287 > Webrev:http://cr.openjdk.java.net/~khazra/7184287/7u8/webrev.00/ > > This had been reviewed by Alan Bateman. [1] > > This fix has been pushed into jdk8 [2]. The fix for 7u8 is identical, > but for the changes in test/ProblemList.txt. The ProblemList in jdk7u > does not > enlist these tests. > > Thanks, > Kurchi > > [1]http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010918.html > > [2]http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74ceda3a98a0 From Alan.Bateman at oracle.com Tue Aug 28 08:17:56 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Aug 2012 09:17:56 +0100 Subject: [PATCH] Review request: 6962637 TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system In-Reply-To: <503C3266.7010402@oracle.com> References: <5034901B.1060103@oracle.com> <5034921F.8080002@oracle.com> <503493F0.30708@oracle.com> <5034A60A.9070103@oracle.com> <503C3266.7010402@oracle.com> Message-ID: <503C7EB4.4070204@oracle.com> On 28/08/2012 03:52, Eric Wang wrote: > Hi David, Amy & Alan > > Thanks for your review, Based on your comments I have updated the fix > again, Can you please review again? > http://dl.dropbox.com/u/90659131/fixes/6962637/webrev/index.html > > Thanks, > Eric I think this is fine and I don't see any reason not to run the test on Solaris. -Alan. From paul.sandoz at oracle.com Tue Aug 28 08:19:20 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 28 Aug 2012 10:19:20 +0200 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <503C58B1.6080502@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <1F4403CF-F8AD-4FA9-BBCB-E373B5329A2D@oracle.com> <503C58B1.6080502@oracle.com> Message-ID: Hi Joe, On Aug 28, 2012, at 7:35 AM, Joe Wang wrote: >> >> -- >> >> datatype/FactoryFinder.java: >> >> 244 } catch (ServiceConfigurationError e) { >> 245 throw new DatatypeConfigurationException(e.getMessage(), e.getCause()); >> >> You are munging the message of the exception and it's cause. Perhaps it would be better just to pass along the SCE as the cause, that way it is better identified that SL is being used when an error occurs. > > None of the ConfigureError classes in other packages accept Error or Throwable as did DataType (and this one is an Exception!) > So instead of making changes to the ConfigureError classes, I wrapped the ServiceConfigurationError in jaxp configuration errors, and in this case (Datatype), a datatype configuration exception > > It should be very rare to get a ServiceConfigurationError that would indicate a serious error in a jar configuration, basically, a non-usable implementation. So I think we don't have to stick with the ServiceConfigurationError. > If there is an SCE it is hard for the developer to trace. Was SL used or not? How would a developer know? The cast from Throwable to Exception should be avoided, here is the code in SL: public S next() { if (!hasNext()) { throw new NoSuchElementException(); } String cn = nextName; nextName = null; try { S p = service.cast(Class.forName(cn, true, loader) .newInstance()); providers.put(cn, p); return p; } catch (ClassNotFoundException x) { fail(service, "Provider " + cn + " not found"); } catch (Throwable x) { // <--------------- this could be an instance of Error fail(service, "Provider " + cn + " could not be instantiated: " + x, x); } throw new Error(); // This cannot happen } Class.forName and newInstance can throw an instance of LinkageError. I have see such errors from SL due to the incorrect class path settings. >> >> -- >> >> parsers/DocumentBuilderFactory.java >> >> 121 public static DocumentBuilderFactory newInstance() { >> 122 try { >> 123 return (DocumentBuilderFactory) FactoryFinder.find(DocumentBuilderFactory.class, >> 124 /* The default property name according to the JAXP spec */ >> 125 "javax.xml.parsers.DocumentBuilderFactory", >> 126 /* The fallback implementation class name */ >> 127 "com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl"); >> 128 } catch (FactoryConfigurationError e) { >> 129 throw e; >> >> 130 } >> >> You are just re-throwing. > > I did. It's not necessary technically. But since the javadoc for the method defined it, I thought it's good to re-throw it within the method, or repeat it, it's also making sure FactoryFinder indeed throw the error. It's redundant code, declare FactoryConfigurationError in the method signature if you want to declare such intent. > >> -- >> >> SchemaFactoryFinder and XPathFactoryFinder >> >> It seems the error behaviour has changed. AFAICT previously any exceptions would be swallowed and null would be returned. If there is an SCE then an exception will now be propagated. This may be OK though, just not totally sure. > > Yes, it's changed. We discussed this issue before, all but Datatype swallowed any error out of the 3rd step and they all fall back to the default impl in the 4th step. In a recent conversation with Alan, he wanted to see the error caught, and I believe you did too. I didn't think we needed to, but I'm okay both ways since it shall very rarely happen. Even if it does, it should have been fixed by an impl developer long before it's out. > > This is also one of those 'differences' in the api impl that kept troubling us :) > I suspect we should be conservative and try and keep as close to the existing behaviour as possible. > >> >> When using SL you are ignoring the classloader passed into the constructor. I think you may have to pass the classloader as an argument to SL because of the selection: >> >> 201 public static final SchemaFactory newInstance(String schemaLanguage) >> 202 { >> 203 ClassLoader cl; >> 204 cl = ss.getContextClassLoader(); >> 205 >> 206 if (cl == null) { >> 207 //cl = ClassLoader.getSystemClassLoader(); >> 208 //use the current class loader >> 209 cl = SchemaFactory.class.getClassLoader(); >> 210 } >> >> Given some of the weird class loader things app servers do i am guessing SchemaFactory may not always be loaded by the system class loader. > > I did. This is the same order as in the ServiceLoader. So I thought it didn't really make any difference. The only case where a user supplied classloader may be used is when a factory class name is also explicitly specified. > It's not quite the same order because the SchemaFactory class may have been loaded by a custom CL, so you need to do: ServiceLoader.load(SchemaFactory.class, classLoader); Normally that classLoader would be the bootstrap CL (i.e. null) and then you would be correct, but things like app servers do some strange stuff, hence the code "cl = SchemaFactory.class.getClassLoader();" which seems redundant on first glance and i am guessing is there for a good reason. Paul. From weijun.wang at oracle.com Tue Aug 28 09:26:49 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 28 Aug 2012 09:26:49 +0000 Subject: hg: jdk8/tl/jdk: 7194472: FileKeyTab.java test fails on Windows Message-ID: <20120828092759.8619747768@hg.openjdk.java.net> Changeset: fe496675b5e7 Author: weijun Date: 2012-08-28 17:25 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe496675b5e7 7194472: FileKeyTab.java test fails on Windows Reviewed-by: alanb ! test/sun/security/krb5/auto/FileKeyTab.java From jonathan.gibbons at oracle.com Tue Aug 28 09:29:52 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 28 Aug 2012 09:29:52 +0000 Subject: hg: jdk8/tl/jdk: 7194032: update tests for upcoming changes for jtreg Message-ID: <20120828093013.189D447769@hg.openjdk.java.net> Changeset: 06d0478023ca Author: jjg Date: 2012-08-28 10:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06d0478023ca 7194032: update tests for upcoming changes for jtreg Reviewed-by: alanb, iris ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh From jonathan.gibbons at oracle.com Tue Aug 28 09:31:48 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 28 Aug 2012 09:31:48 +0000 Subject: hg: jdk8/tl/jdk: 7194035: update tests for upcoming changes for jtreg Message-ID: <20120828093215.DD29B4776A@hg.openjdk.java.net> Changeset: 997e0d6238b7 Author: jjg Date: 2012-08-28 10:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/997e0d6238b7 7194035: update tests for upcoming changes for jtreg Reviewed-by: alanb, sspitsyn ! test/sun/tools/common/ApplicationSetup.sh ! test/sun/tools/jps/jps-Vvml_2.sh ! test/sun/tools/jps/jps-m_2.sh From Alan.Bateman at oracle.com Tue Aug 28 09:45:05 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Aug 2012 10:45:05 +0100 Subject: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed element In-Reply-To: <503BDD09.80006@oracle.com> References: <503BDD09.80006@oracle.com> Message-ID: <503C9321.2070508@oracle.com> On 27/08/2012 21:48, Dan Xu wrote: > This change is to fix the java doc font issue for > ByteArrayOutputStream class. In current javadoc, contents change to > the wrong font starting from toString(String charsetName) in > ByteArrayOutputStream.html, which can be viewed at > http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html. > The issue is caused by the unclosed tag. > > The webrev is at http://cr.openjdk.java.net/~dxu/7193710/webrev/. This looks fine me as it doesn't seem you can use @code here (Joe or Jon might be able to say what the rules are for nesting these javadoc tags). -Alan From alan.bateman at oracle.com Tue Aug 28 10:13:46 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 28 Aug 2012 10:13:46 +0000 Subject: hg: jdk8/tl/jdk: 6962637: TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system Message-ID: <20120828101423.1DAD94776E@hg.openjdk.java.net> Changeset: c5099c988cce Author: alanb Date: 2012-08-28 11:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5099c988cce 6962637: TEST_BUG: java/io/File/MaxPathLength.java may fail in busy system Reviewed-by: dholmes, alanb Contributed-by: Eric Wang ! test/ProblemList.txt ! test/java/io/File/MaxPathLength.java From sean.mullan at oracle.com Tue Aug 28 12:59:24 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 28 Aug 2012 12:59:24 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120828130004.157DF47772@hg.openjdk.java.net> Changeset: 8b90182f2b33 Author: mullan Date: 2012-08-28 08:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b90182f2b33 7192896: Reason of CertPathValidatorException should be UNDETERMINED_REVOCATION_STATUS if OCSP request failed Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: ca7f914b5fea Author: mullan Date: 2012-08-28 08:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca7f914b5fea Merge From daniel.daugherty at oracle.com Tue Aug 28 16:58:36 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Tue, 28 Aug 2012 16:58:36 +0000 Subject: hg: jdk8/tl/jdk: 7194608: add VerifyLocalVariableTableOnRetransformTest.sh to Problem.list Message-ID: <20120828165911.2FECC4777D@hg.openjdk.java.net> Changeset: bfd5ecb1b4aa Author: dcubed Date: 2012-08-28 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bfd5ecb1b4aa 7194608: add VerifyLocalVariableTableOnRetransformTest.sh to Problem.list Reviewed-by: alanb ! test/ProblemList.txt From dan.xu at oracle.com Tue Aug 28 17:29:46 2012 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 28 Aug 2012 10:29:46 -0700 Subject: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed element In-Reply-To: <503C0DCA.4050004@oracle.com> References: <503BDD09.80006@oracle.com> <503C0DCA.4050004@oracle.com> Message-ID: <503D000A.6010302@oracle.com> Hi David, Thank you for reviewing my changes. I tried using {@code } in my change, but it did not work correctly as the tag will be nested. And it will show "{@code charset}" in the generated java doc instead of "charset". And works fine in the nested situation. I also uploaded the generated ByteArrayOutputStream.htmlto the public java review site at, http://cr.openjdk.java.net/~dxu/7193710/javadoc/java/io/ByteArrayOutputStream.html. Thanks for your notification. -Dan On 08/27/2012 05:16 PM, David Holmes wrote: > Hi Dan, > > On 28/08/2012 6:48 AM, Dan Xu wrote: >> This change is to fix the java doc font issue for ByteArrayOutputStream >> class. In current javadoc, contents change to the wrong font starting >> from toString(String charsetName) in ByteArrayOutputStream.html, which >> can be viewed at >> http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html. >> >> The issue is caused by the unclosed tag. >> >> The webrev is at http://cr.openjdk.java.net/~dxu/7193710/webrev/. > > I think the current trend is to move away from etc and use > {@code}, but your fix is correct and in-style with the rest of the > file. Not sure if this is an opportunity to upgrade the file to using > {@code} ? > >> And I also generated new javadoc basing on my fix, which can be looked >> at >> http://act.us.oracle.com/~danxu/javadoc/java/io/ByteArrayOutputStream.html. >> > > That's not accessible to non-Oracle folk. > > David > >> Thanks! >> >> -Dan From huizhe.wang at oracle.com Tue Aug 28 17:46:23 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 28 Aug 2012 10:46:23 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <1F4403CF-F8AD-4FA9-BBCB-E373B5329A2D@oracle.com> <503C58B1.6080502@oracle.com> Message-ID: <503D03EF.1080804@oracle.com> On 8/28/2012 1:19 AM, Paul Sandoz wrote: > Hi Joe, > > On Aug 28, 2012, at 7:35 AM, Joe Wang wrote: >>> -- >>> >>> datatype/FactoryFinder.java: >>> >>> 244 } catch (ServiceConfigurationError e) { >>> 245 throw new DatatypeConfigurationException(e.getMessage(), e.getCause()); >>> >>> You are munging the message of the exception and it's cause. Perhaps it would be better just to pass along the SCE as the cause, that way it is better identified that SL is being used when an error occurs. >> None of the ConfigureError classes in other packages accept Error or Throwable as did DataType (and this one is an Exception!) >> So instead of making changes to the ConfigureError classes, I wrapped the ServiceConfigurationError in jaxp configuration errors, and in this case (Datatype), a datatype configuration exception >> >> It should be very rare to get a ServiceConfigurationError that would indicate a serious error in a jar configuration, basically, a non-usable implementation. So I think we don't have to stick with the ServiceConfigurationError. >> > If there is an SCE it is hard for the developer to trace. Was SL used or not? How would a developer know? The error message is clear enough - the following for example shows the error with or without the cause. There has been no error being reported back ever since the start of jaxp, as you noticed, it always falls back to the default imp, and we never heard any complaint since implementing jaxp is just not a routing work. Adding the cause, we would have to change the signatures of the FactoryConfigurationError, sth. we've trying to avoid in this patch. javax.xml.parsers.FactoryConfigurationError: javax.xml.parsers.DocumentBuilderFactory: Provider test.factoryfinder2.MyDocumentBuilderFactoryXX not found at javax.xml.parsers.FactoryFinder.findServiceProvider(FactoryFinder.java:300) at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:258) at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:142) at common.Bug7169894Test.testDOMFactory(Bug7169894Test.java:85) Caused by: java.util.ServiceConfigurationError: javax.xml.parsers.DocumentBuilderFactory: Provider test.factoryfinder2.MyDocumentBuilderFactoryXX not found at java.util.ServiceLoader.fail(ServiceLoader.java:214) at java.util.ServiceLoader.access$400(ServiceLoader.java:164) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:350) at java.util.ServiceLoader$1.next(ServiceLoader.java:421) at javax.xml.parsers.FactoryFinder$1.run(FactoryFinder.java:286) at java.security.AccessController.doPrivileged(Native Method) at javax.xml.parsers.FactoryFinder.findServiceProvider(FactoryFinder.java:283) > > The cast from Throwable to Exception should be avoided, here is the code in SL: > > public S next() { > if (!hasNext()) { > throw new NoSuchElementException(); > } > String cn = nextName; > nextName = null; > try { > S p = service.cast(Class.forName(cn, true, loader) > .newInstance()); > providers.put(cn, p); > return p; > } catch (ClassNotFoundException x) { > fail(service, > "Provider " + cn + " not found"); > } catch (Throwable x) { //<--------------- this could be an instance of Error > fail(service, > "Provider " + cn + " could not be instantiated: " + x, > x); > } > throw new Error(); // This cannot happen > } > > Class.forName and newInstance can throw an instance of LinkageError. I have see such errors from SL due to the incorrect class path settings. The error I copied above was the only one I've seen so far. > > >>> -- >>> >>> parsers/DocumentBuilderFactory.java >>> >>> 121 public static DocumentBuilderFactory newInstance() { >>> 122 try { >>> 123 return (DocumentBuilderFactory) FactoryFinder.find(DocumentBuilderFactory.class, >>> 124 /* The default property name according to the JAXP spec */ >>> 125 "javax.xml.parsers.DocumentBuilderFactory", >>> 126 /* The fallback implementation class name */ >>> 127 "com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl"); >>> 128 } catch (FactoryConfigurationError e) { >>> 129 throw e; >>> >>> 130 } >>> >>> You are just re-throwing. >> I did. It's not necessary technically. But since the javadoc for the method defined it, I thought it's good to re-throw it within the method, or repeat it, it's also making sure FactoryFinder indeed throw the error. > It's redundant code, declare FactoryConfigurationError in the method signature if you want to declare such intent. I did that almost automatically. But Alan thinks I'd have hard time when it comes to compatibility review since it's a signature change. > > >>> -- >>> >>> SchemaFactoryFinder and XPathFactoryFinder >>> >>> It seems the error behaviour has changed. AFAICT previously any exceptions would be swallowed and null would be returned. If there is an SCE then an exception will now be propagated. This may be OK though, just not totally sure. >> Yes, it's changed. We discussed this issue before, all but Datatype swallowed any error out of the 3rd step and they all fall back to the default impl in the 4th step. In a recent conversation with Alan, he wanted to see the error caught, and I believe you did too. I didn't think we needed to, but I'm okay both ways since it shall very rarely happen. Even if it does, it should have been fixed by an impl developer long before it's out. >> >> This is also one of those 'differences' in the api impl that kept troubling us :) >> > I suspect we should be conservative and try and keep as close to the existing behaviour as possible. Now we're getting back to my initial patch :-) We've been stuck on this part for quite some time. So when I said 'okay with both ways', I really meant that I'd like to see it done. However we do it, and want it 'correct' as the word really means, no one would ever benefit from it since no one is creating a new jaxp impl. > > >>> When using SL you are ignoring the classloader passed into the constructor. I think you may have to pass the classloader as an argument to SL because of the selection: >>> >>> 201 public static final SchemaFactory newInstance(String schemaLanguage) >>> 202 { >>> 203 ClassLoader cl; >>> 204 cl = ss.getContextClassLoader(); >>> 205 >>> 206 if (cl == null) { >>> 207 //cl = ClassLoader.getSystemClassLoader(); >>> 208 //use the current class loader >>> 209 cl = SchemaFactory.class.getClassLoader(); >>> 210 } >>> >>> Given some of the weird class loader things app servers do i am guessing SchemaFactory may not always be loaded by the system class loader. >> I did. This is the same order as in the ServiceLoader. So I thought it didn't really make any difference. The only case where a user supplied classloader may be used is when a factory class name is also explicitly specified. >> > It's not quite the same order because the SchemaFactory class may have been loaded by a custom CL, so you need to do: > > ServiceLoader.load(SchemaFactory.class, classLoader); > > Normally that classLoader would be the bootstrap CL (i.e. null) and then you would be correct, but things like app servers do some strange stuff, hence the code "cl = SchemaFactory.class.getClassLoader();" which seems redundant on first glance and i am guessing is there for a good reason. Yes, it's possible technically. But it hasn't happened as far as I know. Our AS relies on the JDK, while others, such as WebSphere may bundle Xerces but they don't use our current API impl. If it happens, that SchemaFactory is loaded by a custom CL, it'd result in a convoluted jaxp instances since other parts of jaxp assume bootstrap CL. We had this classloader-related discussion back in June, the class loading was to be delegated to ServiceLoader on your suggestion. So they are all rely on the SerciceLoader now. --Joe > > Paul. From Ulf.Zibis at CoSoCo.de Tue Aug 28 21:20:52 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 28 Aug 2012 23:20:52 +0200 Subject: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed element In-Reply-To: <503C9321.2070508@oracle.com> References: <503BDD09.80006@oracle.com> <503C9321.2070508@oracle.com> Message-ID: <503D3634.90807@CoSoCo.de> Am 28.08.2012 11:45, schrieb Alan Bateman: > On 27/08/2012 21:48, Dan Xu wrote: >> This change is to fix the java doc font issue for ByteArrayOutputStream class. In current >> javadoc, contents change to the wrong font starting from toString(String charsetName) in >> ByteArrayOutputStream.html, which can be viewed at >> http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html. I think the link to the javadoc of a class should not be labelled by a variable name: 212 * Converts the buffer's contents into a string by decoding the bytes using 213 * the specified {@link java.nio.charset.Charset charsetName}. The length of Maybe better: 212 * Converts the buffer's contents into a string by decoding the bytes using 213 * the {@link java.nio.charset.Charset}, specified by it's name. The length of or: 212 * Converts the buffer's contents into a string by decoding the bytes using 213 * the {@link java.nio.charset.Charset}, specified by it's [@code charsetName}. The length of Same for: 222 * @param charsetName the name of a supported 223 * {@link(plain) java.nio.charset.Charset} Additionally you could align the param items: 224 * @return String decoded from the buffer's contents. 225 * @throws UnsupportedEncodingException 226 * If the named charset is not supported 227 * @since JDK1.1 227 * @since JDK1.1 Shouldn't it be? : 227 * @since 1.1 >> The webrev is at http://cr.openjdk.java.net/~dxu/7193710/webrev/. > This looks fine me as it doesn't seem you can use @code here (Joe or Jon might be able to say what > the rules are for nesting these javadoc tags). Interesting question, maybe a bug in javadoc? Maybe {@link ...} instead {@linkplain ...} would work. +1 for taking the opportunity to upgrade the file to using {@code}, {@link}, ... to {@code ...} etc., even if in this special nested case a trick is needed. -Ulf From dan.xu at oracle.com Tue Aug 28 23:39:09 2012 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 28 Aug 2012 16:39:09 -0700 Subject: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed element In-Reply-To: <503D3634.90807@CoSoCo.de> References: <503BDD09.80006@oracle.com> <503C9321.2070508@oracle.com> <503D3634.90807@CoSoCo.de> Message-ID: <503D569D.1040206@oracle.com> Thanks for your comments, Ulf. I looked at the definitions of @link and @linkplain again. And I find that this nested situation can be easily avoided by replacing @linkplain with @link as the following, {@link java.nio.charset.Charset charset} I will update my changes. -Dan On 08/28/2012 02:20 PM, Ulf Zibis wrote: > Am 28.08.2012 11:45, schrieb Alan Bateman: >> On 27/08/2012 21:48, Dan Xu wrote: >>> This change is to fix the java doc font issue for >>> ByteArrayOutputStream class. In current javadoc, contents change to >>> the wrong font starting from toString(String charsetName) in >>> ByteArrayOutputStream.html, which can be viewed at >>> http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html. > I think the link to the javadoc of a class should not be labelled by a > variable name: > 212 * Converts the buffer's contents into a string by decoding > the bytes using > 213 * the specified {@link java.nio.charset.Charset > charsetName}. The length of > Maybe better: > 212 * Converts the buffer's contents into a string by decoding > the bytes using > 213 * the {@link java.nio.charset.Charset}, specified by it's > name. The length of > or: > 212 * Converts the buffer's contents into a string by decoding > the bytes using > 213 * the {@link java.nio.charset.Charset}, specified by it's > [@code charsetName}. The length of > Same for: > 222 * @param charsetName the name of a supported > 223 * {@link(plain) java.nio.charset.Charset} > > Additionally you could align the param items: > 224 * @return String decoded from the buffer's contents. > 225 * @throws UnsupportedEncodingException > 226 * If the named charset is not supported > 227 * @since JDK1.1 > > 227 * @since JDK1.1 > Shouldn't it be? : > 227 * @since 1.1 > >>> The webrev is at http://cr.openjdk.java.net/~dxu/7193710/webrev/. >> This looks fine me as it doesn't seem you can use @code here (Joe or >> Jon might be able to say what the rules are for nesting these javadoc >> tags). > Interesting question, maybe a bug in javadoc? > Maybe {@link ...} instead {@linkplain ...} would work. > > +1 for taking the opportunity to upgrade the file to using {@code}, > {@link}, ... to {@code ...} etc., even if in this special > nested case a trick is needed. > > -Ulf > From Ulf.Zibis at CoSoCo.de Tue Aug 28 23:52:44 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 29 Aug 2012 01:52:44 +0200 Subject: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed element In-Reply-To: <503D569D.1040206@oracle.com> References: <503BDD09.80006@oracle.com> <503C9321.2070508@oracle.com> <503D3634.90807@CoSoCo.de> <503D569D.1040206@oracle.com> Message-ID: <503D59CC.3080104@CoSoCo.de> Thanks for your feedback Dan. But I still think, the link to the javadoc of a class should not be labelled by a variable name. So maybe use: 212 * Converts the buffer's contents into a string by decoding the bytes using 213 * the {@link java.nio.charset.Charset}, specified by it's name. The length of or: 212 * Converts the buffer's contents into a string by decoding the bytes using 213 * the {@link java.nio.charset.Charset}, specified by it's {@code charsetName}. And: 222 * @param charsetName the name of a supported 223 * {@link java.nio.charset.Charset} -Ulf Am 29.08.2012 01:39, schrieb Dan Xu: > Thanks for your comments, Ulf. > > I looked at the definitions of @link and @linkplain again. And I find that this nested situation > can be easily avoided by replacing @linkplain with @link as the following, > > {@link java.nio.charset.Charset charset} > > I will update my changes. > > -Dan > > > > On 08/28/2012 02:20 PM, Ulf Zibis wrote: >> Am 28.08.2012 11:45, schrieb Alan Bateman: >>> On 27/08/2012 21:48, Dan Xu wrote: >>>> This change is to fix the java doc font issue for ByteArrayOutputStream class. In current >>>> javadoc, contents change to the wrong font starting from toString(String charsetName) in >>>> ByteArrayOutputStream.html, which can be viewed at >>>> http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html. >> I think the link to the javadoc of a class should not be labelled by a variable name: >> 212 * Converts the buffer's contents into a string by decoding the bytes using >> 213 * the specified {@link java.nio.charset.Charset charsetName}. The length of >> Maybe better: >> 212 * Converts the buffer's contents into a string by decoding the bytes using >> 213 * the {@link java.nio.charset.Charset}, specified by it's name. The length of >> or: >> 212 * Converts the buffer's contents into a string by decoding the bytes using >> 213 * the {@link java.nio.charset.Charset}, specified by it's [@code charsetName}. The >> length of >> Same for: >> 222 * @param charsetName the name of a supported >> 223 * {@link(plain) java.nio.charset.Charset} >> >> Additionally you could align the param items: >> 224 * @return String decoded from the buffer's contents. >> 225 * @throws UnsupportedEncodingException >> 226 * If the named charset is not supported >> 227 * @since JDK1.1 >> >> 227 * @since JDK1.1 >> Shouldn't it be? : >> 227 * @since 1.1 >> >>>> The webrev is at http://cr.openjdk.java.net/~dxu/7193710/webrev/. >>> This looks fine me as it doesn't seem you can use @code here (Joe or Jon might be able to say >>> what the rules are for nesting these javadoc tags). >> Interesting question, maybe a bug in javadoc? >> Maybe {@link ...} instead {@linkplain ...} would work. >> >> +1 for taking the opportunity to upgrade the file to using {@code}, {@link}, ... to >> {@code ...} etc., even if in this special nested case a trick is needed. >> >> -Ulf >> > > From dan.xu at oracle.com Tue Aug 28 23:57:03 2012 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 28 Aug 2012 16:57:03 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503C03C5.8010907@oracle.com> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> Message-ID: <503D5ACF.3050903@oracle.com> Thanks for all your good suggestions! I have updated my changes, which revoke changes to makefiles and put @SuppressWarnings outside methods instead of introducing local variables for small methods. The webrev is at http://cr.openjdk.java.net/~dxu/7193406/webrev.02/. Thanks! -Dan On 08/27/2012 04:33 PM, Stuart Marks wrote: > On 8/27/12 3:55 AM, Doug Lea wrote: >> The underlying issue is that code size is one of the criteria >> that JITs use to decide to compile/inline etc. So long as they do >> so, there will be cases here and there where it critically >> important to keep sizes small in bottleneck code. Not many, >> but still enough for me to object to efforts that might >> blindly increase code size for the sake of warnings cleanup. > > I'm pleased that warnings cleanup has attracted this much attention. :-) > > I was wondering where rule about @SuppressWarnings and local variables > originally came from, and I tracked this back to Effective Java, Item > 24, which says (as part of a fairly long discussion) > > If you find yourself using the SuppressWarnings annotation > on a method or constructor that's more than one line long, > you may be able to move it onto a local variable declaration. > You may have to declare a new local variable, but it's worth it. > > Aha! So it's all Josh Bloch's fault! :-) > > In the warnings cleanup thus far, and in Dan's webrev, we've followed > this rule fairly strictly. But since we seem to have evidence that > this change isn't worth it, we should consider relaxing the rule for > performance-critical code. How about adding a local variable for > @SuppressWarnings only if the method is, say, longer than ten lines? > (Or some other suitable threshold.) For short methods the annotation > should be placed on the method itself. > > The risk of suppressing other warnings inadvertently is pretty small > in a short method, and short methods are the ones most likely to be > impacted by the addition of a local variable affecting > compilation/inlining decisions. Right? > > (Also, while I've recommended that people follow the local variable > rule fairly strictly, I think it tends to garbage up short methods. So > I wouldn't mind seeing the rule relaxed on readability grounds as well.) > > s'marks From kurchi.subhra.hazra at oracle.com Wed Aug 29 00:08:14 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 28 Aug 2012 17:08:14 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503D5ACF.3050903@oracle.com> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> Message-ID: <503D5D6E.50000@oracle.com> I don't think you need the space before "unchecked" and the one after "rawtypes" in lines 128 and 147 in http://cr.openjdk.java.net/~dxu/7193406/webrev.02/src/share/classes/java/util/PropertyResourceBundle.java.sdiff.html. - Kurchi On 8/28/2012 4:57 PM, Dan Xu wrote: > Thanks for all your good suggestions! > > I have updated my changes, which revoke changes to makefiles and put > @SuppressWarnings outside methods instead of introducing local > variables for small methods. > > The webrev is at http://cr.openjdk.java.net/~dxu/7193406/webrev.02/. > Thanks! > > -Dan > > On 08/27/2012 04:33 PM, Stuart Marks wrote: >> On 8/27/12 3:55 AM, Doug Lea wrote: >>> The underlying issue is that code size is one of the criteria >>> that JITs use to decide to compile/inline etc. So long as they do >>> so, there will be cases here and there where it critically >>> important to keep sizes small in bottleneck code. Not many, >>> but still enough for me to object to efforts that might >>> blindly increase code size for the sake of warnings cleanup. >> >> I'm pleased that warnings cleanup has attracted this much attention. :-) >> >> I was wondering where rule about @SuppressWarnings and local >> variables originally came from, and I tracked this back to Effective >> Java, Item 24, which says (as part of a fairly long discussion) >> >> If you find yourself using the SuppressWarnings annotation >> on a method or constructor that's more than one line long, >> you may be able to move it onto a local variable declaration. >> You may have to declare a new local variable, but it's worth it. >> >> Aha! So it's all Josh Bloch's fault! :-) >> >> In the warnings cleanup thus far, and in Dan's webrev, we've followed >> this rule fairly strictly. But since we seem to have evidence that >> this change isn't worth it, we should consider relaxing the rule for >> performance-critical code. How about adding a local variable for >> @SuppressWarnings only if the method is, say, longer than ten lines? >> (Or some other suitable threshold.) For short methods the annotation >> should be placed on the method itself. >> >> The risk of suppressing other warnings inadvertently is pretty small >> in a short method, and short methods are the ones most likely to be >> impacted by the addition of a local variable affecting >> compilation/inlining decisions. Right? >> >> (Also, while I've recommended that people follow the local variable >> rule fairly strictly, I think it tends to garbage up short methods. >> So I wouldn't mind seeing the rule relaxed on readability grounds as >> well.) >> >> s'marks > -- -Kurchi From dan.xu at oracle.com Wed Aug 29 00:13:45 2012 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 28 Aug 2012 17:13:45 -0700 Subject: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed element In-Reply-To: <503D59CC.3080104@CoSoCo.de> References: <503BDD09.80006@oracle.com> <503C9321.2070508@oracle.com> <503D3634.90807@CoSoCo.de> <503D569D.1040206@oracle.com> <503D59CC.3080104@CoSoCo.de> Message-ID: <503D5EB9.6050507@oracle.com> I will update the change with your suggestion. Thanks! -Dan On 08/28/2012 04:52 PM, Ulf Zibis wrote: > Thanks for your feedback Dan. > > But I still think, the link to the javadoc of a class should not be > labelled by a variable name. > So maybe use: > 212 * Converts the buffer's contents into a string by decoding > the bytes using > 213 * the {@link java.nio.charset.Charset}, specified by it's > name. The length of > or: > 212 * Converts the buffer's contents into a string by decoding > the bytes using > 213 * the {@link java.nio.charset.Charset}, specified by it's > {@code charsetName}. > And: > 222 * @param charsetName the name of a supported > 223 * {@link java.nio.charset.Charset} > > -Ulf > > Am 29.08.2012 01:39, schrieb Dan Xu: >> Thanks for your comments, Ulf. >> >> I looked at the definitions of @link and @linkplain again. And I find >> that this nested situation can be easily avoided by replacing >> @linkplain with @link as the following, >> >> {@link java.nio.charset.Charset charset} >> >> I will update my changes. >> >> -Dan >> >> >> >> On 08/28/2012 02:20 PM, Ulf Zibis wrote: >>> Am 28.08.2012 11:45, schrieb Alan Bateman: >>>> On 27/08/2012 21:48, Dan Xu wrote: >>>>> This change is to fix the java doc font issue for >>>>> ByteArrayOutputStream class. In current javadoc, contents change >>>>> to the wrong font starting from toString(String charsetName) in >>>>> ByteArrayOutputStream.html, which can be viewed at >>>>> http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html. >>> I think the link to the javadoc of a class should not be labelled by >>> a variable name: >>> 212 * Converts the buffer's contents into a string by decoding >>> the bytes using >>> 213 * the specified {@link java.nio.charset.Charset >>> charsetName}. The length of >>> Maybe better: >>> 212 * Converts the buffer's contents into a string by decoding >>> the bytes using >>> 213 * the {@link java.nio.charset.Charset}, specified by it's >>> name. The length of >>> or: >>> 212 * Converts the buffer's contents into a string by decoding >>> the bytes using >>> 213 * the {@link java.nio.charset.Charset}, specified by it's >>> [@code charsetName}. The length of >>> Same for: >>> 222 * @param charsetName the name of a supported >>> 223 * {@link(plain) java.nio.charset.Charset} >>> >>> Additionally you could align the param items: >>> 224 * @return String decoded from the buffer's contents. >>> 225 * @throws UnsupportedEncodingException >>> 226 * If the named charset is not supported >>> 227 * @since JDK1.1 >>> >>> 227 * @since JDK1.1 >>> Shouldn't it be? : >>> 227 * @since 1.1 >>> >>>>> The webrev is at http://cr.openjdk.java.net/~dxu/7193710/webrev/. >>>> This looks fine me as it doesn't seem you can use @code here (Joe >>>> or Jon might be able to say what the rules are for nesting these >>>> javadoc tags). >>> Interesting question, maybe a bug in javadoc? >>> Maybe {@link ...} instead {@linkplain ...} would work. >>> >>> +1 for taking the opportunity to upgrade the file to using {@code}, >>> {@link}, ... to {@code ...} etc., even if in this special >>> nested case a trick is needed. >>> >>> -Ulf >>> >> >> > From dan.xu at oracle.com Wed Aug 29 00:23:33 2012 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 28 Aug 2012 17:23:33 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503D5D6E.50000@oracle.com> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> Message-ID: <503D6105.6000708@oracle.com> I also thought the space was not needed. But when I made the changes, I found that many similar codes had the space when two or more warning types need to be suppressed. For example, java/util/Collections.java, java/util/Arrays.java, java/util/ComparableTimSort.java, and etc. If only one warning type needs to be suppressed, I don't see the space in our codes. Thanks! -Dan On 08/28/2012 05:08 PM, Kurchi Hazra wrote: > I don't think you need the space before "unchecked" and the one after > "rawtypes" in lines 128 and 147 in > http://cr.openjdk.java.net/~dxu/7193406/webrev.02/src/share/classes/java/util/PropertyResourceBundle.java.sdiff.html. > > > - Kurchi > > On 8/28/2012 4:57 PM, Dan Xu wrote: >> Thanks for all your good suggestions! >> >> I have updated my changes, which revoke changes to makefiles and put >> @SuppressWarnings outside methods instead of introducing local >> variables for small methods. >> >> The webrev is at http://cr.openjdk.java.net/~dxu/7193406/webrev.02/. >> Thanks! >> >> -Dan >> >> On 08/27/2012 04:33 PM, Stuart Marks wrote: >>> On 8/27/12 3:55 AM, Doug Lea wrote: >>>> The underlying issue is that code size is one of the criteria >>>> that JITs use to decide to compile/inline etc. So long as they do >>>> so, there will be cases here and there where it critically >>>> important to keep sizes small in bottleneck code. Not many, >>>> but still enough for me to object to efforts that might >>>> blindly increase code size for the sake of warnings cleanup. >>> >>> I'm pleased that warnings cleanup has attracted this much attention. >>> :-) >>> >>> I was wondering where rule about @SuppressWarnings and local >>> variables originally came from, and I tracked this back to Effective >>> Java, Item 24, which says (as part of a fairly long discussion) >>> >>> If you find yourself using the SuppressWarnings annotation >>> on a method or constructor that's more than one line long, >>> you may be able to move it onto a local variable declaration. >>> You may have to declare a new local variable, but it's worth it. >>> >>> Aha! So it's all Josh Bloch's fault! :-) >>> >>> In the warnings cleanup thus far, and in Dan's webrev, we've >>> followed this rule fairly strictly. But since we seem to have >>> evidence that this change isn't worth it, we should consider >>> relaxing the rule for performance-critical code. How about adding a >>> local variable for @SuppressWarnings only if the method is, say, >>> longer than ten lines? (Or some other suitable threshold.) For short >>> methods the annotation should be placed on the method itself. >>> >>> The risk of suppressing other warnings inadvertently is pretty small >>> in a short method, and short methods are the ones most likely to be >>> impacted by the addition of a local variable affecting >>> compilation/inlining decisions. Right? >>> >>> (Also, while I've recommended that people follow the local variable >>> rule fairly strictly, I think it tends to garbage up short methods. >>> So I wouldn't mind seeing the rule relaxed on readability grounds as >>> well.) >>> >>> s'marks >> > From kurchi.subhra.hazra at oracle.com Wed Aug 29 00:32:12 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 28 Aug 2012 17:32:12 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503D6105.6000708@oracle.com> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> <503D6105.6000708@oracle.com> Message-ID: <503D630C.2060601@oracle.com> Irony of the day - those changes were done by me! (http://cr.openjdk.java.net/~khazra/7157893/webrev.02/) :D They were probably a mistake/oversight. I guess the better way is without those extra spaces. See http://docs.oracle.com/javase/tutorial/java/javaOO/annotations.html. If you have time, maybe you can remove those spaces I put in as a part of this CR. Thanks! Kurchi On 8/28/2012 5:23 PM, Dan Xu wrote: > I also thought the space was not needed. But when I made the changes, > I found that many similar codes had the space when two or more warning > types need to be suppressed. For example, java/util/Collections.java, > java/util/Arrays.java, java/util/ComparableTimSort.java, and etc. If > only one warning type needs to be suppressed, I don't see the space in > our codes. Thanks! > > -Dan > > > > On 08/28/2012 05:08 PM, Kurchi Hazra wrote: >> I don't think you need the space before "unchecked" and the one after >> "rawtypes" in lines 128 and 147 in >> http://cr.openjdk.java.net/~dxu/7193406/webrev.02/src/share/classes/java/util/PropertyResourceBundle.java.sdiff.html. >> >> >> - Kurchi >> >> On 8/28/2012 4:57 PM, Dan Xu wrote: >>> Thanks for all your good suggestions! >>> >>> I have updated my changes, which revoke changes to makefiles and put >>> @SuppressWarnings outside methods instead of introducing local >>> variables for small methods. >>> >>> The webrev is at http://cr.openjdk.java.net/~dxu/7193406/webrev.02/. >>> Thanks! >>> >>> -Dan >>> >>> On 08/27/2012 04:33 PM, Stuart Marks wrote: >>>> On 8/27/12 3:55 AM, Doug Lea wrote: >>>>> The underlying issue is that code size is one of the criteria >>>>> that JITs use to decide to compile/inline etc. So long as they do >>>>> so, there will be cases here and there where it critically >>>>> important to keep sizes small in bottleneck code. Not many, >>>>> but still enough for me to object to efforts that might >>>>> blindly increase code size for the sake of warnings cleanup. >>>> >>>> I'm pleased that warnings cleanup has attracted this much >>>> attention. :-) >>>> >>>> I was wondering where rule about @SuppressWarnings and local >>>> variables originally came from, and I tracked this back to >>>> Effective Java, Item 24, which says (as part of a fairly long >>>> discussion) >>>> >>>> If you find yourself using the SuppressWarnings annotation >>>> on a method or constructor that's more than one line long, >>>> you may be able to move it onto a local variable declaration. >>>> You may have to declare a new local variable, but it's worth it. >>>> >>>> Aha! So it's all Josh Bloch's fault! :-) >>>> >>>> In the warnings cleanup thus far, and in Dan's webrev, we've >>>> followed this rule fairly strictly. But since we seem to have >>>> evidence that this change isn't worth it, we should consider >>>> relaxing the rule for performance-critical code. How about adding a >>>> local variable for @SuppressWarnings only if the method is, say, >>>> longer than ten lines? (Or some other suitable threshold.) For >>>> short methods the annotation should be placed on the method itself. >>>> >>>> The risk of suppressing other warnings inadvertently is pretty >>>> small in a short method, and short methods are the ones most likely >>>> to be impacted by the addition of a local variable affecting >>>> compilation/inlining decisions. Right? >>>> >>>> (Also, while I've recommended that people follow the local variable >>>> rule fairly strictly, I think it tends to garbage up short methods. >>>> So I wouldn't mind seeing the rule relaxed on readability grounds >>>> as well.) >>>> >>>> s'marks >>> >> > -- -Kurchi From weijun.wang at oracle.com Wed Aug 29 03:03:41 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 29 Aug 2012 03:03:41 +0000 Subject: hg: jdk8/tl/jdk: 7184815: [macosx] Need to read Kerberos config in files Message-ID: <20120829030404.891B247793@hg.openjdk.java.net> Changeset: c4c69b4d9ace Author: weijun Date: 2012-08-29 11:03 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4c69b4d9ace 7184815: [macosx] Need to read Kerberos config in files Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java From dan.xu at oracle.com Wed Aug 29 05:22:08 2012 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 28 Aug 2012 22:22:08 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503D630C.2060601@oracle.com> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> <503D6105.6000708@oracle.com> <503D630C.2060601@oracle.com> Message-ID: <503DA700.5050207@oracle.com> It is funny. :) I have searched all source codes under jdk and removed spaces for the similar cases. Please review the new version of change at, http://cr.openjdk.java.net/~dxu/7193406/webrev.03/. Thanks for your comment! -Dan On 08/28/2012 05:32 PM, Kurchi Hazra wrote: > Irony of the day - those changes were done by me! > (http://cr.openjdk.java.net/~khazra/7157893/webrev.02/) :D > > They were probably a mistake/oversight. I guess the better way is > without those extra spaces. See > http://docs.oracle.com/javase/tutorial/java/javaOO/annotations.html. > > If you have time, maybe you can remove those spaces I put in as a part > of this CR. > > Thanks! > Kurchi > > On 8/28/2012 5:23 PM, Dan Xu wrote: >> I also thought the space was not needed. But when I made the changes, >> I found that many similar codes had the space when two or more >> warning types need to be suppressed. For example, >> java/util/Collections.java, java/util/Arrays.java, >> java/util/ComparableTimSort.java, and etc. If only one warning type >> needs to be suppressed, I don't see the space in our codes. Thanks! >> >> -Dan >> >> >> >> On 08/28/2012 05:08 PM, Kurchi Hazra wrote: >>> I don't think you need the space before "unchecked" and the one >>> after "rawtypes" in lines 128 and 147 in >>> http://cr.openjdk.java.net/~dxu/7193406/webrev.02/src/share/classes/java/util/PropertyResourceBundle.java.sdiff.html. >>> >>> >>> - Kurchi >>> >>> On 8/28/2012 4:57 PM, Dan Xu wrote: >>>> Thanks for all your good suggestions! >>>> >>>> I have updated my changes, which revoke changes to makefiles and >>>> put @SuppressWarnings outside methods instead of introducing local >>>> variables for small methods. >>>> >>>> The webrev is at >>>> http://cr.openjdk.java.net/~dxu/7193406/webrev.02/. Thanks! >>>> >>>> -Dan >>>> >>>> On 08/27/2012 04:33 PM, Stuart Marks wrote: >>>>> On 8/27/12 3:55 AM, Doug Lea wrote: >>>>>> The underlying issue is that code size is one of the criteria >>>>>> that JITs use to decide to compile/inline etc. So long as they do >>>>>> so, there will be cases here and there where it critically >>>>>> important to keep sizes small in bottleneck code. Not many, >>>>>> but still enough for me to object to efforts that might >>>>>> blindly increase code size for the sake of warnings cleanup. >>>>> >>>>> I'm pleased that warnings cleanup has attracted this much >>>>> attention. :-) >>>>> >>>>> I was wondering where rule about @SuppressWarnings and local >>>>> variables originally came from, and I tracked this back to >>>>> Effective Java, Item 24, which says (as part of a fairly long >>>>> discussion) >>>>> >>>>> If you find yourself using the SuppressWarnings annotation >>>>> on a method or constructor that's more than one line long, >>>>> you may be able to move it onto a local variable declaration. >>>>> You may have to declare a new local variable, but it's worth it. >>>>> >>>>> Aha! So it's all Josh Bloch's fault! :-) >>>>> >>>>> In the warnings cleanup thus far, and in Dan's webrev, we've >>>>> followed this rule fairly strictly. But since we seem to have >>>>> evidence that this change isn't worth it, we should consider >>>>> relaxing the rule for performance-critical code. How about adding >>>>> a local variable for @SuppressWarnings only if the method is, say, >>>>> longer than ten lines? (Or some other suitable threshold.) For >>>>> short methods the annotation should be placed on the method itself. >>>>> >>>>> The risk of suppressing other warnings inadvertently is pretty >>>>> small in a short method, and short methods are the ones most >>>>> likely to be impacted by the addition of a local variable >>>>> affecting compilation/inlining decisions. Right? >>>>> >>>>> (Also, while I've recommended that people follow the local >>>>> variable rule fairly strictly, I think it tends to garbage up >>>>> short methods. So I wouldn't mind seeing the rule relaxed on >>>>> readability grounds as well.) >>>>> >>>>> s'marks >>>> >>> >> > > -- > -Kurchi From dan.xu at oracle.com Wed Aug 29 05:29:12 2012 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 28 Aug 2012 22:29:12 -0700 Subject: Review Request: 7193683: Cleanup Warning in java.sql package Message-ID: <503DA8A8.2060701@oracle.com> I made a simple fix to clean up build warnings in java.sql package. The change can be reviewed at http://cr.openjdk.java.net/~dxu/7193683/webrev.01/. Thanks! -Dan From kurchi.subhra.hazra at oracle.com Wed Aug 29 06:33:50 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra) Date: Tue, 28 Aug 2012 23:33:50 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503DA700.5050207@oracle.com> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> <503D6105.6000708@oracle.com> <503D630C.2060601@oracle.com> <503DA700.5050207@oracle.com> Message-ID: <503DB7CE.9060001@oracle.com> Thanks for cleaning up those spaces Dan. The changes look fine. Sorry for the extra trouble! - Kurchi On 8/28/12 10:22 PM, Dan Xu wrote: > It is funny. :) I have searched all source codes under jdk and removed > spaces for the similar cases. > > Please review the new version of change at, > http://cr.openjdk.java.net/~dxu/7193406/webrev.03/. > > Thanks for your comment! > > -Dan > > > On 08/28/2012 05:32 PM, Kurchi Hazra wrote: >> Irony of the day - those changes were done by me! >> (http://cr.openjdk.java.net/~khazra/7157893/webrev.02/) :D >> >> They were probably a mistake/oversight. I guess the better way is >> without those extra spaces. See >> http://docs.oracle.com/javase/tutorial/java/javaOO/annotations.html. >> >> If you have time, maybe you can remove those spaces I put in as a >> part of this CR. >> >> Thanks! >> Kurchi >> >> On 8/28/2012 5:23 PM, Dan Xu wrote: >>> I also thought the space was not needed. But when I made the >>> changes, I found that many similar codes had the space when two or >>> more warning types need to be suppressed. For example, >>> java/util/Collections.java, java/util/Arrays.java, >>> java/util/ComparableTimSort.java, and etc. If only one warning type >>> needs to be suppressed, I don't see the space in our codes. Thanks! >>> >>> -Dan >>> >>> >>> >>> On 08/28/2012 05:08 PM, Kurchi Hazra wrote: >>>> I don't think you need the space before "unchecked" and the one >>>> after "rawtypes" in lines 128 and 147 in >>>> http://cr.openjdk.java.net/~dxu/7193406/webrev.02/src/share/classes/java/util/PropertyResourceBundle.java.sdiff.html. >>>> >>>> >>>> - Kurchi >>>> >>>> On 8/28/2012 4:57 PM, Dan Xu wrote: >>>>> Thanks for all your good suggestions! >>>>> >>>>> I have updated my changes, which revoke changes to makefiles and >>>>> put @SuppressWarnings outside methods instead of introducing local >>>>> variables for small methods. >>>>> >>>>> The webrev is at >>>>> http://cr.openjdk.java.net/~dxu/7193406/webrev.02/. Thanks! >>>>> >>>>> -Dan >>>>> >>>>> On 08/27/2012 04:33 PM, Stuart Marks wrote: >>>>>> On 8/27/12 3:55 AM, Doug Lea wrote: >>>>>>> The underlying issue is that code size is one of the criteria >>>>>>> that JITs use to decide to compile/inline etc. So long as they do >>>>>>> so, there will be cases here and there where it critically >>>>>>> important to keep sizes small in bottleneck code. Not many, >>>>>>> but still enough for me to object to efforts that might >>>>>>> blindly increase code size for the sake of warnings cleanup. >>>>>> >>>>>> I'm pleased that warnings cleanup has attracted this much >>>>>> attention. :-) >>>>>> >>>>>> I was wondering where rule about @SuppressWarnings and local >>>>>> variables originally came from, and I tracked this back to >>>>>> Effective Java, Item 24, which says (as part of a fairly long >>>>>> discussion) >>>>>> >>>>>> If you find yourself using the SuppressWarnings annotation >>>>>> on a method or constructor that's more than one line long, >>>>>> you may be able to move it onto a local variable declaration. >>>>>> You may have to declare a new local variable, but it's worth it. >>>>>> >>>>>> Aha! So it's all Josh Bloch's fault! :-) >>>>>> >>>>>> In the warnings cleanup thus far, and in Dan's webrev, we've >>>>>> followed this rule fairly strictly. But since we seem to have >>>>>> evidence that this change isn't worth it, we should consider >>>>>> relaxing the rule for performance-critical code. How about adding >>>>>> a local variable for @SuppressWarnings only if the method is, >>>>>> say, longer than ten lines? (Or some other suitable threshold.) >>>>>> For short methods the annotation should be placed on the method >>>>>> itself. >>>>>> >>>>>> The risk of suppressing other warnings inadvertently is pretty >>>>>> small in a short method, and short methods are the ones most >>>>>> likely to be impacted by the addition of a local variable >>>>>> affecting compilation/inlining decisions. Right? >>>>>> >>>>>> (Also, while I've recommended that people follow the local >>>>>> variable rule fairly strictly, I think it tends to garbage up >>>>>> short methods. So I wouldn't mind seeing the rule relaxed on >>>>>> readability grounds as well.) >>>>>> >>>>>> s'marks >>>>> >>>> >>> >> >> -- >> -Kurchi > From edvard.wendelin at oracle.com Wed Aug 29 07:54:15 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Wed, 29 Aug 2012 09:54:15 +0200 Subject: [7u8] Request for approval: 7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node In-Reply-To: <503C0F54.2080308@oracle.com> References: <503BBEC0.20105@oracle.com> <503C0F54.2080308@oracle.com> Message-ID: <503DCAA7.5060805@oracle.com> Sorry for the delay. Approved. Cheers, Edvard Ps. Please start new threads instead of replying to an old approval request. On 08/28/2012 02:22 AM, Kurchi Hazra wrote: > > This is a request for approval to backport the fix for 7160252 from 8 > to 7u8. > > Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160252 > Webrev:http://cr.openjdk.java.net/~khazra/7160252/7u8/webrev.00/ > > This had been reviewed by Alan Bateman and Chris Hegarty. [1] > > This fix has been pushed into jdk8 [2]. > > Thanks, > Kurchi > > [1]http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-July/010823.html > > [2]http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9461aeff91f > > From forax at univ-mlv.fr Wed Aug 29 08:48:50 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Wed, 29 Aug 2012 10:48:50 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503DB7CE.9060001@oracle.com> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> <503D6105.6000708@oracle.com> <503D630C.2060601@oracle.com> <503DA700.5050207@oracle.com> <503DB7CE.9060001@oracle.com> Message-ID: <503DD772.6010201@univ-mlv.fr> On 08/29/2012 08:33 AM, Kurchi Subhra Hazra wrote: > Thanks for cleaning up those spaces Dan. The changes look fine. > Sorry for the extra trouble! > > - Kurchi > > On 8/28/12 10:22 PM, Dan Xu wrote: >> It is funny. :) I have searched all source codes under jdk and >> removed spaces for the similar cases. >> >> Please review the new version of change at, >> http://cr.openjdk.java.net/~dxu/7193406/webrev.03/. >> >> Thanks for your comment! >> >> -Dan Hi Dan, In PreHashedMap, the code should be Map.Entry that = (Map.Entry)ob; so the @SuppressWarnings is not needed anymore. And in java.util.Arrays, asList() should not be annotated with @SuppressWarnings because it is already annotated with SafeVarargs, so the compiler should not report the varargs warning. I have CC to compiler-dev to be sure that this is a compiler error. cheers, R?mi From paul.sandoz at oracle.com Wed Aug 29 08:56:15 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 Aug 2012 10:56:15 +0200 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <503D03EF.1080804@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <1F4403CF-F8AD-4FA9-BBCB-E373B5329A2D@oracle.com> <503C58B1.6080502@oracle.com> <503D03EF.1080804@oracle.com> Message-ID: Hi Joe, I would urge you to reconsider errors using SL, since SL is being explicitly called out as part of the specification. You can make any such SL-related errors more meaningful (yes, i want the stack trace telling what bits of SL code were called!) and remove any potential for CCEs, due to linkage errors [*], by passing the SCE instance to the constructor of DatatypeConfigurationException or the FactoryConfigurationError variants e.g. 244 } catch (ServiceConfigurationError e) { 245 throw new DatatypeConfigurationException(""Provider " + className + " could not be loaded or instantiated using java.util.ServiceLoader", e); -- For the SchemaFactoryFinder there is now a potentially subtle difference in what CL is used to load a class by SL and by SchemaFactoryFinder.createInstance. Previously the same CL was always used whatever the mechanism was used to identify the class name. Errors related to class loaders can be extremely hard to track down hence the conservative position. -- I will say no more on the above :-) Paul. [*] If a developer can declare a service provider then such linkage errors can potentially occur. On Aug 28, 2012, at 7:46 PM, Joe Wang wrote: > > > On 8/28/2012 1:19 AM, Paul Sandoz wrote: >> >> Hi Joe, >> >> On Aug 28, 2012, at 7:35 AM, Joe Wang wrote: >>>> -- >>>> >>>> datatype/FactoryFinder.java: >>>> >>>> 244 } catch (ServiceConfigurationError e) { >>>> 245 throw new DatatypeConfigurationException(e.getMessage(), e.getCause()); >>>> >>>> You are munging the message of the exception and it's cause. Perhaps it would be better just to pass along the SCE as the cause, that way it is better identified that SL is being used when an error occurs. >>> None of the ConfigureError classes in other packages accept Error or Throwable as did DataType (and this one is an Exception!) >>> So instead of making changes to the ConfigureError classes, I wrapped the ServiceConfigurationError in jaxp configuration errors, and in this case (Datatype), a datatype configuration exception >>> >>> It should be very rare to get a ServiceConfigurationError that would indicate a serious error in a jar configuration, basically, a non-usable implementation. So I think we don't have to stick with the ServiceConfigurationError. >>> >> If there is an SCE it is hard for the developer to trace. Was SL used or not? How would a developer know? > > The error message is clear enough - the following for example shows the error with or without the cause. There has been no error being reported back ever since the start of jaxp, as you noticed, it always falls back to the default imp, and we never heard any complaint since implementing jaxp is just not a routing work. Adding the cause, we would have to change the signatures of the FactoryConfigurationError, sth. we've trying to avoid in this patch. > > javax.xml.parsers.FactoryConfigurationError: javax.xml.parsers.DocumentBuilderFactory: Provider test.factoryfinder2.MyDocumentBuilderFactoryXX not found > at javax.xml.parsers.FactoryFinder.findServiceProvider(FactoryFinder.java:300) > at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:258) > at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:142) > at common.Bug7169894Test.testDOMFactory(Bug7169894Test.java:85) > > Caused by: java.util.ServiceConfigurationError: javax.xml.parsers.DocumentBuilderFactory: Provider test.factoryfinder2.MyDocumentBuilderFactoryXX not found > at java.util.ServiceLoader.fail(ServiceLoader.java:214) > at java.util.ServiceLoader.access$400(ServiceLoader.java:164) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:350) > at java.util.ServiceLoader$1.next(ServiceLoader.java:421) > at javax.xml.parsers.FactoryFinder$1.run(FactoryFinder.java:286) > at java.security.AccessController.doPrivileged(Native Method) > at javax.xml.parsers.FactoryFinder.findServiceProvider(FactoryFinder.java:283) > > >> >> The cast from Throwable to Exception should be avoided, here is the code in SL: >> >> public S next() { >> if (!hasNext()) { >> throw new NoSuchElementException(); >> } >> String cn = nextName; >> nextName = null; >> try { >> S p = service.cast(Class.forName(cn, true, loader) >> .newInstance()); >> providers.put(cn, p); >> return p; >> } catch (ClassNotFoundException x) { >> fail(service, >> "Provider " + cn + " not found"); >> } catch (Throwable x) { // <--------------- this could be an instance of Error >> fail(service, >> "Provider " + cn + " could not be instantiated: " + x, >> x); >> } >> throw new Error(); // This cannot happen >> } >> >> Class.forName and newInstance can throw an instance of LinkageError. I have see such errors from SL due to the incorrect class path settings. > > The error I copied above was the only one I've seen so far. >> >> >>>> -- >>>> >>>> parsers/DocumentBuilderFactory.java >>>> >>>> 121 public static DocumentBuilderFactory newInstance() { >>>> 122 try { >>>> 123 return (DocumentBuilderFactory) FactoryFinder.find(DocumentBuilderFactory.class, >>>> 124 /* The default property name according to the JAXP spec */ >>>> 125 "javax.xml.parsers.DocumentBuilderFactory", >>>> 126 /* The fallback implementation class name */ >>>> 127 "com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl"); >>>> 128 } catch (FactoryConfigurationError e) { >>>> 129 throw e; >>>> >>>> 130 } >>>> >>>> You are just re-throwing. >>> I did. It's not necessary technically. But since the javadoc for the method defined it, I thought it's good to re-throw it within the method, or repeat it, it's also making sure FactoryFinder indeed throw the error. >> It's redundant code, declare FactoryConfigurationError in the method signature if you want to declare such intent. > > I did that almost automatically. But Alan thinks I'd have hard time when it comes to compatibility review since it's a signature change. >> >> >>>> -- >>>> >>>> SchemaFactoryFinder and XPathFactoryFinder >>>> >>>> It seems the error behaviour has changed. AFAICT previously any exceptions would be swallowed and null would be returned. If there is an SCE then an exception will now be propagated. This may be OK though, just not totally sure. >>> Yes, it's changed. We discussed this issue before, all but Datatype swallowed any error out of the 3rd step and they all fall back to the default impl in the 4th step. In a recent conversation with Alan, he wanted to see the error caught, and I believe you did too. I didn't think we needed to, but I'm okay both ways since it shall very rarely happen. Even if it does, it should have been fixed by an impl developer long before it's out. >>> >>> This is also one of those 'differences' in the api impl that kept troubling us :) >>> >> I suspect we should be conservative and try and keep as close to the existing behaviour as possible. > > Now we're getting back to my initial patch :-) We've been stuck on this part for quite some time. So when I said 'okay with both ways', I really meant that I'd like to see it done. However we do it, and want it 'correct' as the word really means, no one would ever benefit from it since no one is creating a new jaxp impl. > >> >> >>>> When using SL you are ignoring the classloader passed into the constructor. I think you may have to pass the classloader as an argument to SL because of the selection: >>>> >>>> 201 public static final SchemaFactory newInstance(String schemaLanguage) >>>> 202 { >>>> 203 ClassLoader cl; >>>> 204 cl = ss.getContextClassLoader(); >>>> 205 >>>> 206 if (cl == null) { >>>> 207 //cl = ClassLoader.getSystemClassLoader(); >>>> 208 //use the current class loader >>>> 209 cl = SchemaFactory.class.getClassLoader(); >>>> 210 } >>>> >>>> Given some of the weird class loader things app servers do i am guessing SchemaFactory may not always be loaded by the system class loader. >>> I did. This is the same order as in the ServiceLoader. So I thought it didn't really make any difference. The only case where a user supplied classloader may be used is when a factory class name is also explicitly specified. >>> >> It's not quite the same order because the SchemaFactory class may have been loaded by a custom CL, so you need to do: >> >> ServiceLoader.load(SchemaFactory.class, classLoader); >> >> Normally that classLoader would be the bootstrap CL (i.e. null) and then you would be correct, but things like app servers do some strange stuff, hence the code "cl = SchemaFactory.class.getClassLoader();" which seems redundant on first glance and i am guessing is there for a good reason. > > Yes, it's possible technically. But it hasn't happened as far as I know. Our AS relies on the JDK, while others, such as WebSphere may bundle Xerces but they don't use our current API impl. > > If it happens, that SchemaFactory is loaded by a custom CL, it'd result in a convoluted jaxp instances since other parts of jaxp assume bootstrap CL. We had this classloader-related discussion back in June, the class loading was to be delegated to ServiceLoader on your suggestion. So they are all rely on the SerciceLoader now. > > --Joe > >> >> Paul. From Ulf.Zibis at CoSoCo.de Wed Aug 29 09:28:38 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 29 Aug 2012 11:28:38 +0200 Subject: Review Request: 7193683: Cleanup Warning in java.sql package In-Reply-To: <503DA8A8.2060701@oracle.com> References: <503DA8A8.2060701@oracle.com> Message-ID: <503DE0C6.90204@CoSoCo.de> Looks good! While you are there maybe correct indentations and tab -> spaces, e.g.: 531 } catch(Throwable t) { 532 // Do nothing 533 } But here maybe better: 531 } catch(Throwable t) {} // Do nothing -Ulf Am 29.08.2012 07:29, schrieb Dan Xu: > I made a simple fix to clean up build warnings in java.sql package. The change can be reviewed at > http://cr.openjdk.java.net/~dxu/7193683/webrev.01/. Thanks! > > -Dan > From ipremraj11 at gmail.com Wed Aug 29 10:15:05 2012 From: ipremraj11 at gmail.com (Premraj) Date: Wed, 29 Aug 2012 15:45:05 +0530 Subject: Difference between Files#delete(Path) and File#delete() Message-ID: Hi all, I'm not sure whether this is the right place for this question but if in case its not please direct me to the correct forum. I was trying to shift from old file API to NIO API (using JDK 7 update 6) but I found that on Windows (I have Windows 7) platform if I have read only file then File#delete() call will delete the file while Files#delete(Path) fails with exception (java.nio.file.AccessDeniedException), I'm not sure whether this is known issue but since Files#delete(Path) offers better error handling I would like to use Files#delete(Path). My question is - Is there any workaround for this problem in NIO API or should I stick to old File API because of this. Also I was curios why Files#delete(Path) throws exception but File#delete() executes successfully. PS: I asked this question[1] on stackoverflow but did not get any good response. 1. http://stackoverflow.com/questions/12139482/difference-between-filesdeletepath-and-filedelete/ -- Premraj From Alan.Bateman at oracle.com Wed Aug 29 10:27:35 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 Aug 2012 11:27:35 +0100 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <503C4FA2.5050001@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <503B73DA.4060807@oracle.com> <503C4FA2.5050001@oracle.com> Message-ID: <503DEE97.7020000@oracle.com> On 28/08/2012 05:57, Joe Wang wrote: > : > >> >> In DocumentBuilderFactory and SAXParserFactory the javadoc reads " >> Otherwise the default implementation is returned if it is on the >> classpath or installed as a module". I think this statement needs to >> be re-worked, first to remove the word "module" as it is not defined >> here, and also because I don't think it's the classpath. If I read >> the code correctly then initiating loader may actually be the context >> class loader and assuming the usual delegation then the default >> should be loaded by the boot class loader. It may be possible to >> borrow some of the wording from the ServiceLoader javadoc to help here. > > It seems we need to go over this again since it was intended for > jdk8/jigsaw. Without modules, we don't really need to put other > implementations over the default. How about change it to the following: > > * Uses the service-provider loading facilities, defined by the > {@link java.util.ServiceLoader} class, to attempt > * to locate and load an implementation of the service. If there > are multiple providers, the first one returned > * by the {@link java.util.ServiceLoader} will be instantiated > and returned. > * > * If a misconfigured provider is encountered and {@link > java.util.ServiceConfigurationError} is thrown, the error will be wrapped > * in a {@link javax.xml.parsers.FactoryConfigurationException}.

I think it should allow for the possibility that the default factory is itself installed as a service provider. To that end, I think the original proposed working was in the right direction, it's just that it used terms "classpath" and "modules" too loosely and didn't define what the initiating loader was. Here is some suggested wording to chew on: "Installed providers are loaded using the service-provider loading facility defined by the {@link ServiceLoader} class. Providers are loaded using the current thread's context class loader. If the context class loader is {@code null} then the system class loader if used. The first service provider to be instantiated that is not the default provider is returned. If the only service provider to be located is the default provider then it is instantiated and returned. If a {@link ServiceConfigurationError} is encountered when locating or iterating over the providers then this causes {@link FactoryConfigurationException} to be thrown, with the {@code ServiceConfigurationError} as its cause." > > : > >> >> In src/javax/xml/datatype/FactoryFinder.java then is there any reason >> why this class has to use Object? I realize that some of the factory >> finders are called for several types but there are few (like this >> one) where there is only one type involved. > > No, it doesn't. FactoryFinder for datatype and transform can be > dedicated. It was believed that it and SecuritySupport should be > copied for each package, I think we touched this before. I left it > alone, or otherwise we'd need to change all other methods in the class > and also the transformer factory finder, for not much performance gain. Okay, but I do think this needs clean-up at some point. > >> >> DocumentBuilderFactory.java it has: >> catch (FactoryConfigurationError e) { throw e; } >> I assume the catch is not needed, same thing in a few other places. > > It's not. But since the javadoc for the method defined throws, I > thought it's good to re-throw it within the method rather than going > into the finder class to know that the Error will be thrown. I see Paul's has picked up on this in his comments too. > > : > >> >> I think one thing that would be really useful here is to get a >> summary of the behavioral and API changes that this changes brings. >> SchemeFactory now throws FactoryConfigurationError whereas previously >> errors were ignored. It would be good to summarize the others. > > Yes, I think we'll do that in the MR. There isn't a general place in > the Javadoc for us to do that. I understand, I'm just saying think the list would be useful for the review here too. I suggest this because there are subtle differences between the datatype finder and the other finders, also the SchemaFactory is being changed to throw an error that it previously didn't define, etc. You'll need this for for JCP MR too but for now I think it is important for the reviewers here to have the summary so that we know what we are reviewing. -Alan From Alan.Bateman at oracle.com Wed Aug 29 10:42:14 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 Aug 2012 11:42:14 +0100 Subject: Difference between Files#delete(Path) and File#delete() In-Reply-To: References: Message-ID: <503DF206.60104@oracle.com> On 29/08/2012 11:15, Premraj wrote: > > I was trying to shift from old file API to NIO API (using JDK 7 update 6) > but I found that on Windows (I have Windows 7) platform if I have read only > file then File#delete() call will delete the file while Files#delete(Path) > fails with exception (java.nio.file.AccessDeniedException), I'm not sure > whether this is known issue but since Files#delete(Path) offers better > error handling I would like to use Files#delete(Path). > > My question is - Is there any workaround for this problem in NIO API or > should I stick to old File API because of this. Also I was curios why > Files#delete(Path) throws exception but File#delete() executes successfully. > I would expect that if you try to delete the file in Explorer or in a command window that you also get an "Access denied" error. The issue is that java.io.File has many oddities, on Windows in particular. In this case it resets the file attributes before it deletes the file so this is why it does not fail as might be expected. It is behavior that dates back >10 years and so would be risky to change now. It has several other oddities like this, just one of the reason why it wasn't re-implemented to use the new API. -Alan. From Ulf.Zibis at CoSoCo.de Wed Aug 29 10:50:02 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 29 Aug 2012 12:50:02 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <1752716260.10040789.1345767163342.JavaMail.root@redhat.com> References: <1752716260.10040789.1345767163342.JavaMail.root@redhat.com> Message-ID: <503DF3DA.1040106@CoSoCo.de> Am 24.08.2012 02:12, schrieb Andrew Hughes: >> In FilePermission.java file, I make one change to its method >> signature, >> >> public Enumeration elements() ==> public Enumeration >> elements() >> >> >> I am not sure whether it will cause an issue of backward >> compatibility. >> Please advise. Thanks! Actually the whole method is synchronized. To make this more clear, I suggest: 798 public synchronized Enumeration elements() { 799 // Convert Iterator into Enumeration 800 return Collections.enumeration(perms); 801 } > It's in a package-private class so I doubt it. > > Even if it wasn't, a new major release is the perfect time to fix these issues. If this class is package-private, why the constructor is public? (please also check all other methods, especially if not inherited) Please check indentations and tabs -> spaces, while you are here. E.g. following lines should be: 713 final class FilePermissionCollection extends PermissionCollection 714 implements Serializable { 732 * @param permission the Permission object to add. 733 * 734 * @throws IllegalArgumentException - if the permission is not a 743 if (! (permission instanceof FilePermission)) 744 throw new IllegalArgumentException( 745 "invalid permission: "+permission); 746 if (isReadOnly()) 747 throw new SecurityException( 748 "attempt to add a Permission to a readonly PermissionCollection"); 767 if (! (permission instanceof FilePermission)) 768 return false; Lines 822..825 look ugly. Better: 819 /** 820 * @serialData "permissions" field (a Vector containing the FilePermissions). 821 */ 822 /* 823 Writes the contents of the perms field out as a Vector for 824 serialization compatibility with earlier releases. 825 */ or: 819 /** 820 * @serialData "permissions" field (a Vector containing the FilePermissions). 821 */ 822 // Writes the contents of the perms field out as a Vector for 823 // serialization compatibility with earlier releases. I only took a short look on class FilePermission.java, but not the others of this CR for now. -Ulf From Ulf.Zibis at CoSoCo.de Wed Aug 29 11:36:03 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 29 Aug 2012 13:36:03 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <5037D0D8.3030307@oracle.com> References: <5036A4C4.5040709@oracle.com> <5036DEA5.1020100@oracle.com> <5037D0D8.3030307@oracle.com> Message-ID: <503DFEA3.70900@CoSoCo.de> Am 24.08.2012 21:07, schrieb Dan Xu: > On 08/23/2012 06:53 PM, David Holmes wrote: >> I'm surprised that you need this: >> >> 426 @SuppressWarnings("fallthrough") >> ... >> 436 switch (actions) { >> 437 case SecurityConstants.FILE_READ_ACTION: >> 438 return READ; Oops, you have reverted the change to use switch-on-Strings by webrev.03. Why? >> >> If this generates a fallthrough warning then I think whatever tool generates that warning needs >> fixing! > > @SuppressWarnings("fallthrough") is put to suppress warnings generated by another switch/case > statements Can't you move it from method scope to there? > > while (i >= matchlen && !seencomma) { > switch(a[i-matchlen]) { > case ',': > seencomma = true; > /*FALLTHROUGH*/ > case ' ': case '\r': case '\n': > case '\f': case '\t': > break; > default: > throw new IllegalArgumentException( > "invalid permission: " + actions); > } > i--; > } -Ulf From Ulf.Zibis at CoSoCo.de Wed Aug 29 11:59:24 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Wed, 29 Aug 2012 13:59:24 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503DA700.5050207@oracle.com> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> <503D6105.6000708@oracle.com> <503D630C.2060601@oracle.com> <503DA700.5050207@oracle.com> Message-ID: <503E041C.7020303@CoSoCo.de> Am 29.08.2012 07:22, schrieb Dan Xu: > It is funny. :) I have searched all source codes under jdk and removed spaces for the similar cases. > > Please review the new version of change at, http://cr.openjdk.java.net/~dxu/7193406/webrev.03/. > > Thanks for your comment! In class j.u.Collections you have added some @Override annotations. Why don't you add them in all appropriate cases and in all classes of your CR? As they are not very frequent in the JDK, I think we should leave it as it is or write a script, which patches the whole JDK in one chunk. -Ulf From joe.darcy at oracle.com Wed Aug 29 15:27:21 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 29 Aug 2012 08:27:21 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503DD772.6010201@univ-mlv.fr> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> <503D6105.6000708@oracle.com> <503D630C.2060601@oracle.com> <503DA700.5050207@oracle.com> <503DB7CE.9060001@oracle.com> <503DD772.6010201@univ-mlv.fr> Message-ID: <503E34D9.4060309@oracle.com> Hello, On 8/29/2012 1:48 AM, R?mi Forax wrote: > On 08/29/2012 08:33 AM, Kurchi Subhra Hazra wrote: >> Thanks for cleaning up those spaces Dan. The changes look fine. >> Sorry for the extra trouble! >> >> - Kurchi >> >> On 8/28/12 10:22 PM, Dan Xu wrote: >>> It is funny. :) I have searched all source codes under jdk and >>> removed spaces for the similar cases. >>> >>> Please review the new version of change at, >>> http://cr.openjdk.java.net/~dxu/7193406/webrev.03/. >>> >>> Thanks for your comment! >>> >>> -Dan > > Hi Dan, > > In PreHashedMap, the code should be > > Map.Entry that = (Map.Entry)ob; > > so the @SuppressWarnings is not needed anymore. > > And in java.util.Arrays, asList() should not be annotated with > @SuppressWarnings because it is already annotated with SafeVarargs, so > the compiler should not report the varargs warning. > > I have CC to compiler-dev to be sure that this is a compiler error. > > cheers, > R?mi > I've spoken to Stuart about this last point. The @SafeVarargs covers uses of Array.asList and covers the declaration of the asList method itself. However, it does not cover calls to the constructor inside the asList method, a constructor which itself is *not* @SafeVarargs. Solutions include * @SuppressWarnings("varargs") on the asList method * @SuppressWarnings("varargs") on new temporary variable for that purpose (with possible class file size consequences) * @SafeVarargs on the ArrayList constructor Regards, -Joe From ahughes at redhat.com Wed Aug 29 15:48:18 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 29 Aug 2012 11:48:18 -0400 (EDT) Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <5037EAF6.5050907@oracle.com> Message-ID: <1678589493.12653541.1346255298109.JavaMail.root@redhat.com> ----- Original Message ----- > On 8/24/12 2:42 AM, Andrew Hughes wrote: > > However, once the whole build is warning free, would it not be > > preferable > > to remove these and just set JAVAC_WARNINGS_FATAL=true when doing > > development > > builds? > > > > The problem I see is someone new coming to OpenJDK and not being > > able to > > simply build it (with no changes) because a new warnings has > > appeared > > and is being treated as an error. This is less of a problem with > > javac > > as we control its development, and the JDK will use the javac built > > in the > > langtools step in most cases. But, generally, -Werror is something > > you > > should choose to enable, with the intention of fixing failures, not > > something > > that should be forced on everyone building the code. > > Our experience is that when -Werror is off by default, warnings tend > to be > introduced inadvertently. In the time we've been working on warnings > cleanup, > I've noticed the warnings count creeping up in areas of the build > that don't > have -Werror enabled. If it weren't for the implicit compilation > issue, > enabling -Werror incrementally as areas of the build are cleared > would have > been a good way to ensure that we make steady progress without any > backsliding. > But presumably these would be removed when everything is warning free? -Werror should not be the default for everyone building OpenJDK, who then end up having to fix or workaround issues which are nothing to do with them. It's easy enough for those who want to check we don't regress to turn on -Werror throughout, once everything is warning free. > > On a related topic, it would be nice if javadoc could also support > > -Werror > > as I constantly see warnings reappearing in the documentation. > > Yes, javadoc warnings are another *huge* problem. > Yes, I see much more regression on this than code warnings (though I guess this is because most are hidden by javac's defaults). > >> SUBDIRS_MAKEFLAGS += JAVAC_WARNINGS_FATAL=true > >> > >> and this is **not** overridable on the command line. That's wrong. > >> If > >> these are > >> causing problems for you, please do submit patches. > > > > Yes, that's what we have in java/tools and is why > > JAVAC_WARNINGS_FATAL=false > > doesn't completely remove -Werror at present. I'll post a webrev > > of the change > > I have for this. > > Great, looking forward to this. > > s'marks > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From paul.sandoz at oracle.com Wed Aug 29 15:56:17 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 29 Aug 2012 17:56:17 +0200 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <1F4403CF-F8AD-4FA9-BBCB-E373B5329A2D@oracle.com> <503C58B1.6080502@oracle.com> <503D03EF.1080804@oracle.com> Message-ID: On Aug 29, 2012, at 10:56 AM, Paul Sandoz wrote: > Hi Joe, > > I would urge you to reconsider errors using SL, since SL is being explicitly called out as part of the specification. > > You can make any such SL-related errors more meaningful (yes, i want the stack trace telling what bits of SL code were called!) and remove any potential for CCEs, due to linkage errors [*], by passing the SCE instance to the constructor of DatatypeConfigurationException or the FactoryConfigurationError variants e.g. > > 244 } catch (ServiceConfigurationError e) { > 245 throw new DatatypeConfigurationException(""Provider " + className + " could not be loaded or instantiated using java.util.ServiceLoader", e); > Doh, please shoot me now, i was labouring under the misapprehension that SCE was extending from Exception and not Error. Apologies for the confusion. Paul. From lance.andersen at oracle.com Wed Aug 29 17:39:37 2012 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 29 Aug 2012 13:39:37 -0400 Subject: Review Request: 7193683: Cleanup Warning in java.sql package In-Reply-To: <503DA8A8.2060701@oracle.com> References: <503DA8A8.2060701@oracle.com> Message-ID: <5D348175-AD75-4156-ABC0-3EE0A0A305B0@oracle.com> This looks fine. Dan, I will commit this for you Thursday Best Lance On Aug 29, 2012, at 1:29 AM, Dan Xu wrote: > I made a simple fix to clean up build warnings in java.sql package. The change can be reviewed at http://cr.openjdk.java.net/~dxu/7193683/webrev.01/. Thanks! > > -Dan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From dan.xu at oracle.com Wed Aug 29 19:11:01 2012 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 29 Aug 2012 12:11:01 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503E34D9.4060309@oracle.com> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> <503D6105.6000708@oracle.com> <503D630C.2060601@oracle.com> <503DA700.5050207@oracle.com> <503DB7CE.9060001@oracle.com> <503DD772.6010201@univ-mlv.fr> <503E34D9.4060309@oracle.com> Message-ID: <503E6945.9020206@oracle.com> On 08/29/2012 08:27 AM, Joe Darcy wrote: > Hello, > > On 8/29/2012 1:48 AM, R?mi Forax wrote: >> On 08/29/2012 08:33 AM, Kurchi Subhra Hazra wrote: >>> Thanks for cleaning up those spaces Dan. The changes look fine. >>> Sorry for the extra trouble! >>> >>> - Kurchi >>> >>> On 8/28/12 10:22 PM, Dan Xu wrote: >>>> It is funny. :) I have searched all source codes under jdk and >>>> removed spaces for the similar cases. >>>> >>>> Please review the new version of change at, >>>> http://cr.openjdk.java.net/~dxu/7193406/webrev.03/. >>>> >>>> Thanks for your comment! >>>> >>>> -Dan >> >> Hi Dan, >> >> In PreHashedMap, the code should be >> >> Map.Entry that = (Map.Entry)ob; >> >> so the @SuppressWarnings is not needed anymore. >> >> And in java.util.Arrays, asList() should not be annotated with >> @SuppressWarnings because it is already annotated with SafeVarargs, >> so the compiler should not report the varargs warning. >> >> I have CC to compiler-dev to be sure that this is a compiler error. >> >> cheers, >> R?mi >> > > I've spoken to Stuart about this last point. The @SafeVarargs covers > uses of Array.asList and covers the declaration of the asList method > itself. However, it does not cover calls to the constructor inside > the asList method, a constructor which itself is *not* @SafeVarargs. > Solutions include > > * @SuppressWarnings("varargs") on the asList method > * @SuppressWarnings("varargs") on new temporary variable for that > purpose (with possible class file size consequences) > * @SafeVarargs on the ArrayList constructor > > Regards, > > -Joe The first change to the PreHashedMap is right, and I will update my fix. For the second comment, as Joe mentioned, it is necessary. Otherwise, the compiler will give the following warnings. ../../../src/share/classes/java/util/Arrays.java:2837: warning: [varargs] Varargs method could cause heap pollution from non-reifiable varargs parameter a return new ArrayList<>(a); ^ ../../../src/share/classes/java/util/Arrays.java:2837: warning: [varargs] Varargs method could cause heap pollution from non-reifiable varargs parameter a return new ArrayList<>(a); ^ The first and second options works fine. But if I follow the third option to add @SafeVarargs on the ArrayList constructor, I get the following error. ../../../src/share/classes/java/util/Arrays.java:2849: error: Invalid SafeVarargs annotation. Method ArrayList(E[]) is not a varargs method. ArrayList(E[] array) { ^ where E is a type-variable: E extends Object declared in class ArrayList So I tried further to change the constructor to a varargs method and add the @SafeVarargs annotation, but the compiler still gives me warnings like this, ../../../src/share/classes/java/util/Arrays.java:2837: warning: [varargs] Varargs method could cause heap pollution from non-reifiable varargs parameter a return new ArrayList<>(a); ^ ../../../src/share/classes/java/util/Arrays.java:2837: warning: [varargs] Varargs method could cause heap pollution from non-reifiable varargs parameter a return new ArrayList<>(a); ^ ../../../src/share/classes/java/util/Arrays.java:2852: warning: [varargs] Varargs method could cause heap pollution from non-reifiable varargs parameter array a = array; ^ 3 warnings I think the current change is good for this one. Thanks for your comments. -Dan From dan.xu at oracle.com Wed Aug 29 21:47:39 2012 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 29 Aug 2012 14:47:39 -0700 Subject: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed element In-Reply-To: <503D5EB9.6050507@oracle.com> References: <503BDD09.80006@oracle.com> <503C9321.2070508@oracle.com> <503D3634.90807@CoSoCo.de> <503D569D.1040206@oracle.com> <503D59CC.3080104@CoSoCo.de> <503D5EB9.6050507@oracle.com> Message-ID: <503E8DFB.2050503@oracle.com> Thanks for your comments. I have updated my fix and posted at, http://cr.openjdk.java.net/~dxu/7193710/webrev.01/. I think the effort to upgrade to use new tags is out of the scope of this fix and will be addressed against the whole JDK in one chunk later. -Dan On 08/28/2012 05:13 PM, Dan Xu wrote: > I will update the change with your suggestion. Thanks! > > -Dan > > > > On 08/28/2012 04:52 PM, Ulf Zibis wrote: >> Thanks for your feedback Dan. >> >> But I still think, the link to the javadoc of a class should not be >> labelled by a variable name. >> So maybe use: >> 212 * Converts the buffer's contents into a string by decoding >> the bytes using >> 213 * the {@link java.nio.charset.Charset}, specified by it's >> name. The length of >> or: >> 212 * Converts the buffer's contents into a string by decoding >> the bytes using >> 213 * the {@link java.nio.charset.Charset}, specified by it's >> {@code charsetName}. >> And: >> 222 * @param charsetName the name of a supported >> 223 * {@link java.nio.charset.Charset} >> >> -Ulf >> >> Am 29.08.2012 01:39, schrieb Dan Xu: >>> Thanks for your comments, Ulf. >>> >>> I looked at the definitions of @link and @linkplain again. And I >>> find that this nested situation can be easily avoided by replacing >>> @linkplain with @link as the following, >>> >>> {@link java.nio.charset.Charset charset} >>> >>> I will update my changes. >>> >>> -Dan >>> >>> >>> >>> On 08/28/2012 02:20 PM, Ulf Zibis wrote: >>>> Am 28.08.2012 11:45, schrieb Alan Bateman: >>>>> On 27/08/2012 21:48, Dan Xu wrote: >>>>>> This change is to fix the java doc font issue for >>>>>> ByteArrayOutputStream class. In current javadoc, contents change >>>>>> to the wrong font starting from toString(String charsetName) in >>>>>> ByteArrayOutputStream.html, which can be viewed at >>>>>> http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html. >>>> I think the link to the javadoc of a class should not be labelled >>>> by a variable name: >>>> 212 * Converts the buffer's contents into a string by >>>> decoding the bytes using >>>> 213 * the specified {@link java.nio.charset.Charset >>>> charsetName}. The length of >>>> Maybe better: >>>> 212 * Converts the buffer's contents into a string by >>>> decoding the bytes using >>>> 213 * the {@link java.nio.charset.Charset}, specified by it's >>>> name. The length of >>>> or: >>>> 212 * Converts the buffer's contents into a string by >>>> decoding the bytes using >>>> 213 * the {@link java.nio.charset.Charset}, specified by it's >>>> [@code charsetName}. The length of >>>> Same for: >>>> 222 * @param charsetName the name of a supported >>>> 223 * {@link(plain) java.nio.charset.Charset} >>>> >>>> Additionally you could align the param items: >>>> 224 * @return String decoded from the buffer's contents. >>>> 225 * @throws UnsupportedEncodingException >>>> 226 * If the named charset is not supported >>>> 227 * @since JDK1.1 >>>> >>>> 227 * @since JDK1.1 >>>> Shouldn't it be? : >>>> 227 * @since 1.1 >>>> >>>>>> The webrev is at http://cr.openjdk.java.net/~dxu/7193710/webrev/. >>>>> This looks fine me as it doesn't seem you can use @code here (Joe >>>>> or Jon might be able to say what the rules are for nesting these >>>>> javadoc tags). >>>> Interesting question, maybe a bug in javadoc? >>>> Maybe {@link ...} instead {@linkplain ...} would work. >>>> >>>> +1 for taking the opportunity to upgrade the file to using {@code}, >>>> {@link}, ... to {@code ...} etc., even if in this special >>>> nested case a trick is needed. >>>> >>>> -Ulf >>>> >>> >>> >> > From stuart.marks at oracle.com Wed Aug 29 22:53:02 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 29 Aug 2012 15:53:02 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <1678589493.12653541.1346255298109.JavaMail.root@redhat.com> References: <1678589493.12653541.1346255298109.JavaMail.root@redhat.com> Message-ID: <503E9D4E.10002@oracle.com> On 8/29/12 8:48 AM, Andrew Hughes wrote: > But presumably [-Werror] would be removed when everything is warning free? > -Werror should not be the default for everyone building OpenJDK, who then > end up having to fix or workaround issues which are nothing to do with them. > It's easy enough for those who want to check we don't regress to turn on > -Werror throughout, once everything is warning free. Once everything is warning free, -Werror *should* be enabled by default. That's how we'll keep everything warning free. If everything were warning free, I don't see how people could be blocked by warnings that are unrelated to their current changes. This does happen today with implicit compilation, but it shouldn't happen in the bright shining future where there are no warnings. :-) If there's some other phenomenon that could cause warnings to pop up spontaneously, unrelated to their current changes, I'd like to understand what that is. s'marks From stuart.marks at oracle.com Wed Aug 29 23:03:19 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 29 Aug 2012 16:03:19 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503DF3DA.1040106@CoSoCo.de> References: <1752716260.10040789.1345767163342.JavaMail.root@redhat.com> <503DF3DA.1040106@CoSoCo.de> Message-ID: <503E9FB7.9070203@oracle.com> On 8/29/12 3:50 AM, Ulf Zibis wrote: >>> In FilePermission.java file, I make one change to its method >>> signature, >>> >>> public Enumeration elements() ==> public Enumeration >>> elements() >>> > Actually the whole method is synchronized. To make this more clear, I suggest: > 798 public synchronized Enumeration elements() { > 799 // Convert Iterator into Enumeration > 800 return Collections.enumeration(perms); > 801 } [...] > If this class is package-private, why the constructor is public? > (please also check all other methods, especially if not inherited) [...] > Please check indentations and tabs -> spaces, while you are here. > E.g. following lines should be: [...] [...] > I only took a short look on class FilePermission.java, but not the others of > this CR for now. Hi Ulf, You're making some reasonable suggestions for general code cleanup. However, this is not general code cleanup. Several issues have already been raised that are directly relevant to the warnings fixes. I'd like to get these resolved, to get Dan's fix integrated, and to keep Dan focused on further warnings cleanup, without getting bogged down in other code cleanup issues. Thanks. s'marks From huizhe.wang at oracle.com Wed Aug 29 23:08:13 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 29 Aug 2012 16:08:13 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <1F4403CF-F8AD-4FA9-BBCB-E373B5329A2D@oracle.com> <503C58B1.6080502@oracle.com> <503D03EF.1080804@oracle.com> Message-ID: <503EA0DD.60705@oracle.com> I actually updated the webrev yesterday with your suggestion. Recall our discussions back in June, the suggestion was to delegate to the ServiceLoader, e.g. ServiceLoader.load(serviceClass). The rational was that the ServiceLoader uses context and then bootstrap class loader. The spec for public static ServiceLoader load(Class service, ClassLoader loader) states: loader - The class loader to be used to load provider-configuration files and provider classes, or null if the system class loader (or, failing that, the bootstrap class loader) is to be used This is different. In JAXP, null is recognized as bootstrap classloader, but the ServiceLoader actually assumes it as system class loader. This will be a problem, whether or now a classloader is passed to the load method. --Joe On 8/29/2012 1:56 AM, Paul Sandoz wrote: > For the SchemaFactoryFinder there is now a potentially subtle difference in what CL is used to load a class by SL and by SchemaFactoryFinder.createInstance. Previously the same CL was always used whatever the mechanism was used to identify the class name. Errors related to class loaders can be extremely hard to track down hence the conservative position. > > -- > > I will say no more on the above:-) > > Paul. > > [*] If a developer can declare a service provider then such linkage errors can potentially occur. From stuart.marks at oracle.com Wed Aug 29 23:20:03 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 29 Aug 2012 16:20:03 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503DFEA3.70900@CoSoCo.de> References: <5036A4C4.5040709@oracle.com> <5036DEA5.1020100@oracle.com> <5037D0D8.3030307@oracle.com> <503DFEA3.70900@CoSoCo.de> Message-ID: <503EA3A3.6010402@oracle.com> On 8/29/12 4:36 AM, Ulf Zibis wrote: >>> 436 switch (actions) { >>> 437 case SecurityConstants.FILE_READ_ACTION: >>> 438 return READ; > > Oops, you have reverted the change to use switch-on-Strings by webrev.03. Why? A fair question. I had instigated some internal conversation about reverting this change, so here's the explanation. (Good catch, by the way.) The original code was like this: 427 private static int getMask(String actions) { ... 435 // Check against use of constants (used heavily within the JDK) 436 if (actions == SecurityConstants.FILE_READ_ACTION) { 437 return READ; 438 } else if (actions == SecurityConstants.FILE_WRITE_ACTION) { The various SecurityConstants being used here are Strings. Note that this is doing String comparisons using == which is usually a bug. But this code is relying on String interning to provide object identity for equal string literals, in order to provide a fast path optimization for these common cases. Changing this code to use switch-over-strings would be semantically equivalent, but it would probably slow things down, since switch provides equals() semantics instead of == semantics. The permissions code is quite performance-sensitive, so I've asked Dan to revert this change. >> @SuppressWarnings("fallthrough") is put to suppress warnings generated by >> another switch/case statements > Can't you move it from method scope to there? > >> while (i >= matchlen && !seencomma) { >> switch(a[i-matchlen]) { >> case ',': >> seencomma = true; >> /*FALLTHROUGH*/ >> case ' ': case '\r': case '\n': >> case '\f': case '\t': >> break; >> default: >> throw new IllegalArgumentException( >> "invalid permission: " + actions); >> } >> i--; >> } Unfortunately there is no suitable place to put the annotation. Annotations can only be placed on declarations, and the narrowest enclosing declaration around this switch statement is, unfortunately, the entire method. One might consider refactoring the switch statement into its own method, but that kind of refactoring is too large a change for warnings cleanup. s'marks From huizhe.wang at oracle.com Wed Aug 29 23:33:20 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 29 Aug 2012 16:33:20 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <1F4403CF-F8AD-4FA9-BBCB-E373B5329A2D@oracle.com> <503C58B1.6080502@oracle.com> <503D03EF.1080804@oracle.com> Message-ID: <503EA6C0.50007@oracle.com> Paul, Alan, Confusion was what jaxp meant to give :) I was told that the factory/object finders, security support classes were duplicated, and needed to be kept in sync. But they are not even in their original form, unfortunately. Both of you mentioned that it's desirable to make SCE the cause for the configuration exception. DatatypeConfigurationException is different from all others in that, it's an Exception while others Error, it takes Throwable as cause while others Exception. I did not want to change the signatures of the other configuration error classes, that is, the constructors would need to take Throwable instead of Exception (as they should have already done). As a comprise, I've wrapped the error message in a confguration error. Would you think it's sufficient to add to the message what you did below (e.g. " could not be loaded or instantiated using java.util.ServiceLoader"? Or are you into making signature changes? (sth. I thought we didn't want to for this patch) --Joe On 8/29/2012 8:56 AM, Paul Sandoz wrote: > On Aug 29, 2012, at 10:56 AM, Paul Sandoz wrote: > >> Hi Joe, >> >> I would urge you to reconsider errors using SL, since SL is being explicitly called out as part of the specification. >> >> You can make any such SL-related errors more meaningful (yes, i want the stack trace telling what bits of SL code were called!) and remove any potential for CCEs, due to linkage errors [*], by passing the SCE instance to the constructor of DatatypeConfigurationException or the FactoryConfigurationError variants e.g. >> >> 244 } catch (ServiceConfigurationError e) { >> 245 throw new DatatypeConfigurationException(""Provider " + className + " could not be loaded or instantiated using java.util.ServiceLoader", e); >> > Doh, please shoot me now, i was labouring under the misapprehension that SCE was extending from Exception and not Error. > > Apologies for the confusion. > > Paul. From dan.xu at oracle.com Wed Aug 29 23:39:04 2012 From: dan.xu at oracle.com (Dan Xu) Date: Wed, 29 Aug 2012 16:39:04 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503E6945.9020206@oracle.com> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> <503D6105.6000708@oracle.com> <503D630C.2060601@oracle.com> <503DA700.5050207@oracle.com> <503DB7CE.9060001@oracle.com> <503DD772.6010201@univ-mlv.fr> <503E34D9.4060309@oracle.com> <503E6945.9020206@oracle.com> Message-ID: <503EA818.4000602@oracle.com> On 08/29/2012 12:11 PM, Dan Xu wrote: > > On 08/29/2012 08:27 AM, Joe Darcy wrote: >> Hello, >> >> On 8/29/2012 1:48 AM, R?mi Forax wrote: >>> On 08/29/2012 08:33 AM, Kurchi Subhra Hazra wrote: >>>> Thanks for cleaning up those spaces Dan. The changes look fine. >>>> Sorry for the extra trouble! >>>> >>>> - Kurchi >>>> >>>> On 8/28/12 10:22 PM, Dan Xu wrote: >>>>> It is funny. :) I have searched all source codes under jdk and >>>>> removed spaces for the similar cases. >>>>> >>>>> Please review the new version of change at, >>>>> http://cr.openjdk.java.net/~dxu/7193406/webrev.03/. >>>>> >>>>> Thanks for your comment! >>>>> >>>>> -Dan >>> >>> Hi Dan, >>> >>> In PreHashedMap, the code should be >>> >>> Map.Entry that = (Map.Entry)ob; >>> >>> so the @SuppressWarnings is not needed anymore. >>> >>> And in java.util.Arrays, asList() should not be annotated with >>> @SuppressWarnings because it is already annotated with SafeVarargs, >>> so the compiler should not report the varargs warning. >>> >>> I have CC to compiler-dev to be sure that this is a compiler error. >>> >>> cheers, >>> R?mi >>> >> >> I've spoken to Stuart about this last point. The @SafeVarargs covers >> uses of Array.asList and covers the declaration of the asList method >> itself. However, it does not cover calls to the constructor inside >> the asList method, a constructor which itself is *not* @SafeVarargs. >> Solutions include >> >> * @SuppressWarnings("varargs") on the asList method >> * @SuppressWarnings("varargs") on new temporary variable for that >> purpose (with possible class file size consequences) >> * @SafeVarargs on the ArrayList constructor >> >> Regards, >> >> -Joe > The first change to the PreHashedMap is right, and I will update my fix. > > For the second comment, as Joe mentioned, it is necessary. Otherwise, > the compiler will give the following warnings. > > ../../../src/share/classes/java/util/Arrays.java:2837: warning: > [varargs] Varargs method could cause heap pollution from > non-reifiable varargs parameter a > return new ArrayList<>(a); > ^ > ../../../src/share/classes/java/util/Arrays.java:2837: warning: > [varargs] Varargs method could cause heap pollution from > non-reifiable varargs parameter a > return new ArrayList<>(a); > > ^ > > The first and second options works fine. But if I follow the third > option to add @SafeVarargs on the ArrayList constructor, I get the > following error. > > ../../../src/share/classes/java/util/Arrays.java:2849: error: > Invalid SafeVarargs annotation. Method ArrayList(E[]) is not a > varargs method. > ArrayList(E[] array) { > ^ > where E is a type-variable: > E extends Object declared in class ArrayList > > > So I tried further to change the constructor to a varargs method and > add the @SafeVarargs annotation, but the compiler still gives me > warnings like this, > > ../../../src/share/classes/java/util/Arrays.java:2837: warning: > [varargs] Varargs method could cause heap pollution from > non-reifiable varargs parameter a > return new ArrayList<>(a); > ^ > ../../../src/share/classes/java/util/Arrays.java:2837: warning: > [varargs] Varargs method could cause heap pollution from > non-reifiable varargs parameter a > return new ArrayList<>(a); > ^ > ../../../src/share/classes/java/util/Arrays.java:2852: warning: > [varargs] Varargs method could cause heap pollution from > non-reifiable varargs parameter array > a = array; > ^ > 3 warnings > > > > I think the current change is good for this one. Thanks for your > comments. > > -Dan > > > I have updated my fix with above suggestions. Thanks for your comments. The webrev is at http://cr.openjdk.java.net/~dxu/7193406/webrev.04/. Thanks! -Dan From joe.darcy at oracle.com Wed Aug 29 23:56:46 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 29 Aug 2012 16:56:46 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503EA3A3.6010402@oracle.com> References: <5036A4C4.5040709@oracle.com> <5036DEA5.1020100@oracle.com> <5037D0D8.3030307@oracle.com> <503DFEA3.70900@CoSoCo.de> <503EA3A3.6010402@oracle.com> Message-ID: <503EAC3E.9010000@oracle.com> On 8/29/2012 4:20 PM, Stuart Marks wrote: > On 8/29/12 4:36 AM, Ulf Zibis wrote: >>>> 436 switch (actions) { >>>> 437 case SecurityConstants.FILE_READ_ACTION: >>>> 438 return READ; >> >> Oops, you have reverted the change to use switch-on-Strings by >> webrev.03. Why? > > A fair question. I had instigated some internal conversation about > reverting this change, so here's the explanation. (Good catch, by the > way.) > > The original code was like this: > > 427 private static int getMask(String actions) { > ... > 435 // Check against use of constants (used heavily within > the JDK) > 436 if (actions == SecurityConstants.FILE_READ_ACTION) { > 437 return READ; > 438 } else if (actions == SecurityConstants.FILE_WRITE_ACTION) { > > The various SecurityConstants being used here are Strings. > > Note that this is doing String comparisons using == which is usually a > bug. But this code is relying on String interning to provide object > identity for equal string literals, in order to provide a fast path > optimization for these common cases. Changing this code to use > switch-over-strings would be semantically equivalent, but it would > probably slow things down, since switch provides equals() semantics > instead of == semantics. This would be a fine point to highlight in the comments around this check! -Joe From stuart.marks at oracle.com Thu Aug 30 02:01:58 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 29 Aug 2012 19:01:58 -0700 Subject: RFR: 7195099 update problem list with RMI test failures Message-ID: <503EC996.4060505@oracle.com> Hi Alan, I'm opening another front in the war against test failures. Please review these additions to the problem list. Thanks. s'marks diff -r c4c69b4d9ace test/ProblemList.txt --- a/test/ProblemList.txt Wed Aug 29 11:03:02 2012 +0800 +++ b/test/ProblemList.txt Wed Aug 29 19:00:56 2012 -0700 @@ -261,6 +261,18 @@ # 7146541 java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java linux-all +# 7187882 +java/rmi/activation/checkusage/CheckUsage.java generic-all + +# 7190106 +java/rmi/reliability/benchmark/runRmiBench.sh generic-all + +# 7191877 +java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java generic-all + +# 7195095 +sun/rmi/transport/proxy/EagerHttpFallback.java linux-all + ############################################################################ # jdk_security From stuart.marks at oracle.com Thu Aug 30 02:07:19 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 29 Aug 2012 19:07:19 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503EAC3E.9010000@oracle.com> References: <5036A4C4.5040709@oracle.com> <5036DEA5.1020100@oracle.com> <5037D0D8.3030307@oracle.com> <503DFEA3.70900@CoSoCo.de> <503EA3A3.6010402@oracle.com> <503EAC3E.9010000@oracle.com> Message-ID: <503ECAD7.1020707@oracle.com> On 8/29/12 4:56 PM, Joe Darcy wrote: > On 8/29/2012 4:20 PM, Stuart Marks wrote: >> The original code was like this: >> >> 427 private static int getMask(String actions) { >> ... >> 435 // Check against use of constants (used heavily within the JDK) >> 436 if (actions == SecurityConstants.FILE_READ_ACTION) { >> 437 return READ; >> 438 } else if (actions == SecurityConstants.FILE_WRITE_ACTION) { >> >> The various SecurityConstants being used here are Strings. >> >> Note that this is doing String comparisons using == which is usually a bug. >> But this code is relying on String interning to provide object identity for >> equal string literals, in order to provide a fast path optimization for these >> common cases. Changing this code to use switch-over-strings would be >> semantically equivalent, but it would probably slow things down, since switch >> provides equals() semantics instead of == semantics. > > This would be a fine point to highlight in the comments around this check! The comment at line 435 did serve to tip me off that something unusual was going on with this code, so it served its purpose. But I'll admit that it's not as explicit as it could be. How about this: // Use object identity comparisons with String constants for performance // reasons (these values are used heavily within the JDK). s'marks From david.holmes at oracle.com Thu Aug 30 05:28:25 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Aug 2012 15:28:25 +1000 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503E9D4E.10002@oracle.com> References: <1678589493.12653541.1346255298109.JavaMail.root@redhat.com> <503E9D4E.10002@oracle.com> Message-ID: <503EF9F9.6030005@oracle.com> Hi Stuart, On 30/08/2012 8:53 AM, Stuart Marks wrote: > On 8/29/12 8:48 AM, Andrew Hughes wrote: >> But presumably [-Werror] would be removed when everything is warning >> free? >> -Werror should not be the default for everyone building OpenJDK, who then >> end up having to fix or workaround issues which are nothing to do with >> them. >> It's easy enough for those who want to check we don't regress to turn on >> -Werror throughout, once everything is warning free. > > Once everything is warning free, -Werror *should* be enabled by default. > That's how we'll keep everything warning free. > > If everything were warning free, I don't see how people could be blocked > by warnings that are unrelated to their current changes. This does > happen today with implicit compilation, but it shouldn't happen in the > bright shining future where there are no warnings. :-) It will happen to the first person who updates gcc and encounters the next round of gcc enhancements that cause our old C++ code to now generate warnings. > If there's some other phenomenon that could cause warnings to pop up > spontaneously, unrelated to their current changes, I'd like to > understand what that is. gcc :) David > > s'marks From joe.darcy at oracle.com Thu Aug 30 06:23:28 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 29 Aug 2012 23:23:28 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503ECAD7.1020707@oracle.com> References: <5036A4C4.5040709@oracle.com> <5036DEA5.1020100@oracle.com> <5037D0D8.3030307@oracle.com> <503DFEA3.70900@CoSoCo.de> <503EA3A3.6010402@oracle.com> <503EAC3E.9010000@oracle.com> <503ECAD7.1020707@oracle.com> Message-ID: <503F06E0.4020906@oracle.com> On 8/29/2012 7:07 PM, Stuart Marks wrote: > > > On 8/29/12 4:56 PM, Joe Darcy wrote: >> On 8/29/2012 4:20 PM, Stuart Marks wrote: >>> The original code was like this: >>> >>> 427 private static int getMask(String actions) { >>> ... >>> 435 // Check against use of constants (used heavily within >>> the JDK) >>> 436 if (actions == SecurityConstants.FILE_READ_ACTION) { >>> 437 return READ; >>> 438 } else if (actions == >>> SecurityConstants.FILE_WRITE_ACTION) { >>> >>> The various SecurityConstants being used here are Strings. >>> >>> Note that this is doing String comparisons using == which is usually >>> a bug. >>> But this code is relying on String interning to provide object >>> identity for >>> equal string literals, in order to provide a fast path optimization >>> for these >>> common cases. Changing this code to use switch-over-strings would be >>> semantically equivalent, but it would probably slow things down, >>> since switch >>> provides equals() semantics instead of == semantics. >> >> This would be a fine point to highlight in the comments around this >> check! > > The comment at line 435 did serve to tip me off that something unusual > was going on with this code, so it served its purpose. But I'll admit > that it's not as explicit as it could be. How about this: > > // Use object identity comparisons with String constants for > performance > // reasons (these values are used heavily within the JDK). > I recommend explicitly mentioning interning "Using identity comparison against known-interned strings for performance benefit." -Joe From huizhe.wang at oracle.com Thu Aug 30 06:59:24 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 29 Aug 2012 23:59:24 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <503DEE97.7020000@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <503B73DA.4060807@oracle.com> <503C4FA2.5050001@oracle.com> <503DEE97.7020000@oracle.com> Message-ID: <503F0F4C.4010509@oracle.com> Alan, Paul, While I was writing a summery as you suggested below, I noticed an issue with using ServiceLoader. I was trying to use the word 'delegate' but found the ServiceLoader might be doing sth. different than the original jaxp process. Here's the spec: The ServiceLoader.load(service) is equivalent to ServiceLoader.load(service, Thread.currentThread().getContextClassLoader()) where "loader - The class loader to be used to load provider-configuration files and provider classes, or null if the system class loader (or, failing that, the bootstrap class loader) is to be used " Somehow, our earlier discussion concluded that the original process I created, where the context class loader is tried first, if no provider found, bootstrap classloader will be tried next, could be 'delegated' to the ServiceLoader. But the above didn't really showed that. When I looked at the code, it actually simply returns false if loader.getResources fails to find a provider. Also, it calls ClassLoader.getSystemResources when loader=null. The later would be a regression to CR6723276 if we had called ServiceLoader.load(service, loader) with loader=null. Am I missing sth. about ServiceLoader? --Joe On 8/29/2012 3:27 AM, Alan Bateman wrote: > On 28/08/2012 05:57, Joe Wang wrote: >> : >> >>> >>> In DocumentBuilderFactory and SAXParserFactory the javadoc reads " >>> Otherwise the default implementation is returned if it is on the >>> classpath or installed as a module". I think this statement needs to >>> be re-worked, first to remove the word "module" as it is not defined >>> here, and also because I don't think it's the classpath. If I read >>> the code correctly then initiating loader may actually be the >>> context class loader and assuming the usual delegation then the >>> default should be loaded by the boot class loader. It may be >>> possible to borrow some of the wording from the ServiceLoader >>> javadoc to help here. >> >> It seems we need to go over this again since it was intended for >> jdk8/jigsaw. Without modules, we don't really need to put other >> implementations over the default. How about change it to the following: >> >> * Uses the service-provider loading facilities, defined by the >> {@link java.util.ServiceLoader} class, to attempt >> * to locate and load an implementation of the service. If there >> are multiple providers, the first one returned >> * by the {@link java.util.ServiceLoader} will be instantiated >> and returned. >> * >> * If a misconfigured provider is encountered and {@link >> java.util.ServiceConfigurationError} is thrown, the error will be >> wrapped >> * in a {@link javax.xml.parsers.FactoryConfigurationException}.

> I think it should allow for the possibility that the default factory > is itself installed as a service provider. To that end, I think the > original proposed working was in the right direction, it's just that > it used terms "classpath" and "modules" too loosely and didn't define > what the initiating loader was. Here is some suggested wording to chew on: > > "Installed providers are loaded using the service-provider loading > facility defined by the {@link ServiceLoader} class. Providers are > loaded using the current thread's context class loader. If the context > class loader is {@code null} then the system class loader if used. The > first service provider to be instantiated that is not the default > provider is returned. If the only service provider to be located is > the default provider then it is instantiated and returned. > > If a {@link ServiceConfigurationError} is encountered when locating or > iterating over the providers then this causes {@link > FactoryConfigurationException} to be thrown, with the {@code > ServiceConfigurationError} as its cause." > >> >> : >> >>> >>> In src/javax/xml/datatype/FactoryFinder.java then is there any >>> reason why this class has to use Object? I realize that some of the >>> factory finders are called for several types but there are few (like >>> this one) where there is only one type involved. >> >> No, it doesn't. FactoryFinder for datatype and transform can be >> dedicated. It was believed that it and SecuritySupport should be >> copied for each package, I think we touched this before. I left it >> alone, or otherwise we'd need to change all other methods in the >> class and also the transformer factory finder, for not much >> performance gain. > Okay, but I do think this needs clean-up at some point. > > >> >>> >>> DocumentBuilderFactory.java it has: >>> catch (FactoryConfigurationError e) { throw e; } >>> I assume the catch is not needed, same thing in a few other places. >> >> It's not. But since the javadoc for the method defined throws, I >> thought it's good to re-throw it within the method rather than going >> into the finder class to know that the Error will be thrown. > I see Paul's has picked up on this in his comments too. > > >> >> : >> >>> >>> I think one thing that would be really useful here is to get a >>> summary of the behavioral and API changes that this changes brings. >>> SchemeFactory now throws FactoryConfigurationError whereas >>> previously errors were ignored. It would be good to summarize the >>> others. >> >> Yes, I think we'll do that in the MR. There isn't a general place in >> the Javadoc for us to do that. > I understand, I'm just saying think the list would be useful for the > review here too. I suggest this because there are subtle differences > between the datatype finder and the other finders, also the > SchemaFactory is being changed to throw an error that it previously > didn't define, etc. You'll need this for for JCP MR too but for now I > think it is important for the reviewers here to have the summary so > that we know what we are reviewing. > > -Alan > > > From paul.sandoz at oracle.com Thu Aug 30 07:22:18 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 30 Aug 2012 09:22:18 +0200 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <503EA0DD.60705@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <1F4403CF-F8AD-4FA9-BBCB-E373B5329A2D@oracle.com> <503C58B1.6080502@oracle.com> <503D03EF.1080804@oracle.com> <503EA0DD.60705@oracle.com> Message-ID: Hi Joe, On Aug 30, 2012, at 1:08 AM, Joe Wang wrote: > I actually updated the webrev yesterday with your suggestion. > OK! Sorry if i am being stubbornly persistent! > Recall our discussions back in June, the suggestion was to delegate to the ServiceLoader, e.g. ServiceLoader.load(serviceClass). The rational was that the ServiceLoader uses context and then bootstrap class loader. > Yes. > The spec for public static ServiceLoader load(Class service, ClassLoader loader) states: > loader - The class loader to be used to load provider-configuration files and provider classes, or null if the system class loader (or, failing that, the bootstrap class loader) is to be used > > This is different. In JAXP, null is recognized as bootstrap classloader, but the ServiceLoader actually assumes it as system class loader. This will be a problem, whether or now a classloader is passed to the load method. > It's slightly different. For loading the provider-configuration file SL does: if (loader == null) configs = ClassLoader.getSystemResources(fullName); else configs = loader.getResources(fullName); For loading the class: S p = service.cast(Class.forName(cn, true, loader) .newInstance()); And the JavaDoc for Class.forName states: "If the parameter loader is null, the class is loaded through the bootstrap class loader." So there is some vagueness in the JavaDoc of SL of when the system CL is utilised. However, i think things are consistent with loading the provider-configuration file, it's a bit of a tangle but AFAICT previously loading the configuration file deferred to SecuritySupport.getResourceAsStream which does: if (cl == null) { ris = Object.class.getResourceAsStream(name); } else { ris = cl.getResourceAsStream(name); } And the JavaDoc of Class.getResourceAsStream states: "If this object was loaded by the bootstrap class loader, the method delegates to ClassLoader.getSystemResourceAsStream(java.lang.String)" Paul. From paul.sandoz at oracle.com Thu Aug 30 07:30:03 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 30 Aug 2012 09:30:03 +0200 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <503EA6C0.50007@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <1F4403CF-F8AD-4FA9-BBCB-E373B5329A2D@oracle.com> <503C58B1.6080502@oracle.com> <503D03EF.1080804@oracle.com> <503EA6C0.50007@oracle.com> Message-ID: <16AE42B6-4B70-4766-9533-36DF477E3324@oracle.com> On Aug 30, 2012, at 1:33 AM, Joe Wang wrote: > Paul, Alan, > > Confusion was what jaxp meant to give :) My eyes wobble when i look at all that class loading code! > I was told that the factory/object finders, security support classes were duplicated, and needed to be kept in sync. But they are not even in their original form, unfortunately. > > Both of you mentioned that it's desirable to make SCE the cause for the configuration exception. DatatypeConfigurationException is different from all others in that, it's an Exception while others Error, it takes Throwable as cause while others Exception. I did not want to change the signatures of the other configuration error classes, that is, the constructors would need to take Throwable instead of Exception (as they should have already done). > Argh! what a mess. > As a comprise, I've wrapped the error message in a confguration error. Would you think it's sufficient to add to the message what you did below (e.g. " could not be loaded or instantiated using java.util.ServiceLoader"? > Yeah, something like that might be helpful. > Or are you into making signature changes? (sth. I thought we didn't want to for this patch) > I would leave those FactoryConfigurationError classes alone and wrap the SCE. Those classes are beyond saving! Paul. From aph at redhat.com Thu Aug 30 08:17:49 2012 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Aug 2012 09:17:49 +0100 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503E9D4E.10002@oracle.com> References: <1678589493.12653541.1346255298109.JavaMail.root@redhat.com> <503E9D4E.10002@oracle.com> Message-ID: <503F21AD.8000108@redhat.com> On 08/29/2012 11:53 PM, Stuart Marks wrote: > > > On 8/29/12 8:48 AM, Andrew Hughes wrote: >> But presumably [-Werror] would be removed when everything is warning free? >> -Werror should not be the default for everyone building OpenJDK, who then >> end up having to fix or workaround issues which are nothing to do with them. >> It's easy enough for those who want to check we don't regress to turn on >> -Werror throughout, once everything is warning free. > > Once everything is warning free, -Werror *should* be enabled by default. That's > how we'll keep everything warning free. > > If everything were warning free, I don't see how people could be blocked by > warnings that are unrelated to their current changes. This does happen today > with implicit compilation, but it shouldn't happen in the bright shining future > where there are no warnings. :-) -Werror is probably OK for Java code, but not for HotSpot. We GCC developers keep adding new warnings, so poor souls who keep up-to-date with new Fedora (and other leading-edge) distributions tend to be the first to discover problems. Thus is very awkward for people who don't understand advanced C++ features. Andrew. From christos at zoulas.com Thu Aug 30 09:04:30 2012 From: christos at zoulas.com (Christos Zoulas) Date: Thu, 30 Aug 2012 05:04:30 -0400 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503F21AD.8000108@redhat.com> from Andrew Haley (Aug 30, 9:17am) Message-ID: <20120830090431.0557597124@rebar.astron.com> On Aug 30, 9:17am, aph at redhat.com (Andrew Haley) wrote: -- Subject: Re: Review Request: 7193406 - Clean-up JDK Build Warnings in java | -Werror is probably OK for Java code, but not for HotSpot. | | We GCC developers keep adding new warnings, so poor souls who keep | up-to-date with new Fedora (and other leading-edge) distributions tend | to be the first to discover problems. Thus is very awkward for people | who don't understand advanced C++ features. There are people who write code, and people who build the code to run/test binaries. The first group should use -Werror, the second should not. christos From Alan.Bateman at oracle.com Thu Aug 30 09:23:44 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Aug 2012 10:23:44 +0100 Subject: RFR: 7195099 update problem list with RMI test failures In-Reply-To: <503EC996.4060505@oracle.com> References: <503EC996.4060505@oracle.com> Message-ID: <503F3120.80407@oracle.com> On 30/08/2012 03:01, Stuart Marks wrote: > Hi Alan, > > I'm opening another front in the war against test failures. Please > review these additions to the problem list. > > Thanks. > > s'marks I see you've got bugs for each of these so looks okay to me. BTW: On EagerHttpFallback.java, I've seen that fail too but only on systems where the host name resolves to the loopback address. That's the out of the box configuration with most Linux distributions so the tests need to tolerant that (even if RMI itself needs the host name resolving to the host address for it to work between hosts). -Alan From sean.coffey at oracle.com Thu Aug 30 11:48:33 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 30 Aug 2012 12:48:33 +0100 Subject: RFR: 7195063 [TEST] jtreg flags com/sun/corba/cachedSocket/7056731.sh with Error failure. Message-ID: <503F5311.7050501@oracle.com> bug report should be live shortly : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195063 The introduction of a new corba testcase in recent past is showing up as a random failure on our internal build/test harness (JPRT). === --------------------------------------------- com/sun/corba/cachedSocket/7056731 .sh --------------------------------------------- JDK under test: C:\\Users\\aurora\\sandbox\\jdk warning: failed to delete C:\\Users\\aurora\\sandbox\\gresults\\testoutput\\jdk_misc\\JTwork\\scratch\\client.1432 Test result (overridden): Passed. Execution successful failed to clean up files after test javatestOS=Windows XP 5.1 (x86) ==== Even though the testcase is passing, the jtreg harness flags it since it can't delete the client.$$ file. The issue is only randomly seen and I saw it for first time last night while testing and pushing the 7056731 change to 7u-dev. It was reported to me offline also. Fix seems to be allowing some sleep time before/after deleting the test log files. I attempted a patch up in 7u testcase last night with the 7056731 push but that went wrong. webrevs for jdk8 & jdk7u below. jdk 8 : http://cr.openjdk.java.net/~coffeys/webrev.7195063.jdk8/ jdk 7u : http://cr.openjdk.java.net/~coffeys/webrev.7195063.jdk7u/ regards, Sean. From Alan.Bateman at oracle.com Thu Aug 30 11:59:37 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Aug 2012 12:59:37 +0100 Subject: Review Request: 7193710 ByteArrayOutputStream Javadoc contains unclosed element In-Reply-To: <503E8DFB.2050503@oracle.com> References: <503BDD09.80006@oracle.com> <503C9321.2070508@oracle.com> <503D3634.90807@CoSoCo.de> <503D569D.1040206@oracle.com> <503D59CC.3080104@CoSoCo.de> <503D5EB9.6050507@oracle.com> <503E8DFB.2050503@oracle.com> Message-ID: <503F55A9.3070200@oracle.com> On 29/08/2012 22:47, Dan Xu wrote: > Thanks for your comments. I have updated my fix and posted at, > http://cr.openjdk.java.net/~dxu/7193710/webrev.01/. > > I think the effort to upgrade to use new tags is out of the scope of > this fix and will be addressed against the whole JDK in one chunk later. > > -Dan > This looks good to me and I can push it for you. There is clearly other clean-up that could be done but I agree this does not need to be part of 7193710. -Alan. From alan.bateman at oracle.com Thu Aug 30 12:00:15 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 30 Aug 2012 12:00:15 +0000 Subject: hg: jdk8/tl/jdk: 7193710: ByteArrayOutputStream Javadoc contains unclosed element Message-ID: <20120830120101.5E081477E8@hg.openjdk.java.net> Changeset: cf492d1199dc Author: dxu Date: 2012-08-30 12:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf492d1199dc 7193710: ByteArrayOutputStream Javadoc contains unclosed element Reviewed-by: dholmes, alanb, ulfzibis ! src/share/classes/java/io/ByteArrayOutputStream.java ! src/share/classes/java/io/InputStreamReader.java From forax at univ-mlv.fr Thu Aug 30 12:06:04 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Thu, 30 Aug 2012 14:06:04 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503E6945.9020206@oracle.com> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> <503D6105.6000708@oracle.com> <503D630C.2060601@oracle.com> <503DA700.5050207@oracle.com> <503DB7CE.9060001@oracle.com> <503DD772.6010201@univ-mlv.fr> <503E34D9.4060309@oracle.com> <503E6945.9020206@oracle.com> Message-ID: <503F572C.4030105@univ-mlv.fr> On 08/29/2012 09:11 PM, Dan Xu wrote: > > On 08/29/2012 08:27 AM, Joe Darcy wrote: >> Hello, >> >> On 8/29/2012 1:48 AM, R?mi Forax wrote: >>> On 08/29/2012 08:33 AM, Kurchi Subhra Hazra wrote: >>>> Thanks for cleaning up those spaces Dan. The changes look fine. >>>> Sorry for the extra trouble! >>>> >>>> - Kurchi >>>> >>>> On 8/28/12 10:22 PM, Dan Xu wrote: >>>>> It is funny. :) I have searched all source codes under jdk and >>>>> removed spaces for the similar cases. >>>>> >>>>> Please review the new version of change at, >>>>> http://cr.openjdk.java.net/~dxu/7193406/webrev.03/. >>>>> >>>>> Thanks for your comment! >>>>> >>>>> -Dan >>> >>> Hi Dan, >>> >>> In PreHashedMap, the code should be >>> >>> Map.Entry that = (Map.Entry)ob; >>> >>> so the @SuppressWarnings is not needed anymore. >>> >>> And in java.util.Arrays, asList() should not be annotated with >>> @SuppressWarnings because it is already annotated with SafeVarargs, >>> so the compiler should not report the varargs warning. >>> >>> I have CC to compiler-dev to be sure that this is a compiler error. >>> >>> cheers, >>> R?mi >>> >> >> I've spoken to Stuart about this last point. The @SafeVarargs covers >> uses of Array.asList and covers the declaration of the asList method >> itself. However, it does not cover calls to the constructor inside >> the asList method, a constructor which itself is *not* @SafeVarargs. >> Solutions include >> >> * @SuppressWarnings("varargs") on the asList method >> * @SuppressWarnings("varargs") on new temporary variable for that >> purpose (with possible class file size consequences) >> * @SafeVarargs on the ArrayList constructor >> >> Regards, >> >> -Joe > The first change to the PreHashedMap is right, and I will update my fix. > > For the second comment, as Joe mentioned, it is necessary. Otherwise, > the compiler will give the following warnings. > > ../../../src/share/classes/java/util/Arrays.java:2837: warning: > [varargs] Varargs method could cause heap pollution from > non-reifiable varargs parameter a > return new ArrayList<>(a); > ^ > ../../../src/share/classes/java/util/Arrays.java:2837: warning: > [varargs] Varargs method could cause heap pollution from > non-reifiable varargs parameter a > return new ArrayList<>(a); > > ^ > > The first and second options works fine. But if I follow the third > option to add @SafeVarargs on the ArrayList constructor, I get the > following error. > > ../../../src/share/classes/java/util/Arrays.java:2849: error: > Invalid SafeVarargs annotation. Method ArrayList(E[]) is not a > varargs method. > ArrayList(E[] array) { > ^ > where E is a type-variable: > E extends Object declared in class ArrayList > > > So I tried further to change the constructor to a varargs method and > add the @SafeVarargs annotation, but the compiler still gives me > warnings like this, > > ../../../src/share/classes/java/util/Arrays.java:2837: warning: > [varargs] Varargs method could cause heap pollution from > non-reifiable varargs parameter a > return new ArrayList<>(a); > ^ > ../../../src/share/classes/java/util/Arrays.java:2837: warning: > [varargs] Varargs method could cause heap pollution from > non-reifiable varargs parameter a > return new ArrayList<>(a); > ^ > ../../../src/share/classes/java/util/Arrays.java:2852: warning: > [varargs] Varargs method could cause heap pollution from > non-reifiable varargs parameter array > a = array; > ^ > 3 warnings > > > > I think the current change is good for this one. Thanks for your > comments. > > -Dan > > > @Joe, So the question is whenever @SafeVarargs change the status of the variable 'a' to consider it as a safe use of a varargs. Given the fact that the user annotate the method with @SafeVarargs, the interpretation is that @SafeVarargs is only something for methods that call asList() but it has no effect on the body of the method asList(). That make sense. cheers, R?mi From forax at univ-mlv.fr Thu Aug 30 12:06:56 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Thu, 30 Aug 2012 14:06:56 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503EA818.4000602@oracle.com> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> <503D6105.6000708@oracle.com> <503D630C.2060601@oracle.com> <503DA700.5050207@oracle.com> <503DB7CE.9060001@oracle.com> <503DD772.6010201@univ-mlv.fr> <503E34D9.4060309@oracle.com> <503E6945.9020206@oracle.com> <503EA818.4000602@oracle.com> Message-ID: <503F5760.6080307@univ-mlv.fr> On 08/30/2012 01:39 AM, Dan Xu wrote: > > On 08/29/2012 12:11 PM, Dan Xu wrote: >> >> On 08/29/2012 08:27 AM, Joe Darcy wrote: >>> Hello, >>> >>> On 8/29/2012 1:48 AM, R?mi Forax wrote: >>>> On 08/29/2012 08:33 AM, Kurchi Subhra Hazra wrote: >>>>> Thanks for cleaning up those spaces Dan. The changes look fine. >>>>> Sorry for the extra trouble! >>>>> >>>>> - Kurchi >>>>> >>>>> On 8/28/12 10:22 PM, Dan Xu wrote: >>>>>> It is funny. :) I have searched all source codes under jdk and >>>>>> removed spaces for the similar cases. >>>>>> >>>>>> Please review the new version of change at, >>>>>> http://cr.openjdk.java.net/~dxu/7193406/webrev.03/. >>>>>> >>>>>> Thanks for your comment! >>>>>> >>>>>> -Dan >>>> >>>> Hi Dan, >>>> >>>> In PreHashedMap, the code should be >>>> >>>> Map.Entry that = (Map.Entry)ob; >>>> >>>> so the @SuppressWarnings is not needed anymore. >>>> >>>> And in java.util.Arrays, asList() should not be annotated with >>>> @SuppressWarnings because it is already annotated with SafeVarargs, >>>> so the compiler should not report the varargs warning. >>>> >>>> I have CC to compiler-dev to be sure that this is a compiler error. >>>> >>>> cheers, >>>> R?mi >>>> >>> >>> I've spoken to Stuart about this last point. The @SafeVarargs >>> covers uses of Array.asList and covers the declaration of the asList >>> method itself. However, it does not cover calls to the constructor >>> inside the asList method, a constructor which itself is *not* >>> @SafeVarargs. Solutions include >>> >>> * @SuppressWarnings("varargs") on the asList method >>> * @SuppressWarnings("varargs") on new temporary variable for that >>> purpose (with possible class file size consequences) >>> * @SafeVarargs on the ArrayList constructor >>> >>> Regards, >>> >>> -Joe >> The first change to the PreHashedMap is right, and I will update my fix. >> >> For the second comment, as Joe mentioned, it is necessary. Otherwise, >> the compiler will give the following warnings. >> >> ../../../src/share/classes/java/util/Arrays.java:2837: warning: >> [varargs] Varargs method could cause heap pollution from >> non-reifiable varargs parameter a >> return new ArrayList<>(a); >> ^ >> ../../../src/share/classes/java/util/Arrays.java:2837: warning: >> [varargs] Varargs method could cause heap pollution from >> non-reifiable varargs parameter a >> return new ArrayList<>(a); >> >> ^ >> >> The first and second options works fine. But if I follow the third >> option to add @SafeVarargs on the ArrayList constructor, I get the >> following error. >> >> ../../../src/share/classes/java/util/Arrays.java:2849: error: >> Invalid SafeVarargs annotation. Method ArrayList(E[]) is not a >> varargs method. >> ArrayList(E[] array) { >> ^ >> where E is a type-variable: >> E extends Object declared in class ArrayList >> >> >> So I tried further to change the constructor to a varargs method and >> add the @SafeVarargs annotation, but the compiler still gives me >> warnings like this, >> >> ../../../src/share/classes/java/util/Arrays.java:2837: warning: >> [varargs] Varargs method could cause heap pollution from >> non-reifiable varargs parameter a >> return new ArrayList<>(a); >> ^ >> ../../../src/share/classes/java/util/Arrays.java:2837: warning: >> [varargs] Varargs method could cause heap pollution from >> non-reifiable varargs parameter a >> return new ArrayList<>(a); >> ^ >> ../../../src/share/classes/java/util/Arrays.java:2852: warning: >> [varargs] Varargs method could cause heap pollution from >> non-reifiable varargs parameter array >> a = array; >> ^ >> 3 warnings >> >> >> >> I think the current change is good for this one. Thanks for your >> comments. >> >> -Dan >> >> >> > > I have updated my fix with above suggestions. Thanks for your > comments. The webrev is at > http://cr.openjdk.java.net/~dxu/7193406/webrev.04/. Thanks! > > -Dan Dan, I'm Ok with this new webrev, thumb up. R?mi From Ulf.Zibis at CoSoCo.de Thu Aug 30 12:33:53 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 30 Aug 2012 14:33:53 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503EA818.4000602@oracle.com> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> <503D6105.6000708@oracle.com> <503D630C.2060601@oracle.com> <503DA700.5050207@oracle.com> <503DB7CE.9060001@oracle.com> <503DD772.6010201@univ-mlv.fr> <503E34D9.4060309@oracle.com> <503E6945.9020206@oracle.com> <503EA818.4000602@oracle.com> Message-ID: <503F5DB1.8070708@CoSoCo.de> Am 30.08.2012 01:39, schrieb Dan Xu: > > I have updated my fix with above suggestions. Thanks for your comments. The webrev is at > http://cr.openjdk.java.net/~dxu/7193406/webrev.04/. Thanks! > > -Dan - * @param action the action string. + * @param actions the action string. I think you would better rename the variable to action, as it never contains more than one action. -Ulf From Ulf.Zibis at CoSoCo.de Thu Aug 30 12:51:15 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 30 Aug 2012 14:51:15 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503F5DB1.8070708@CoSoCo.de> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> <503D6105.6000708@oracle.com> <503D630C.2060601@oracle.com> <503DA700.5050207@oracle.com> <503DB7CE.9060001@oracle.com> <503DD772.6010201@univ-mlv.fr> <503E34D9.4060309@oracle.com> <503E6945.9020206@oracle.com> <503EA818.4000602@oracle.com> <503F5DB1.8070708@CoSoCo.de> Message-ID: <503F61C3.4090303@CoSoCo.de> Oops, sorry about the noise. I was wrong :-( -Ulf Am 30.08.2012 14:33, schrieb Ulf Zibis: > Am 30.08.2012 01:39, schrieb Dan Xu: >> >> I have updated my fix with above suggestions. Thanks for your comments. The webrev is at >> http://cr.openjdk.java.net/~dxu/7193406/webrev.04/. Thanks! >> >> -Dan > > - * @param action the action string. > + * @param actions the action string. > > I think you would better rename the variable to action, as it never contains more than one action. > > -Ulf > > From Ulf.Zibis at CoSoCo.de Thu Aug 30 13:23:23 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 30 Aug 2012 15:23:23 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503E9FB7.9070203@oracle.com> References: <1752716260.10040789.1345767163342.JavaMail.root@redhat.com> <503DF3DA.1040106@CoSoCo.de> <503E9FB7.9070203@oracle.com> Message-ID: <503F694B.8030209@CoSoCo.de> Am 30.08.2012 01:03, schrieb Stuart Marks: > On 8/29/12 3:50 AM, Ulf Zibis wrote: >>>> In FilePermission.java file, I make one change to its method >>>> signature, >>>> >>>> public Enumeration elements() ==> public Enumeration >>>> elements() >>>> >> Actually the whole method is synchronized. To make this more clear, I suggest: >> 798 public synchronized Enumeration elements() { >> 799 // Convert Iterator into Enumeration >> 800 return Collections.enumeration(perms); >> 801 } > > Hi Ulf, > > You're making some reasonable suggestions for general code cleanup. However, this is not general > code cleanup. Several issues have already been raised that are directly relevant to the warnings > fixes. I'd like to get these resolved, to get Dan's fix integrated, and to keep Dan focused on > further warnings cleanup, without getting bogged down in other code cleanup issues. As there were cleanups in javadoc, I thought, some small ones could be included too, at least the synchronized stuff, as this line was already touched.. OK, thanks for your feedback. -Ulf From Ulf.Zibis at CoSoCo.de Thu Aug 30 14:03:42 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 30 Aug 2012 16:03:42 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503F06E0.4020906@oracle.com> References: <5036A4C4.5040709@oracle.com> <5036DEA5.1020100@oracle.com> <5037D0D8.3030307@oracle.com> <503DFEA3.70900@CoSoCo.de> <503EA3A3.6010402@oracle.com> <503EAC3E.9010000@oracle.com> <503ECAD7.1020707@oracle.com> <503F06E0.4020906@oracle.com> Message-ID: <503F72BE.4000101@CoSoCo.de> Am 30.08.2012 08:23, schrieb Joe Darcy: > On 8/29/2012 7:07 PM, Stuart Marks wrote: >> On 8/29/12 4:56 PM, Joe Darcy wrote: >>> On 8/29/2012 4:20 PM, Stuart Marks wrote: >>>> The various SecurityConstants being used here are Strings. >>>> >>>> Note that this is doing String comparisons using == which is usually a bug. >>>> But this code is relying on String interning to provide object identity for >>>> equal string literals, in order to provide a fast path optimization for these >>>> common cases. Oops, didn't notice that the code is a fastpath in advance. >>>> Changing this code to use switch-over-strings would be >>>> semantically equivalent, but it would probably slow things down, since switch >>>> provides equals() semantics instead of == semantics. For that reason in project coin I always voted for == semantics as default for switch-on-strings and optionally using case .equals("foo") : syntax for equals() semantics. But anyway, equals() always first checks ==, and in fail switch-on-strings compares the hashes in 2nd step, so performance should not matter such heavy, compared to the processing which follows, and additionally the following code must not slowly process the, I guess also frequent, case of normal equality. Anyway the following code could be faster, if first upper-casing the the actions string instead comparing each char against upper AND lower case. A // FIXME tag would be nice for that, to not forget the possible tuning in future. > I recommend explicitly mentioning interning "Using identity comparison against known-interned > strings for performance benefit." I would additionally prefix with: "First using ..." or "Fastpath, using ..." -Ulf From Ulf.Zibis at CoSoCo.de Thu Aug 30 14:14:27 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 30 Aug 2012 16:14:27 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503EA3A3.6010402@oracle.com> References: <5036A4C4.5040709@oracle.com> <5036DEA5.1020100@oracle.com> <5037D0D8.3030307@oracle.com> <503DFEA3.70900@CoSoCo.de> <503EA3A3.6010402@oracle.com> Message-ID: <503F7543.6070409@CoSoCo.de> Am 30.08.2012 01:20, schrieb Stuart Marks: > On 8/29/12 4:36 AM, Ulf Zibis wrote: >>> @SuppressWarnings("fallthrough") is put to suppress warnings generated by >>> another switch/case statements >> Can't you move it from method scope to there? >> >>> while (i >= matchlen && !seencomma) { >>> switch(a[i-matchlen]) { >>> case ',': >>> seencomma = true; >>> /*FALLTHROUGH*/ >>> case ' ': case '\r': case '\n': >>> case '\f': case '\t': >>> break; >>> default: >>> throw new IllegalArgumentException( >>> "invalid permission: " + actions); >>> } >>> i--; >>> } > > Unfortunately there is no suitable place to put the annotation. Annotations can only be placed on > declarations, and the narrowest enclosing declaration around this switch statement is, > unfortunately, the entire method. One might consider refactoring the switch statement into its own > method, but that kind of refactoring is too large a change for warnings cleanup. I can see that it is reasonable/possible to bind a @SuppressWarnings("unchecked") to a declaration which contains the unchecked assignment, but which declaration should contain a fallthrough case? So shouldn't @SuppressWarnings("fallthrough") better be binded to a switch or case statement? -Ulf From Alan.Bateman at oracle.com Thu Aug 30 14:56:09 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Aug 2012 15:56:09 +0100 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <503EA0DD.60705@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <1F4403CF-F8AD-4FA9-BBCB-E373B5329A2D@oracle.com> <503C58B1.6080502@oracle.com> <503D03EF.1080804@oracle.com> <503EA0DD.60705@oracle.com> Message-ID: <503F7F09.7000105@oracle.com> On 30/08/2012 00:08, Joe Wang wrote: > I actually updated the webrev yesterday with your suggestion. Can you send a link? I checked the original location [1] but it's doesn't seem to have updated since Monday evening. -Alan [1] http://cr.openjdk.java.net/~joehw/jdk8/7169894/ From joe.darcy at oracle.com Thu Aug 30 15:28:15 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 30 Aug 2012 08:28:15 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503F572C.4030105@univ-mlv.fr> References: <5036A4C4.5040709@oracle.com> <503754A9.7010708@univ-mlv.fr> <50375B39.9080805@cs.oswego.edu> <50377B5F.4050803@cs.oswego.edu> <503B5237.8000806@cs.oswego.edu> <503C03C5.8010907@oracle.com> <503D5ACF.3050903@oracle.com> <503D5D6E.50000@oracle.com> <503D6105.6000708@oracle.com> <503D630C.2060601@oracle.com> <503DA700.5050207@oracle.com> <503DB7CE.9060001@oracle.com> <503DD772.6010201@univ-mlv.fr> <503E34D9.4060309@oracle.com> <503E6945.9020206@oracle.com> <503F572C.4030105@univ-mlv.fr> Message-ID: <503F868F.9050005@oracle.com> Hi Remi, On 8/30/2012 5:06 AM, R?mi Forax wrote: > On 08/29/2012 09:11 PM, Dan Xu wrote: >> >> On 08/29/2012 08:27 AM, Joe Darcy wrote: >>> Hello, >>> >>> On 8/29/2012 1:48 AM, R?mi Forax wrote: >>>> On 08/29/2012 08:33 AM, Kurchi Subhra Hazra wrote: >>>>> Thanks for cleaning up those spaces Dan. The changes look fine. >>>>> Sorry for the extra trouble! >>>>> >>>>> - Kurchi >>>>> >>>>> On 8/28/12 10:22 PM, Dan Xu wrote: >>>>> [snip] > > @Joe, > So the question is whenever @SafeVarargs change the status of the > variable 'a' > to consider it as a safe use of a varargs. > Given the fact that the user annotate the method with @SafeVarargs, > the interpretation is that @SafeVarargs is only something for methods > that call asList() > but it has no effect on the body of the method asList(). > > That make sense. The specification for the @SafeVarargs annotation types says: http://docs.oracle.com/javase/7/docs/api/java/lang/SafeVarargs.html > > Compilers are encouraged to issue warnings when this annotation type > is applied to a method or constructor declaration where: > > * The variable arity parameter has a reifiable element type, which > includes primitive types, Object, and String. (The unchecked warnings > this annotation type suppresses already do not occur for a reifiable > element type.) > * The body of the method or constructor declaration performs > potentially unsafe operations, such as an assignment to an element of > the variable arity parameter's array that generates an unchecked > warning. Some unsafe operations do not trigger an unchecked warning. > [...] > Future versions of the platform may mandate compiler errors for such > unsafe operations. So currently the SafeVarargs annotation on a method is treated as an assertion, but compilers are allowed to (and encouraged to) "trust, but verify" that the assertion is correct. We didn't have enough time to specify and implement a sufficiently powerful analysis that would have allowed all the safe varargs methods we wanted to see. The Arrays.asList method is anomalous in how it works for a SafeVarargs methods since it intentionally uses aliasing. -Joe From paul.sandoz at oracle.com Thu Aug 30 15:47:16 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 30 Aug 2012 17:47:16 +0200 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <503F0F4C.4010509@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <503B73DA.4060807@oracle.com> <503C4FA2.5050001@oracle.com> <503DEE97.7020000@oracle.com> <503F0F4C.4010509@oracle.com> Message-ID: <81472643-22A5-4A29-A410-00E04D7F04CD@oracle.com> On Aug 30, 2012, at 8:59 AM, Joe Wang wrote: > Alan, Paul, > > While I was writing a summery as you suggested below, I noticed an issue with using ServiceLoader. I was trying to use the word 'delegate' but found the ServiceLoader might be doing sth. different than the original jaxp process. > > Here's the spec: > The ServiceLoader.load(service) is equivalent to ServiceLoader.load(service, Thread.currentThread().getContextClassLoader()) where "loader - The class loader to be used to load provider-configuration files and provider classes, or null if the system class loader (or, failing that, the bootstrap class loader) is to be used " > > > Somehow, our earlier discussion concluded that the original process I created, where the context class loader is tried first, if no provider found, bootstrap classloader will be tried next, could be 'delegated' to the ServiceLoader. But the above didn't really showed that. When I looked at the code, it actually simply returns false if loader.getResources fails to find a provider. The CL.getResources will also delegate to the parent CL if one is present which should eventually get to the bootstrap CL. > Also, it calls ClassLoader.getSystemResources when loader=null. The later would be a regression to CR6723276 if we had called ServiceLoader.load(service, loader) with loader=null. > Seems as OK as i said in the previous email, since Object.class.getResourceAsStream does: public InputStream getResourceAsStream(String name) { name = resolveName(name); ClassLoader cl = getClassLoader0(); // <--- This will be null for Object.class if (cl==null) { // A system class. return ClassLoader.getSystemResourceAsStream(name); // <--- Look! } return cl.getResourceAsStream(name); } This area is complicated i think you need to write some SL tests. Paul. From stuart.marks at oracle.com Thu Aug 30 16:31:07 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 30 Aug 2012 09:31:07 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503F21AD.8000108@redhat.com> References: <1678589493.12653541.1346255298109.JavaMail.root@redhat.com> <503E9D4E.10002@oracle.com> <503F21AD.8000108@redhat.com> Message-ID: <503F954B.7090408@oracle.com> On 8/30/12 1:17 AM, Andrew Haley wrote: > On 08/29/2012 11:53 PM, Stuart Marks wrote: >> On 8/29/12 8:48 AM, Andrew Hughes wrote: >>> But presumably [-Werror] would be removed when everything is warning free? >>> -Werror should not be the default for everyone building OpenJDK, who then >>> end up having to fix or workaround issues which are nothing to do with them. >>> It's easy enough for those who want to check we don't regress to turn on >>> -Werror throughout, once everything is warning free. >> >> Once everything is warning free, -Werror *should* be enabled by default. That's >> how we'll keep everything warning free. >> >> If everything were warning free, I don't see how people could be blocked by >> warnings that are unrelated to their current changes. This does happen today >> with implicit compilation, but it shouldn't happen in the bright shining future >> where there are no warnings. :-) > > -Werror is probably OK for Java code, but not for HotSpot. > > We GCC developers keep adding new warnings, so poor souls who keep > up-to-date with new Fedora (and other leading-edge) distributions tend > to be the first to discover problems. Thus is very awkward for people > who don't understand advanced C++ features. Yes, absolutely, I had intended this to be about Java warnings only, not about GCC warnings. More precisely, this discussion is about potentially setting JAVAC_WARNINGS_FATAL=true in the makefiles, which obviously applies only to Java code. (And to be absolutely clear, Dan's warnings fix will not change any makefile warnings settings. The setting of JAVAC_WARNINGS_FATAL=true may occur in some hypothetical future changeset.) Sorry for the confusion. s'marks From lance.andersen at oracle.com Thu Aug 30 17:38:39 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Thu, 30 Aug 2012 17:38:39 +0000 Subject: hg: jdk8/tl/jdk: 7193683: DriverManager Iterator Warning cleanup Message-ID: <20120830173900.5451A477FC@hg.openjdk.java.net> Changeset: 11bfec75d333 Author: lancea Date: 2012-08-30 13:38 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11bfec75d333 7193683: DriverManager Iterator Warning cleanup Reviewed-by: lancea Contributed-by: Dan Xu ! src/share/classes/java/sql/DriverManager.java From huizhe.wang at oracle.com Thu Aug 30 18:38:08 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 30 Aug 2012 11:38:08 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <81472643-22A5-4A29-A410-00E04D7F04CD@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <503B73DA.4060807@oracle.com> <503C4FA2.5050001@oracle.com> <503DEE97.7020000@oracle.com> <503F0F4C.4010509@oracle.com> <81472643-22A5-4A29-A410-00E04D7F04CD@oracle.com> Message-ID: <503FB310.50502@oracle.com> Hi Paul, Alan, I've read your latest comments. Before getting back to you on those items, I felt it's important we get the classloader handling correctly. If it's as what I suspected (as I described in the last email), we may have problem with using ServiceLoader. I've read Paul's explanation, esp. the delegation to ClassLoader.getSystemResourceAsStream part. It looks right as it's stated in the spec. But I do remember it was the issue for CR6723276 and I did change it to Object.class.getResourceAsStream (without a way to call bootstrap classloader). Just as Paul said, the classloader stuff is quite tricky. I had three dummy jars that I've been running tests with. I haven't had problems loading those jars. But the tests were under 'normal' conditions, that is, the usual jdk classloader hierarchy was followed. Also, dummy jars may work. But I should at least test Xerces. So that's what I'm going to do as well. --Joe On 8/30/2012 8:47 AM, Paul Sandoz wrote: > On Aug 30, 2012, at 8:59 AM, Joe Wang wrote: > >> Alan, Paul, >> >> While I was writing a summery as you suggested below, I noticed an issue with using ServiceLoader. I was trying to use the word 'delegate' but found the ServiceLoader might be doing sth. different than the original jaxp process. >> >> Here's the spec: >> The ServiceLoader.load(service) is equivalent to ServiceLoader.load(service, Thread.currentThread().getContextClassLoader()) where "loader - The class loader to be used to load provider-configuration files and provider classes, or null if the system class loader (or, failing that, the bootstrap class loader) is to be used " >> >> >> Somehow, our earlier discussion concluded that the original process I created, where the context class loader is tried first, if no provider found, bootstrap classloader will be tried next, could be 'delegated' to the ServiceLoader. But the above didn't really showed that. When I looked at the code, it actually simply returns false if loader.getResources fails to find a provider. > The CL.getResources will also delegate to the parent CL if one is present which should eventually get to the bootstrap CL. > > >> Also, it calls ClassLoader.getSystemResources when loader=null. The later would be a regression to CR6723276 if we had called ServiceLoader.load(service, loader) with loader=null. >> > > Seems as OK as i said in the previous email, since Object.class.getResourceAsStream does: > > public InputStream getResourceAsStream(String name) { > name = resolveName(name); > ClassLoader cl = getClassLoader0(); //<--- This will be null for Object.class > if (cl==null) { > // A system class. > return ClassLoader.getSystemResourceAsStream(name); //<--- Look! > } > return cl.getResourceAsStream(name); > } > > This area is complicated i think you need to write some SL tests. > > Paul. From Alan.Bateman at oracle.com Thu Aug 30 21:20:39 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 Aug 2012 22:20:39 +0100 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <503FB310.50502@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <503B73DA.4060807@oracle.com> <503C4FA2.5050001@oracle.com> <503DEE97.7020000@oracle.com> <503F0F4C.4010509@oracle.com> <81472643-22A5-4A29-A410-00E04D7F04CD@oracle.com> <503FB310.50502@oracle.com> Message-ID: <503FD927.1090603@oracle.com> On 30/08/2012 19:38, Joe Wang wrote: > Hi Paul, Alan, > > I've read your latest comments. Before getting back to you on those > items, I felt it's important we get the classloader handling > correctly. If it's as what I suspected (as I described in the last > email), we may have problem with using ServiceLoader. > > I've read Paul's explanation, esp. the delegation to > ClassLoader.getSystemResourceAsStream part. It looks right as it's > stated in the spec. But I do remember it was the issue for CR6723276 > and I did change it to Object.class.getResourceAsStream (without a way > to call bootstrap classloader). > > Just as Paul said, the classloader stuff is quite tricky. I had three > dummy jars that I've been running tests with. I haven't had problems > loading those jars. But the tests were under 'normal' conditions, > that is, the usual jdk classloader hierarchy was followed. > > Also, dummy jars may work. But I should at least test Xerces. So > that's what I'm going to do as well. > > --Joe I don't think I'm following the concern here as I thought the SecuritySupport will either give you the TCCL or the system class loader (but never null). As I quick check I created a no-op SchemaFactory, packaged it up with META-INF/services/javax.xml.validation.SchemaFactory into a JAR and verified that it was located when I deploy it on either the class path or extensions directory. In this case, the thread invoking SchemaFactory.newInstance had its TCCL set to the system class loader (the default). Same thing if I change the TCCL to null because SecuritySupport gives the Finder the system class loader for that case. Paul - slap me in the face if I have this wrong, I don't want to cause any confusion on this, I really just want to see a current vs. proposed behavior for each of the finders. -Alan. From sean.mullan at oracle.com Thu Aug 30 21:47:52 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 30 Aug 2012 21:47:52 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120830214825.E8E1E47802@hg.openjdk.java.net> Changeset: 0a2565113920 Author: mullan Date: 2012-08-30 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a2565113920 6995421: Eliminate the static dependency to sun.security.ec.ECKeyFactory Reviewed-by: mullan, vinnie Contributed-by: stephen.flores at oracle.com ! make/sun/security/ec/Makefile ! make/sun/security/other/Makefile ! src/share/classes/sun/security/ec/ECKeyFactory.java ! src/share/classes/sun/security/ec/ECParameters.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/ec/ReadPKCS12.java ! test/sun/security/pkcs11/ec/TestECDH.java ! test/sun/security/pkcs11/ec/TestECDSA.java Changeset: 47f8ba39265c Author: mullan Date: 2012-08-30 14:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/47f8ba39265c Merge From lana.steuck at oracle.com Fri Aug 31 00:01:05 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 31 Aug 2012 00:01:05 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20120831000154.815484780D@hg.openjdk.java.net> Changeset: baf30df50ce3 Author: andrew Date: 2012-08-23 15:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/baf30df50ce3 7192804: Build should not install jvisualvm man page for OpenJDK Summary: OpenJDK builds don't ship VisualVM so shouldn't ship its man page either. Reviewed-by: dholmes ! make/common/Release.gmk ! makefiles/Images.gmk Changeset: 70ad0ed1d6ce Author: katleman Date: 2012-08-29 15:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70ad0ed1d6ce Merge Changeset: 334b6f0c547f Author: lana Date: 2012-08-30 16:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/334b6f0c547f Merge From lana.steuck at oracle.com Fri Aug 31 00:01:08 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Fri, 31 Aug 2012 00:01:08 +0000 Subject: hg: jdk8/tl/hotspot: 31 new changesets Message-ID: <20120831000218.EFDD04780E@hg.openjdk.java.net> Changeset: 6898d85cf0bb Author: amurillo Date: 2012-08-10 23:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6898d85cf0bb 7190772: new hotspot build - hs24-b21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d5ec46c7da5c Author: amurillo Date: 2012-08-15 16:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d5ec46c7da5c 7191765: make jdk8 the default jprt release for hs24 Reviewed-by: jcoomes ! make/jprt.properties Changeset: aaf61e68b255 Author: johnc Date: 2012-08-06 12:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aaf61e68b255 6818524: G1: use ergonomic resizing of PLABs Summary: Employ PLABStats instances to record information about survivor and old PLABs, and use the recorded stats to adjust the sizes of survivor and old PLABS. Reviewed-by: johnc, ysr Contributed-by: Brandon Mitchell ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp + src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/precompiled/precompiled.hpp Changeset: eff5d59db7e1 Author: amurillo Date: 2012-08-07 09:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eff5d59db7e1 7189729: jprt.properties should include release jdk7u8 Reviewed-by: jcoomes ! make/jprt.properties Changeset: 3958f0acde31 Author: amurillo Date: 2012-08-17 15:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3958f0acde31 Merge ! make/jprt.properties - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: 6acee021f5ac Author: coleenp Date: 2012-08-01 16:52 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6acee021f5ac 7129723: MAC: Some regression tests need to recognize Mac OS X platform Summary: Add Darwin like Linux to shell scripts Reviewed-by: kvn, kamg, dholmes ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7110720/Test7110720.sh ! test/runtime/7158800/Test7158800.sh ! test/runtime/7158988/TestFieldMonitor.sh Changeset: 4acebbe310e1 Author: zgu Date: 2012-08-01 17:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4acebbe310e1 7185614: NMT ON: "check by caller" assertion failed on nsk ThreadMXBean test 7187429: NMT ON: Merge failure should cause NMT to shutdown Summary: Fixed NMT assertion failures Reviewed-by: acorn, kvn ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTracker.hpp Changeset: b27675afea11 Author: zgu Date: 2012-08-01 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b27675afea11 Merge Changeset: 8e69438de9c6 Author: zgu Date: 2012-08-01 16:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8e69438de9c6 Merge Changeset: 282abd0fd878 Author: dcubed Date: 2012-08-02 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/282abd0fd878 7188168: 7071904 broke the DEBUG_BINARIES option on Linux Summary: Change DEBUG_BINARIES option logic to be more clear. Reviewed-by: fparain, andrew ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make Changeset: 0d8e265ba727 Author: dcubed Date: 2012-08-03 18:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0d8e265ba727 7181175: Enable builds on Windows with MinGW/MSYS Summary: This fix is the minimum number of Makefile changes to enable building HotSpot with MinGW/MSYS Reviewed-by: jcoomes, dcubed, tbell, ohair Contributed-by: volker.simonis at gmail.com ! make/windows/makefiles/defs.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/shared.make Changeset: c3c2141203e7 Author: dcubed Date: 2012-08-06 09:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c3c2141203e7 Merge Changeset: 4ee06e614636 Author: kamg Date: 2012-08-06 15:54 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4ee06e614636 7116786: RFE: Detailed information on VerifyErrors Summary: Provide additional detail in VerifyError messages Reviewed-by: sspitsyn, acorn ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/stackMapTableFormat.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/relocator.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + test/runtime/7116786/Test7116786.java + test/runtime/7116786/testcases.jar Changeset: 98625323d3a3 Author: tbell Date: 2012-08-10 23:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/98625323d3a3 7190512: Fix for 7181175 broke hotspot/make/windows/create.bat builds Summary: Add some quotes around the classpath in the project file rule. Reviewed-by: dcubed ! make/windows/projectfiles/common/Makefile Changeset: e5bf1c79ed5b Author: zgu Date: 2012-08-14 13:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e5bf1c79ed5b 7191124: Optimized build is broken due to inconsistent use of DEBUG_ONLY and NOT_PRODUCT macros in NMT Summary: Updated all related variables and methods to use NOT_PRODUCT macros Reviewed-by: coleenp, acorn, kvn ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memPtrArray.hpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memTracker.cpp Changeset: fce6d7280776 Author: dcubed Date: 2012-08-17 11:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fce6d7280776 Merge ! src/share/vm/classfile/verifier.cpp ! src/share/vm/runtime/globals.hpp Changeset: b63c0564035a Author: dcubed Date: 2012-08-21 19:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b63c0564035a Merge Changeset: f99a36499b8c Author: johnc Date: 2012-08-21 10:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f99a36499b8c 7192128: G1: Extend fix for 6948537 to G1's BOT Summary: G1 does not appear to be immune to the issue described in CR 6948537 and increasing the size of old-generation PLABs appears to increase the liklihood of seeing the issue. Extend the fix for 6948537 to G1's BlockOffsetTable. Reviewed-by: brutisso, jmasa ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 7383557659bd Author: johnc Date: 2012-08-21 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7383557659bd 7185699: G1: Prediction model discrepancies Summary: Correct the result value of G1CollectedHeap::pending_card_num(). Change the code that calculates the GC efficiency of a non-young heap region to use historical data from mixed GCs and the actual number of live bytes when predicting how long it would take to collect the region. Changes were also reviewed by Thomas Schatzl. Reviewed-by: azeemj, brutisso ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1ErgoVerbose.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp Changeset: 3650da95d2ee Author: brutisso Date: 2012-08-23 05:25 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3650da95d2ee 7193157: G1: Make some develpflags available in product builds Summary: Also reviewed by: vitalyd at gmail.com. Make G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, G1OldCSetRegionLiveThresholdPercent and G1OldCSetRegionThresholdPercent experimental flags Reviewed-by: ysr, johnc, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ce0254b13eb8 Author: brutisso Date: 2012-08-24 09:45 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce0254b13eb8 Merge Changeset: 006050192a5a Author: kvn Date: 2012-08-20 09:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/006050192a5a 6340864: Implement vectorization optimizations in hotspot-server Summary: Added asm encoding and mach nodes for vector arithmetic instructions on x86. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/6340864/TestByteVect.java + test/compiler/6340864/TestDoubleVect.java + test/compiler/6340864/TestFloatVect.java + test/compiler/6340864/TestIntVect.java + test/compiler/6340864/TestLongVect.java + test/compiler/6340864/TestShortVect.java Changeset: 09aad8452938 Author: kvn Date: 2012-08-20 09:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/09aad8452938 7190310: Inlining WeakReference.get(), and hoisting $referent may lead to non-terminating loops Summary: In C2 add software membar after load from Reference.referent field to prevent commoning of loads across safepoint since GC can change its value. In C1 always generate Reference.get() intrinsic. Reviewed-by: roland, twisti, dholmes, johnc ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/library_call.cpp + test/compiler/7190310/Test7190310.java + test/compiler/7190310/Test7190310_unsafe.java Changeset: 7a302948f5a4 Author: twisti Date: 2012-08-21 10:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7a302948f5a4 7192167: JSR 292: C1 has old broken code which needs to be removed Reviewed-by: kvn, roland, jrose ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/opto/callGenerator.cpp Changeset: 4b0d6fd74911 Author: kvn Date: 2012-08-21 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4b0d6fd74911 7192964: assert(false) failed: bad AD file Summary: Shifts with loop variant counts "a[i]=1<= 1) failed: illegal call to offset() Summary: C1 value numbering hits unloaded klass. Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_ValueMap.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: 5af51c882207 Author: kvn Date: 2012-08-22 11:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5af51c882207 7192963: assert(_in[req-1] == this) failed: Must pass arg count to 'new' Summary: Fixed Pack node generation. Not vectorize shift instructions if count is not the same for all shifts and if count is vector. Reviewed-by: twisti ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp + test/compiler/7192963/TestByteVect.java + test/compiler/7192963/TestDoubleVect.java + test/compiler/7192963/TestFloatVect.java + test/compiler/7192963/TestIntVect.java + test/compiler/7192963/TestLongVect.java + test/compiler/7192963/TestShortVect.java Changeset: f7cd53cedd78 Author: kvn Date: 2012-08-23 09:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f7cd53cedd78 7192965: assert(is_aligned_sets(size)) failed: mask is not aligned, adjacent sets Summary: Change pair check to vector check in RA bias coloring code. Reviewed-by: jrose, twisti ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/output.cpp Changeset: c32dee9b8023 Author: twisti Date: 2012-08-24 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c32dee9b8023 Merge Changeset: 9e3ae661284d Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9e3ae661284d Merge - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp Changeset: e8fb566b9466 Author: amurillo Date: 2012-08-24 15:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8fb566b9466 Added tag hs24-b21 for changeset 9e3ae661284d ! .hgtags From stuart.marks at oracle.com Fri Aug 31 01:45:50 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 30 Aug 2012 18:45:50 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503F7543.6070409@CoSoCo.de> References: <5036A4C4.5040709@oracle.com> <5036DEA5.1020100@oracle.com> <5037D0D8.3030307@oracle.com> <503DFEA3.70900@CoSoCo.de> <503EA3A3.6010402@oracle.com> <503F7543.6070409@CoSoCo.de> Message-ID: <5040174E.3000503@oracle.com> On 8/30/12 7:14 AM, Ulf Zibis wrote: > Am 30.08.2012 01:20, schrieb Stuart Marks: >> On 8/29/12 4:36 AM, Ulf Zibis wrote: >>>> @SuppressWarnings("fallthrough") is put to suppress warnings generated by >>>> another switch/case statements >>> Can't you move it from method scope to there? >>> >>>> while (i >= matchlen && !seencomma) { >>>> switch(a[i-matchlen]) { >>>> case ',': >>>> seencomma = true; >>>> /*FALLTHROUGH*/ >>>> case ' ': case '\r': case '\n': >>>> case '\f': case '\t': >>>> break; >>>> default: >>>> throw new IllegalArgumentException( >>>> "invalid permission: " + actions); >>>> } >>>> i--; >>>> } >> >> Unfortunately there is no suitable place to put the annotation. Annotations >> can only be placed on declarations, and the narrowest enclosing declaration >> around this switch statement is, unfortunately, the entire method. One might >> consider refactoring the switch statement into its own method, but that kind >> of refactoring is too large a change for warnings cleanup. > > I can see that it is reasonable/possible to bind a > @SuppressWarnings("unchecked") to a declaration which contains the unchecked > assignment, but which declaration should contain a fallthrough case? > > So shouldn't @SuppressWarnings("fallthrough") better be binded to a switch or > case statement? In principle it would be nice to place the @SuppressWarnings right next to the switch statement for which the warnings are suppressed. However, it is a syntactic restriction of the Java programming language that annotations can only be used as modifiers on declarations, specifically package, class, method, method parameter, constructor, and local variable declarations. See JLS 9.7 [1]. It is not legal to place annotations on statements. So, the SuppressWarnings annotation has to be placed on a declaration that encloses the switch statement in question. In this case that's the declaration of the entire method. [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.7 It turns out that this discussion is moot, as the switch fall-through is actually unnecessary! The comma case falls through to the next case, but all that does is break. The warning can be eliminated simply by replacing /*FALLTHROUGH*/ with a break statement. This removes the need for the SuppressWarnings annotation. This permissions-parsing code occurs in several places around the JDK, copied and slightly modified. Some of them use the string identity comparison optimization, and some have this switch fall through. (We've discussed this previously. See [2].) Accordingly, I've asked Dan to adjust a couple of these other cases to have the same comment about string identity comparisons, and to change the switch statement to avoid the fall-through entirely. [2] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000415.html While I'm reluctant to expand the scope of this changeset, I think it's important to keep these five occurrences consistent. Obviously it would be nicer to unify the five copies into one, but this is a much bigger change that I think is clearly out of scope. Dan will issue another webrev with these changes shortly. s'marks From stuart.marks at oracle.com Fri Aug 31 01:49:16 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 30 Aug 2012 18:49:16 -0700 Subject: RFR: 7195099 update problem list with RMI test failures In-Reply-To: <503F3120.80407@oracle.com> References: <503EC996.4060505@oracle.com> <503F3120.80407@oracle.com> Message-ID: <5040181C.4020005@oracle.com> On 8/30/12 2:23 AM, Alan Bateman wrote: > On 30/08/2012 03:01, Stuart Marks wrote: >> Hi Alan, >> >> I'm opening another front in the war against test failures. Please review >> these additions to the problem list. >> >> Thanks. >> >> s'marks > I see you've got bugs for each of these so looks okay to me. > > BTW: On EagerHttpFallback.java, I've seen that fail too but only on systems > where the host name resolves to the loopback address. That's the out of the box > configuration with most Linux distributions so the tests need to tolerant that > (even if RMI itself needs the host name resolving to the host address for it to > work between hosts). Thanks. Interesting point about the cases where this test fails when the hostname resolved to the loopback address. I'll add a note to the bug report. The other cases I've seen occur when the address of localhost is not 127.0.0.1, as the test has 127.0.0.1 hardcoded. On Ubuntu localhost is 127.0.1.1 and the test fails every time. s'marks From stuart.marks at oracle.com Fri Aug 31 01:53:29 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 31 Aug 2012 01:53:29 +0000 Subject: hg: jdk8/tl/jdk: 7195099: update problem list with RMI test failures Message-ID: <20120831015350.8702947819@hg.openjdk.java.net> Changeset: f9b11772c4b2 Author: smarks Date: 2012-08-30 18:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9b11772c4b2 7195099: update problem list with RMI test failures Reviewed-by: alanb ! test/ProblemList.txt From forax at univ-mlv.fr Fri Aug 31 07:20:15 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 31 Aug 2012 09:20:15 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <503F7543.6070409@CoSoCo.de> References: <5036A4C4.5040709@oracle.com> <5036DEA5.1020100@oracle.com> <5037D0D8.3030307@oracle.com> <503DFEA3.70900@CoSoCo.de> <503EA3A3.6010402@oracle.com> <503F7543.6070409@CoSoCo.de> Message-ID: <504065AF.2070103@univ-mlv.fr> On 08/30/2012 04:14 PM, Ulf Zibis wrote: > Am 30.08.2012 01:20, schrieb Stuart Marks: >> On 8/29/12 4:36 AM, Ulf Zibis wrote: >>>> @SuppressWarnings("fallthrough") is put to suppress warnings >>>> generated by >>>> another switch/case statements >>> Can't you move it from method scope to there? >>> >>>> while (i >= matchlen && !seencomma) { >>>> switch(a[i-matchlen]) { >>>> case ',': >>>> seencomma = true; >>>> /*FALLTHROUGH*/ >>>> case ' ': case '\r': case '\n': >>>> case '\f': case '\t': >>>> break; >>>> default: >>>> throw new IllegalArgumentException( >>>> "invalid permission: " + actions); >>>> } >>>> i--; >>>> } >> >> Unfortunately there is no suitable place to put the annotation. >> Annotations can only be placed on declarations, and the narrowest >> enclosing declaration around this switch statement is, unfortunately, >> the entire method. One might consider refactoring the switch >> statement into its own method, but that kind of refactoring is too >> large a change for warnings cleanup. > > I can see that it is reasonable/possible to bind a > @SuppressWarnings("unchecked") to a declaration which contains the > unchecked assignment, but which declaration should contain a > fallthrough case? > > So shouldn't @SuppressWarnings("fallthrough") better be binded to a > switch or case statement? > > -Ulf > You can't put an annotation on a statement and the last time I check JSR 308, (a long time ago), it was something that was put aside. R?mi From huizhe.wang at oracle.com Fri Aug 31 07:59:09 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 31 Aug 2012 00:59:09 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <503FD927.1090603@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <503B73DA.4060807@oracle.com> <503C4FA2.5050001@oracle.com> <503DEE97.7020000@oracle.com> <503F0F4C.4010509@oracle.com> <81472643-22A5-4A29-A410-00E04D7F04CD@oracle.com> <503FB310.50502@oracle.com> <503FD927.1090603@oracle.com> Message-ID: <50406ECD.8060302@oracle.com> On 8/30/2012 2:20 PM, Alan Bateman wrote: > On 30/08/2012 19:38, Joe Wang wrote: >> Hi Paul, Alan, >> >> I've read your latest comments. Before getting back to you on those >> items, I felt it's important we get the classloader handling >> correctly. If it's as what I suspected (as I described in the last >> email), we may have problem with using ServiceLoader. >> >> I've read Paul's explanation, esp. the delegation to >> ClassLoader.getSystemResourceAsStream part. It looks right as it's >> stated in the spec. But I do remember it was the issue for CR6723276 >> and I did change it to Object.class.getResourceAsStream (without a >> way to call bootstrap classloader). >> >> Just as Paul said, the classloader stuff is quite tricky. I had >> three dummy jars that I've been running tests with. I haven't had >> problems loading those jars. But the tests were under 'normal' >> conditions, that is, the usual jdk classloader hierarchy was followed. >> >> Also, dummy jars may work. But I should at least test Xerces. So >> that's what I'm going to do as well. >> >> --Joe > I don't think I'm following the concern here as I thought the > SecuritySupport will either give you the TCCL or the system class > loader (but never null). As I quick check I created a no-op > SchemaFactory, packaged it up with > META-INF/services/javax.xml.validation.SchemaFactory into a JAR and > verified that it was located when I deploy it on either the class path > or extensions directory. In this case, the thread invoking > SchemaFactory.newInstance had its TCCL set to the system class loader > (the default). Same thing if I change the TCCL to null because > SecuritySupport gives the Finder the system class loader for that case. Yes, it works just fine under normal conditions. Note the old process: read the service file using TCCL (if null, system cl), if nothing found, then BCL Somehow I was under the impression ServiceLoader does just that so that we could delegate to it. It's probably a good thing that it actually doesn't. If it did, it'd cause error in the following case: The TCCL's parent is BCL (that is Bootstrap), a jaxp impl (e.g. Xerces) is on the classpath Old process: try TCCL, not found, try BCL, not found ServiceLoader: use TCCL, not found, return null (I thought it'd continue using System CL, but it didn't) **although worked differently, the results are the same, so not an issue in terms of the result, still a behavior change though. I did many tests, but so far the results are the same before and after the patch. If TCCL is set to null, I actually saw SCE other than SchemaFactory, for example: javax.xml.stream.FactoryConfigurationError: javax.xml.stream.XMLEventFactory: Provider org.apache.xerces.stax.XMLEventFactoryImpl not found --Joe > > Paul - slap me in the face if I have this wrong, I don't want to cause > any confusion on this, I really just want to see a current vs. > proposed behavior for each of the finders. > > -Alan. From paul.sandoz at oracle.com Fri Aug 31 08:36:26 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 31 Aug 2012 10:36:26 +0200 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <503FD927.1090603@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <503B73DA.4060807@oracle.com> <503C4FA2.5050001@oracle.com> <503DEE97.7020000@oracle.com> <503F0F4C.4010509@oracle.com> <81472643-22A5-4A29-A410-00E04D7F04CD@oracle.com> <503FB310.50502@oracle.com> <503FD927.1090603@oracle.com> Message-ID: <4CAC9AAE-83F8-432D-A417-363C39ED552C@oracle.com> On Aug 30, 2012, at 11:20 PM, Alan Bateman wrote: > On 30/08/2012 19:38, Joe Wang wrote: >> Hi Paul, Alan, >> >> I've read your latest comments. Before getting back to you on those items, I felt it's important we get the classloader handling correctly. If it's as what I suspected (as I described in the last email), we may have problem with using ServiceLoader. >> >> I've read Paul's explanation, esp. the delegation to ClassLoader.getSystemResourceAsStream part. It looks right as it's stated in the spec. But I do remember it was the issue for CR6723276 and I did change it to Object.class.getResourceAsStream (without a way to call bootstrap classloader). >> >> Just as Paul said, the classloader stuff is quite tricky. I had three dummy jars that I've been running tests with. I haven't had problems loading those jars. But the tests were under 'normal' conditions, that is, the usual jdk classloader hierarchy was followed. >> >> Also, dummy jars may work. But I should at least test Xerces. So that's what I'm going to do as well. >> >> --Joe > I don't think I'm following the concern here as I thought the SecuritySupport will either give you the TCCL or the system class loader (but never null). As I quick check I created a no-op SchemaFactory, packaged it up with META-INF/services/javax.xml.validation.SchemaFactory into a JAR and verified that it was located when I deploy it on either the class path or extensions directory. In this case, the thread invoking SchemaFactory.newInstance had its TCCL set to the system class loader (the default). Same thing if I change the TCCL to null because SecuritySupport gives the Finder the system class loader for that case. > It seems the SecuritySupport variants have slightly different functionality. javax.xml.stream.SecuritySupport: ClassLoader getContextClassLoader() throws SecurityException{ return (ClassLoader) AccessController.doPrivileged(new PrivilegedAction() { public Object run() { ClassLoader cl = null; //try { cl = Thread.currentThread().getContextClassLoader(); //} catch (SecurityException ex) { } if (cl == null) cl = ClassLoader.getSystemClassLoader(); return cl; } }); } javax.xml.datatype.SecuritySupport: ClassLoader getContextClassLoader() { return (ClassLoader) AccessController.doPrivileged(new PrivilegedAction() { public Object run() { ClassLoader cl = null; try { cl = Thread.currentThread().getContextClassLoader(); } catch (SecurityException ex) { } return cl; } }); } I made an incorrect assumption that javax.xml.datatype.SecuritySupport was the same as all the others. > Paul - slap me in the face if I have this wrong, I don't want to cause any confusion on this, I really just want to see a current vs. proposed behavior for each of the finders. > I am getting bogged down in the weeds on this. This area is more inconsistent than i previously thought. I think we need tests and enumerate exactly the loading policy for each factory finder. Paul. From jonathan.gibbons at oracle.com Fri Aug 31 09:32:20 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 31 Aug 2012 09:32:20 +0000 Subject: hg: jdk8/tl/jdk: 7151010: Add compiler support for repeating annotations Message-ID: <20120831093502.8291647830@hg.openjdk.java.net> Changeset: bdfcc13ddeb4 Author: jfranck Date: 2012-08-31 10:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdfcc13ddeb4 7151010: Add compiler support for repeating annotations Reviewed-by: darcy, jjg + src/share/classes/java/lang/annotation/ContainerFor.java From jonathan.gibbons at oracle.com Fri Aug 31 09:38:54 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 31 Aug 2012 09:38:54 +0000 Subject: hg: jdk8/tl/langtools: 7151010: Add compiler support for repeating annotations Message-ID: <20120831093903.4FE7A47831@hg.openjdk.java.net> Changeset: 873ddd9f4900 Author: jfranck Date: 2012-08-31 10:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/873ddd9f4900 7151010: Add compiler support for repeating annotations Reviewed-by: jjg, mcimadamore + src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/sym/CreateSymbols.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java + test/tools/javac/annotations/repeatingAnnotations/BasicRepeatingAnnotations.java + test/tools/javac/annotations/repeatingAnnotations/CheckTargets.java + test/tools/javac/annotations/repeatingAnnotations/ContainerHasRepeatedContained.java + test/tools/javac/annotations/repeatingAnnotations/DelayRepeatedContainer.java + test/tools/javac/annotations/repeatingAnnotations/InvalidTarget.java + test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java + test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java + test/tools/javac/annotations/repeatingAnnotations/NestedContainers.java + test/tools/javac/annotations/repeatingAnnotations/RepMemberAnno.java + test/tools/javac/annotations/repeatingAnnotations/RepSelfMemberAnno.java + test/tools/javac/annotations/repeatingAnnotations/RepeatingAndContainerPresent.java + test/tools/javac/annotations/repeatingAnnotations/SelfRepeatingAnnotations.java + test/tools/javac/annotations/repeatingAnnotations/SingleRepeatingAndContainer.java + test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java + test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java + test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java + test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java + test/tools/javac/diags/examples/ContainedByInheritedMismatch.java + test/tools/javac/diags/examples/ContainedByNoValue.java + test/tools/javac/diags/examples/ContainedByNonDefault.java + test/tools/javac/diags/examples/ContainedByRetentionMismatch.java + test/tools/javac/diags/examples/ContainedByTargetMismatch.java + test/tools/javac/diags/examples/ContainedByWrongValueType.java ! test/tools/javac/diags/examples/DuplicateAnnotation.java + test/tools/javac/diags/examples/DuplicateAnnotationJava8.java + test/tools/javac/diags/examples/RepeatingAnnotationAndContainer.java + test/tools/javac/diags/examples/WrongContainedBy.java + test/tools/javac/diags/examples/WrongContainerFor.java From Ulf.Zibis at CoSoCo.de Fri Aug 31 10:19:11 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 31 Aug 2012 12:19:11 +0200 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <5040174E.3000503@oracle.com> References: <5036A4C4.5040709@oracle.com> <5036DEA5.1020100@oracle.com> <5037D0D8.3030307@oracle.com> <503DFEA3.70900@CoSoCo.de> <503EA3A3.6010402@oracle.com> <503F7543.6070409@CoSoCo.de> <5040174E.3000503@oracle.com> Message-ID: <50408F9F.7000504@CoSoCo.de> Stuart, much thanks for your detailed explanation. The as is situation has not been in question from my side, but anyway it seems, that it had catalysed a new solution, despite that the additional break; could affect JIT optimization of the enclosing loop. So there should be an explaining comment, even if Hotspot (but maybe others) is not affected in current configuration. Am 31.08.2012 03:45, schrieb Stuart Marks: > On 8/30/12 7:14 AM, Ulf Zibis wrote: >> I can see that it is reasonable/possible to bind a >> @SuppressWarnings("unchecked") to a declaration which contains the unchecked >> assignment, but which declaration should contain a fallthrough case? ... You may call me pedantic, but the above question is still open to me. > It turns out that this discussion is moot, as the switch fall-through is actually unnecessary! The > comma case falls through to the next case, but all that does is break. The warning can be > eliminated simply by replacing /*FALLTHROUGH*/ with a break statement. This removes the need for > the SuppressWarnings annotation. Maybe one could optimize javac to recognize such situation and hold back the warning in that case, as the current code looks more intuitive and has potential advantage for JIT optimization. > > This permissions-parsing code occurs in several places around the JDK, ..... > [...] > Obviously it would be nicer to unify the five copies into one, but this is a much bigger change > that I think is clearly out of scope. Is there already a bug report about that or do you consider to post one? -Ulf From chris.hegarty at oracle.com Fri Aug 31 11:10:49 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 31 Aug 2012 12:10:49 +0100 Subject: RFR: 7195063 [TEST] jtreg flags com/sun/corba/cachedSocket/7056731.sh with Error failure. In-Reply-To: <503F5311.7050501@oracle.com> References: <503F5311.7050501@oracle.com> Message-ID: <50409BB9.2080302@oracle.com> I can't say I know this area too well, but I think it is worth pushing the changes you have. Hopefully that will be an end to this intermittent failure. -Chris On 30/08/12 12:48, Se?n Coffey wrote: > bug report should be live shortly : > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7195063 > > The introduction of a new corba testcase in recent past is showing up as > a random failure on our internal build/test harness (JPRT). > === > > --------------------------------------------- > com/sun/corba/cachedSocket/7056731 > .sh > --------------------------------------------- > > JDK under test: C:\\Users\\aurora\\sandbox\\jdk > warning: failed to delete > C:\\Users\\aurora\\sandbox\\gresults\\testoutput\\jdk_misc\\JTwork\\scratch\\client.1432 > > Test result (overridden): Passed. Execution successful > > > > failed to clean up files after test > javatestOS=Windows XP 5.1 (x86) > > ==== > > Even though the testcase is passing, the jtreg harness flags it since it > can't delete the client.$$ file. The issue is only randomly seen and I > saw it for first time last night while testing and pushing the 7056731 > change to 7u-dev. It was reported to me offline also. > > Fix seems to be allowing some sleep time before/after deleting the test > log files. I attempted a patch up in 7u testcase last night with the > 7056731 push but that went wrong. webrevs for jdk8 & jdk7u below. > > jdk 8 : http://cr.openjdk.java.net/~coffeys/webrev.7195063.jdk8/ > > jdk 7u : http://cr.openjdk.java.net/~coffeys/webrev.7195063.jdk7u/ > > > regards, > Sean. > From Alan.Bateman at oracle.com Fri Aug 31 11:20:07 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 31 Aug 2012 12:20:07 +0100 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <50406ECD.8060302@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <503B73DA.4060807@oracle.com> <503C4FA2.5050001@oracle.com> <503DEE97.7020000@oracle.com> <503F0F4C.4010509@oracle.com> <81472643-22A5-4A29-A410-00E04D7F04CD@oracle.com> <503FB310.50502@oracle.com> <503FD927.1090603@oracle.com> <50406ECD.8060302@oracle.com> Message-ID: <50409DE7.6060109@oracle.com> On 31/08/2012 08:59, Joe Wang wrote: > > Yes, it works just fine under normal conditions. > > Note the old process: read the service file using TCCL (if null, > system cl), if nothing found, then BCL > > Somehow I was under the impression ServiceLoader does just that so > that we could delegate to it. It's probably a good thing that it > actually doesn't. If it did, it'd cause error in the following case: > > The TCCL's parent is BCL (that is Bootstrap), a jaxp impl (e.g. > Xerces) is on the classpath > Old process: try TCCL, not found, try BCL, not found > ServiceLoader: use TCCL, not found, return null (I thought it'd > continue using System CL, but it didn't) > > **although worked differently, the results are the same, so not an > issue in terms of the result, still a behavior change though. > > I did many tests, but so far the results are the same before and after > the patch. > > If TCCL is set to null, I actually saw SCE other than SchemaFactory, > for example: > javax.xml.stream.FactoryConfigurationError: > javax.xml.stream.XMLEventFactory: Provider > org.apache.xerces.stax.XMLEventFactoryImpl not found > > --Joe This is a mess. I realize it pre-dates your watch but it looks like we're going to have to sort this out in order to make progress. I think sorting this out will require some behavior changes so that the factories are located in a consistent manner and also work consistently when there is a security manager set. So what would you think about putting the ServiceLoader changes on hold for a little bit and spending some time to get the factory finders working consistently. I hope this will be mostly just fixing the SecuritySupport.getContextClassLoader implementations and so will not conflict with the SL work. As part of this then we get a list of existing vs. proposal behavior for each factory and for each of the security manager + no security manager cases. This will allow us to assess the impact to each factory finder. My gut feel is that the impact will not be too significant and in most cases will be an improvement to how it works today. I also agree with Paul about getting a useful set of tests as it's impossible to say from reading the javadoc how it should behave. These tests will help you to get the list of current behavior, proposed behavior and should give you confidence when you get to the changing this code to use ServiceLoader. -Alan From sean.coffey at oracle.com Fri Aug 31 11:22:45 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 31 Aug 2012 11:22:45 +0000 Subject: hg: jdk8/tl/jdk: 7195063: [TEST] jtreg flags com/sun/corba/cachedSocket/7056731.sh with Error failure. Message-ID: <20120831112311.A2D4547834@hg.openjdk.java.net> Changeset: da1436b21bc2 Author: coffeys Date: 2012-08-31 12:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da1436b21bc2 7195063: [TEST] jtreg flags com/sun/corba/cachedSocket/7056731.sh with Error failure. Reviewed-by: chegar ! test/com/sun/corba/cachedSocket/7056731.sh From alan.bateman at oracle.com Fri Aug 31 11:26:16 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 31 Aug 2012 11:26:16 +0000 Subject: hg: jdk8/tl/jdk: 7033824: TEST_BUG: java/nio/file/Files/CopyAndMove.java fails intermittently Message-ID: <20120831112639.482B947835@hg.openjdk.java.net> Changeset: 33f8ca2b4ba3 Author: alanb Date: 2012-08-31 12:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33f8ca2b4ba3 7033824: TEST_BUG: java/nio/file/Files/CopyAndMove.java fails intermittently Reviewed-by: chegar ! test/java/nio/file/Files/CopyAndMove.java From huizhe.wang at oracle.com Fri Aug 31 17:12:31 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 31 Aug 2012 10:12:31 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <50409DE7.6060109@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> <4FE8B9D5.6030005@oracle.com> <501630CB.8000100@oracle.com> <5037B13B.8060206@oracle.com> <503B73DA.4060807@oracle.com> <503C4FA2.5050001@oracle.com> <503DEE97.7020000@oracle.com> <503F0F4C.4010509@oracle.com> <81472643-22A5-4A29-A410-00E04D7F04CD@oracle.com> <503FB310.50502@oracle.com> <503FD927.1090603@oracle.com> <50406ECD.8060302@oracle.com> <50409DE7.6060109@oracle.com> Message-ID: <5040F07F.7010308@oracle.com> On 8/31/2012 4:20 AM, Alan Bateman wrote: > On 31/08/2012 08:59, Joe Wang wrote: >> >> Yes, it works just fine under normal conditions. >> >> Note the old process: read the service file using TCCL (if null, >> system cl), if nothing found, then BCL >> >> Somehow I was under the impression ServiceLoader does just that so >> that we could delegate to it. It's probably a good thing that it >> actually doesn't. If it did, it'd cause error in the following case: >> >> The TCCL's parent is BCL (that is Bootstrap), a jaxp impl (e.g. >> Xerces) is on the classpath >> Old process: try TCCL, not found, try BCL, not found >> ServiceLoader: use TCCL, not found, return null (I thought it'd >> continue using System CL, but it didn't) >> >> **although worked differently, the results are the same, so not >> an issue in terms of the result, still a behavior change though. >> >> I did many tests, but so far the results are the same before and >> after the patch. >> >> If TCCL is set to null, I actually saw SCE other than SchemaFactory, >> for example: >> javax.xml.stream.FactoryConfigurationError: >> javax.xml.stream.XMLEventFactory: Provider >> org.apache.xerces.stax.XMLEventFactoryImpl not found >> >> --Joe > This is a mess. I realize it pre-dates your watch but it looks like > we're going to have to sort this out in order to make progress. I > think sorting this out will require some behavior changes so that the > factories are located in a consistent manner and also work > consistently when there is a security manager set. > > So what would you think about putting the ServiceLoader changes on > hold for a little bit and spending some time to get the factory > finders working consistently. I hope this will be mostly just fixing > the SecuritySupport.getContextClassLoader implementations and so will > not conflict with the SL work. As part of this then we get a list of > existing vs. proposal behavior for each factory and for each of the > security manager + no security manager cases. This will allow us to > assess the impact to each factory finder. My gut feel is that the > impact will not be too significant and in most cases will be an > improvement to how it works today. > > I also agree with Paul about getting a useful set of tests as it's > impossible to say from reading the javadoc how it should behave. These > tests will help you to get the list of current behavior, proposed > behavior and should give you confidence when you get to the changing > this code to use ServiceLoader. Okay, let's streamline the factories. I think we should: 1) align to the SAX/DOM since these are most frequently used, and proven. Any changes to other factories will have lower impact in comparison; 2) no spec change involved: for example, the StAX factories have newFactory/newInstance(String factoryId, ClassLoader classLoader), while others define the first parameter as factory classname, e.g. newInstance(String factoryClassName, ClassLoader classLoader). We also know that some factories have throws clause while others don't. In this effort of making factories behave consistently, we'll restrain from making any spec change. --Joe > > -Alan From dan.xu at oracle.com Fri Aug 31 19:06:31 2012 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 31 Aug 2012 12:06:31 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <5040174E.3000503@oracle.com> References: <5036A4C4.5040709@oracle.com> <5036DEA5.1020100@oracle.com> <5037D0D8.3030307@oracle.com> <503DFEA3.70900@CoSoCo.de> <503EA3A3.6010402@oracle.com> <503F7543.6070409@CoSoCo.de> <5040174E.3000503@oracle.com> Message-ID: <50410B37.9050909@oracle.com> On 08/30/2012 06:45 PM, Stuart Marks wrote: > On 8/30/12 7:14 AM, Ulf Zibis wrote: >> Am 30.08.2012 01:20, schrieb Stuart Marks: >>> On 8/29/12 4:36 AM, Ulf Zibis wrote: >>>>> @SuppressWarnings("fallthrough") is put to suppress warnings >>>>> generated by >>>>> another switch/case statements >>>> Can't you move it from method scope to there? >>>> >>>>> while (i >= matchlen && !seencomma) { >>>>> switch(a[i-matchlen]) { >>>>> case ',': >>>>> seencomma = true; >>>>> /*FALLTHROUGH*/ >>>>> case ' ': case '\r': case '\n': >>>>> case '\f': case '\t': >>>>> break; >>>>> default: >>>>> throw new IllegalArgumentException( >>>>> "invalid permission: " + actions); >>>>> } >>>>> i--; >>>>> } >>> >>> Unfortunately there is no suitable place to put the annotation. >>> Annotations >>> can only be placed on declarations, and the narrowest enclosing >>> declaration >>> around this switch statement is, unfortunately, the entire method. >>> One might >>> consider refactoring the switch statement into its own method, but >>> that kind >>> of refactoring is too large a change for warnings cleanup. >> >> I can see that it is reasonable/possible to bind a >> @SuppressWarnings("unchecked") to a declaration which contains the >> unchecked >> assignment, but which declaration should contain a fallthrough case? >> >> So shouldn't @SuppressWarnings("fallthrough") better be binded to a >> switch or >> case statement? > > In principle it would be nice to place the @SuppressWarnings right > next to the switch statement for which the warnings are suppressed. > However, it is a syntactic restriction of the Java programming > language that annotations can only be used as modifiers on > declarations, specifically package, class, method, method parameter, > constructor, and local variable declarations. See JLS 9.7 [1]. It is > not legal to place annotations on statements. So, the SuppressWarnings > annotation has to be placed on a declaration that encloses the switch > statement in question. In this case that's the declaration of the > entire method. > > [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.7 > > It turns out that this discussion is moot, as the switch fall-through > is actually unnecessary! The comma case falls through to the next > case, but all that does is break. The warning can be eliminated simply > by replacing /*FALLTHROUGH*/ with a break statement. This removes the > need for the SuppressWarnings annotation. > > This permissions-parsing code occurs in several places around the JDK, > copied and slightly modified. Some of them use the string identity > comparison optimization, and some have this switch fall through. > (We've discussed this previously. See [2].) Accordingly, I've asked > Dan to adjust a couple of these other cases to have the same comment > about string identity comparisons, and to change the switch statement > to avoid the fall-through entirely. > > [2] > http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000415.html > > While I'm reluctant to expand the scope of this changeset, I think > it's important to keep these five occurrences consistent. Obviously it > would be nicer to unify the five copies into one, but this is a much > bigger change that I think is clearly out of scope. > > Dan will issue another webrev with these changes shortly. > > s'marks > I have adjusted my fix with the above suggestions. The latest webrev is posted at, http://cr.openjdk.java.net/~dxu/7193406/webrev.05/. Thanks for your comments! -Dan From mike.duigou at oracle.com Fri Aug 31 19:42:04 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 31 Aug 2012 12:42:04 -0700 Subject: Review Request: 7193406 - Clean-up JDK Build Warnings in java.util, java.io In-Reply-To: <50410B37.9050909@oracle.com> References: <5036A4C4.5040709@oracle.com> <5036DEA5.1020100@oracle.com> <5037D0D8.3030307@oracle.com> <503DFEA3.70900@CoSoCo.de> <503EA3A3.6010402@oracle.com> <503F7543.6070409@CoSoCo.de> <5040174E.3000503@oracle.com> <50410B37.9050909@oracle.com> Message-ID: The changes look good to me. I am starting to come into agreement with Remi though that unless a type specific array can be created for situations like the E[] elements array in ArrayDeque then it should be declared as Object[] array since that's what is actually created. Mike On Aug 31 2012, at 12:06 , Dan Xu wrote: > On 08/30/2012 06:45 PM, Stuart Marks wrote: >> On 8/30/12 7:14 AM, Ulf Zibis wrote: >>> Am 30.08.2012 01:20, schrieb Stuart Marks: >>>> On 8/29/12 4:36 AM, Ulf Zibis wrote: >>>>>> @SuppressWarnings("fallthrough") is put to suppress warnings generated by >>>>>> another switch/case statements >>>>> Can't you move it from method scope to there? >>>>> >>>>>> while (i >= matchlen && !seencomma) { >>>>>> switch(a[i-matchlen]) { >>>>>> case ',': >>>>>> seencomma = true; >>>>>> /*FALLTHROUGH*/ >>>>>> case ' ': case '\r': case '\n': >>>>>> case '\f': case '\t': >>>>>> break; >>>>>> default: >>>>>> throw new IllegalArgumentException( >>>>>> "invalid permission: " + actions); >>>>>> } >>>>>> i--; >>>>>> } >>>> >>>> Unfortunately there is no suitable place to put the annotation. Annotations >>>> can only be placed on declarations, and the narrowest enclosing declaration >>>> around this switch statement is, unfortunately, the entire method. One might >>>> consider refactoring the switch statement into its own method, but that kind >>>> of refactoring is too large a change for warnings cleanup. >>> >>> I can see that it is reasonable/possible to bind a >>> @SuppressWarnings("unchecked") to a declaration which contains the unchecked >>> assignment, but which declaration should contain a fallthrough case? >>> >>> So shouldn't @SuppressWarnings("fallthrough") better be binded to a switch or >>> case statement? >> >> In principle it would be nice to place the @SuppressWarnings right next to the switch statement for which the warnings are suppressed. However, it is a syntactic restriction of the Java programming language that annotations can only be used as modifiers on declarations, specifically package, class, method, method parameter, constructor, and local variable declarations. See JLS 9.7 [1]. It is not legal to place annotations on statements. So, the SuppressWarnings annotation has to be placed on a declaration that encloses the switch statement in question. In this case that's the declaration of the entire method. >> >> [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.7 >> >> It turns out that this discussion is moot, as the switch fall-through is actually unnecessary! The comma case falls through to the next case, but all that does is break. The warning can be eliminated simply by replacing /*FALLTHROUGH*/ with a break statement. This removes the need for the SuppressWarnings annotation. >> >> This permissions-parsing code occurs in several places around the JDK, copied and slightly modified. Some of them use the string identity comparison optimization, and some have this switch fall through. (We've discussed this previously. See [2].) Accordingly, I've asked Dan to adjust a couple of these other cases to have the same comment about string identity comparisons, and to change the switch statement to avoid the fall-through entirely. >> >> [2] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000415.html >> >> While I'm reluctant to expand the scope of this changeset, I think it's important to keep these five occurrences consistent. Obviously it would be nicer to unify the five copies into one, but this is a much bigger change that I think is clearly out of scope. >> >> Dan will issue another webrev with these changes shortly. >> >> s'marks >> > > I have adjusted my fix with the above suggestions. > > The latest webrev is posted at, http://cr.openjdk.java.net/~dxu/7193406/webrev.05/. Thanks for your comments! > > -Dan From erik.joelsson at oracle.com Tue Aug 7 09:57:49 2012 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 07 Aug 2012 09:57:49 -0000 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: References: <4FFC93CF.40105@oracle.com> Message-ID: <5020E699.3000600@oracle.com> See inline On 2012-07-13 22:20, Kelly O'Hair wrote: > Something seems strange here: > http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html > It's like someone was avoiding overall quotes, but using them to add spaces somehow... > I sure would like to get rid of this shell logic, seems like there are lots repeated logic that > this script does over and over or could be done with makefile pattern subst's instead of exec's. The new version isn't any worse than the old in my opinion. In build-infra, this file is indeed replaced with make logic. After having decoded both versions I'm confident in converting the changes. > Overall, just looking at the makefiles, the build-infra team may need some time to fully absorb this into the > new makefiles, some of it will be trivial, not sure all of it will be. > I have applied the patch to a clone of build-infra and done the minimal changes to keep build-infra building, which was rather trivial. The resulting build has large differences since I haven't converted all of it yet. There are a couple of things that will require some more work, but not more than a day or two. > Not sure how to proceed here, the build-infra team does need an action item to deal with this, maybe > before it gets integrated because I suspect the new makefiles will break with all the filename or > directory changes. But I hate to hold up your integration plans. I see these as possible options: 1. Let this go in, build-infra will break in jdk8 until we do our next push and it trickles through the repos. 2. The build-infra project provides a patch with the full conversion that can go in together with these changes. 3. The build-infra project provides a simple patch which just keeps the build-infra-build from failing that can go in with these changes. The conversion needs to happen regardless of option. The changes required are pretty isolated from remaining build-infra work. What do you think? Other than that, I have no objections to the review. /Erik > I'd like to get some advice from Erik on this before saying anything further. > > -kto > > On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: > >> Hello, >> >> Please review the JDK8 changes for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data (http://openjdk.java.net/jeps/127). The webrev is located at: >> >> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >> >> The main bug id for this enhancement is: >> >> 6336885: RFE: Locale Data Deployment Enhancements >> >> Along with this, the following bugs/enhancements are also implemented in this change: >> >> 4609153 Provide locale data for Indic locales >> 5104387 Support for gl_ES locale (galician language) >> 6337471 desktop/system locale preferences support >> 7056139 (cal) SPI support for locale-dependent Calendar parameters >> 7058206 Provide CalendarData SPI for week params and display field value names >> 7073852 Support multiple scripts for digits and decimal symbols per locale >> 7079560 [Fmt-Da] Context dependent month names support in SimpleDateFormat >> 7171324 getAvailableLocales() of locale sensitive services should return the actual availability of locales >> 7151414 (cal) Support calendar type identification >> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >> 7171372 (cal) locale's default Calendar should be created if unknown calendar is specified >> >> Please note that packaging changes that relate to Jigsaw module system aren't included in this changeset. >> >> Naoto Sato and Masayoshi Okutsu From erik.joelsson at oracle.com Tue Aug 14 06:40:07 2012 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 Aug 2012 06:40:07 -0000 Subject: [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data In-Reply-To: <50297505.7050603@oracle.com> References: <4FFC93CF.40105@oracle.com> <5020E699.3000600@oracle.com> <5022D686.9070203@oracle.com> <50297505.7050603@oracle.com> Message-ID: <5029F2C5.6030109@oracle.com> I finished making the changes yesterday, but didn't manage to get the patch completed before I had to run. (webrev and mercurial wouldn't cooperate). I will get it done asap today. /Erik On 2012-08-13 23:43, Naoto Sato wrote: > Since I haven't heard any more comments from Erik/Kelly, I would like > to push the changeset without the new build infra patch. Erik/Kelly, > can you please give us an official "GO" in terms of the build related > changes? > > Aside from build changes, I have updated the changeset based on an > internal review: > > http://cr.openjdk.java.net/~naoto/6336885/webrev.01/ > > This includes: > > - a couple of fixes to the CLDR Converter > - Added fallback for any bad SPI implementations which return null for > requested instances. > > Still asking for review comments. > > Naoto > > On 8/8/12 2:13 PM, Naoto Sato wrote: >> On 8/7/12 2:57 AM, Erik Joelsson wrote: >>> See inline >>> >>> On 2012-07-13 22:20, Kelly O'Hair wrote: >>>> Something seems strange here: >>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/make/java/java/localegen.sh.sdiff.html >>>> >>>> >>>> >>>> It's like someone was avoiding overall quotes, but using them to add >>>> spaces somehow... >>>> I sure would like to get rid of this shell logic, seems like there are >>>> lots repeated logic that >>>> this script does over and over or could be done with makefile pattern >>>> subst's instead of exec's. >>> The new version isn't any worse than the old in my opinion. In >>> build-infra, this file is indeed replaced with make logic. After having >>> decoded both versions I'm confident in converting the changes. >>>> Overall, just looking at the makefiles, the build-infra team may need >>>> some time to fully absorb this into the >>>> new makefiles, some of it will be trivial, not sure all of it will be. >>>> >>> I have applied the patch to a clone of build-infra and done the minimal >>> changes to keep build-infra building, which was rather trivial. The >>> resulting build has large differences since I haven't converted all of >>> it yet. There are a couple of things that will require some more work, >>> but not more than a day or two. >>>> Not sure how to proceed here, the build-infra team does need an action >>>> item to deal with this, maybe >>>> before it gets integrated because I suspect the new makefiles will >>>> break with all the filename or >>>> directory changes. But I hate to hold up your integration plans. >>> I see these as possible options: >>> >>> 1. Let this go in, build-infra will break in jdk8 until we do our next >>> push and it trickles through the repos. >>> 2. The build-infra project provides a patch with the full conversion >>> that can go in together with these changes. >>> 3. The build-infra project provides a simple patch which just keeps the >>> build-infra-build from failing that can go in with these changes. >>> >>> The conversion needs to happen regardless of option. The changes >>> required are pretty isolated from remaining build-infra work. What do >>> you think? >> >> Either way is fine with me. If build-infra team prefers 2 or 3, please >> give me the patch, and I will go ahead and merge them to my changeset. >> >> Naoto >> >>> >>> Other than that, I have no objections to the review. >>> >>> /Erik >>> >>>> I'd like to get some advice from Erik on this before saying anything >>>> further. >>>> >>>> -kto >>>> >>>> On Jul 10, 2012, at 1:42 PM, Naoto Sato wrote: >>>> >>>>> Hello, >>>>> >>>>> Please review the JDK8 changes for JEP 127: Improve Locale Data >>>>> Packaging and Adopt Unicode CLDR Data >>>>> (http://openjdk.java.net/jeps/127). The webrev is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/ >>>>> >>>>> The main bug id for this enhancement is: >>>>> >>>>> 6336885: RFE: Locale Data Deployment Enhancements >>>>> >>>>> Along with this, the following bugs/enhancements are also implemented >>>>> in this change: >>>>> >>>>> 4609153 Provide locale data for Indic locales >>>>> 5104387 Support for gl_ES locale (galician language) >>>>> 6337471 desktop/system locale preferences support >>>>> 7056139 (cal) SPI support for locale-dependent Calendar parameters >>>>> 7058206 Provide CalendarData SPI for week params and display field >>>>> value names >>>>> 7073852 Support multiple scripts for digits and decimal symbols per >>>>> locale >>>>> 7079560 [Fmt-Da] Context dependent month names support in >>>>> SimpleDateFormat >>>>> 7171324 getAvailableLocales() of locale sensitive services should >>>>> return the actual availability of locales >>>>> 7151414 (cal) Support calendar type identification >>>>> 7168528 LocaleServiceProvider needs to be aware of Locale extensions >>>>> 7171372 (cal) locale's default Calendar should be created if unknown >>>>> calendar is specified >>>>> >>>>> Please note that packaging changes that relate to Jigsaw module >>>>> system aren't included in this changeset. >>>>> >>>>> Naoto Sato and Masayoshi Okutsu >> > From amy.lu at oracle.com Thu Aug 16 08:36:41 2012 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 16 Aug 2012 08:36:41 -0000 Subject: Code review request 7191892: ProblemList.txt updates (8/2012) Message-ID: <502CB1CD.6080907@oracle.com> Following bugs have been resolved, tests have been verified working fine. CR and related tests should be removed from ProblemList: 7149181 [Fix-Delivered]: sun/management/jmxremote/startstop/JMXStartStopTest.sh failing on all platforms 7174532 [Fix-Delivered]: jdk/test/java/lang/Math/WorstCaseTests.java failing on x86 Following test still fail, but the related CR should be 7172176: sun/tools/jconsole/ResourceCheckTest.sh Please review the ProblemList updates: http://cr.openjdk.java.net/~alanb/7191892/webrev/ Thanks, Amy