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
>
> 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