Home > From chris.hegarty at oracle.com Sun Jan 1 11:54:21 2012

From chris.hegarty at oracle.com Sun Jan 1 11:54:21 2012

From chris.hegarty at oracle.com Sun Jan 1 11:54:21 2012
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Sun, 01 Jan 2012 11:54:21 +0000
Subject: hg: jdk8/tl/jdk: 7125055: ContentHandler.getContent API changed in
error
Message-ID: <20120101115447.590E647858@hg.openjdk.java.net>

Changeset: 5aeefe0e5d8c
Author: chegar
Date: 2012-01-01 09:24 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5aeefe0e5d8c

7125055: ContentHandler.getContent API changed in error
Reviewed-by: alanb

! src/share/classes/java/net/ContentHandler.java
! src/share/classes/sun/net/www/content/image/gif.java
! src/share/classes/sun/net/www/content/image/jpeg.java
! src/share/classes/sun/net/www/content/image/png.java
! src/share/classes/sun/net/www/content/image/x_xbitmap.java
! src/share/classes/sun/net/www/content/image/x_xpixmap.java



From tbee at tbee.org Sun Jan 1 16:54:56 2012
From: tbee at tbee.org (Tom Eugelink)
Date: Sun, 01 Jan 2012 17:54:56 +0100
Subject: Fraction
Message-ID: <4F008FE0.60501@tbee.org>


Hello guys,

I was wondering if it was of any interest to OpenJFX to have a calculation class that does not round. I've got "Fraction" laying around, which does math using two BigIntegers, so it never even rounds. The API is roughly equivalent to BigDecimal, so you have methods like add, divide, etc.

Any interest in adding such a class to Java?

Tom



From kumar.x.srinivasan at oracle.com Tue Jan 3 16:29:04 2012
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Tue, 03 Jan 2012 16:29:04 +0000
Subject: hg: jdk8/tl/jdk: 7123582: (launcher) display the -version and
-XshowSettings
Message-ID: <20120103162914.97A394785E@hg.openjdk.java.net>

Changeset: 8952a5f494f9
Author: ksrini
Date: 2012-01-03 08:27 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8952a5f494f9

7123582: (launcher) display the -version and -XshowSettings
Reviewed-by: alanb

! src/share/bin/java.c
! test/tools/launcher/Settings.java



From kumar.x.srinivasan at oracle.com Tue Jan 3 16:36:05 2012
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Tue, 03 Jan 2012 16:36:05 +0000
Subject: hg: jdk8/tl/jdk: 7124443: (launcher) test DefaultsLocaleTest fails
with Windows shells.
Message-ID: <20120103163615.67A264785F@hg.openjdk.java.net>

Changeset: 5e34726cb4bb
Author: ksrini
Date: 2012-01-03 08:33 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e34726cb4bb

7124443: (launcher) test DefaultsLocaleTest fails with Windows shells.
Reviewed-by: darcy

! test/tools/launcher/DefaultLocaleTest.java
- test/tools/launcher/DefaultLocaleTest.sh
+ test/tools/launcher/DefaultLocaleTestRun.java
! test/tools/launcher/TestHelper.java



From brandon.passanisi at oracle.com Tue Jan 3 18:37:22 2012
From: brandon.passanisi at oracle.com (Brandon Passanisi)
Date: Tue, 03 Jan 2012 10:37:22 -0800
Subject: Review request for #6783209
Message-ID: <4F034AE2.10308@oracle.com>

Hello core-libs-dev. Can someone please do a code review of the
following proposed fix for 6783209 : (fmt)Formatter doesn't support
width for %%.

Webrev : http://cr.openjdk.java.net/~bpassani/6783209/0/webrev/
Bug URL: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6783209

The fix is to use justify() within Formatter.java to do the proper
padding when using the '%' conversion. I have included a new test
program to test instances of format specifiers that use the '%'
conversion with a width value. The test also includes the testing of
'%' without a width to ensure there aren't regressions.

Thanks.
--
Oracle <http://www.oracle.com>
Brandon Passanisi | Principle Member of Technical Staff


Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment


From kelly.ohair at oracle.com Tue Jan 3 19:16:18 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 3 Jan 2012 11:16:18 -0800
Subject: 7121110 : JAXP 1.4.5 update 1 for 7u4 & jaxp source in jdk7 repo
In-Reply-To: <4EFDFEE5.1080803@oracle.com>
References: <4EF4F236.3080200@oracle.com> <4EFAF5C7.90509@oracle.com>
<4EFB4F74.9010809@oracle.com> <4EFDC736.1090302@oracle.com>
<4EFDFEE5.1080803@oracle.com>
Message-ID: <BA4D08F0-7DF2-45A1-8697-14928A33372A@oracle.com>

So you have a review from me.

I think you need to send this CR/webrev and request for approval to the jdk7u-dev at openjdk.java.net alias for 7u4

Or did you do that already? Hopefully we can fix this drop stuff before 12/12/12 and the end of the world. 8^{

-kto

On Dec 30, 2011, at 10:11 AM, Joe Wang wrote:

> On 12/30/2011 6:14 AM, Alan Bateman wrote:
>> On 28/12/2011 17:18, Joe Wang wrote:
>>> Kelly asked for 6-open and jdk8 as well. Since we're changing the jaxp bundle process, we thought we would do the same for 6-open and jdk8 once this works out. But we can take the change to jdk8 first if this is approved. The only question I had was that the jdk8 modularization would change the jaxp source structure. But Kelly thought that's not a problem. I guess we don't mind another big changeset :)
>> I think it's too early to know if modularization will require the jaxp source code to be restructured as modules. It would clearly be desirable, in particular if jaxp migrates completely. However, if there are still activity upstream (you mentioned monitoring commits at jaxp-sources.java.net) or some need to keep the 7u and 8 code in sync then it would complicate things a bit.
> Yeh, there are several undecided factors affecting jaxp project/source right now. If there's no absolute requirement for a jaxp update in jdk8, I would prefer we wait a couple of weeks for things to settle.
>
> -Joe
>
>>
>> -Alan



From kelly.ohair at oracle.com Tue Jan 3 19:18:07 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Tue, 3 Jan 2012 11:18:07 -0800
Subject: Known issue?
java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java
In-Reply-To: <4EFEE480.2090603@oracle.com>
References: <31DA93C9-C289-4143-873B-E13071442822@oracle.com>
<4EFEE480.2090603@oracle.com>
Message-ID: <051AB6E5-8C79-452E-BF28-292D3C7C93DF@oracle.com>


On Dec 31, 2011, at 2:31 AM, Alan Bateman wrote:

> On 31/12/2011 01:31, Kelly O'Hair wrote:
>> Just wondering if anyone has seen this testcase failure.
>> I'm using Fedora 9 x86.
>>
>> -kto
>> :
>>
>> Test DatagramChannel to INET socket
>> join 225.4.5.6 @ virbr0
>> Send message from 192.168.122.1 -> group 225.4.5.6 (id=0x23b98c4a)
>> Waiting to receive message
>> STDERR:
>> java.lang.RuntimeException: Expected message not recieved
>>
> We've had test failures on systems with the ip6tables packet filter blocking IPv6 multicast packets but otherwise I can't think of any issues.
>
> In this case the interface is virbr0 so I assume this is a virtual environment. I think this may need going through the libvirt configuration as I assume the issue is that IPv4 multicast packets aren't being forwarded.
>
> -Alan.

WHOOSH ... something flew over my head, probably packets I don't understand... ;^)

Let me know if I need to file a bug, or need to look closer at the system I was using, and what to look at.

-kto



From jonathan.gibbons at oracle.com Tue Jan 3 19:37:41 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 03 Jan 2012 19:37:41 +0000
Subject: hg: jdk8/tl/langtools: 4881269: improve diagnostic for ill-formed
tokens
Message-ID: <20120103193744.D72C447860@hg.openjdk.java.net>

Changeset: 7a836147b266
Author: jjg
Date: 2012-01-03 11:37 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7a836147b266

4881269: improve diagnostic for ill-formed tokens
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/tools/javac/diags/examples/IllegalDot.java
+ test/tools/javac/parser/T4881269.java
+ test/tools/javac/parser/T4881269.out



From huizhe.wang at oracle.com Tue Jan 3 20:27:15 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 03 Jan 2012 12:27:15 -0800
Subject: 7121110 : JAXP 1.4.5 update 1 for 7u4 & jaxp source in jdk7 repo
In-Reply-To: <BA4D08F0-7DF2-45A1-8697-14928A33372A@oracle.com>
References: <4EF4F236.3080200@oracle.com> <4EFAF5C7.90509@oracle.com>
<4EFB4F74.9010809@oracle.com> <4EFDC736.1090302@oracle.com>
<4EFDFEE5.1080803@oracle.com>
<BA4D08F0-7DF2-45A1-8697-14928A33372A@oracle.com>
Message-ID: <4F0364A3.9010300@oracle.com>

If you meant this:
http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-December/001130.html
Yes, I've gotten the approval from Edvard.
Note that, the jaxp update itself (without the build change) was
approved for 7u2.

On 1/3/2012 11:16 AM, Kelly O'Hair wrote:
> So you have a review from me.
>
> I think you need to send this CR/webrev and request for approval to the jdk7u-dev at openjdk.java.net alias for 7u4
>
> Or did you do that already? Hopefully we can fix this drop stuff before 12/12/12 and the end of the world. 8^{
We have 330 days to pray the world could make enough change to alter
that fate. And maybe, this could be a tiny tiny tiny bit of it - no one
knows, but since no one else has done it, we can claim that that was it
when 12/13 comes ;-)

-Joe

>
> -kto
>
> On Dec 30, 2011, at 10:11 AM, Joe Wang wrote:
>
>> On 12/30/2011 6:14 AM, Alan Bateman wrote:
>>> On 28/12/2011 17:18, Joe Wang wrote:
>>>> Kelly asked for 6-open and jdk8 as well. Since we're changing the jaxp bundle process, we thought we would do the same for 6-open and jdk8 once this works out. But we can take the change to jdk8 first if this is approved. The only question I had was that the jdk8 modularization would change the jaxp source structure. But Kelly thought that's not a problem. I guess we don't mind another big changeset :)
>>> I think it's too early to know if modularization will require the jaxp source code to be restructured as modules. It would clearly be desirable, in particular if jaxp migrates completely. However, if there are still activity upstream (you mentioned monitoring commits at jaxp-sources.java.net) or some need to keep the 7u and 8 code in sync then it would complicate things a bit.
>> Yeh, there are several undecided factors affecting jaxp project/source right now. If there's no absolute requirement for a jaxp update in jdk8, I would prefer we wait a couple of weeks for things to settle.
>>
>> -Joe
>>
>>> -Alan


From iris.clark at oracle.com Tue Jan 3 21:27:48 2012
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 3 Jan 2012 13:27:48 -0800 (PST)
Subject: Review request for #6783209
In-Reply-To: <4F034AE2.10308@oracle.com>
References: <4F034AE2.10308@oracle.com>
Message-ID: <340566ee-2ca0-4677-98b5-8cbf2f21a728@default>

Hi, Brandon.

I am not a jdk8 Reviewer (http://openjdk.java.net/census#jdk8), but I am the original author.

No time to check the spec now, but is precision ever applicable when the flag '%' is provided? If it is, then old line 2726 should probably just be changed to "print("%')".

Rather than write a brand new test for this bug, I suggest you add a test case to the rather extensive set of unit tests for Formatter defined by this file:

test/java/util/Formatter/Basic.java

(Look at Basic-X.java.template, line 1703. Regenerate Basic*.java via Basic.sh.)

Thanks,
iris


-----Original Message-----
From: Brandon Passanisi
Sent: Tuesday, January 03, 2012 10:37 AM
To: core-libs-dev
Subject: Review request for #6783209

Hello core-libs-dev. Can someone please do a code review of the following proposed fix for 6783209 : (fmt)Formatter doesn't support width for %%.

Webrev : http://cr.openjdk.java.net/~bpassani/6783209/0/webrev/
Bug URL: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6783209

The fix is to use justify() within Formatter.java to do the proper padding when using the '%' conversion. I have included a new test program to test instances of format specifiers that use the '%'
conversion with a width value. The test also includes the testing of '%' without a width to ensure there aren't regressions.

Thanks.
--
Oracle <http://www.oracle.com>
Brandon Passanisi | Principle Member of Technical Staff


Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment


From brandon.passanisi at oracle.com Tue Jan 3 23:52:45 2012
From: brandon.passanisi at oracle.com (Brandon Passanisi)
Date: Tue, 03 Jan 2012 15:52:45 -0800
Subject: Review request for #6783209
In-Reply-To: <340566ee-2ca0-4677-98b5-8cbf2f21a728@default>
References: <4F034AE2.10308@oracle.com>
<340566ee-2ca0-4677-98b5-8cbf2f21a728@default>
Message-ID: <4F0394CD.8050006@oracle.com>

Hi Iris. Answers below:

On 1/3/2012 1:27 PM, Iris Clark wrote:
> Hi, Brandon.
>
> I am not a jdk8 Reviewer (http://openjdk.java.net/census#jdk8), but I am the original author.
>
> No time to check the spec now, but is precision ever applicable when the flag '%' is provided? If it is, then old line 2726 should probably just be changed to "print("%')".

According to the spec, the precision isn't applicable when the '%'
conversion is used. Here's the quote from the Formatter javadoc
regarding precision and the '%' conversion:

"The precision is not applicable. If the precision is specified an
IllegalFormatPrecisionException will be thrown."

Because of this, it appears that I don't need to change line 2726 to
print("%").

>
> Rather than write a brand new test for this bug, I suggest you add a test case to the rather extensive set of unit tests for Formatter defined by this file:
>
> test/java/util/Formatter/Basic.java
>
> (Look at Basic-X.java.template, line 1703. Regenerate Basic*.java via Basic.sh.)

Thanks for the suggestion regarding the Basic-* set of tests. I have
removed the new test I had written and instead have updated
Basic-X.java.template as you have suggested. I have created an updated
webrev for review that reflects these changes.

Webrev: http://cr.openjdk.java.net/~bpassani/6783209/1/webrev/


Thanks.


>
> Thanks,
> iris
>
>
> -----Original Message-----
> From: Brandon Passanisi
> Sent: Tuesday, January 03, 2012 10:37 AM
> To: core-libs-dev
> Subject: Review request for #6783209
>
> Hello core-libs-dev. Can someone please do a code review of the following proposed fix for 6783209 : (fmt)Formatter doesn't support width for %%.
>
> Webrev : http://cr.openjdk.java.net/~bpassani/6783209/0/webrev/
> Bug URL: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6783209
>
> The fix is to use justify() within Formatter.java to do the proper padding when using the '%' conversion. I have included a new test program to test instances of format specifiers that use the '%'
> conversion with a width value. The test also includes the testing of '%' without a width to ensure there aren't regressions.
>
> Thanks.
> --
> Oracle<http://www.oracle.com>
> Brandon Passanisi | Principle Member of Technical Staff
>
>
> Green Oracle<http://www.oracle.com/commitment> Oracle is committed to
> developing practices and products that help protect the environment

--
Oracle <http://www.oracle.com>
Brandon Passanisi | Principle Member of Technical Staff


Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment


From david.holmes at oracle.com Wed Jan 4 00:08:57 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 04 Jan 2012 10:08:57 +1000
Subject: 100218: BigInteger staticRandom field
In-Reply-To: <CAHD7==5N1Xg-ZzUc=GC4rcWA-FPuHz5jUBqwd=6im+PoTh3R_Q@mail.gmail.com>
References: <CAHD7==5G6QC7Rpe=g=yLD8gt=X7_=NKc+idjJ=MFh0e8r4mDyg@mail.gmail.com>
<CAHD7==5N1Xg-ZzUc=GC4rcWA-FPuHz5jUBqwd=6im+PoTh3R_Q@mail.gmail.com>
Message-ID: <4F039899.7050004@oracle.com>

Hi Paul,

For some reason this email, despite being dated Dec 14, only just
appeared in my inbox on Jan 3!

On 14/12/2011 12:44 AM, Paul Ciprich wrote:
> All,
>
> I've created a bug report to address a scalability problem with
> BigInteger's staticRandom field. The problem is that the shared
> staticRandom field causes bottlenecks with parallel code. The proposed
> solution is to change the staticRandom field to a ThreadLocal and eliminate
> the bottleneck by giving each thread its own copy of the SecureRandom
> object. Bug 100218 contains a patch with the proposed change if it is
> deemed acceptable.

As I mention in the bug report we have to ensure that we don't add
unacceptable overhead to the non-concurrent case. Also I'm wondering if
anyone might be relying on the existing SecureRandom instance being shared?

Can you clarify the context for the proposed fix: what code is the
bottleneck (isProbablePrime?), under what conditions - is it a
microbenchmark or real code?

Thanks,
David Holmes


From david.holmes at oracle.com Wed Jan 4 00:15:10 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 04 Jan 2012 10:15:10 +1000
Subject: 100218: BigInteger staticRandom field
In-Reply-To: <4F039899.7050004@oracle.com>
References: <CAHD7==5G6QC7Rpe=g=yLD8gt=X7_=NKc+idjJ=MFh0e8r4mDyg@mail.gmail.com>
<CAHD7==5N1Xg-ZzUc=GC4rcWA-FPuHz5jUBqwd=6im+PoTh3R_Q@mail.gmail.com>
<4F039899.7050004@oracle.com>
Message-ID: <4F039A0E.3000906@oracle.com>

On 4/01/2012 10:08 AM, David Holmes wrote:
> Hi Paul,
>
> For some reason this email, despite being dated Dec 14, only just
> appeared in my inbox on Jan 3!

Oops! I missed the fact a copy of this email also turned up on Dec 15
and that I already replied to it.

Comments still apply. Need to understand the context in which this
becomes a bottleneck and the performance implications for non-concurrent
use.

David

> On 14/12/2011 12:44 AM, Paul Ciprich wrote:
>> All,
>>
>> I've created a bug report to address a scalability problem with
>> BigInteger's staticRandom field. The problem is that the shared
>> staticRandom field causes bottlenecks with parallel code. The proposed
>> solution is to change the staticRandom field to a ThreadLocal and
>> eliminate
>> the bottleneck by giving each thread its own copy of the SecureRandom
>> object. Bug 100218 contains a patch with the proposed change if it is
>> deemed acceptable.
>
> As I mention in the bug report we have to ensure that we don't add
> unacceptable overhead to the non-concurrent case. Also I'm wondering if
> anyone might be relying on the existing SecureRandom instance being shared?
>
> Can you clarify the context for the proposed fix: what code is the
> bottleneck (isProbablePrime?), under what conditions - is it a
> microbenchmark or real code?
>
> Thanks,
> David Holmes


From jim.holmlund at sun.com Wed Jan 4 01:19:06 2012
From: jim.holmlund at sun.com (jim.holmlund at sun.com)
Date: Wed, 04 Jan 2012 01:19:06 +0000
Subject: hg: jdk8/tl/langtools: 7046929: tools/javac/api/T6397104.java fails
Message-ID: <20120104011908.8E5474786C@hg.openjdk.java.net>

Changeset: a07eef109532
Author: jjh
Date: 2012-01-03 17:18 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a07eef109532

7046929: tools/javac/api/T6397104.java fails
Reviewed-by: jjg

! test/tools/javac/api/T6397104.java



From frederic.parain at oracle.com Wed Jan 4 13:26:27 2012
From: frederic.parain at oracle.com (frederic.parain at oracle.com)
Date: Wed, 04 Jan 2012 13:26:27 +0000
Subject: hg: jdk8/tl/jdk: 7104647: Adding a diagnostic command framework
Message-ID: <20120104132648.F151947874@hg.openjdk.java.net>

Changeset: 0194fe5ca404
Author: fparain
Date: 2012-01-04 03:49 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0194fe5ca404

7104647: Adding a diagnostic command framework
Reviewed-by: mchung, dholmes

! make/common/Release.gmk
! make/java/management/mapfile-vers
! make/launchers/Makefile
! make/sun/tools/Makefile
+ src/linux/doc/man/jcmd.1
+ src/share/classes/com/sun/management/DiagnosticCommandArgumentInfo.java
+ src/share/classes/com/sun/management/DiagnosticCommandInfo.java
! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java
! src/share/classes/sun/management/HotSpotDiagnostic.java
! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java
+ src/share/classes/sun/tools/jcmd/Arguments.java
+ src/share/classes/sun/tools/jcmd/JCmd.java
! src/share/javavm/export/jmm.h
! src/share/native/sun/management/HotSpotDiagnostic.c
+ src/solaris/doc/sun/man/man1/jcmd.1
+ test/com/sun/management/HotSpotDiagnosticMXBean/ExecuteDiagnosticCommand.java
+ test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommandInfo.java
+ test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticCommands.java
! test/sun/tools/common/CommonSetup.sh
+ test/sun/tools/jcmd/dcmd-script.txt
+ test/sun/tools/jcmd/help_help.out
+ test/sun/tools/jcmd/jcmd-Defaults.sh
+ test/sun/tools/jcmd/jcmd-f.sh
+ test/sun/tools/jcmd/jcmd-help-help.sh
+ test/sun/tools/jcmd/jcmd-help.sh
+ test/sun/tools/jcmd/jcmd-pid.sh
+ test/sun/tools/jcmd/jcmd_Output1.awk
+ test/sun/tools/jcmd/jcmd_pid_Output1.awk
+ test/sun/tools/jcmd/jcmd_pid_Output2.awk
+ test/sun/tools/jcmd/usage.out



From iris.clark at oracle.com Wed Jan 4 17:39:44 2012
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 4 Jan 2012 09:39:44 -0800 (PST)
Subject: Review request for #6783209
In-Reply-To: <4F0394CD.8050006@oracle.com>
References: <4F034AE2.10308@oracle.com>
<340566ee-2ca0-4677-98b5-8cbf2f21a728@default>
<4F0394CD.8050006@oracle.com>
Message-ID: <a3ddee6d-1b62-48a5-814e-009c56cb3416@default>

Hi, Brandon.

> Webrev: http://cr.openjdk.java.net/~bpassani/6783209/1/webrev/

You're revised webrev looks good to me.

Thanks,
iris


From Alan.Bateman at oracle.com Wed Jan 4 17:54:07 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Jan 2012 17:54:07 +0000
Subject: Review request for #6783209
In-Reply-To: <a3ddee6d-1b62-48a5-814e-009c56cb3416@default>
References: <4F034AE2.10308@oracle.com>
<340566ee-2ca0-4677-98b5-8cbf2f21a728@default>
<4F0394CD.8050006@oracle.com>
<a3ddee6d-1b62-48a5-814e-009c56cb3416@default>
Message-ID: <4F04923F.2060606@oracle.com>

On 04/01/2012 17:39, Iris Clark wrote:
> Hi, Brandon.
>
>> Webrev: http://cr.openjdk.java.net/~bpassani/6783209/1/webrev/
> You're revised webrev looks good to me.
>
Looks good to me too.

Sherman - you sponsored Brandon's previous update to Formatter, are you
planning to do the same this time?


From xueming.shen at oracle.com Wed Jan 4 17:54:06 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 04 Jan 2012 09:54:06 -0800
Subject: Review request for #6783209
In-Reply-To: <4F04923F.2060606@oracle.com>
References: <4F034AE2.10308@oracle.com>
<340566ee-2ca0-4677-98b5-8cbf2f21a728@default>
<4F0394CD.8050006@oracle.com>
<a3ddee6d-1b62-48a5-814e-009c56cb3416@default>
<4F04923F.2060606@oracle.com>
Message-ID: <4F04923E.9030702@oracle.com>

On 01/04/2012 09:54 AM, Alan Bateman wrote:
> On 04/01/2012 17:39, Iris Clark wrote:
>> Hi, Brandon.
>>
>>> Webrev: http://cr.openjdk.java.net/~bpassani/6783209/1/webrev/
>> You're revised webrev looks good to me.
>>
> Looks good to me too.
>
> Sherman - you sponsored Brandon's previous update to Formatter, are
> you planning to do the same this time?

Sure, I can do it.


From brandon.passanisi at oracle.com Wed Jan 4 18:26:45 2012
From: brandon.passanisi at oracle.com (Brandon Passanisi)
Date: Wed, 04 Jan 2012 10:26:45 -0800
Subject: Code review request for #6469160, #7088271
Message-ID: <4F0499E5.1060509@oracle.com>

Resending...

Hello core-libs. I was wondering of somebody could be please review the
following fix for #6469160 and #7088271. The changes in the webrev fix
both bugs. Information is below:

Webrev URL: http://cr.openjdk.java.net/~bpassani/6469160_7088271/1/
<http://cr.openjdk.java.net/%7Ebpassani/6469160_7088271/1/>
Bug #6469160: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469160
Bug #7088271: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7088271

Both bugs uncover the current behavior where using a 0 or 1 precision
value with a float zero causes an ArrayIndexOutOfBoundsException. The
current code in FormattedFloatingDecimal.java interprets the float zero
as "0.0" in the case where precision is 0 or 1 and returns the length of
it's characters as 3. Later in Formatter.addZeros(), the character
array "0.0" is passed in, but a new array of only 1 character is
allocated. When an System.arraycopy() is performed, the
ArrayIndexOutOfBoundsException occurs. In fact, when run with "-esa" an
AssertionError occurs at "assert (outPrec <= prec);" on line 3393 of
Formatter.java. The fix is for FormatedFloatingDecimal.java to
interpret the float zero as a single "0" because of the precision being
set to 0 or 1.

Since java has been throwing exceptions in these cases, I consulted with
the output of C's printf to make sure that the outputted strings are the
same. I updated the Formatter's Basic-X template of tests with a little
over 20 test format strings that were causing exceptions without the
change and the output of each is compared with the output from C's
printf with the same format string. And, I ran all of the Basic-X tests
to make sure there weren't any regressions in behavior.

Thanks.
--
Oracle <http://www.oracle.com>
Brandon Passanisi | Principle Member of Technical Staff


Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment


From kelly.ohair at oracle.com Thu Jan 5 01:59:32 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 4 Jan 2012 17:59:32 -0800
Subject: Need reviewer: ant script bug in jaxws
Message-ID: <782467F3-0E84-44E4-A87F-B164843D16D2@oracle.com>

For jdk8. Had this on my CR list for a long time. :^(

Need reviewer. This is an ant script change in jaxws

Minor issue of missing files:
META-INF/mailcap.default
META-INF/mimetypes.default
In the dist/lib/classes.jar file created by the jaxws build and delivered into the jdk.

7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar
http://cr.openjdk.java.net/~ohair/openjdk8/jaxws-missing-files/webrev/

-kto



From Alan.Bateman at oracle.com Thu Jan 5 12:39:44 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 05 Jan 2012 12:39:44 +0000
Subject: CFV: New core-libs Group Member: Brian Goetz
Message-ID: <4F059A10.1030401@oracle.com>


I hereby nominate Brian Goetz to membership of the core-libs group.

Brian doesn't need too much introduction. He's lead for OpenJDK's
Project Lambda, and while this project is sponsored by the compiler
group, is all about the libraries and their evolution too. He's an
existing committer on the JDK 7 and JDK 8 projects and well known from
his membership of JSR-166 that brought us java.util.concurrent and more.

Votes are due by Jan 18, 2012, 23.59 PST.

Only current members of the core-libs group [1] are eligible to vote on
this nomination. For lazy consensus voting instructions, see [2].

-Alan.

[1] http://openjdk.java.net/census#core-libs
[2] http://openjdk.java.net/groups/#member-vote


From dl at cs.oswego.edu Thu Jan 5 12:47:05 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 05 Jan 2012 07:47:05 -0500
Subject: CFV: New core-libs Group Member: Brian Goetz
In-Reply-To: <4F059A10.1030401@oracle.com>
References: <4F059A10.1030401@oracle.com>
Message-ID: <4F059BC9.3050406@cs.oswego.edu>

Vote: yes

It's weird that Brian was not already on this. Also David Holmes?

On 01/05/12 07:39, Alan Bateman wrote:
>
> I hereby nominate Brian Goetz to membership of the core-libs group.
>
> Brian doesn't need too much introduction. He's lead for OpenJDK's Project
> Lambda, and while this project is sponsored by the compiler group, is all about
> the libraries and their evolution too. He's an existing committer on the JDK 7
> and JDK 8 projects and well known from his membership of JSR-166 that brought us
> java.util.concurrent and more.
>
> Votes are due by Jan 18, 2012, 23.59 PST.
>
> Only current members of the core-libs group [1] are eligible to vote on this
> nomination. For lazy consensus voting instructions, see [2].
>
> -Alan.
>
> [1] http://openjdk.java.net/census#core-libs
> [2] http://openjdk.java.net/groups/#member-vote
>



From chris.hegarty at oracle.com Thu Jan 5 12:50:48 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 05 Jan 2012 12:50:48 +0000
Subject: CFV: New core-libs Group Member: Brian Goetz
In-Reply-To: <4F059A10.1030401@oracle.com>
References: <4F059A10.1030401@oracle.com>
Message-ID: <4F059CA8.5070003@oracle.com>

Vote: yes

-Chris.


From Alan.Bateman at oracle.com Thu Jan 5 13:08:23 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 05 Jan 2012 13:08:23 +0000
Subject: CFV: New core-libs Group Member: David Holmes
Message-ID: <4F05A0C7.5020304@oracle.com>

I hereby nominate David Holmes to membership of the core-libs group.

David doesn't need too much introduction. He is a reviewer on several
OpenJDK projects, including the HotSpot Express project, JDK 7 and JDK
8. He is a prolific reviewer, particularly for library changes discussed
on the core-libs mailing list. He's also a committer for the Lambda
Project and well known from his membership of JSR-166 that brought us
java.util.concurrent and more.

Votes are due by Jan 18, 2012, 23.59 PST.

Only current members of the core-libs group [1] are eligible to vote on
this nomination. For lazy consensus voting instructions, see [2].

-Alan.

[1] http://openjdk.java.net/census#core-libs
[2] http://openjdk.java.net/groups/#member-vote


From chris.hegarty at oracle.com Thu Jan 5 13:07:24 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 05 Jan 2012 13:07:24 +0000
Subject: CFV: New core-libs Group Member: David Holmes
In-Reply-To: <4F05A0C7.5020304@oracle.com>
References: <4F05A0C7.5020304@oracle.com>
Message-ID: <4F05A08C.2010803@oracle.com>

Vote: yes

-Chris.


From dl at cs.oswego.edu Thu Jan 5 13:19:32 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 05 Jan 2012 08:19:32 -0500
Subject: CFV: New core-libs Group Member: David Holmes
In-Reply-To: <4F05A0C7.5020304@oracle.com>
References: <4F05A0C7.5020304@oracle.com>
Message-ID: <4F05A364.1030801@cs.oswego.edu>

Vote: yes.

I guess I should have given you a few minutes to put out this CFV before
asking about it :-)

On 01/05/12 08:08, Alan Bateman wrote:
> I hereby nominate David Holmes to membership of the core-libs group.
>
> David doesn't need too much introduction. He is a reviewer on several OpenJDK
> projects, including the HotSpot Express project, JDK 7 and JDK 8. He is a
> prolific reviewer, particularly for library changes discussed on the core-libs
> mailing list. He's also a committer for the Lambda Project and well known from
> his membership of JSR-166 that brought us java.util.concurrent and more.
>
> Votes are due by Jan 18, 2012, 23.59 PST.
>
> Only current members of the core-libs group [1] are eligible to vote on this
> nomination. For lazy consensus voting instructions, see [2].
>
> -Alan.
>
> [1] http://openjdk.java.net/census#core-libs
> [2] http://openjdk.java.net/groups/#member-vote
>



From Alan.Bateman at oracle.com Thu Jan 5 13:30:31 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 05 Jan 2012 13:30:31 +0000
Subject: Code Review - CR# 7030573 insufficient disk space for large file
test
In-Reply-To: <4EF4AA0C.1010204@oracle.com>
References: <4EF4AA0C.1010204@oracle.com>
Message-ID: <4F05A5F7.5040805@oracle.com>

On 23/12/2011 16:19, Gary Adams wrote:
> The LargeFileAvailable regression test had intermittent failures
> when there was not sufficient space available to create
> a 7G temp file. This webrev presents a simple check to
> see if the available usable space is less than 7G and
> scales the test back accordingly.
>
> The original bug report suggests that the test be switched
> to use the current working directory rather than a temp
> file. I think that could be the wrong choice for an embedded
> system that might have the tests mounted from a remote
> file system. In that scenario, using the local temp file
> space provides a better solution for what this test is designed
> to check.
>
> http://cr.openjdk.java.net/~gadams/7030573/
The only thing is that when the test is scaled back too much then it no
longer tests the original issue. This test will create a sparse file on
file systems that support it and I suspect the reason it fails on
Solaris is that tmp is backed by swap. It might be better if we changed
the test to create the file in the current directory (or a sub-directory
of). It will be removed by jtreg if the test doesn't delete it.

-Alan




From Alan.Bateman at oracle.com Thu Jan 5 14:31:32 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 05 Jan 2012 14:31:32 +0000
Subject: Known issue?
java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java
In-Reply-To: <051AB6E5-8C79-452E-BF28-292D3C7C93DF@oracle.com>
References: <31DA93C9-C289-4143-873B-E13071442822@oracle.com>
<4EFEE480.2090603@oracle.com>
<051AB6E5-8C79-452E-BF28-292D3C7C93DF@oracle.com>
Message-ID: <4F05B444.9050509@oracle.com>

On 03/01/2012 19:18, Kelly O'Hair wrote:
> :
> WHOOSH ... something flew over my head, probably packets I don't understand... ;^)
>
> Let me know if I need to file a bug, or need to look closer at the system I was using, and what to look at.
>
I think it will require looking at the system, maybe libvirt isn't
needed. The test exercises multicasting on all interfaces that have it
enabled so one workaround is to just disable it on this interface
(ifconfig virbr0 -multicast). I think I would need to poke around on the
specific system to offer other suggestions.

-Alan


From kumar.x.srinivasan at oracle.COM Thu Jan 5 15:39:46 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Thu, 05 Jan 2012 07:39:46 -0800
Subject: CFV: New core-libs Group Member: David Holmes
In-Reply-To: <4F05A0C7.5020304@oracle.com>
References: <4F05A0C7.5020304@oracle.com>
Message-ID: <4F05C442.9070400@oracle.COM>

Vote: yes

Kumar

> I hereby nominate David Holmes to membership of the core-libs group.
>
> David doesn't need too much introduction. He is a reviewer on several
> OpenJDK projects, including the HotSpot Express project, JDK 7 and JDK
> 8. He is a prolific reviewer, particularly for library changes
> discussed on the core-libs mailing list. He's also a committer for the
> Lambda Project and well known from his membership of JSR-166 that
> brought us java.util.concurrent and more.
>
> Votes are due by Jan 18, 2012, 23.59 PST.
>
> Only current members of the core-libs group [1] are eligible to vote
> on this nomination. For lazy consensus voting instructions, see [2].
>
> -Alan.
>
> [1] http://openjdk.java.net/census#core-libs
> [2] http://openjdk.java.net/groups/#member-vote



From joe.darcy at oracle.com Thu Jan 5 17:43:27 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 05 Jan 2012 09:43:27 -0800
Subject: CFV: New core-libs Group Member: David Holmes
In-Reply-To: <4F05A0C7.5020304@oracle.com>
References: <4F05A0C7.5020304@oracle.com>
Message-ID: <4F05E13F.1010503@oracle.com>

Vote: yes

-Joe

On 1/5/2012 5:08 AM, Alan Bateman wrote:
> I hereby nominate David Holmes to membership of the core-libs group.
>
> David doesn't need too much introduction. He is a reviewer on several
> OpenJDK projects, including the HotSpot Express project, JDK 7 and JDK
> 8. He is a prolific reviewer, particularly for library changes
> discussed on the core-libs mailing list. He's also a committer for the
> Lambda Project and well known from his membership of JSR-166 that
> brought us java.util.concurrent and more.
>
> Votes are due by Jan 18, 2012, 23.59 PST.
>
> Only current members of the core-libs group [1] are eligible to vote
> on this nomination. For lazy consensus voting instructions, see [2].
>
> -Alan.
>
> [1] http://openjdk.java.net/census#core-libs
> [2] http://openjdk.java.net/groups/#member-vote


From xueming.shen at oracle.com Thu Jan 5 17:42:00 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 05 Jan 2012 09:42:00 -0800
Subject: CFV: New core-libs Group Member: Brian Goetz
In-Reply-To: <4F059A10.1030401@oracle.com>
References: <4F059A10.1030401@oracle.com>
Message-ID: <4F05E0E8.80608@oracle.com>

Vote: yes

On 01/05/2012 04:39 AM, Alan Bateman wrote:
>
> I hereby nominate Brian Goetz to membership of the core-libs group.
>
> Brian doesn't need too much introduction. He's lead for OpenJDK's
> Project Lambda, and while this project is sponsored by the compiler
> group, is all about the libraries and their evolution too. He's an
> existing committer on the JDK 7 and JDK 8 projects and well known from
> his membership of JSR-166 that brought us java.util.concurrent and more.
>
> Votes are due by Jan 18, 2012, 23.59 PST.
>
> Only current members of the core-libs group [1] are eligible to vote
> on this nomination. For lazy consensus voting instructions, see [2].
>
> -Alan.
>
> [1] http://openjdk.java.net/census#core-libs
> [2] http://openjdk.java.net/groups/#member-vote



From xueming.shen at oracle.com Thu Jan 5 17:42:25 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 05 Jan 2012 09:42:25 -0800
Subject: CFV: New core-libs Group Member: David Holmes
In-Reply-To: <4F05A0C7.5020304@oracle.com>
References: <4F05A0C7.5020304@oracle.com>
Message-ID: <4F05E101.4010402@oracle.com>

Vote: yes

On 01/05/2012 05:08 AM, Alan Bateman wrote:
> I hereby nominate David Holmes to membership of the core-libs group.
>
> David doesn't need too much introduction. He is a reviewer on several
> OpenJDK projects, including the HotSpot Express project, JDK 7 and JDK
> 8. He is a prolific reviewer, particularly for library changes
> discussed on the core-libs mailing list. He's also a committer for the
> Lambda Project and well known from his membership of JSR-166 that
> brought us java.util.concurrent and more.
>
> Votes are due by Jan 18, 2012, 23.59 PST.
>
> Only current members of the core-libs group [1] are eligible to vote
> on this nomination. For lazy consensus voting instructions, see [2].
>
> -Alan.
>
> [1] http://openjdk.java.net/census#core-libs
> [2] http://openjdk.java.net/groups/#member-vote



From joe.darcy at oracle.com Thu Jan 5 17:45:40 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 05 Jan 2012 09:45:40 -0800
Subject: CFV: New core-libs Group Member: Brian Goetz
In-Reply-To: <4F059A10.1030401@oracle.com>
References: <4F059A10.1030401@oracle.com>
Message-ID: <4F05E1C4.7020009@oracle.com>

Vote: yes

-Joe

On 1/5/2012 4:39 AM, Alan Bateman wrote:
>
> I hereby nominate Brian Goetz to membership of the core-libs group.
>
> Brian doesn't need too much introduction. He's lead for OpenJDK's
> Project Lambda, and while this project is sponsored by the compiler
> group, is all about the libraries and their evolution too. He's an
> existing committer on the JDK 7 and JDK 8 projects and well known from
> his membership of JSR-166 that brought us java.util.concurrent and more.
>
> Votes are due by Jan 18, 2012, 23.59 PST.
>
> Only current members of the core-libs group [1] are eligible to vote
> on this nomination. For lazy consensus voting instructions, see [2].
>
> -Alan.
>
> [1] http://openjdk.java.net/census#core-libs
> [2] http://openjdk.java.net/groups/#member-vote


From dl at cs.oswego.edu Thu Jan 5 17:58:32 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 05 Jan 2012 12:58:32 -0500
Subject: 100218: BigInteger staticRandom field
In-Reply-To: <4EA545BF-252D-44CD-B459-0567CCA80D54@cs.umd.edu>
References: <4F03A96E.1040101@cs.oswego.edu>
<4EA545BF-252D-44CD-B459-0567CCA80D54@cs.umd.edu>
Message-ID: <4F05E4C8.1070101@cs.oswego.edu>

On 01/05/12 01:02, Bill Pugh wrote:

> So I think the right thing to do is to abandon the original patch, and instead
> make the following changes:
>
> * add the following method to BigInteger public boolean
> *isProbablePrime*(int certainty, Random end) , which allows primality
> testing with arbitrary Random objects. In many cases, using a well seeded
> normal Random object will work just fine, and this will give users the
> ability to provide their own Random objects
> * Document SecureRandom to note that all instances of SecureRandom depend on
> a common shared source of randomness, and thus it can be a concurrency
> bottlenck.
> * Document that BigInteger.*isProbablePrime*(int certainty) is a concurrency
> bottleneck.

This all sounds perfect to me.
Joe Darcy - do you have any thoughts?

> * Add java.util.concurrent.MostlySecureRandom which uses /dev/random for
> seeding, and uses only the SHA1PRNG implementation provided by
> sun.security.provider.SecureRandom to generate subsequent randomness. Feel
> free to pick a name other than MostlySecureRandom. After the initial
> seeding, calls to generate randomness using a MostlySecureRandom should
> not use any shared values.

I think the only question is whether, given low expected usage, it would be
OK just to explain how to do this in some javadoc, and also provide in some
jsr166<n>.extras package.

-Doug



From joe.darcy at oracle.com Thu Jan 5 23:46:09 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 05 Jan 2012 15:46:09 -0800
Subject: Fraction
In-Reply-To: <4F008FE0.60501@tbee.org>
References: <4F008FE0.60501@tbee.org>
Message-ID: <4F063641.9070804@oracle.com>

Hello,

On 1/1/2012 8:54 AM, Tom Eugelink wrote:
>
> Hello guys,
>
> I was wondering if it was of any interest to OpenJFX to have a
> calculation class that does not round. I've got "Fraction" laying
> around, which does math using two BigIntegers, so it never even
> rounds. The API is roughly equivalent to BigDecimal, so you have
> methods like add, divide, etc.
>
> Any interest in adding such a class to Java?
>

The BigDecimal class can already preform exact computations. To get
exact behavior, use the version of add, subtract, etc. that takes a
single BigDecimal argument or the version that takes a BigDecimal
argument and a MathContext argument and pass a MathContext object with a
precision of 0. Of the four basic arithmetic operations, the most
interesting operation is divide since it can result in infinite inputs
(fractions that are non-terminating in decimal) from finite inputs while
the other operations cannot.

In terms of its representation, BigDecimal class uses a floating-point
style scaled representation so that very large or very small numbers
that are low-precision don't use a lot of storage.

When doing general computations, there is a need to round result
periodically to avoid unbounded growth in the sizes of the numbers being
operated on. BigDecimal supports various rounding operations, including
rounding to a given number of places after the decimal point and
rounding to a given number of total digits. These styles of rounding
are relatively easy to understand, but still quite vexing for numerical
analysis.

The rounding options I'm familiar with for rational packages are fixed
slash vs floating-slash, that is, given constraints on the sizes of the
numerator and denominator, return the nearest fraction to the exact
result. AFAIK, such system are less studied if not more difficult to
work with than traditional rounding.

In short, while there would be some use cases, without additional
justification I don't see the need to add a rational number package to
the JDK.

Cheers,

-Joe



From mark.reinhold at oracle.com Fri Jan 6 05:32:39 2012
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 05 Jan 2012 21:32:39 -0800
Subject: CFV: New core-libs Group Member: David Holmes
In-Reply-To: alan.bateman@oracle.com; Thu, 05 Jan 2012 13:08:23 GMT;
<4F05A0C7.5020304@oracle.com>
Message-ID: <20120106053239.5875C1EEF@eggemoggin.niobe.net>

Vote: yes

- Mark


From mark.reinhold at oracle.com Fri Jan 6 05:32:09 2012
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 05 Jan 2012 21:32:09 -0800
Subject: CFV: New core-libs Group Member: Brian Goetz
In-Reply-To: alan.bateman@oracle.com; Thu, 05 Jan 2012 12:39:44 GMT;
<4F059A10.1030401@oracle.com>
Message-ID: <20120106053209.8C6E110A1@eggemoggin.niobe.net>

Vote: yes

- Mark


From alan.bateman at oracle.com Fri Jan 6 15:01:57 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 06 Jan 2012 15:01:57 +0000
Subject: hg: jdk8/tl/jdk: 7127235: (fs) NPE in Files.walkFileTree if cached
attributes are GC'ed
Message-ID: <20120106150224.844CE478CF@hg.openjdk.java.net>

Changeset: 400cc379adb5
Author: alanb
Date: 2012-01-06 15:00 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/400cc379adb5

7127235: (fs) NPE in Files.walkFileTree if cached attributes are GC'ed
Reviewed-by: forax, chegar

! src/share/classes/java/nio/file/FileTreeWalker.java



From kelly.ohair at oracle.com Fri Jan 6 18:35:49 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Fri, 6 Jan 2012 10:35:49 -0800
Subject: Fwd: Need reviewer: ant script bug in jaxws
References: <782467F3-0E84-44E4-A87F-B164843D16D2@oracle.com>
Message-ID: <3D95202C-CE48-4C35-89D7-8AAB68B55402@oracle.com>

Still need a reviewer for this small change. Any volunteers?

-kto

Begin forwarded message:

> From: "Kelly O'Hair" <kelly.ohair at oracle.com>
> Subject: Need reviewer: ant script bug in jaxws
> Date: January 4, 2012 17:59:32 PM PST
> To: core-libs-dev Libs <core-libs-dev at openjdk.java.net>
> Cc: miroslav.kos at oracle.com
>
> For jdk8. Had this on my CR list for a long time. :^(
>
> Need reviewer. This is an ant script change in jaxws
>
> Minor issue of missing files:
> META-INF/mailcap.default
> META-INF/mimetypes.default
> In the dist/lib/classes.jar file created by the jaxws build and delivered into the jdk.
>
> 7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar
> http://cr.openjdk.java.net/~ohair/openjdk8/jaxws-missing-files/webrev/
>
> -kto
>



From valerie.peng at oracle.com Fri Jan 6 19:05:01 2012
From: valerie.peng at oracle.com (valerie.peng at oracle.com)
Date: Fri, 06 Jan 2012 19:05:01 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20120106190520.A8FB5478D2@hg.openjdk.java.net>

Changeset: cdc128128044
Author: valeriep
Date: 2012-01-05 18:18 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdc128128044

6414899: P11Digest should support cloning
Summary: Enhanced the PKCS11 Digest implementation to support cloning
Reviewed-by: vinnie

! make/sun/security/pkcs11/mapfile-vers
! src/share/classes/sun/security/pkcs11/P11Digest.java
! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java
! src/share/lib/security/sunpkcs11-solaris.cfg
! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h
+ test/sun/security/pkcs11/MessageDigest/TestCloning.java

Changeset: e6ef778c1df4
Author: valeriep
Date: 2012-01-06 11:02 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6ef778c1df4

Merge




From gary.adams at oracle.com Fri Jan 6 19:47:34 2012
From: gary.adams at oracle.com (Gary Adams)
Date: Fri, 06 Jan 2012 14:47:34 -0500
Subject: Code Review - CR# 7030573 insufficient disk space for large file
test
In-Reply-To: <4F05A5F7.5040805@oracle.com>
References: <4EF4AA0C.1010204@oracle.com> <4F05A5F7.5040805@oracle.com>
Message-ID: <4F074FD6.5030907@oracle.com>

On 01/ 5/12 08:30 AM, Alan Bateman wrote:
> On 23/12/2011 16:19, Gary Adams wrote:
>> The LargeFileAvailable regression test had intermittent failures
>> when there was not sufficient space available to create
>> a 7G temp file. This webrev presents a simple check to
>> see if the available usable space is less than 7G and
>> scales the test back accordingly.
>>
>> The original bug report suggests that the test be switched
>> to use the current working directory rather than a temp
>> file. I think that could be the wrong choice for an embedded
>> system that might have the tests mounted from a remote
>> file system. In that scenario, using the local temp file
>> space provides a better solution for what this test is designed
>> to check.
>>
>> http://cr.openjdk.java.net/~gadams/7030573/
> The only thing is that when the test is scaled back too much then it no longer
> tests the original issue. This test will create a sparse file on file systems
> that support it and I suspect the reason it fails on Solaris is that tmp is
> backed by swap. It might be better if we changed the test to create the file
> in the current directory (or a sub-directory of). It will be removed by jtreg
> if the test doesn't delete it.
>
> -Alan
>
>
I've updated the webrev with the temp file created in the current directory.

I'm not sure what to do about the case if there is only a little space available
only a small file will be used. Should the test fail and force the test operator
to create a new test environment where 7G space is available?

I lean toward allowing the test to pass using the space that is available.


From Alan.Bateman at oracle.com Fri Jan 6 20:32:59 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 06 Jan 2012 20:32:59 +0000
Subject: Code Review - CR# 7030573 insufficient disk space for large file
test
In-Reply-To: <4F074FD6.5030907@oracle.com>
References: <4EF4AA0C.1010204@oracle.com> <4F05A5F7.5040805@oracle.com>
<4F074FD6.5030907@oracle.com>
Message-ID: <4F075A7B.8050004@oracle.com>

On 06/01/2012 19:47, Gary Adams wrote:
>
> I've updated the webrev with the temp file created in the current
> directory.
>
> I'm not sure what to do about the case if there is only a little space
> available
> only a small file will be used. Should the test fail and force the
> test operator
> to create a new test environment where 7G space is available?
>
> I lean toward allowing the test to pass using the space that is
> available.
I looked briefly at the updated webrev and I see it checks the usable
space on the file system/volume where the current directory is but
creates the file in the temporary directory, easily done :-)

I think you're right that the best we can do when there is insufficient
space is just to run with the small file. It doesn't test the original
issue but we don't want this test failing when there isn't sufficient space.

Rather than creating largefile, deleting it, and then creating it again
(twice) then how about:

File file = File.createTempFile("largefile", null, new File("."));
long usableSpace = largefile.getUsableSpace();
if (usuableSpace == 0L)
throw new RuntimeException(...);
long size = Math.min(usableSpace, 7405576182L);
recreateAsLargeFile(file, size);

-Alan.








From valerie.peng at oracle.com Sat Jan 7 00:12:58 2012
From: valerie.peng at oracle.com (valerie.peng at oracle.com)
Date: Sat, 07 Jan 2012 00:12:58 +0000
Subject: hg: jdk8/tl/jdk: 7033170: Cipher.getMaxAllowedKeyLength(String)
throws NoSuchAlgorithmException
Message-ID: <20120107001308.B7DB7478D8@hg.openjdk.java.net>

Changeset: 6720ae7b1448
Author: valeriep
Date: 2012-01-06 16:06 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6720ae7b1448

7033170: Cipher.getMaxAllowedKeyLength(String) throws NoSuchAlgorithmException
Summary: Changed to always use full transformation as provider properties.
Reviewed-by: mullan

! src/share/classes/sun/security/pkcs11/SunPKCS11.java
! test/javax/crypto/Cipher/GetMaxAllowed.java



From joe.darcy at oracle.com Sat Jan 7 03:13:07 2012
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Sat, 07 Jan 2012 03:13:07 +0000
Subject: hg: jdk8/tl/jdk: 7123649: Remove public modifier from
Math.powerOfTwoF.
Message-ID: <20120107031317.03BA7478DB@hg.openjdk.java.net>

Changeset: 2050ff9dfc92
Author: darcy
Date: 2012-01-06 18:47 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2050ff9dfc92

7123649: Remove public modifier from Math.powerOfTwoF.
Reviewed-by: smarks, alanb

! src/share/classes/java/lang/Math.java



From tbuktu at hotmail.com Sat Jan 7 21:10:44 2012
From: tbuktu at hotmail.com (Tim Buktu)
Date: Sat, 7 Jan 2012 14:10:44 -0700
Subject: Review request: Fast multiplication and division
Message-ID: <BLU0-SMTP1834158AEF452F0E964F245C69A0@phx.gbl>

Hi everyone,

I made a patch against the latest BigInteger.java that speeds up
multiplication and division of large numbers. It is based on Alan
Eliasen's excellent work which unfortunately hasn't been included yet.

There are three algorithms in this patch,
1) Karatsuba multiplication which is used above ~480 decimal digits;
2) Toom-Cook multiplication which is used above ~720 decimal digits;
3) Burnikel-Ziegler division which is used above ~480 decimal digits.

Karatsuba and Toom-Cook were implemented by Alan, and Burnikel-Ziegler
was implemented by me. I have reviewed Alan's code, and I verified that
the patched BigInteger passes BigIntegerTest (using suitable lengths) as
well as my own tests.

On my machine, the speedup for multiplication is as follows:
* 1.3 times faster for 1,000-digit numbers
* 3.9 times faster for 10,000-digit numbers
* 12.4 times faster for 100,000-digit numbers

The speedup for division is as follows:
* 1.4 times faster for 1,000-digit numbers
* 3.4 times faster for 10,000-digit numbers
* 10.4 times faster for 100,000-digit numbers

The patch is at https://gist.github.com/1576016
and the patched BigInteger.java is at https://gist.github.com/1576025 .
Thanks,

Tim


From david.holmes at oracle.com Sun Jan 8 23:35:36 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 09 Jan 2012 09:35:36 +1000
Subject: Fwd: Need reviewer: ant script bug in jaxws
In-Reply-To: <3D95202C-CE48-4C35-89D7-8AAB68B55402@oracle.com>
References: <782467F3-0E84-44E4-A87F-B164843D16D2@oracle.com>
<3D95202C-CE48-4C35-89D7-8AAB68B55402@oracle.com>
Message-ID: <4F0A2848.1070309@oracle.com>

Hi Kelly,

On 7/01/2012 4:35 AM, Kelly O'Hair wrote:
> Still need a reviewer for this small change. Any volunteers?

Seems okay. Did we determine how they went missing in the first place?

David
-----


> -kto
>
> Begin forwarded message:
>
>> From: "Kelly O'Hair"<kelly.ohair at oracle.com>
>> Subject: Need reviewer: ant script bug in jaxws
>> Date: January 4, 2012 17:59:32 PM PST
>> To: core-libs-dev Libs<core-libs-dev at openjdk.java.net>
>> Cc: miroslav.kos at oracle.com
>>
>> For jdk8. Had this on my CR list for a long time. :^(
>>
>> Need reviewer. This is an ant script change in jaxws
>>
>> Minor issue of missing files:
>> META-INF/mailcap.default
>> META-INF/mimetypes.default
>> In the dist/lib/classes.jar file created by the jaxws build and delivered into the jdk.
>>
>> 7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar
>> http://cr.openjdk.java.net/~ohair/openjdk8/jaxws-missing-files/webrev/
>>
>> -kto
>>
>


From gary.adams at oracle.com Mon Jan 9 15:26:29 2012
From: gary.adams at oracle.com (Gary Adams)
Date: Mon, 09 Jan 2012 10:26:29 -0500
Subject: Code Review - CR# 7030573 insufficient disk space for large file
test
In-Reply-To: <4F075A7B.8050004@oracle.com>
References: <4EF4AA0C.1010204@oracle.com> <4F05A5F7.5040805@oracle.com>
<4F074FD6.5030907@oracle.com> <4F075A7B.8050004@oracle.com>
Message-ID: <4F0B0725.8010908@oracle.com>

On 01/ 6/12 03:32 PM, Alan Bateman wrote:
> On 06/01/2012 19:47, Gary Adams wrote:
>>
>> I've updated the webrev with the temp file created in the current directory.
>>
>> I'm not sure what to do about the case if there is only a little space available
>> only a small file will be used. Should the test fail and force the test operator
>> to create a new test environment where 7G space is available?
>>
>> I lean toward allowing the test to pass using the space that is available.
> I looked briefly at the updated webrev and I see it checks the usable space on
> the file system/volume where the current directory is but creates the file in
> the temporary directory, easily done :-)
>
> I think you're right that the best we can do when there is insufficient space
> is just to run with the small file. It doesn't test the original issue but we
> don't want this test failing when there isn't sufficient space.
>
> Rather than creating largefile, deleting it, and then creating it again
> (twice) then how about:
>
> File file = File.createTempFile("largefile", null, new File("."));
> long usableSpace = largefile.getUsableSpace();
> if (usuableSpace == 0L)
> throw new RuntimeException(...);
> long size = Math.min(usableSpace, 7405576182L);
> recreateAsLargeFile(file, size);
>
A fresh webrev is available :
http://cr.openjdk.java.net/~gadams/7030573/

Includes the following changes
- moved temp file create into main
- use Math.min for selecting 7G or space available
and for skip size
- added runtime exception if no space available
- reformatting to wrap >80 column lines


From Alan.Bateman at oracle.com Mon Jan 9 16:23:53 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 09 Jan 2012 16:23:53 +0000
Subject: Code Review - CR# 7030573 insufficient disk space for large file
test
In-Reply-To: <4F0B0725.8010908@oracle.com>
References: <4EF4AA0C.1010204@oracle.com> <4F05A5F7.5040805@oracle.com>
<4F074FD6.5030907@oracle.com> <4F075A7B.8050004@oracle.com>
<4F0B0725.8010908@oracle.com>
Message-ID: <4F0B1499.1020609@oracle.com>

On 09/01/2012 15:26, Gary Adams wrote:
> A fresh webrev is available :
>
> http://cr.openjdk.java.net/~gadams/7030573/
>
> Includes the following changes
> - moved temp file create into main
> - use Math.min for selecting 7G or space available
> and for skip size
> - added runtime exception if no space available
> - reformatting to wrap >80 column lines
This looks okay to me. I'll add the bugID to the @bug tag before pushing
it for you.

-Alan.


From kelly.ohair at oracle.com Mon Jan 9 17:09:47 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Mon, 9 Jan 2012 09:09:47 -0800
Subject: Need reviewer: ant script bug in jaxws
In-Reply-To: <4F0A2848.1070309@oracle.com>
References: <782467F3-0E84-44E4-A87F-B164843D16D2@oracle.com>
<3D95202C-CE48-4C35-89D7-8AAB68B55402@oracle.com>
<4F0A2848.1070309@oracle.com>
Message-ID: <C3EFB94F-5DEE-486F-AC12-7441A730CE4C@oracle.com>


On Jan 8, 2012, at 3:35 PM, David Holmes wrote:

> Hi Kelly,
>
> On 7/01/2012 4:35 AM, Kelly O'Hair wrote:
>> Still need a reviewer for this small change. Any volunteers?
>
> Seems okay. Did we determine how they went missing in the first place?

A long long time ago, when we did the split of jaxws sources from the jdk, this got broken.
For the most part, nobody noticed.

This is another reason why we need a good 'compare these two jdk images' tool. :^(

-kto

>
> David
> -----
>
>
>> -kto
>>
>> Begin forwarded message:
>>
>>> From: "Kelly O'Hair"<kelly.ohair at oracle.com>
>>> Subject: Need reviewer: ant script bug in jaxws
>>> Date: January 4, 2012 17:59:32 PM PST
>>> To: core-libs-dev Libs<core-libs-dev at openjdk.java.net>
>>> Cc: miroslav.kos at oracle.com
>>>
>>> For jdk8. Had this on my CR list for a long time. :^(
>>>
>>> Need reviewer. This is an ant script change in jaxws
>>>
>>> Minor issue of missing files:
>>> META-INF/mailcap.default
>>> META-INF/mimetypes.default
>>> In the dist/lib/classes.jar file created by the jaxws build and delivered into the jdk.
>>>
>>> 7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar
>>> http://cr.openjdk.java.net/~ohair/openjdk8/jaxws-missing-files/webrev/
>>>
>>> -kto
>>>
>>



From dmitry.nadezhin at gmail.com Mon Jan 9 17:13:46 2012
From: dmitry.nadezhin at gmail.com (Dmitry Nadezhin)
Date: Mon, 9 Jan 2012 20:13:46 +0300
Subject: Fraction
In-Reply-To: <4F063641.9070804@oracle.com>
References: <4F008FE0.60501@tbee.org>
<4F063641.9070804@oracle.com>
Message-ID: <CAAUNa5s817aJ_yiykuyNoU9ERK7MOd14sUtUemjaz5GR6AZi1g@mail.gmail.com>

Hello Joe,

Thank you for the clarification.

What do you think about using BigBinary to solve the problem of a
calculation class with higher precision.
BigBinary implements arbitrary precision binary floating-point numbers
and arithmetic operations on them.
Although it rounds, the precision and rounding direction are controlled.
It seems to me that binary floating-point numbers are more natural
than decimal for scientific applications.
Should such a class be in the JDK or outside?

If you don't think that BigBinary is appropriate, then let me ask some
other questions.
IEEE 754-2008 defines three basic binary formats: Binary32, Binary64,
Binary128 .
Binary32 and Binary64 are already known in JDK as Float and Double
(with rounding to nearest even).
Should there be a software emulation of Binary128 in JDK (as a class
with two private long fields)?
Should the JDK have a class with static methods that implement
arithmetic operations on floats and doubles with directed rounding like
http://java.net/projects/projectfortress/sources/sources/content/ProjectFortress/src/com/sun/fortress/numerics/DirectedRounding.java
?
Is there a chance that Binary128 or DirectedRounding methods would be
internalized in hotspot?

These questions are important to me because I am working on an
interval arithmetic library
http://kenai.com/projects/jinterval/ and could use these new classes.

I understand that the addition of numerical features to the JDK is closed.
However, if there is a chance to add any new classes, I'd be glad to
contibute to their development.

Cheers,

-Dima


On Fri, Jan 6, 2012 at 2:46 AM, Joe Darcy <joe.darcy at oracle.com> wrote:
> Hello,
>
>
> On 1/1/2012 8:54 AM, Tom Eugelink wrote:
>>
>>
>> Hello guys,
>>
>> I was wondering if it was of any interest to OpenJFX to have a calculation
>> class that does not round. I've got "Fraction" laying around, which does
>> math using two BigIntegers, so it never even rounds. The API is roughly
>> equivalent to BigDecimal, so you have methods like add, divide, etc.
>>
>> Any interest in adding such a class to Java?
>>
>
> The BigDecimal class can already preform exact computations. ?To get exact
> behavior, use the version of add, subtract, etc. that takes a single
> BigDecimal argument or the version that takes a BigDecimal argument and a
> MathContext argument and pass a MathContext object with a precision of 0.
> ?Of the four basic arithmetic operations, the most interesting operation is
> divide since it can result in infinite inputs (fractions that are
> non-terminating in decimal) from finite inputs while the other operations
> cannot.
>
> In terms of its representation, BigDecimal class uses a floating-point style
> scaled representation so that very large or very small numbers that are
> low-precision don't use a lot of storage.
>
> When doing general computations, there is a need to round result
> periodically to avoid unbounded growth in the sizes of the numbers being
> operated on. ?BigDecimal supports various rounding operations, including
> rounding to a given number of places after the decimal point and rounding to
> a given number of total digits. ?These styles of rounding are relatively
> easy to understand, but still quite vexing for numerical analysis.
>
> The rounding options I'm familiar with for rational packages are fixed slash
> vs floating-slash, that is, given constraints on the sizes of the numerator
> and denominator, return the nearest fraction to the exact result. ?AFAIK,
> such system are less studied if not more difficult to work with than
> traditional rounding.
>
> In short, while there would be some use cases, without additional
> justification I don't see the need to add a rational number package to the
> JDK.
>
> Cheers,
>
> -Joe
>


From alan.bateman at oracle.com Mon Jan 9 19:33:51 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 09 Jan 2012 19:33:51 +0000
Subject: hg: jdk8/tl/jdk: 7030573:
test/java/io/FileInputStream/LargeFileAvailable.java fails when
there is insufficient disk space
Message-ID: <20120109193414.B83CB478F2@hg.openjdk.java.net>

Changeset: 74c92c3e66ad
Author: gadams
Date: 2012-01-09 19:33 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74c92c3e66ad

7030573: test/java/io/FileInputStream/LargeFileAvailable.java fails when there is insufficient disk space
Reviewed-by: alanb

! test/java/io/FileInputStream/LargeFileAvailable.java



From joe.darcy at oracle.com Mon Jan 9 23:55:51 2012
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Mon, 09 Jan 2012 23:55:51 +0000
Subject: hg: jdk8/tl/jdk: 7128441: StrictMath performance improvement note
shared with Math
Message-ID: <20120109235609.65D34478F6@hg.openjdk.java.net>

Changeset: 858038d89fd5
Author: darcy
Date: 2012-01-09 15:54 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/858038d89fd5

7128441: StrictMath performance improvement note shared with Math
Reviewed-by: darcy
Contributed-by: Martin Desruisseaux <martin.desruisseaux at geomatys.fr>

! src/share/classes/java/lang/Math.java
! src/share/classes/java/lang/StrictMath.java



From joe.darcy at oracle.com Mon Jan 9 23:58:34 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 09 Jan 2012 15:58:34 -0800
Subject: StrictMath performance improvement not ported to Math?
In-Reply-To: <4ECC1861.3090604@geomatys.fr>
References: <4EC66BD2.5050205@geomatys.fr> <4ECB14E0.9040205@oracle.com>
<4ECC1861.3090604@geomatys.fr>
Message-ID: <4F0B7F2A.6050405@oracle.com>

Hello Martin,

Catching up after the holidays, I built a JDK with your patch and all
the relevant regression tests passed and I've just pushed the changes to
JDK 8's TL integration repository:

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/858038d89fd5

Thanks,

-Joe

On 11/22/2011 1:47 PM, Martin Desruisseaux wrote:
> Hello Joe
>
> Le 22/11/11 04:20, Joe Darcy a ?crit :
>>> 3) In if statements, replaced:
>>>
>>> (a == 0.0d) && (Double.doubleToLongBits(a) == negativeZeroDoubleBits)
>>> by
>>> (Double.doubleToLongBits(a) == negativeZeroDoubleBits)
>>>
>>> since the later implies the former.
>>
>> The performance properties of the two versions of the code may differ
>> depending on the frequency of zeros in the input and the cost of the
>> bitwise conversion operation. I'd prefer to leave the code logic
>> as-is in absence of some benchmarking that showed a helpful difference.
> I presumed that Double.doubleToRawLongBits(a) - I forgot the "Raw" in
> my previous post - was very cheap after HotSpot intrinsics (which
> exist according vmSymbols.hpp). If my old memory from 80286 assembler
> still have some value, it would have simply be a matter of comparing
> the value from the same memory address using a different machine
> instruction. But obviously this is only supposition, today picture is
> very different and I have no benchmark for confirming or refuting my
> supposition?
>
>
>> I'd prefer to see a webrev with:
>>
>> * All min/max logic from StrictMath moved into math, including for
>> the integral types int and long
>> * All StrictMath min/max methods delegating to their Math counterpart
> Done. I updated the webrev at the same URL:
> http://webrev.geomatys.com/Math/min_max/index.html
> The new Math code is a verbatim copy-and-paste from StrictMath,
> including the formatting.
>
> I also made StrictMath.abs methods delegating to their Math
> counterpart, after making sure that the code was really identical.
> After this change, the only remaining duplicated code is toDegrees and
> toRadians. For those two methods, I added a comment saying why
> StrictMath dos not delegate to Math for them (because the StrictMath
> methods have the "strictfp" modifier - but this modifier is easy to
> miss, so a comment may be a worthy safety).
>
>
>> * Verification all java/lang/Math and java/lang/StrictMath regression
>> tests still pass
> I quicky tried, but it seems to be a bit tricky for me since I'm on a
> MacOS machine. Maybe it will be easier when the MacOS port project
> will be completed...
>
> Martin
>



From neil.richards at ngmr.net Tue Jan 10 01:05:33 2012
From: neil.richards at ngmr.net (Neil Richards)
Date: Tue, 10 Jan 2012 01:05:33 +0000
Subject: Request for review: 7123229: (coll) EnumMap.containsValue(null)
returns true
Message-ID: <1326157533.18727.31.camel@chalkhill>

Hi all,
When proposing the change for 6312706 [1], I erroneously managed to
convince myself (and others!) that it would be safe to use 'new
Integer(0)' for java.util.EnumMap.NULL (the object used to mark null
values for entries in the map) [2].

This was on the basis that I thought it was only compared by identity.
However, on closer inspection, this turns out not to be the case.

7123229 was raised to report the bug that was introduced based on this
invalid assumption.

I've created a webrev with a suggested fix for 7123229 [3], which
changes NULL to be an Object which:
* will only return 'true' from equals(Object) for itself
* returns 0 from hashCode()

For good measure, it also returns a sensible value from toString().

Please review this fix and let me know your thoughts,
Thanks,
Neil

[1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c1e87a18e46a
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-March/006353.html
[3] http://cr.openjdk.java.net/~ngmr/7123229/webrev.00/

--
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 joe.darcy at oracle.com Tue Jan 10 02:17:48 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 09 Jan 2012 18:17:48 -0800
Subject: Code review request for javadoc problem in
java.lang.invoke.MethodHandle
Message-ID: <4F0B9FCC.6030402@oracle.com>

Hello,

Please review the simple patch below to fix a javadoc problem in
java.lang.invoke.MethodHandle which stems from the arguments to the
{@link} javadoc tag being reversed.

Once reviewed, I'll file a bug for this and push the fix.

Thanks,

-Joe

diff -r 858038d89fd5 src/share/classes/java/lang/invoke/MethodHandle.java
--- a/src/share/classes/java/lang/invoke/MethodHandle.java Mon Jan 09
15:54:44 2012 -0800
+++ b/src/share/classes/java/lang/invoke/MethodHandle.java Mon Jan 09
18:14:23 2012 -0800
@@ -275,7 +275,7 @@
* generates a single invokevirtual instruction with
* the symbolic type descriptor indicated in the following comment.
* In these examples, the helper method {@code assertEquals} is assumed to
- * be a method which calls {@link Objects.equals java.util.Objects#equals}
+ * be a method which calls {@link
java.util.Objects#equals(Object,Object) Objects.equals }
* on its arguments, and asserts that the result is true.
*
* <h3>Exceptions</h3>



From luchsh at linux.vnet.ibm.com Tue Jan 10 03:09:27 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Tue, 10 Jan 2012 11:09:27 +0800
Subject: Patch to expand tz checking scope in TimeZone_md.c
In-Reply-To: <4EB105D1.9020401@linux.vnet.ibm.com>
References: <4EB105D1.9020401@linux.vnet.ibm.com>
Message-ID: <4F0BABE7.7060507@linux.vnet.ibm.com>

Hi core-libs-dev,

Here's another approach to just add a defined(AIX) check to make sure it
works on Aix platform.
http://cr.openjdk.java.net/~luchsh/timezone_md_ret_check/

Any suggestions?

Cheers,
- Jonathan

On 11/02/2011 04:56 PM, Jonathan Lu wrote:
> Hi core-libs-dev,
>
> In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from line
> 626, I found that the scope of "#ifdef __solaris__" might be too
> narrow, since it also works for some kind of OS which I'm currently
> working on, such as AIX.
> So I suggest to just remove the '#ifdef __solaris__' and leave the
> "#else" to accommodate more conditions, see attachment 'patch.diff'. I
> think this may enhance the cross-platform ability, any ideas about
> this modification?
>
> Regards
> - Jonathan Lu



From mike.duigou at oracle.com Tue Jan 10 03:43:58 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 9 Jan 2012 19:43:58 -0800
Subject: Request for review: 7123229: (coll) EnumMap.containsValue(null)
returns true
In-Reply-To: <1326157533.18727.31.camel@chalkhill>
References: <1326157533.18727.31.camel@chalkhill>
Message-ID: <4822D106-8F4C-4716-8E4E-889774066B03@oracle.com>

This looks correct. I appreciate the toString() method with a unique result.

Mike

On Jan 9 2012, at 17:05 , Neil Richards wrote:

> Hi all,
> When proposing the change for 6312706 [1], I erroneously managed to
> convince myself (and others!) that it would be safe to use 'new
> Integer(0)' for java.util.EnumMap.NULL (the object used to mark null
> values for entries in the map) [2].
>
> This was on the basis that I thought it was only compared by identity.
> However, on closer inspection, this turns out not to be the case.
>
> 7123229 was raised to report the bug that was introduced based on this
> invalid assumption.
>
> I've created a webrev with a suggested fix for 7123229 [3], which
> changes NULL to be an Object which:
> * will only return 'true' from equals(Object) for itself
> * returns 0 from hashCode()
>
> For good measure, it also returns a sensible value from toString().
>
> Please review this fix and let me know your thoughts,
> Thanks,
> Neil
>
> [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c1e87a18e46a
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-March/006353.html
> [3] http://cr.openjdk.java.net/~ngmr/7123229/webrev.00/
>
> --
> 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 mike.duigou at oracle.com Tue Jan 10 03:44:59 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 9 Jan 2012 19:44:59 -0800
Subject: Code review request for javadoc problem in
java.lang.invoke.MethodHandle
In-Reply-To: <4F0B9FCC.6030402@oracle.com>
References: <4F0B9FCC.6030402@oracle.com>
Message-ID: <2AD06CD1-A3A2-40B9-83FE-A46A5CD17B33@oracle.com>

+1

On Jan 9 2012, at 18:17 , Joe Darcy wrote:

> Hello,
>
> Please review the simple patch below to fix a javadoc problem in java.lang.invoke.MethodHandle which stems from the arguments to the {@link} javadoc tag being reversed.
>
> Once reviewed, I'll file a bug for this and push the fix.
>
> Thanks,
>
> -Joe
>
> diff -r 858038d89fd5 src/share/classes/java/lang/invoke/MethodHandle.java
> --- a/src/share/classes/java/lang/invoke/MethodHandle.java Mon Jan 09 15:54:44 2012 -0800
> +++ b/src/share/classes/java/lang/invoke/MethodHandle.java Mon Jan 09 18:14:23 2012 -0800
> @@ -275,7 +275,7 @@
> * generates a single invokevirtual instruction with
> * the symbolic type descriptor indicated in the following comment.
> * In these examples, the helper method {@code assertEquals} is assumed to
> - * be a method which calls {@link Objects.equals java.util.Objects#equals}
> + * be a method which calls {@link java.util.Objects#equals(Object,Object) Objects.equals }
> * on its arguments, and asserts that the result is true.
> *
> * <h3>Exceptions</h3>
>



From joe.darcy at oracle.com Tue Jan 10 04:14:46 2012
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Tue, 10 Jan 2012 04:14:46 +0000
Subject: hg: jdk8/tl/jdk: 7128512: Javadoc typo in
java.lang.invoke.MethodHandle
Message-ID: <20120110041508.719D4478FB@hg.openjdk.java.net>

Changeset: dd69d3695cee
Author: darcy
Date: 2012-01-09 20:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd69d3695cee

7128512: Javadoc typo in java.lang.invoke.MethodHandle
Reviewed-by: mduigou

! src/share/classes/java/lang/invoke/MethodHandle.java



From tbuktu at hotmail.com Tue Jan 10 05:01:35 2012
From: tbuktu at hotmail.com (Tim Buktu)
Date: Mon, 9 Jan 2012 22:01:35 -0700
Subject: Updated unit test for BigInteger patch (#4837946)
In-Reply-To: <BLU0-SMTP1834158AEF452F0E964F245C69A0@phx.gbl>
References: <BLU0-SMTP1834158AEF452F0E964F245C69A0@phx.gbl>
Message-ID: <BLU0-SMTP220B8AE166DE1CB2D348063C6990@phx.gbl>

I updated BigIntegerTest so it tests the existing multiplication and
division algorithms as well as the ones added by my (and Alan's)
BigInteger patch.

This patch also adds a 6th type of random number to the 5 already
present. The new type outputs random numbers that contain long runs of
1-bits and 0-bits. GMP uses these numbers because apparently they are a
good way to trigger bugs in bigint arithmetic.

The patch is at https://gist.github.com/1586984
The whole BigIntegerTest.java file is at https://gist.github.com/1586990

I forgot to mention in my previous email that this is for bug 4837946.
Thanks,

Tim


From rednaxelafx at gmail.com Tue Jan 10 05:51:50 2012
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Tue, 10 Jan 2012 13:51:50 +0800
Subject: typo in sun.misc.VM's comment
Message-ID: <CA+cQ+tTVx=kgGoc7t3p_0gx6uuW41aiv1q0fQjDYpW50R2HrGg@mail.gmail.com>

Hi all,

Just found a little typo in sun.misc.VM:

diff -r 00e2c88e2234 src/share/classes/sun/misc/VM.java
--- a/src/share/classes/sun/misc/VM.java Thu Nov 17 10:46:02 2011 -0800
+++ b/src/share/classes/sun/misc/VM.java Tue Jan 10 13:42:52 2012 +0800
@@ -167,7 +167,7 @@
//
// The initial value of this field is arbitrary; during JRE
initialization
// it will be reset to the value specified on the command line, if any,
- // otherwise to Runtime.getRuntime.maxDirectMemory().
+ // otherwise to Runtime.getRuntime().maxMemory().
//
private static long directMemory = 64 * 1024 * 1024;


I was looking for the default max direct memory size when I found this
comment. It would have been nice if this typo was fixed in 6977738. [1]
Could anybody include this fix in some future commits?

Regards,
Kris Mok

[1]: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/b444f86c4abe


From pcj at roundroom.net Tue Jan 10 06:31:58 2012
From: pcj at roundroom.net (Peter Jones)
Date: Tue, 10 Jan 2012 01:31:58 -0500
Subject: CFV: New core-libs Group Member: Brian Goetz
In-Reply-To: <4F059A10.1030401@oracle.com>
References: <4F059A10.1030401@oracle.com>
Message-ID: <EEAF3597-79C7-4AD2-ABFA-55C9C126ACD8@roundroom.net>

Vote: yes

-- Peter


On Jan 5, 2012, at 7:39 AM, Alan Bateman wrote:

> I hereby nominate Brian Goetz to membership of the core-libs group.
>
> Brian doesn't need too much introduction. He's lead for OpenJDK's Project Lambda, and while this project is sponsored by the compiler group, is all about the libraries and their evolution too. He's an existing committer on the JDK 7 and JDK 8 projects and well known from his membership of JSR-166 that brought us java.util.concurrent and more.
>
> Votes are due by Jan 18, 2012, 23.59 PST.
>
> Only current members of the core-libs group [1] are eligible to vote on this nomination. For lazy consensus voting instructions, see [2].
>
> -Alan.
>
> [1] http://openjdk.java.net/census#core-libs
> [2] http://openjdk.java.net/groups/#member-vote



From pcj at roundroom.net Tue Jan 10 06:32:10 2012
From: pcj at roundroom.net (Peter Jones)
Date: Tue, 10 Jan 2012 01:32:10 -0500
Subject: CFV: New core-libs Group Member: David Holmes
In-Reply-To: <4F05A0C7.5020304@oracle.com>
References: <4F05A0C7.5020304@oracle.com>
Message-ID: <2640AEA0-5F81-442C-AFF5-2CC06A5D0304@roundroom.net>

Vote: yes

-- Peter


On Jan 5, 2012, at 8:08 AM, Alan Bateman wrote:

> I hereby nominate David Holmes to membership of the core-libs group.
>
> David doesn't need too much introduction. He is a reviewer on several OpenJDK projects, including the HotSpot Express project, JDK 7 and JDK 8. He is a prolific reviewer, particularly for library changes discussed on the core-libs mailing list. He's also a committer for the Lambda Project and well known from his membership of JSR-166 that brought us java.util.concurrent and more.
>
> Votes are due by Jan 18, 2012, 23.59 PST.
>
> Only current members of the core-libs group [1] are eligible to vote on this nomination. For lazy consensus voting instructions, see [2].
>
> -Alan.
>
> [1] http://openjdk.java.net/census#core-libs
> [2] http://openjdk.java.net/groups/#member-vote



From john.r.rose at oracle.com Tue Jan 10 06:35:35 2012
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 9 Jan 2012 22:35:35 -0800
Subject: Code review request for javadoc problem in
java.lang.invoke.MethodHandle
In-Reply-To: <4F0B9FCC.6030402@oracle.com>
References: <4F0B9FCC.6030402@oracle.com>
Message-ID: <396DD247-1CF4-4C3F-9B8A-672512A4A46F@oracle.com>

Yes. Thanks, Joe. -- John

On Jan 9, 2012, at 6:17 PM, Joe Darcy wrote:

> Please review the simple patch below to fix a javadoc problem in java.lang.invoke.MethodHandle which stems from the arguments to the {@link} javadoc tag being reversed.



From joe.darcy at oracle.com Tue Jan 10 07:19:59 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 09 Jan 2012 23:19:59 -0800
Subject: 100218: BigInteger staticRandom field
In-Reply-To: <4F05E4C8.1070101@cs.oswego.edu>
References: <4F03A96E.1040101@cs.oswego.edu>
<4EA545BF-252D-44CD-B459-0567CCA80D54@cs.umd.edu>
<4F05E4C8.1070101@cs.oswego.edu>
Message-ID: <4F0BE69F.6000905@oracle.com>

Hello,

Catching up on email after the holidays...

On 01/05/2012 09:58 AM, Doug Lea wrote:
> On 01/05/12 01:02, Bill Pugh wrote:
>
>> So I think the right thing to do is to abandon the original patch,
>> and instead
>> make the following changes:
>>
>> * add the following method to BigInteger public boolean
>> *isProbablePrime*(int certainty, Random end) , which allows
>> primality
>> testing with arbitrary Random objects. In many cases, using a
>> well seeded
>> normal Random object will work just fine, and this will give
>> users the
>> ability to provide their own Random objects
>> * Document SecureRandom to note that all instances of
>> SecureRandom depend on
>> a common shared source of randomness, and thus it can be a
>> concurrency
>> bottlenck.
>> * Document that BigInteger.*isProbablePrime*(int certainty) is a
>> concurrency
>> bottleneck.
>
> This all sounds perfect to me.
> Joe Darcy - do you have any thoughts?

Hmmm. While the API changes appear fine at first, I'm a bit concerned
about how to make isProbablePrime*(int certainty, Random end) suitably
robust against possibly adversarial sources of randomness (all zeros,
all ones, etc.) The number-theoretic primarily tests used by the
existing isProbablePrime(int) rely on a good source of random bits; I'd
have to research what the weakest assumptions on the source of
randomness are for the existing checks to still be valid.

I think informative (not normative) notes in the javadoc on the latter
two points would be fine.

Cheers,

-Joe



From forax at univ-mlv.fr Tue Jan 10 08:22:01 2012
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 10 Jan 2012 09:22:01 +0100
Subject: typo in sun.misc.VM's comment
In-Reply-To: <CA+cQ+tTVx=kgGoc7t3p_0gx6uuW41aiv1q0fQjDYpW50R2HrGg@mail.gmail.com>
References: <CA+cQ+tTVx=kgGoc7t3p_0gx6uuW41aiv1q0fQjDYpW50R2HrGg@mail.gmail.com>
Message-ID: <4F0BF529.60004@univ-mlv.fr>

I think it's better if it has it's own bug id and changeset.
I'm sure Joe can create a bug id for it.

R?mi

On 01/10/2012 06:51 AM, Krystal Mok wrote:
> Hi all,
>
> Just found a little typo in sun.misc.VM:
>
> diff -r 00e2c88e2234 src/share/classes/sun/misc/VM.java
> --- a/src/share/classes/sun/misc/VM.java Thu Nov 17 10:46:02 2011 -0800
> +++ b/src/share/classes/sun/misc/VM.java Tue Jan 10 13:42:52 2012 +0800
> @@ -167,7 +167,7 @@
> //
> // The initial value of this field is arbitrary; during JRE
> initialization
> // it will be reset to the value specified on the command line, if any,
> - // otherwise to Runtime.getRuntime.maxDirectMemory().
> + // otherwise to Runtime.getRuntime().maxMemory().
> //
> private static long directMemory = 64 * 1024 * 1024;
>
>
> I was looking for the default max direct memory size when I found this
> comment. It would have been nice if this typo was fixed in 6977738. [1]
> Could anybody include this fix in some future commits?
>
> Regards,
> Kris Mok
>
> [1]: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/b444f86c4abe



From Alan.Bateman at oracle.com Tue Jan 10 08:57:41 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Jan 2012 08:57:41 +0000
Subject: Request for review: 7123229: (coll) EnumMap.containsValue(null)
returns true
In-Reply-To: <1326157533.18727.31.camel@chalkhill>
References: <1326157533.18727.31.camel@chalkhill>
Message-ID: <4F0BFD85.5020601@oracle.com>

On 10/01/2012 01:05, Neil Richards wrote:
> Hi all,
> When proposing the change for 6312706 [1], I erroneously managed to
> convince myself (and others!) that it would be safe to use 'new
> Integer(0)' for java.util.EnumMap.NULL (the object used to mark null
> values for entries in the map) [2].
>
> This was on the basis that I thought it was only compared by identity.
> However, on closer inspection, this turns out not to be the case.
>
> 7123229 was raised to report the bug that was introduced based on this
> invalid assumption.
>
> I've created a webrev with a suggested fix for 7123229 [3], which
> changes NULL to be an Object which:
> * will only return 'true' from equals(Object) for itself
> * returns 0 from hashCode()
>
> For good measure, it also returns a sensible value from toString().
>
> Please review this fix and let me know your thoughts,
>
Looks okay to me too. In the test I probably would have used if
(!map.containsValue(...)) rather than if (false == map.containsValue...)).

-Alan.


From chris.hegarty at oracle.com Tue Jan 10 10:43:55 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 10 Jan 2012 10:43:55 +0000
Subject: typo in sun.misc.VM's comment
In-Reply-To: <4F0BF529.60004@univ-mlv.fr>
References: <CA+cQ+tTVx=kgGoc7t3p_0gx6uuW41aiv1q0fQjDYpW50R2HrGg@mail.gmail.com>
<4F0BF529.60004@univ-mlv.fr>
Message-ID: <4F0C166B.4090808@oracle.com>

I created CR 7128584: "Typo in sun.misc.VM's private directMemory field
comment", for this issue, and will push Kris' change with Remi and
myself as reviewer and listing Kris as the contributor.

Thanks,
-Chris.

On 01/10/12 08:22 AM, R?mi Forax wrote:
> I think it's better if it has it's own bug id and changeset.
> I'm sure Joe can create a bug id for it.
>
> R?mi
>
> On 01/10/2012 06:51 AM, Krystal Mok wrote:
>> Hi all,
>>
>> Just found a little typo in sun.misc.VM:
>>
>> diff -r 00e2c88e2234 src/share/classes/sun/misc/VM.java
>> --- a/src/share/classes/sun/misc/VM.java Thu Nov 17 10:46:02 2011 -0800
>> +++ b/src/share/classes/sun/misc/VM.java Tue Jan 10 13:42:52 2012 +0800
>> @@ -167,7 +167,7 @@
>> //
>> // The initial value of this field is arbitrary; during JRE
>> initialization
>> // it will be reset to the value specified on the command line, if any,
>> - // otherwise to Runtime.getRuntime.maxDirectMemory().
>> + // otherwise to Runtime.getRuntime().maxMemory().
>> //
>> private static long directMemory = 64 * 1024 * 1024;
>>
>>
>> I was looking for the default max direct memory size when I found this
>> comment. It would have been nice if this typo was fixed in 6977738. [1]
>> Could anybody include this fix in some future commits?
>>
>> Regards,
>> Kris Mok
>>
>> [1]: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/b444f86c4abe
>


From forax at univ-mlv.fr Tue Jan 10 10:58:46 2012
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 10 Jan 2012 11:58:46 +0100
Subject: typo in sun.misc.VM's comment
In-Reply-To: <4F0C166B.4090808@oracle.com>
References: <CA+cQ+tTVx=kgGoc7t3p_0gx6uuW41aiv1q0fQjDYpW50R2HrGg@mail.gmail.com>
<4F0BF529.60004@univ-mlv.fr> <4F0C166B.4090808@oracle.com>
Message-ID: <4F0C19E6.2020202@univ-mlv.fr>

On 01/10/2012 11:43 AM, Chris Hegarty wrote:
> I created CR 7128584: "Typo in sun.misc.VM's private directMemory
> field comment", for this issue, and will push Kris' change with Remi
> and myself as reviewer and listing Kris as the contributor.
>
> Thanks,
> -Chris.

Thanks,
R?mi

>
> On 01/10/12 08:22 AM, R?mi Forax wrote:
>> I think it's better if it has it's own bug id and changeset.
>> I'm sure Joe can create a bug id for it.
>>
>> R?mi
>>
>> On 01/10/2012 06:51 AM, Krystal Mok wrote:
>>> Hi all,
>>>
>>> Just found a little typo in sun.misc.VM:
>>>
>>> diff -r 00e2c88e2234 src/share/classes/sun/misc/VM.java
>>> --- a/src/share/classes/sun/misc/VM.java Thu Nov 17 10:46:02 2011 -0800
>>> +++ b/src/share/classes/sun/misc/VM.java Tue Jan 10 13:42:52 2012 +0800
>>> @@ -167,7 +167,7 @@
>>> //
>>> // The initial value of this field is arbitrary; during JRE
>>> initialization
>>> // it will be reset to the value specified on the command line, if any,
>>> - // otherwise to Runtime.getRuntime.maxDirectMemory().
>>> + // otherwise to Runtime.getRuntime().maxMemory().
>>> //
>>> private static long directMemory = 64 * 1024 * 1024;
>>>
>>>
>>> I was looking for the default max direct memory size when I found this
>>> comment. It would have been nice if this typo was fixed in 6977738. [1]
>>> Could anybody include this fix in some future commits?
>>>
>>> Regards,
>>> Kris Mok
>>>
>>> [1]: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/b444f86c4abe
>>



From rednaxelafx at gmail.com Tue Jan 10 11:35:06 2012
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Tue, 10 Jan 2012 19:35:06 +0800
Subject: typo in sun.misc.VM's comment
In-Reply-To: <4F0C19E6.2020202@univ-mlv.fr>
References: <CA+cQ+tTVx=kgGoc7t3p_0gx6uuW41aiv1q0fQjDYpW50R2HrGg@mail.gmail.com>
<4F0BF529.60004@univ-mlv.fr> <4F0C166B.4090808@oracle.com>
<4F0C19E6.2020202@univ-mlv.fr>
Message-ID: <CA+cQ+tS5atz=e89GnRD3yRHzcP27_TnnRhc=EdKHOCwLCxjrUQ@mail.gmail.com>

Hi Chris and Remi,

Thank you very much :-)

Regards,
Kris Mok

On Tue, Jan 10, 2012 at 6:58 PM, R?mi Forax <forax at univ-mlv.fr> wrote:

> On 01/10/2012 11:43 AM, Chris Hegarty wrote:
>
>> I created CR 7128584: "Typo in sun.misc.VM's private directMemory field
>> comment", for this issue, and will push Kris' change with Remi and myself
>> as reviewer and listing Kris as the contributor.
>>
>> Thanks,
>> -Chris.
>>
>
> Thanks,
> R?mi
>
>
>
>> On 01/10/12 08:22 AM, R?mi Forax wrote:
>>
>>> I think it's better if it has it's own bug id and changeset.
>>> I'm sure Joe can create a bug id for it.
>>>
>>> R?mi
>>>
>>> On 01/10/2012 06:51 AM, Krystal Mok wrote:
>>>
>>>> Hi all,
>>>>
>>>> Just found a little typo in sun.misc.VM:
>>>>
>>>> diff -r 00e2c88e2234 src/share/classes/sun/misc/VM.**java
>>>> --- a/src/share/classes/sun/misc/**VM.java Thu Nov 17 10:46:02 2011
>>>> -0800
>>>> +++ b/src/share/classes/sun/misc/**VM.java Tue Jan 10 13:42:52 2012
>>>> +0800
>>>> @@ -167,7 +167,7 @@
>>>> //
>>>> // The initial value of this field is arbitrary; during JRE
>>>> initialization
>>>> // it will be reset to the value specified on the command line, if any,
>>>> - // otherwise to Runtime.getRuntime.**maxDirectMemory().
>>>> + // otherwise to Runtime.getRuntime().**maxMemory().
>>>> //
>>>> private static long directMemory = 64 * 1024 * 1024;
>>>>
>>>>
>>>> I was looking for the default max direct memory size when I found this
>>>> comment. It would have been nice if this typo was fixed in 6977738. [1]
>>>> Could anybody include this fix in some future commits?
>>>>
>>>> Regards,
>>>> Kris Mok
>>>>
>>>> [1]: http://hg.openjdk.java.net/**jdk8/jdk8/jdk/rev/b444f86c4abe<http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/b444f86c4abe>
>>>>
>>>
>>>
>


From chris.hegarty at oracle.com Tue Jan 10 12:46:12 2012
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 10 Jan 2012 12:46:12 +0000
Subject: hg: jdk8/tl/jdk: 7123415: Some cases of network interface indexes
being read incorrectly
Message-ID: <20120110124633.CD6EE47901@hg.openjdk.java.net>

Changeset: d72de8b3fe36
Author: chegar
Date: 2012-01-10 10:57 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d72de8b3fe36

7123415: Some cases of network interface indexes being read incorrectly
Reviewed-by: chegar
Contributed-by: brandon.passanisi at oracle.com

! src/solaris/native/java/net/net_util_md.c



From chris.hegarty at oracle.com Tue Jan 10 12:49:14 2012
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 10 Jan 2012 12:49:14 +0000
Subject: hg: jdk8/tl/jdk: 7128584: Typo in sun.misc.VM's private directMemory
field comment
Message-ID: <20120110124923.C329247902@hg.openjdk.java.net>

Changeset: bba276a6aa0d
Author: chegar
Date: 2012-01-10 12:48 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bba276a6aa0d

7128584: Typo in sun.misc.VM's private directMemory field comment
Reviewed-by: forax, chegar
Contributed-by: Krystal Mok <sajia at taobao.com>

! src/share/classes/sun/misc/VM.java



From kumar.x.srinivasan at oracle.COM Tue Jan 10 20:34:02 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Tue, 10 Jan 2012 12:34:02 -0800
Subject: Please review: 7125442
Message-ID: <4F0CA0BA.7030109@oracle.COM>

Hi,

Please review:
CR:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125442

Webrev:
http://cr.openjdk.java.net/~ksrini/7124443/

Thanks
Kumar



From kumar.x.srinivasan at oracle.COM Tue Jan 10 21:06:14 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Tue, 10 Jan 2012 13:06:14 -0800
Subject: Please review: 7125442
In-Reply-To: <4F0CA0BA.7030109@oracle.COM>
References: <4F0CA0BA.7030109@oracle.COM>
Message-ID: <4F0CA846.60802@oracle.COM>

sorry I pasted the wrong webrev in the email,
here is the right one...
http://cr.openjdk.java.net/~ksrini/7125442/

Kumar



> Hi,
>
> Please review:
> CR:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125442
>
> Webrev:
> http://cr.openjdk.java.net/~ksrini/7124443/
>
> Thanks
> Kumar
>



From joe.darcy at oracle.com Tue Jan 10 21:10:24 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 10 Jan 2012 13:10:24 -0800
Subject: JDK 8 code review request for 7112008 Javadoc for
j.l.Object.finalize() vs JLS 12.6 Finalization of Class Instances
Message-ID: <4F0CA940.6020909@oracle.com>

Hello,

Please review this small doc cleanup of java.lang.Object:

7112008 Javadoc for j.l.Object.finalize() vs JLS 12.6 Finalization
of Class Instances
http://cr.openjdk.java.net/~darcy/7112008.0/

Full patch below inline.

Thanks,

-Joe

--- old/src/share/classes/java/lang/Object.java 2012-01-10
13:04:42.000000000 -0800
+++ new/src/share/classes/java/lang/Object.java 2012-01-10
13:04:42.000000000 -0800
@@ -58,8 +58,7 @@
*
* @return The {@code Class} object that represents the runtime
* class of this object.
- * @see Class Literals, section 15.8.2 of
- * <cite>The Java&trade; Language Specification</cite>.
+ * @jls 15.8.2 Class Literals
*/
public final native Class<?> getClass();

@@ -92,7 +91,7 @@
* objects. (This is typically implemented by converting the internal
* address of the object into an integer, but this implementation
* technique is not required by the
- * Java<font size="-2"><sup>TM</sup></font> programming language.)
+ * Java&trade; programming language.)
*
* @return a hash code value for this object.
* @see java.lang.Object#equals(java.lang.Object)
@@ -203,7 +202,7 @@
* exception at run time.
*
* @return a clone of this instance.
- * @exception CloneNotSupportedException if the object's class
does not
+ * @throws CloneNotSupportedException if the object's class does not
* support the {@code Cloneable} interface. Subclasses
* that override the {@code clone} method can also
* throw this exception to indicate that an instance
cannot
@@ -264,7 +263,7 @@
* <p>
* Only one thread at a time can own an object's monitor.
*
- * @exception IllegalMonitorStateException if the current thread
is not
+ * @throws IllegalMonitorStateException if the current thread is not
* the owner of this object's monitor.
* @see java.lang.Object#notifyAll()
* @see java.lang.Object#wait()
@@ -288,7 +287,7 @@
* description of the ways in which a thread can become the owner of
* a monitor.
*
- * @exception IllegalMonitorStateException if the current thread
is not
+ * @throws IllegalMonitorStateException if the current thread is not
* the owner of this object's monitor.
* @see java.lang.Object#notify()
* @see java.lang.Object#wait()
@@ -368,11 +367,11 @@
* a monitor.
*
* @param timeout the maximum time to wait in milliseconds.
- * @exception IllegalArgumentException if the value of timeout is
+ * @throws IllegalArgumentException if the value of timeout is
* negative.
- * @exception IllegalMonitorStateException if the current thread
is not
+ * @throws IllegalMonitorStateException if the current thread is not
* the owner of the object's monitor.
- * @exception InterruptedException if any thread interrupted the
+ * @throws InterruptedException if any thread interrupted the
* current thread before or while the current thread
* was waiting for a notification. The <i>interrupted
* status</i> of the current thread is cleared when
@@ -433,12 +432,12 @@
* @param timeout the maximum time to wait in milliseconds.
* @param nanos additional time, in nanoseconds range
* 0-999999.
- * @exception IllegalArgumentException if the value of timeout is
+ * @throws IllegalArgumentException if the value of timeout is
* negative or the value of nanos is
* not in the range 0-999999.
- * @exception IllegalMonitorStateException if the current thread
is not
+ * @throws IllegalMonitorStateException if the current thread is not
* the owner of this object's monitor.
- * @exception InterruptedException if any thread interrupted the
+ * @throws InterruptedException if any thread interrupted the
* current thread before or while the current thread
* was waiting for a notification. The <i>interrupted
* status</i> of the current thread is cleared when
@@ -489,9 +488,9 @@
* description of the ways in which a thread can become the owner of
* a monitor.
*
- * @exception IllegalMonitorStateException if the current thread
is not
+ * @throws IllegalMonitorStateException if the current thread is not
* the owner of the object's monitor.
- * @exception InterruptedException if any thread interrupted the
+ * @throws InterruptedException if any thread interrupted the
* current thread before or while the current thread
* was waiting for a notification. The <i>interrupted
* status</i> of the current thread is cleared when
@@ -510,7 +509,7 @@
* system resources or to perform other cleanup.
* <p>
* The general contract of {@code finalize} is that it is invoked
- * if and when the Java<font size="-2"><sup>TM</sup></font> virtual
+ * if and when the Java&trade; virtual
* machine has determined that there is no longer any
* means by which this object can be accessed by any thread that has
* not yet died, except as a result of an action taken by the
@@ -549,6 +548,9 @@
* ignored.
*
* @throws Throwable the {@code Exception} raised by this method
+ * @see java.lang.ref.WeakReference
+ * @see java.lang.ref.PhantomReference
+ * @jls 12.6 Finalization of Class Instances
*/
protected void finalize() throws Throwable { }
}



From mandy.chung at oracle.com Tue Jan 10 21:14:54 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Jan 2012 13:14:54 -0800
Subject: Please review: 7125442
In-Reply-To: <4F0CA846.60802@oracle.COM>
References: <4F0CA0BA.7030109@oracle.COM> <4F0CA846.60802@oracle.COM>
Message-ID: <4F0CAA4E.1050005@oracle.com>

I18NJarTest.java
L29: Is -XDignore.symbol.file really needed? As far as I see,
the test only uses the public APIs.
L79: should it check if the returned value is false?

Otherwise, looks good.

Mandy

On 1/10/2012 1:06 PM, Kumar Srinivasan wrote:
> sorry I pasted the wrong webrev in the email,
> here is the right one...
> http://cr.openjdk.java.net/~ksrini/7125442/
>
> Kumar
>
>
>
>> Hi,
>>
>> Please review:
>> CR:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125442
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ksrini/7124443/
>>
>> Thanks
>> Kumar
>>
>


From kumar.x.srinivasan at oracle.COM Tue Jan 10 21:44:47 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Tue, 10 Jan 2012 13:44:47 -0800
Subject: Please review: 7125442
In-Reply-To: <4F0CAA4E.1050005@oracle.com>
References: <4F0CA0BA.7030109@oracle.COM> <4F0CA846.60802@oracle.COM>
<4F0CAA4E.1050005@oracle.com>
Message-ID: <4F0CB14F.5040303@oracle.COM>


> I18NJarTest.java
> L29: Is -XDignore.symbol.file really needed? As far as I see,
> the test only uses the public APIs.

This is needed, since TestHelper uses javac and tar apis
behind the scenes.

> L79: should it check if the returned value is false?

IMO not necessary, if mkdir fails then createJar will throw exception.


>
> Otherwise, looks good.

Thanks
Kumar

>
> Mandy
>
> On 1/10/2012 1:06 PM, Kumar Srinivasan wrote:
>> sorry I pasted the wrong webrev in the email,
>> here is the right one...
>> http://cr.openjdk.java.net/~ksrini/7125442/
>>
>> Kumar
>>
>>
>>
>>> Hi,
>>>
>>> Please review:
>>> CR:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125442
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ksrini/7124443/
>>>
>>> Thanks
>>> Kumar
>>>
>>



From iris.clark at oracle.com Tue Jan 10 21:47:39 2012
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 10 Jan 2012 13:47:39 -0800 (PST)
Subject: CFV: New core-libs Group Member: Brian Goetz
In-Reply-To: <4F059A10.1030401@oracle.com>
References: <4F059A10.1030401@oracle.com>
Message-ID: <705e387d-4d81-4af1-8b5b-fb3dd8de8d33@default>

Vote: yes

iris


From iris.clark at oracle.com Tue Jan 10 21:48:02 2012
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 10 Jan 2012 13:48:02 -0800 (PST)
Subject: CFV: New core-libs Group Member: David Holmes
In-Reply-To: <4F05A0C7.5020304@oracle.com>
References: <4F05A0C7.5020304@oracle.com>
Message-ID: <58b494eb-0efb-47eb-99c8-cf6cc89933b4@default>

Vote: yes

iris


From mandy.chung at oracle.com Tue Jan 10 21:52:21 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Jan 2012 13:52:21 -0800
Subject: Please review: 7125442
In-Reply-To: <4F0CB14F.5040303@oracle.COM>
References: <4F0CA0BA.7030109@oracle.COM> <4F0CA846.60802@oracle.COM>
<4F0CAA4E.1050005@oracle.com> <4F0CB14F.5040303@oracle.COM>
Message-ID: <4F0CB315.3090503@oracle.com>

On 1/10/2012 1:44 PM, Kumar Srinivasan wrote:
>
>> I18NJarTest.java
>> L29: Is -XDignore.symbol.file really needed? As far as I see,
>> the test only uses the public APIs.
>
> This is needed, since TestHelper uses javac and tar apis
> behind the scenes.

Ah. I missed its reference to sun.tools.jar.Main. It uses
javax.tools.ToolProvider and JavaCompiler API and so sun.tools.jar
api is the only one.

>
>> L79: should it check if the returned value is false?
>
> IMO not necessary, if mkdir fails then createJar will throw exception.
>

Okay. Thanks.

Mandy


From jeannette.hung at oracle.com Tue Jan 10 22:12:52 2012
From: jeannette.hung at oracle.com (Jeannette Hung)
Date: Tue, 10 Jan 2012 14:12:52 -0800
Subject: Please review: 7125442
In-Reply-To: <4F0CB315.3090503@oracle.com>
References: <4F0CA0BA.7030109@oracle.COM> <4F0CA846.60802@oracle.COM>
<4F0CAA4E.1050005@oracle.com> <4F0CB14F.5040303@oracle.COM>
<4F0CB315.3090503@oracle.com>
Message-ID: <8123DCEA-F82A-4826-A59A-8A3BE7B1F87C@oracle.com>

Kumar,
Could you fill in the introduced-in field in the CR?

Thanks
jeannette

On Jan 10, 2012, at 1:52 PM, Mandy Chung wrote:

> On 1/10/2012 1:44 PM, Kumar Srinivasan wrote:
>>
>>> I18NJarTest.java
>>> L29: Is -XDignore.symbol.file really needed? As far as I see,
>>> the test only uses the public APIs.
>>
>> This is needed, since TestHelper uses javac and tar apis
>> behind the scenes.
>
> Ah. I missed its reference to sun.tools.jar.Main. It uses
> javax.tools.ToolProvider and JavaCompiler API and so sun.tools.jar
> api is the only one.
>
>>
>>> L79: should it check if the returned value is false?
>>
>> IMO not necessary, if mkdir fails then createJar will throw exception.
>>
>
> Okay. Thanks.
>
> Mandy



From joe.darcy at oracle.com Wed Jan 11 01:13:02 2012
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 11 Jan 2012 01:13:02 +0000
Subject: hg: jdk8/tl/jdk: 7112008: Javadoc for j.l.Object.finalize() vs JLS
12.6 Finalization of Class Instances
Message-ID: <20120111011327.5669247913@hg.openjdk.java.net>

Changeset: 49e64a8fc18f
Author: darcy
Date: 2012-01-10 17:12 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/49e64a8fc18f

7112008: Javadoc for j.l.Object.finalize() vs JLS 12.6 Finalization of Class Instances
Reviewed-by: mduigou

! src/share/classes/java/lang/Object.java



From joe.darcy at oracle.com Wed Jan 11 01:20:25 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 10 Jan 2012 17:20:25 -0800
Subject: Code review request for trivial javadoc issue in Throwable
Message-ID: <4F0CE3D9.9010403@oracle.com>

Hello,

Please review this simple fix to the javadoc of java.lang.Throwable; use
of "<" and ">" rather than "&lt;" and "&gt;" currently causes malformed
HTML to be generated.

--- a/src/share/classes/java/lang/Throwable.java Tue Jan 10 17:12:11
2012 -0800
+++ b/src/share/classes/java/lang/Throwable.java Tue Jan 10 17:17:27
2012 -0800
@@ -625,7 +625,7 @@
* at Resource2.close(Resource2.java:20)
* at Foo4.main(Foo4.java:5)
* Caused by: java.lang.Exception: Rats, you caught me
- * at Resource2$CloseFailException.<init>(Resource2.java:45)
+ * at
Resource2$CloseFailException.&lt;init&gt;(Resource2.java:45)
* ... 2 more
* </pre>
*/

After the review, I'll file a bug and do the push, etc.

Thanks,

-Joe


From mike.duigou at oracle.com Wed Jan 11 01:25:49 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 10 Jan 2012 17:25:49 -0800
Subject: Code review request for trivial javadoc issue in Throwable
In-Reply-To: <4F0CE3D9.9010403@oracle.com>
References: <4F0CE3D9.9010403@oracle.com>
Message-ID: <A028A837-F69E-4BD4-8F93-388B2D23AABE@oracle.com>

Looks good.

On Jan 10 2012, at 17:20 , Joe Darcy wrote:

> Hello,
>
> Please review this simple fix to the javadoc of java.lang.Throwable; use of "<" and ">" rather than "&lt;" and "&gt;" currently causes malformed HTML to be generated.
>
> --- a/src/share/classes/java/lang/Throwable.java Tue Jan 10 17:12:11 2012 -0800
> +++ b/src/share/classes/java/lang/Throwable.java Tue Jan 10 17:17:27 2012 -0800
> @@ -625,7 +625,7 @@
> * at Resource2.close(Resource2.java:20)
> * at Foo4.main(Foo4.java:5)
> * Caused by: java.lang.Exception: Rats, you caught me
> - * at Resource2$CloseFailException.<init>(Resource2.java:45)
> + * at Resource2$CloseFailException.&lt;init&gt;(Resource2.java:45)
> * ... 2 more
> * </pre>
> */
>
> After the review, I'll file a bug and do the push, etc.
>
> Thanks,
>
> -Joe



From joe.darcy at oracle.com Wed Jan 11 01:38:13 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 10 Jan 2012 17:38:13 -0800
Subject: Please review: 7125442
In-Reply-To: <4F0CAA4E.1050005@oracle.com>
References: <4F0CA0BA.7030109@oracle.COM> <4F0CA846.60802@oracle.COM>
<4F0CAA4E.1050005@oracle.com>
Message-ID: <4F0CE805.5060906@oracle.com>

On 01/10/2012 01:14 PM, Mandy Chung wrote:
> I18NJarTest.java
> L29: Is -XDignore.symbol.file really needed? As far as I see,
> the test only uses the public APIs.
> L79: should it check if the returned value is false?
>
> Otherwise, looks good.

Looks fine,

-Joe

>
> Mandy
>
> On 1/10/2012 1:06 PM, Kumar Srinivasan wrote:
>> sorry I pasted the wrong webrev in the email,
>> here is the right one...
>> http://cr.openjdk.java.net/~ksrini/7125442/
>>
>> Kumar
>>
>>
>>
>>> Hi,
>>>
>>> Please review:
>>> CR:
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7125442
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~ksrini/7124443/
>>>
>>> Thanks
>>> Kumar
>>>
>>



From joe.darcy at oracle.com Wed Jan 11 01:47:02 2012
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Wed, 11 Jan 2012 01:47:02 +0000
Subject: hg: jdk8/tl/jdk: 7128931: Bad HTML escaping in java.lang.Throwable
javadoc
Message-ID: <20120111014712.8637A47914@hg.openjdk.java.net>

Changeset: 62dbcbe4c446
Author: darcy
Date: 2012-01-10 17:46 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/62dbcbe4c446

7128931: Bad HTML escaping in java.lang.Throwable javadoc
Reviewed-by: mduigou

! src/share/classes/java/lang/Throwable.java



From Lance.Andersen at oracle.com Wed Jan 11 02:18:51 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 10 Jan 2012 21:18:51 -0500
Subject: Code review request for trivial javadoc issue in Throwable
In-Reply-To: <4F0CE3D9.9010403@oracle.com>
References: <4F0CE3D9.9010403@oracle.com>
Message-ID: <246F41C8-2081-4E0A-A709-6A7698EB2A3D@oracle.com>

Looks good


On Jan 10, 2012, at 8:20 PM, Joe Darcy wrote:

> Hello,
>
> Please review this simple fix to the javadoc of java.lang.Throwable; use of "<" and ">" rather than "&lt;" and "&gt;" currently causes malformed HTML to be generated.
>
> --- a/src/share/classes/java/lang/Throwable.java Tue Jan 10 17:12:11 2012 -0800
> +++ b/src/share/classes/java/lang/Throwable.java Tue Jan 10 17:17:27 2012 -0800
> @@ -625,7 +625,7 @@
> * at Resource2.close(Resource2.java:20)
> * at Foo4.main(Foo4.java:5)
> * Caused by: java.lang.Exception: Rats, you caught me
> - * at Resource2$CloseFailException.<init>(Resource2.java:45)
> + * at Resource2$CloseFailException.&lt;init&gt;(Resource2.java:45)
> * ... 2 more
> * </pre>
> */
>
> After the review, I'll file a bug and do the push, etc.
>
> 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 mandy.chung at oracle.com Wed Jan 11 03:39:28 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Jan 2012 19:39:28 -0800
Subject: Code review request for trivial javadoc issue in Throwable
In-Reply-To: <4F0CE3D9.9010403@oracle.com>
References: <4F0CE3D9.9010403@oracle.com>
Message-ID: <4F0D0470.9020601@oracle.com>

Looks good.
Mandy

On 1/10/2012 5:20 PM, Joe Darcy wrote:
> Hello,
>
> Please review this simple fix to the javadoc of java.lang.Throwable;
> use of "<" and ">" rather than "&lt;" and "&gt;" currently causes
> malformed HTML to be generated.
>
> --- a/src/share/classes/java/lang/Throwable.java Tue Jan 10
> 17:12:11 2012 -0800
> +++ b/src/share/classes/java/lang/Throwable.java Tue Jan 10
> 17:17:27 2012 -0800
> @@ -625,7 +625,7 @@
> * at Resource2.close(Resource2.java:20)
> * at Foo4.main(Foo4.java:5)
> * Caused by: java.lang.Exception: Rats, you caught me
> - * at
> Resource2$CloseFailException.<init>(Resource2.java:45)
> + * at
> Resource2$CloseFailException.&lt;init&gt;(Resource2.java:45)
> * ... 2 more
> * </pre>
> */
>
> After the review, I'll file a bug and do the push, etc.
>
> Thanks,
>
> -Joe


From chris.hegarty at oracle.com Wed Jan 11 13:04:07 2012
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 11 Jan 2012 13:04:07 +0000
Subject: hg: jdk8/tl/jdk: 7128648: HttpURLConnection.getHeaderFields should
return an unmodifiable Map
Message-ID: <20120111130426.417554791A@hg.openjdk.java.net>

Changeset: 31a1fc60a895
Author: chegar
Date: 2012-01-11 10:52 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31a1fc60a895

7128648: HttpURLConnection.getHeaderFields should return an unmodifiable Map
Reviewed-by: michaelm

! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
+ test/java/net/HttpURLConnection/UnmodifiableMaps.java



From alan.bateman at oracle.com Wed Jan 11 13:07:57 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 11 Jan 2012 13:07:57 +0000
Subject: hg: jdk8/tl/jdk: 7068856: (fs) Typo in Files.isSameFile() javadoc; ...
Message-ID: <20120111130807.33E614791B@hg.openjdk.java.net>

Changeset: 82144054d2d8
Author: alanb
Date: 2012-01-11 13:07 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82144054d2d8

7068856: (fs) Typo in Files.isSameFile() javadoc
7099208: (fs) Files.newBufferedReader has typo in javadoc
Reviewed-by: forax

! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/nio/file/Path.java



From kumar.x.srinivasan at oracle.com Wed Jan 11 17:07:53 2012
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Wed, 11 Jan 2012 17:07:53 +0000
Subject: hg: jdk8/tl/jdk: 7125442: jar application located in two bytes
character named folder cannot be run with JRE 7 u1/u2
Message-ID: <20120111170810.E146B47923@hg.openjdk.java.net>

Changeset: 96fe796fd242
Author: ksrini
Date: 2012-01-11 08:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/96fe796fd242

7125442: jar application located in two bytes character named folder cannot be run with JRE 7 u1/u2
Reviewed-by: sherman, mchung, darcy

! src/share/bin/java.c
+ test/tools/launcher/I18NJarTest.java
! test/tools/launcher/TestHelper.java



From maurizio.cimadamore at oracle.com Wed Jan 11 18:25:45 2012
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 11 Jan 2012 18:25:45 +0000
Subject: hg: jdk8/tl/langtools: 7126754: Generics compilation failure casting
List<? extends Set...> to List<Set...>
Message-ID: <20120111182549.7716F47925@hg.openjdk.java.net>

Changeset: 70d92518063e
Author: mcimadamore
Date: 2012-01-11 18:23 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/70d92518063e

7126754: Generics compilation failure casting List<? extends Set...> to List<Set...>
Summary: Problems with Types.rewriteQuantifiers not preserving variance
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Types.java
+ test/tools/javac/cast/7126754/T7126754.java
+ test/tools/javac/cast/7126754/T7126754.out



From joe.darcy at oracle.com Wed Jan 11 18:38:11 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 11 Jan 2012 10:38:11 -0800
Subject: Fraction
In-Reply-To: <CAAUNa5s817aJ_yiykuyNoU9ERK7MOd14sUtUemjaz5GR6AZi1g@mail.gmail.com>
References: <4F008FE0.60501@tbee.org> <4F063641.9070804@oracle.com>
<CAAUNa5s817aJ_yiykuyNoU9ERK7MOd14sUtUemjaz5GR6AZi1g@mail.gmail.com>
Message-ID: <4F0DD713.7030800@oracle.com>

Hello Dima,

On 01/09/2012 09:13 AM, Dmitry Nadezhin wrote:
> Hello Joe,
>
> Thank you for the clarification.
>
> What do you think about using BigBinary to solve the problem of a
> calculation class with higher precision.
> BigBinary implements arbitrary precision binary floating-point numbers
> and arithmetic operations on them.
> Although it rounds, the precision and rounding direction are controlled.
> It seems to me that binary floating-point numbers are more natural
> than decimal for scientific applications.
> Should such a class be in the JDK or outside?

Some time ago I filed and more recently deferred the JDK RFE

4529368 RFE: Add a BigBinary class for arbitrary precision
floating-point computation
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4529368

While this is a fine idea on a technical basis, given other priorities,
I don't anticipate Oracle's JDK group funding work on this in the
foreseeable future. However, the JEP process allows other parties to
propose and develop such efforts. [1]

>
> If you don't think that BigBinary is appropriate, then let me ask some
> other questions.
> IEEE 754-2008 defines three basic binary formats: Binary32, Binary64,
> Binary128 .
> Binary32 and Binary64 are already known in JDK as Float and Double
> (with rounding to nearest even).
> Should there be a software emulation of Binary128 in JDK (as a class
> with two private long fields)?

There would be some utility in having such a Binary128/Quad class, but
again I don't see the JDK group taking the initiative in its
development. (Note that while straightforward, direct use of the quad
type never really caught on. The type is supported in both the sparc
and pa-risc instruction sets, but never got direct hardware support on
those processors since customers typically found another approach to
address their numerical difficulties. On processor families with a fused
mac instruction, there are other relatively fast ways to implement
somewhat grubby higher-precision operations.)

> Should the JDK have a class with static methods that implement
> arithmetic operations on floats and doubles with directed rounding like
> http://java.net/projects/projectfortress/sources/sources/content/ProjectFortress/src/com/sun/fortress/numerics/DirectedRounding.java
> ?

From an API perspective, I think this functionality would be better
done as methods like

double add(double, double, java.math.RoundingMode)


> Is there a chance that Binary128 or DirectedRounding methods would be
> internalized in hotspot?
>
> These questions are important to me because I am working on an
> interval arithmetic library
> http://kenai.com/projects/jinterval/ and could use these new classes.
>
> I understand that the addition of numerical features to the JDK is closed.
> However, if there is a chance to add any new classes, I'd be glad to
> contibute to their development.

However, I don't think directed rounding methods will be added to the
JDK in JDK 8; if they were added, they would not likely have sufficient
duty-cycle to justify HotSpot intrinsics for them.

Cheers,

-Joe

[1] http://openjdk.java.net/jeps/0

> Cheers,
>
> -Dima
>
>
> On Fri, Jan 6, 2012 at 2:46 AM, Joe Darcy<joe.darcy at oracle.com> wrote:
>> Hello,
>>
>>
>> On 1/1/2012 8:54 AM, Tom Eugelink wrote:
>>>
>>> Hello guys,
>>>
>>> I was wondering if it was of any interest to OpenJFX to have a calculation
>>> class that does not round. I've got "Fraction" laying around, which does
>>> math using two BigIntegers, so it never even rounds. The API is roughly
>>> equivalent to BigDecimal, so you have methods like add, divide, etc.
>>>
>>> Any interest in adding such a class to Java?
>>>
>> The BigDecimal class can already preform exact computations. To get exact
>> behavior, use the version of add, subtract, etc. that takes a single
>> BigDecimal argument or the version that takes a BigDecimal argument and a
>> MathContext argument and pass a MathContext object with a precision of 0.
>> Of the four basic arithmetic operations, the most interesting operation is
>> divide since it can result in infinite inputs (fractions that are
>> non-terminating in decimal) from finite inputs while the other operations
>> cannot.
>>
>> In terms of its representation, BigDecimal class uses a floating-point style
>> scaled representation so that very large or very small numbers that are
>> low-precision don't use a lot of storage.
>>
>> When doing general computations, there is a need to round result
>> periodically to avoid unbounded growth in the sizes of the numbers being
>> operated on. BigDecimal supports various rounding operations, including
>> rounding to a given number of places after the decimal point and rounding to
>> a given number of total digits. These styles of rounding are relatively
>> easy to understand, but still quite vexing for numerical analysis.
>>
>> The rounding options I'm familiar with for rational packages are fixed slash
>> vs floating-slash, that is, given constraints on the sizes of the numerator
>> and denominator, return the nearest fraction to the exact result. AFAIK,
>> such system are less studied if not more difficult to work with than
>> traditional rounding.
>>
>> In short, while there would be some use cases, without additional
>> justification I don't see the need to add a rational number package to the
>> JDK.
>>
>> Cheers,
>>
>> -Joe
>>



From joe.darcy at oracle.com Wed Jan 11 18:59:45 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 11 Jan 2012 10:59:45 -0800
Subject: Updated unit test for BigInteger patch (#4837946)
In-Reply-To: <BLU0-SMTP220B8AE166DE1CB2D348063C6990@phx.gbl>
References: <BLU0-SMTP1834158AEF452F0E964F245C69A0@phx.gbl>
<BLU0-SMTP220B8AE166DE1CB2D348063C6990@phx.gbl>
Message-ID: <4F0DDC21.90504@oracle.com>

On 01/09/2012 09:01 PM, Tim Buktu wrote:
> I updated BigIntegerTest so it tests the existing multiplication and
> division algorithms as well as the ones added by my (and Alan's)
> BigInteger patch.
>
> This patch also adds a 6th type of random number to the 5 already
> present. The new type outputs random numbers that contain long runs of
> 1-bits and 0-bits. GMP uses these numbers because apparently they are a
> good way to trigger bugs in bigint arithmetic.
>
> The patch is at https://gist.github.com/1586984
> The whole BigIntegerTest.java file is at https://gist.github.com/1586990
>
> I forgot to mention in my previous email that this is for bug 4837946.
> Thanks,
>
> Tim

Thanks Tim. I'll add this to my review queue after Alan Eliasen's work
(finally) gets in.

-Joe


From luchsh at linux.vnet.ibm.com Thu Jan 12 09:35:37 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Thu, 12 Jan 2012 17:35:37 +0800
Subject: POSIX compatibility change for including wait.h in UNIXProcess_md.c
Message-ID: <4F0EA969.5000600@linux.vnet.ibm.com>

Hi core-libs-dev,

It was found that solaris/native/java/lang/UNIXProcess_md.c includes
<wait.h> which does not seem to be compliant with POSIX specification,
in which the expected header file name should be <sys/wait.h>. see
http://en.wikipedia.org/wiki/C_POSIX_library. I also performed a 'grep'
for the code base, it seems nowhere else needs to be changed so far.

So here is a simple patch to adjust this issue, any suggestions?
http://cr.openjdk.java.net/~luchsh/wait_h_POSIX_comp/

Cheers
- Jonathan



From david.holmes at oracle.com Thu Jan 12 10:13:51 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Jan 2012 20:13:51 +1000
Subject: POSIX compatibility change for including wait.h in
UNIXProcess_md.c
In-Reply-To: <4F0EA969.5000600@linux.vnet.ibm.com>
References: <4F0EA969.5000600@linux.vnet.ibm.com>
Message-ID: <4F0EB25F.3080100@oracle.com>

Hi Jonathon,

On 12/01/2012 7:35 PM, Jonathan Lu wrote:
> It was found that solaris/native/java/lang/UNIXProcess_md.c includes
> <wait.h> which does not seem to be compliant with POSIX specification,
> in which the expected header file name should be <sys/wait.h>. see
> http://en.wikipedia.org/wiki/C_POSIX_library. I also performed a 'grep'
> for the code base, it seems nowhere else needs to be changed so far.
>
> So here is a simple patch to adjust this issue, any suggestions?
> http://cr.openjdk.java.net/~luchsh/wait_h_POSIX_comp/

It looks like this is a remnant from when we used waitid on Solaris. Now
we use waitpid <sys/wait.h> is more correct - as per the man page.
On Linux wait.h simply includes sys/wait.h so no issue there.

This change looks okay to me. If Martin is still lurking here he may be
able to confirm.

David


From michael.x.mcmahon at oracle.com Thu Jan 12 11:22:08 2012
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 12 Jan 2012 11:22:08 +0000
Subject: Code review: 7126979 (props) JCK test
java_lang/System/GetProperties.java failing [macosx]
Message-ID: <4F0EC260.1050605@oracle.com>

Could I get the following change for jdk7u-osx reviewed please?

http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/

The freeProps() call added by mac port can only be called once. Issue
seen if System.setProperties(null) is called.
GetJavaProperties() called a second time, which is supposed to return
the statically populated information
from first call. But some of it has been freed already.

Fix is to remove the freeProps() code added in the original port
changeset. The fix reverts the mac specific code
to the original version.

- Michael



From martin.desruisseaux at geomatys.fr Thu Jan 12 11:30:16 2012
From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux)
Date: Thu, 12 Jan 2012 12:30:16 +0100
Subject: Strange or obsolete @see tags in some exception javadoc
Message-ID: <4F0EC448.5020801@geomatys.fr>

Hello all

Some widely-used exceptions which were defined in the old Java 1.0 days have
strange or obsolete javadoc "@see" tags:

http://docs.oracle.com/javase/7/docs/api/java/lang/IllegalArgumentException.html
IllegalArgumentException declares "@see Thread#setPriority(int)". Why is
Thread.setPriority(int) so special in regard to IllegalArgumentException?

http://docs.oracle.com/javase/7/docs/api/java/lang/NumberFormatException.html
NumberFormatException declares "@see Integer#toString()". Shouldn't it be "@see
Integer#parseInt(String)" instead?

http://docs.oracle.com/javase/7/docs/api/java/util/NoSuchElementException.html
NoSuchElementException declares the legacy "@see Enumeration#nextElement()", but
does not declare the "@see Iterator#next()" replacement.

Martin



From Alan.Bateman at oracle.com Thu Jan 12 11:33:57 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Jan 2012 11:33:57 +0000
Subject: POSIX compatibility change for including wait.h in
UNIXProcess_md.c
In-Reply-To: <4F0EA969.5000600@linux.vnet.ibm.com>
References: <4F0EA969.5000600@linux.vnet.ibm.com>
Message-ID: <4F0EC525.4070507@oracle.com>

On 12/01/2012 09:35, Jonathan Lu wrote:
> Hi core-libs-dev,
>
> It was found that solaris/native/java/lang/UNIXProcess_md.c includes
> <wait.h> which does not seem to be compliant with POSIX specification,
> in which the expected header file name should be <sys/wait.h>. see
> http://en.wikipedia.org/wiki/C_POSIX_library. I also performed a
> 'grep' for the code base, it seems nowhere else needs to be changed so
> far.
>
> So here is a simple patch to adjust this issue, any suggestions?
> http://cr.openjdk.java.net/~luchsh/wait_h_POSIX_comp/
>
> Cheers
> - Jonathan
>
This looks fine to me.

-Alan


From Alan.Bateman at oracle.com Thu Jan 12 11:35:02 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Jan 2012 11:35:02 +0000
Subject: Code review: 7126979 (props) JCK test
java_lang/System/GetProperties.java failing [macosx]
In-Reply-To: <4F0EC260.1050605@oracle.com>
References: <4F0EC260.1050605@oracle.com>
Message-ID: <4F0EC566.4070407@oracle.com>

On 12/01/2012 11:22, Michael McMahon wrote:
> Could I get the following change for jdk7u-osx reviewed please?
>
> http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/
>
> The freeProps() call added by mac port can only be called once. Issue
> seen if System.setProperties(null) is called.
> GetJavaProperties() called a second time, which is supposed to return
> the statically populated information
> from first call. But some of it has been freed already.
>
> Fix is to remove the freeProps() code added in the original port
> changeset. The fix reverts the mac specific code
> to the original version.
>
> - Michael
I think this is the same issue that Scott Kovatch has under a different
bugID;

http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-January/002148.html

-Alan.



From xuelei.fan at oracle.com Thu Jan 12 11:40:18 2012
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Thu, 12 Jan 2012 11:40:18 +0000
Subject: hg: jdk8/tl/jdk: 7106773: 512 bits RSA key cannot work with SHA384
and SHA512
Message-ID: <20120112114046.B5E6A47939@hg.openjdk.java.net>

Changeset: 11e52d5ba64e
Author: xuelei
Date: 2012-01-12 03:39 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11e52d5ba64e

7106773: 512 bits RSA key cannot work with SHA384 and SHA512
Reviewed-by: weijun

! src/share/classes/sun/security/pkcs11/P11Cipher.java
! src/share/classes/sun/security/pkcs11/P11Key.java
! src/share/classes/sun/security/pkcs11/P11RSACipher.java
! src/share/classes/sun/security/pkcs11/P11Signature.java
! src/share/classes/sun/security/ssl/ClientHandshaker.java
! src/share/classes/sun/security/ssl/ServerHandshaker.java
! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java
+ src/share/classes/sun/security/util/KeyLength.java
+ src/share/classes/sun/security/util/Length.java
! src/windows/classes/sun/security/mscapi/Key.java
! src/windows/classes/sun/security/mscapi/RSACipher.java
! src/windows/classes/sun/security/mscapi/RSASignature.java
+ test/sun/security/mscapi/ShortRSAKey1024.sh
+ test/sun/security/mscapi/ShortRSAKey512.sh
+ test/sun/security/mscapi/ShortRSAKey768.sh
+ test/sun/security/mscapi/ShortRSAKeyWithinTLS.java
! test/sun/security/pkcs11/KeyStore/ClientAuth.java
! test/sun/security/pkcs11/KeyStore/ClientAuth.sh
! test/sun/security/ssl/javax/net/ssl/SSLContextVersion.java
+ test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java



From david.holmes at oracle.com Thu Jan 12 11:52:40 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Jan 2012 21:52:40 +1000
Subject: Code review: 7126979 (props) JCK test
java_lang/System/GetProperties.java failing [macosx]
In-Reply-To: <4F0EC260.1050605@oracle.com>
References: <4F0EC260.1050605@oracle.com>
Message-ID: <4F0EC988.5030405@oracle.com>

Michael,

There was a different patch for this posted earlier today where the
props fields were all nulled out so they didn't reference the freed
locations amy more. (I didn't keep the email)

???

David

On 12/01/2012 9:22 PM, Michael McMahon wrote:
> Could I get the following change for jdk7u-osx reviewed please?
>
> http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/
>
> The freeProps() call added by mac port can only be called once. Issue
> seen if System.setProperties(null) is called.
> GetJavaProperties() called a second time, which is supposed to return
> the statically populated information
> from first call. But some of it has been freed already.
>
> Fix is to remove the freeProps() code added in the original port
> changeset. The fix reverts the mac specific code
> to the original version.
>
> - Michael
>


From michael.x.mcmahon at oracle.com Thu Jan 12 12:49:00 2012
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Thu, 12 Jan 2012 12:49:00 +0000
Subject: Code review: 7126979 (props) JCK test
java_lang/System/GetProperties.java failing [macosx]
In-Reply-To: <4F0EC988.5030405@oracle.com>
References: <4F0EC260.1050605@oracle.com> <4F0EC988.5030405@oracle.com>
Message-ID: <4F0ED6BC.3070405@oracle.com>

Thanks David. Just found it now (Alan noticed it too). Scott sent his
webrev yesterday.

It looks like both solutions fix the problem. The difference is that
Scott's re-initializes
the properties from native code each time System.initProperties() is called.
On the other platforms, we only call it once.

So, do we want Macos to diverge slightly from the other platforms in
this respect?

My preference is to keep the platforms as similar as possible,
minimising the changes
with jdk7u ...

- Michael.

On 12/01/12 11:52, David Holmes wrote:
> Michael,
>
> There was a different patch for this posted earlier today where the
> props fields were all nulled out so they didn't reference the freed
> locations amy more. (I didn't keep the email)
>
> ???
>
> David
>
> On 12/01/2012 9:22 PM, Michael McMahon wrote:
>> Could I get the following change for jdk7u-osx reviewed please?
>>
>> http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/
>>
>> The freeProps() call added by mac port can only be called once. Issue
>> seen if System.setProperties(null) is called.
>> GetJavaProperties() called a second time, which is supposed to return
>> the statically populated information
>> from first call. But some of it has been freed already.
>>
>> Fix is to remove the freeProps() code added in the original port
>> changeset. The fix reverts the mac specific code
>> to the original version.
>>
>> - Michael
>>



From david.holmes at oracle.com Thu Jan 12 13:02:29 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 12 Jan 2012 23:02:29 +1000
Subject: Code review: 7126979 (props) JCK test
java_lang/System/GetProperties.java failing [macosx]
In-Reply-To: <4F0ED6BC.3070405@oracle.com>
References: <4F0EC260.1050605@oracle.com> <4F0EC988.5030405@oracle.com>
<4F0ED6BC.3070405@oracle.com>
Message-ID: <4F0ED9E5.9070800@oracle.com>

On 12/01/2012 10:49 PM, Michael McMahon wrote:
> Thanks David. Just found it now (Alan noticed it too). Scott sent his
> webrev yesterday.
>
> It looks like both solutions fix the problem. The difference is that
> Scott's re-initializes
> the properties from native code each time System.initProperties() is
> called.
> On the other platforms, we only call it once.
>
> So, do we want Macos to diverge slightly from the other platforms in
> this respect?

I haven't compared things in detail but If there is no need to diverge
then I would not diverge.

David
-----

> My preference is to keep the platforms as similar as possible,
> minimising the changes
> with jdk7u ...
>
> - Michael.
>
> On 12/01/12 11:52, David Holmes wrote:
>> Michael,
>>
>> There was a different patch for this posted earlier today where the
>> props fields were all nulled out so they didn't reference the freed
>> locations amy more. (I didn't keep the email)
>>
>> ???
>>
>> David
>>
>> On 12/01/2012 9:22 PM, Michael McMahon wrote:
>>> Could I get the following change for jdk7u-osx reviewed please?
>>>
>>> http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/
>>>
>>> The freeProps() call added by mac port can only be called once. Issue
>>> seen if System.setProperties(null) is called.
>>> GetJavaProperties() called a second time, which is supposed to return
>>> the statically populated information
>>> from first call. But some of it has been freed already.
>>>
>>> Fix is to remove the freeProps() code added in the original port
>>> changeset. The fix reverts the mac specific code
>>> to the original version.
>>>
>>> - Michael
>>>
>


From maurizio.cimadamore at oracle.com Thu Jan 12 15:29:13 2012
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 12 Jan 2012 15:29:13 +0000
Subject: hg: jdk8/tl/langtools: 7123100: javac fails with
java.lang.StackOverflowError
Message-ID: <20120112152917.CB5DB4793E@hg.openjdk.java.net>

Changeset: 133744729455
Author: mcimadamore
Date: 2012-01-12 15:28 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/133744729455

7123100: javac fails with java.lang.StackOverflowError
Summary: Inference of under-constrained type-variables creates erroneous recursive wildcard types
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Infer.java
+ test/tools/javac/cast/7123100/T7123100a.java
+ test/tools/javac/cast/7123100/T7123100a.out
+ test/tools/javac/cast/7123100/T7123100b.java
+ test/tools/javac/cast/7123100/T7123100b.out
+ test/tools/javac/cast/7123100/T7123100c.java
+ test/tools/javac/cast/7123100/T7123100c.out
+ test/tools/javac/cast/7123100/T7123100d.java
+ test/tools/javac/cast/7123100/T7123100d.out



From weijun.wang at oracle.com Fri Jan 13 01:51:25 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Fri, 13 Jan 2012 01:51:25 +0000
Subject: hg: jdk8/tl/jdk: 7090565: Move
test/closed/javax/security/auth/x500/X500Principal/Parse.java
to open tests
Message-ID: <20120113015144.632D54794D@hg.openjdk.java.net>

Changeset: 38bf1e9b6979
Author: weijun
Date: 2012-01-13 09:50 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38bf1e9b6979

7090565: Move test/closed/javax/security/auth/x500/X500Principal/Parse.java to open tests
Reviewed-by: mullan

+ test/javax/security/auth/x500/X500Principal/NameFormat.java



From valerie.peng at oracle.com Fri Jan 13 02:56:39 2012
From: valerie.peng at oracle.com (valerie.peng at oracle.com)
Date: Fri, 13 Jan 2012 02:56:39 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20120113025658.EB51B4794F@hg.openjdk.java.net>

Changeset: ef3b6736c074
Author: valeriep
Date: 2012-01-12 16:04 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef3b6736c074

7088989: Improve the performance for T4 by utilizing the newly provided crypto APIs
Summary: Added the OracleUcrypto provider for utilizing the Solaris ucrypto API.
Reviewed-by: weijun

! make/com/oracle/Makefile
+ make/com/oracle/net/Makefile
+ make/com/oracle/nio/Makefile
+ make/com/oracle/security/ucrypto/FILES_c.gmk
+ make/com/oracle/security/ucrypto/Makefile
+ make/com/oracle/security/ucrypto/mapfile-vers
+ make/com/oracle/util/Makefile
! src/share/lib/security/java.security-solaris
! test/Makefile
+ test/com/oracle/security/ucrypto/TestAES.java
+ test/com/oracle/security/ucrypto/TestDigest.java
+ test/com/oracle/security/ucrypto/TestRSA.java
+ test/com/oracle/security/ucrypto/UcryptoTest.java
! test/java/security/Provider/DefaultPKCS11.java

Changeset: a7ad2fcd7291
Author: valeriep
Date: 2012-01-12 18:49 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7ad2fcd7291

Merge




From tbuktu at hotmail.com Fri Jan 13 04:31:58 2012
From: tbuktu at hotmail.com (Tim Buktu)
Date: Thu, 12 Jan 2012 21:31:58 -0700
Subject: Updated unit test for BigInteger patch (#4837946)
In-Reply-To: <4F0DDC21.90504@oracle.com>
References: <BLU0-SMTP1834158AEF452F0E964F245C69A0@phx.gbl>
<BLU0-SMTP220B8AE166DE1CB2D348063C6990@phx.gbl>
<4F0DDC21.90504@oracle.com>
Message-ID: <BLU0-SMTP445492E17D46E8EDED4CBA7C69C0@phx.gbl>

On 01/11/2012 11:59 AM, Joe Darcy wrote:
> Thanks Tim. I'll add this to my review queue after Alan Eliasen's work
> (finally) gets in.

Sounds good.

I wanted to point out that my patch includes Alan's and it applies to
the latest JDK8 sources without any manual merging, so it should be less
work than first applying Alan's patch and then mine.
On the other hand, doing Alan's patch first means less code to review at
a time.

Tim


From luchsh at linux.vnet.ibm.com Fri Jan 13 07:38:45 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Fri, 13 Jan 2012 15:38:45 +0800
Subject: POSIX compatibility change for including wait.h in
UNIXProcess_md.c
In-Reply-To: <4F0EC525.4070507@oracle.com>
References: <4F0EA969.5000600@linux.vnet.ibm.com> <4F0EC525.4070507@oracle.com>
Message-ID: <4F0FDF85.1060406@linux.vnet.ibm.com>

Hello David and Alan,

Thanks for the review.
Do you plan to push it?

Cheers
- Jonathan

On 01/12/2012 07:33 PM, Alan Bateman wrote:
> On 12/01/2012 09:35, Jonathan Lu wrote:
>> Hi core-libs-dev,
>>
>> It was found that solaris/native/java/lang/UNIXProcess_md.c includes
>> <wait.h> which does not seem to be compliant with POSIX
>> specification, in which the expected header file name should be
>> <sys/wait.h>. see http://en.wikipedia.org/wiki/C_POSIX_library. I
>> also performed a 'grep' for the code base, it seems nowhere else
>> needs to be changed so far.
>>
>> So here is a simple patch to adjust this issue, any suggestions?
>> http://cr.openjdk.java.net/~luchsh/wait_h_POSIX_comp/
>>
>> Cheers
>> - Jonathan
>>
> This looks fine to me.
>
> -Alan



From alan.bateman at oracle.com Fri Jan 13 13:32:13 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 13 Jan 2012 13:32:13 +0000
Subject: hg: jdk8/tl/jdk: 7129029: (fs) Unix file system provider should be
buildable on platforms that don't support O_NOFOLLOW
Message-ID: <20120113133235.A9F634795E@hg.openjdk.java.net>

Changeset: 7e593aa6ad41
Author: littlee
Date: 2012-01-13 13:20 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7e593aa6ad41

7129029: (fs) Unix file system provider should be buildable on platforms that don't support O_NOFOLLOW
Reviewed-by: alanb

! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java
! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java
! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java
! src/solaris/classes/sun/nio/fs/UnixPath.java
! src/solaris/native/sun/nio/fs/genUnixConstants.c



From joe.darcy at oracle.com Sat Jan 14 05:26:25 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 13 Jan 2012 21:26:25 -0800
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
Message-ID: <4F111201.3060407@oracle.com>

Hello,

Polishing up some work I've had *almost* done for a long time, please
review an initial take on providing library support for unsigned integer
arithmetic:

4504839 Java libraries should provide support for unsigned integer
arithmetic
4215269 Some Integer.toHexString(int) results cannot be decoded
back to an int
6322074 Converting integers to string as if unsigned

http://cr.openjdk.java.net/~darcy/4504839.1/

For the first cut, I've favored keeping the code straightforward over
trickier but potentially faster algorithms. Tests need to be written
for the unsigned divide and remainder methods, but otherwise the
regression tests are fairly extensive.

To avoid the overhead of having to deal with boxed objects, the unsigned
functionality is implemented as static methods on Integer and Long, etc.
as opposed to introducing new types like UnsignedInteger and UnsignedLong.

(This work is not meant to preclude other integer arithmetic
enhancements from going into JDK 8, such as add/subtract/multiply/divide
methods that throw exceptions on overflow.)

Thanks,

-Joe




From mike.duigou at oracle.com Sat Jan 14 05:51:32 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 13 Jan 2012 21:51:32 -0800
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <4F111201.3060407@oracle.com>
References: <4F111201.3060407@oracle.com>
Message-ID: <2F004A12-DDF6-4C42-A95E-9186A84E9AF4@oracle.com>

Really cool stuff Joe.

One initial note:

parseUnsigned*() returns a signed value that may not be able to hold the entire result. I would rather see a larger size be returned to be sure that subsequent operations don't have to be special cased for > MAX_VALUE. At minimum some documentation describing the interpretation of negative return values is needed.

Mike

On Jan 13 2012, at 21:26 , Joe Darcy wrote:

> Hello,
>
> Polishing up some work I've had *almost* done for a long time, please review an initial take on providing library support for unsigned integer arithmetic:
>
> 4504839 Java libraries should provide support for unsigned integer arithmetic
> 4215269 Some Integer.toHexString(int) results cannot be decoded back to an int
> 6322074 Converting integers to string as if unsigned
>
> http://cr.openjdk.java.net/~darcy/4504839.1/
>
> For the first cut, I've favored keeping the code straightforward over trickier but potentially faster algorithms. Tests need to be written for the unsigned divide and remainder methods, but otherwise the regression tests are fairly extensive.
>
> To avoid the overhead of having to deal with boxed objects, the unsigned functionality is implemented as static methods on Integer and Long, etc. as opposed to introducing new types like UnsignedInteger and UnsignedLong.
>
> (This work is not meant to preclude other integer arithmetic enhancements from going into JDK 8, such as add/subtract/multiply/divide methods that throw exceptions on overflow.)
>
> Thanks,
>
> -Joe
>
>



From joe.darcy at oracle.com Sat Jan 14 18:58:04 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 14 Jan 2012 10:58:04 -0800
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <2F004A12-DDF6-4C42-A95E-9186A84E9AF4@oracle.com>
References: <4F111201.3060407@oracle.com>
<2F004A12-DDF6-4C42-A95E-9186A84E9AF4@oracle.com>
Message-ID: <4F11D03C.9000100@oracle.com>

Hi Mike,

On 01/13/2012 09:51 PM, Mike Duigou wrote:
> Really cool stuff Joe.
>
> One initial note:
>
> parseUnsigned*() returns a signed value that may not be able to hold the entire result. I would rather see a larger size be returned to be sure that subsequent operations don't have to be special cased for> MAX_VALUE. At minimum some documentation describing the interpretation of negative return values is needed.

The intention of the fooUnsigned methods is that they interpret the 32
or 64 bit value as unsigned. So for example, for parseUnsigned, rather
than recognizing strings representing values between -2^31 and (2^31)-1,
the method recognizes values between 0 and (2^32)-1, mapping results
between 2^31 and (2^32)-1 to what are usually thought of as the negative
values.

I'll take another pass over the new javadoc to try to make this clearer.

Thanks,

-Joe

>
> Mike
>
> On Jan 13 2012, at 21:26 , Joe Darcy wrote:
>
>> Hello,
>>
>> Polishing up some work I've had *almost* done for a long time, please review an initial take on providing library support for unsigned integer arithmetic:
>>
>> 4504839 Java libraries should provide support for unsigned integer arithmetic
>> 4215269 Some Integer.toHexString(int) results cannot be decoded back to an int
>> 6322074 Converting integers to string as if unsigned
>>
>> http://cr.openjdk.java.net/~darcy/4504839.1/
>>
>> For the first cut, I've favored keeping the code straightforward over trickier but potentially faster algorithms. Tests need to be written for the unsigned divide and remainder methods, but otherwise the regression tests are fairly extensive.
>>
>> To avoid the overhead of having to deal with boxed objects, the unsigned functionality is implemented as static methods on Integer and Long, etc. as opposed to introducing new types like UnsignedInteger and UnsignedLong.
>>
>> (This work is not meant to preclude other integer arithmetic enhancements from going into JDK 8, such as add/subtract/multiply/divide methods that throw exceptions on overflow.)
>>
>> Thanks,
>>
>> -Joe
>>
>>



From eamonn at mcmanus.net Sun Jan 15 17:53:35 2012
From: eamonn at mcmanus.net (Eamonn McManus)
Date: Sun, 15 Jan 2012 09:53:35 -0800
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <4F111201.3060407@oracle.com>
References: <4F111201.3060407@oracle.com>
Message-ID: <CACBEn45ZHo_=3WnKF6YvOBYHoO7H4idzeThivyCaiY1msmfWMg@mail.gmail.com>

It's great to see this! The API looks reasonable to me.

> For the first cut, I've favored keeping the code straightforward over
trickier but potentially faster algorithms.

The code looks clean and correct to me. But I think we could afford one or
two cheap improvements to Long without diving into the full-blown Hacker's
Delight algorithms:

In toUnsignedBigInteger(i) we could check whether i is nonnegative and use
plain BigInteger.valueOf(i) in that case. Also, although the difference is
sure to be unmeasurable, I think (int) (i >>> 32) would be better
than (int) ((i >> 32) & 0xffffffff).

In parseUnsignedLong, we can avoid using BigInteger by parsing all but the
last digit as a positive number and then adding in that digit:
long first = parseLong(s.substring(0, len - 1), radix);
int second = Character.digit(s.charAt(len - 1), radix);
if (second < 0) {
throw new NumberFormatException("Bad digit at end of " + s);
}
long result = first * radix + second;
if (compareUnsigned(result, first) < 0) {
throw new NumberFormatException(String.format("String value %s
exceeds " +
"range of unsigned
long.", s));
}
By my measurements this speeds up the parsing of random decimal unsigned
longs by about 2.5 times. Changing the existing code to move the limit
constant to a field or to test for overflow using bi.bitLength() instead
still leaves it about twice as slow.

In divideUnsigned, after eliminating negative divisors we could check
whether the dividend is also nonnegative and use plain division in that
case.

In remainderUnsigned, we could check whether both arguments are nonnegative
and use plain % in that case, and we could also check whether the divisor
is unsigned-less than the dividend, and return it directly in that case.

?amonn


On 13 January 2012 21:26, Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello,
>
> Polishing up some work I've had *almost* done for a long time, please
> review an initial take on providing library support for unsigned integer
> arithmetic:
>
> 4504839 Java libraries should provide support for unsigned integer
> arithmetic
> 4215269 Some Integer.toHexString(int) results cannot be decoded back to
> an int
> 6322074 Converting integers to string as if unsigned
>
> http://cr.openjdk.java.net/~**darcy/4504839.1/<http://cr.openjdk.java.net/~darcy/4504839.1/>
>
> For the first cut, I've favored keeping the code straightforward over
> trickier but potentially faster algorithms. Tests need to be written for
> the unsigned divide and remainder methods, but otherwise the regression
> tests are fairly extensive.
>
> To avoid the overhead of having to deal with boxed objects, the unsigned
> functionality is implemented as static methods on Integer and Long, etc. as
> opposed to introducing new types like UnsignedInteger and UnsignedLong.
>
> (This work is not meant to preclude other integer arithmetic enhancements
> from going into JDK 8, such as add/subtract/multiply/divide methods that
> throw exceptions on overflow.)
>
> Thanks,
>
> -Joe
>
>
>


From weijun.wang at oracle.com Mon Jan 16 02:14:45 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Mon, 16 Jan 2012 02:14:45 +0000
Subject: hg: jdk8/tl/jdk: 7118809: rcache deadlock
Message-ID: <20120116021517.899F94797D@hg.openjdk.java.net>

Changeset: e8e08d46cc37
Author: weijun
Date: 2012-01-16 10:10 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8e08d46cc37

7118809: rcache deadlock
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java
! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java
! test/sun/security/krb5/auto/Context.java
+ test/sun/security/krb5/auto/ReplayCache.java



From sean.coffey at oracle.com Mon Jan 16 11:36:41 2012
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Mon, 16 Jan 2012 11:36:41 +0000
Subject: Code review request for 7058133 : Javah should use the freshly built
classes instead of those from the BOOTDIR jdk
Message-ID: <4F140BC9.9030300@oracle.com>

Valerie,

I'm porting this fix to the JDK 7u repo. It's been fixed in JDK 6 & JDK
8 repos already.

full builds have been made with no issues seen.

Bug report : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7058133
webrev : http://cr.openjdk.java.net/~coffeys/webrev.7058133.jdk7u/

The fix differs slightly with the JDK 8 webrev (pkcs11 make directory is
touched in JDK 7)
We may need to revisit the JDK 8 one again.

regards,
Sean.


From Alan.Bateman at oracle.com Mon Jan 16 16:12:47 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Jan 2012 16:12:47 +0000
Subject: 7130398: ProblemList.txt updates (1/2012)
Message-ID: <4F144C7F.2040803@oracle.com>


It's time to sync up test/ProblemList.txt again as it's currently not
possible to do a clean test run.

-Alan.


diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -195,18 +195,21 @@ java/beans/XMLEncoder/6329581/Test632958

# jdk_lang

+# 7123972
+test/java/lang/annotation/loaderLeak/Main.java generic-all
+
# 7079093
java/lang/instrument/ManifestTest.sh
windows-all
-
-############################################################################
-
-# jdk_management

# 6944188
java/lang/management/ThreadMXBean/ThreadStateTest.java
generic-all

# 7067973
java/lang/management/MemoryMXBean/CollectionUsageThreshold.java
generic-all
+
+############################################################################
+
+# jdk_management

# Failing, bug was filed: 6959636
javax/management/loading/LibraryLoader/LibraryLoaderTest.java
generic-all
@@ -288,6 +291,9 @@ javax/management/monitor/AttributeArbitr
############################################################################

# jdk_misc
+
+# 6988950
+demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java generic-all

# Need to be marked othervm, or changed to be samevm safe
com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java
generic-all



From chris.hegarty at oracle.com Mon Jan 16 16:32:12 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 16 Jan 2012 16:32:12 +0000
Subject: 7130398: ProblemList.txt updates (1/2012)
In-Reply-To: <4F144C7F.2040803@oracle.com>
References: <4F144C7F.2040803@oracle.com>
Message-ID: <4F14510C.8020606@oracle.com>

test/java/lang/annotation/loaderLeak/Main.java ->
java/lang/annotation/loaderLeak/Main.java

,otherwise fine.

Thanks for adding these, I've been running into them also.

-Chris.

On 16/01/2012 16:12, Alan Bateman wrote:
>
> It's time to sync up test/ProblemList.txt again as it's currently not
> possible to do a clean test run.
>
> -Alan.
>
>
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -195,18 +195,21 @@ java/beans/XMLEncoder/6329581/Test632958
>
> # jdk_lang
>
> +# 7123972
> +test/java/lang/annotation/loaderLeak/Main.java generic-all
> +
> # 7079093
> java/lang/instrument/ManifestTest.sh windows-all
> -
> -############################################################################
>
> -
> -# jdk_management
>
> # 6944188
> java/lang/management/ThreadMXBean/ThreadStateTest.java generic-all
>
> # 7067973
> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java generic-all
> +
> +############################################################################
>
> +
> +# jdk_management
>
> # Failing, bug was filed: 6959636
> javax/management/loading/LibraryLoader/LibraryLoaderTest.java generic-all
> @@ -288,6 +291,9 @@ javax/management/monitor/AttributeArbitr
> ############################################################################
>
>
> # jdk_misc
> +
> +# 6988950
> +demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java generic-all
>
> # Need to be marked othervm, or changed to be samevm safe
> com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java generic-all
>


From alan.bateman at oracle.com Mon Jan 16 16:31:26 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 16 Jan 2012 16:31:26 +0000
Subject: hg: jdk8/tl/jdk: 7130398: ProblemList.txt updates (1/2012)
Message-ID: <20120116163149.C44094798C@hg.openjdk.java.net>

Changeset: d1b0bda3a3c7
Author: alanb
Date: 2012-01-16 16:30 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1b0bda3a3c7

7130398: ProblemList.txt updates (1/2012)
Reviewed-by: chegar

! test/ProblemList.txt



From Alan.Bateman at oracle.com Mon Jan 16 16:32:16 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Jan 2012 16:32:16 +0000
Subject: 7130398: ProblemList.txt updates (1/2012)
In-Reply-To: <4F14510C.8020606@oracle.com>
References: <4F144C7F.2040803@oracle.com> <4F14510C.8020606@oracle.com>
Message-ID: <4F145110.4080001@oracle.com>

On 16/01/2012 16:32, Chris Hegarty wrote:
> test/java/lang/annotation/loaderLeak/Main.java ->
> java/lang/annotation/loaderLeak/Main.java
>
> ,otherwise fine.
>
> Thanks for adding these, I've been running into them also.
>
> -Chris.
I noticed the additional test/ after sending the mail. Thanks, pushing
it now and hopefully that's enough test whacking for a while.

-Alan.


From chris.hegarty at oracle.com Mon Jan 16 21:28:04 2012
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 16 Jan 2012 21:28:04 +0000
Subject: hg: jdk8/tl/jdk: 7129083: CookieManager does not store cookies if url
is read before setting cookie manager
Message-ID: <20120116212828.15AF54798E@hg.openjdk.java.net>

Changeset: e8a143213c65
Author: chegar
Date: 2012-01-16 18:05 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8a143213c65

7129083: CookieManager does not store cookies if url is read before setting cookie manager
Reviewed-by: michaelm

! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/share/classes/sun/net/www/protocol/https/HttpsClient.java
+ test/sun/net/www/http/HttpClient/CookieHttpClientTest.java
+ test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java



From chris.hegarty at oracle.com Tue Jan 17 12:05:55 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 17 Jan 2012 12:05:55 +0000
Subject: 7130398: ProblemList.txt updates (1/2012)
In-Reply-To: <4F144C7F.2040803@oracle.com>
References: <4F144C7F.2040803@oracle.com>
Message-ID: <4F156423.5010401@oracle.com>

Alan,

I'd like to use this CR to backport some similar changes to 7u4. I guess
this is a request for review of the following, for 7u-dev:

--- a/test/ProblemList.txt Mon Jan 16 18:05:29 2012 +0000
+++ b/test/ProblemList.txt Tue Jan 17 12:09:17 2012 +0000
@@ -195,6 +195,9 @@ java/beans/XMLEncoder/6329581/Test632958

# jdk_lang

+# 7123972
+java/lang/annotation/loaderLeak/Main.java generic-all
+
# Times out on solaris 10 sparc
java/lang/ClassLoader/Assert.java generic-all

@@ -369,6 +372,9 @@ javax/print/attribute/MediaMappingsTest.

# 6962637
java/io/File/MaxPathLength.java
windows-all
+
+# 6671616
+java/io/File/BlockIsDirectory.java solaris-all


############################################################################

Thanks,
-Chris



On 01/16/12 04:12 PM, Alan Bateman wrote:
>
> It's time to sync up test/ProblemList.txt again as it's currently not
> possible to do a clean test run.
>
> -Alan.
>
>
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -195,18 +195,21 @@ java/beans/XMLEncoder/6329581/Test632958
>
> # jdk_lang
>
> +# 7123972
> +test/java/lang/annotation/loaderLeak/Main.java generic-all
> +
> # 7079093
> java/lang/instrument/ManifestTest.sh windows-all
> -
> -############################################################################
>
> -
> -# jdk_management
>
> # 6944188
> java/lang/management/ThreadMXBean/ThreadStateTest.java generic-all
>
> # 7067973
> java/lang/management/MemoryMXBean/CollectionUsageThreshold.java generic-all
> +
> +############################################################################
>
> +
> +# jdk_management
>
> # Failing, bug was filed: 6959636
> javax/management/loading/LibraryLoader/LibraryLoaderTest.java generic-all
> @@ -288,6 +291,9 @@ javax/management/monitor/AttributeArbitr
> ############################################################################
>
>
> # jdk_misc
> +
> +# 6988950
> +demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java generic-all
>
> # Need to be marked othervm, or changed to be samevm safe
> com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java generic-all
>


From Alan.Bateman at oracle.com Tue Jan 17 12:23:38 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 17 Jan 2012 12:23:38 +0000
Subject: 7130398: ProblemList.txt updates (1/2012)
In-Reply-To: <4F156423.5010401@oracle.com>
References: <4F144C7F.2040803@oracle.com> <4F156423.5010401@oracle.com>
Message-ID: <4F15684A.8060003@oracle.com>

On 17/01/2012 12:05, Chris Hegarty wrote:
> Alan,
>
> I'd like to use this CR to backport some similar changes to 7u4. I
> guess this is a request for review of the following, for 7u-dev:
The 7u ProblemList.txt file is clearly out of date and needs to be
sync'ed up.

The CR that added java/io/File/BlockIsDirectory.java to the ProblemList
in jdk8 is 7081813. I would actually prefer to just get rid of this test
(see 6671616). At one point Stuart was going to do this but I think it
fell off his radar.

If you are going to push 7130398 to 7u then I think it should include
demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java too - that
test will likely fail more once hotspot is sync'ed up.

-Alan.


From chris.hegarty at oracle.com Tue Jan 17 12:51:30 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 17 Jan 2012 12:51:30 +0000
Subject: 7130398: ProblemList.txt updates (1/2012)
In-Reply-To: <4F15684A.8060003@oracle.com>
References: <4F144C7F.2040803@oracle.com> <4F156423.5010401@oracle.com>
<4F15684A.8060003@oracle.com>
Message-ID: <4F156ED2.7000100@oracle.com>

OK, lets backport 7130398 as is to 7u4. And I'll look at 6671616.

-Chris.

On 01/17/12 12:23 PM, Alan Bateman wrote:
> On 17/01/2012 12:05, Chris Hegarty wrote:
>> Alan,
>>
>> I'd like to use this CR to backport some similar changes to 7u4. I
>> guess this is a request for review of the following, for 7u-dev:
> The 7u ProblemList.txt file is clearly out of date and needs to be
> sync'ed up.
>
> The CR that added java/io/File/BlockIsDirectory.java to the ProblemList
> in jdk8 is 7081813. I would actually prefer to just get rid of this test
> (see 6671616). At one point Stuart was going to do this but I think it
> fell off his radar.
>
> If you are going to push 7130398 to 7u then I think it should include
> demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java too - that
> test will likely fail more once hotspot is sync'ed up.
>
> -Alan.


From chris.hegarty at oracle.com Tue Jan 17 13:26:21 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 17 Jan 2012 13:26:21 +0000
Subject: RFR 6671616: TEST_BUG java/io/File/BlockIsDirectory.java fails when
/dev/dsk empty (sol)
Message-ID: <4F1576FD.4070603@oracle.com>

On Solaris, this test looks in /dev/dsk for block special devices.
Unfortunately, /dev/dsk is empty within a zone. Also unfortunately, on a
non-zone Solaris machine, /dev/dsk is filled with symlinks to the actual
device nodes.

On Linux, this test looks at /dev/ide0 and /dev/scd0 which are presumed
to be block special devices. This is not always the case.

It's infeasible for the test to create its own block special devices for
testing, since this requires root access. It seems quite unlikely for
there to be a regression with this specific area, so the test should
simply be deleted, and removed from the ProblemList.

Changes being requested:
'hg remove test/java/io/File/BlockIsDirectory.java'

--- a/test/ProblemList.txt Mon Jan 16 18:05:29 2012 +0000
+++ b/test/ProblemList.txt Tue Jan 17 13:27:53 2012 +0000
@@ -393,9 +393,6 @@ java/net/PortUnreachableException/OneExc
# 6962637
java/io/File/MaxPathLength.java
windows-all

-# 6671616
-java/io/File/BlockIsDirectory.java solaris-all
-
# 7076644
java/io/File/Basic.java
windows-all


-Chris.


From Alan.Bateman at oracle.com Tue Jan 17 13:33:28 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 17 Jan 2012 13:33:28 +0000
Subject: RFR 6671616: TEST_BUG java/io/File/BlockIsDirectory.java fails
when /dev/dsk empty (sol)
In-Reply-To: <4F1576FD.4070603@oracle.com>
References: <4F1576FD.4070603@oracle.com>
Message-ID: <4F1578A8.5090504@oracle.com>

On 17/01/2012 13:26, Chris Hegarty wrote:
> On Solaris, this test looks in /dev/dsk for block special devices.
> Unfortunately, /dev/dsk is empty within a zone. Also unfortunately, on
> a non-zone Solaris machine, /dev/dsk is filled with symlinks to the
> actual device nodes.
>
> On Linux, this test looks at /dev/ide0 and /dev/scd0 which are
> presumed to be block special devices. This is not always the case.
>
> It's infeasible for the test to create its own block special devices
> for testing, since this requires root access. It seems quite unlikely
> for there to be a regression with this specific area, so the test
> should simply be deleted, and removed from the ProblemList.
>
> Changes being requested:
> 'hg remove test/java/io/File/BlockIsDirectory.java'
>
> --- a/test/ProblemList.txt Mon Jan 16 18:05:29 2012 +0000
> +++ b/test/ProblemList.txt Tue Jan 17 13:27:53 2012 +0000
> @@ -393,9 +393,6 @@ java/net/PortUnreachableException/OneExc
> # 6962637
> java/io/File/MaxPathLength.java windows-all
>
> -# 6671616
> -java/io/File/BlockIsDirectory.java
> solaris-all
> -
> # 7076644
> java/io/File/Basic.java windows-all
>
Thanks for taking this, we should have removed this test a long time ago.

-Alan


From chris.hegarty at oracle.com Tue Jan 17 16:51:18 2012
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 17 Jan 2012 16:51:18 +0000
Subject: hg: jdk8/tl/jdk: 6671616: TEST_BUG:
java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol)
Message-ID: <20120117165139.0ECB64799E@hg.openjdk.java.net>

Changeset: 40d699d7f6a1
Author: chegar
Date: 2012-01-17 14:10 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40d699d7f6a1

6671616: TEST_BUG: java/io/File/BlockIsDirectory.java fails when /dev/dsk empty (sol)
Reviewed-by: alanb

! test/ProblemList.txt
- test/java/io/File/BlockIsDirectory.java



From valerie.peng at oracle.com Tue Jan 17 20:01:58 2012
From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng)
Date: Tue, 17 Jan 2012 12:01:58 -0800
Subject: Code review request for 7058133 : Javah should use the freshly
built classes instead of those from the BOOTDIR jdk
In-Reply-To: <4F140BC9.9030300@oracle.com>
References: <4F140BC9.9030300@oracle.com>
Message-ID: <4F15D3B6.5000704@oracle.com>


Yes, it's good to have the fixes consistent across releases.
I'll get to the JDK8 makefiles later when I have cycles.
Regards,
Valerie

On 01/16/12 03:36, Se?n Coffey wrote:
> Valerie,
>
> I'm porting this fix to the JDK 7u repo. It's been fixed in JDK 6 &
> JDK 8 repos already.
>
> full builds have been made with no issues seen.
>
> Bug report : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7058133
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7058133.jdk7u/
>
> The fix differs slightly with the JDK 8 webrev (pkcs11 make directory
> is touched in JDK 7)
> We may need to revisit the JDK 8 one again.
>
> regards,
> Sean.



From jim.holmlund at sun.com Wed Jan 18 01:19:44 2012
From: jim.holmlund at sun.com (jim.holmlund at sun.com)
Date: Wed, 18 Jan 2012 01:19:44 +0000
Subject: hg: jdk8/tl/langtools: 7127924: langtools regression tests sometimes
fail en-masse on windows
Message-ID: <20120118011947.69437479AC@hg.openjdk.java.net>

Changeset: 1e2f4f4fb9f7
Author: jjh
Date: 2012-01-17 17:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1e2f4f4fb9f7

7127924: langtools regression tests sometimes fail en-masse on windows
Reviewed-by: jjg

! test/tools/javac/diags/CheckExamples.java
! test/tools/javac/diags/MessageInfo.java
! test/tools/javac/diags/RunExamples.java



From mandy.chung at oracle.com Wed Jan 18 02:03:55 2012
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Wed, 18 Jan 2012 02:03:55 +0000
Subject: hg: jdk8/tl/jdk: 7117570: Warnings in sun.mangement.* and its
subpackages
Message-ID: <20120118020408.796D4479AE@hg.openjdk.java.net>

Changeset: 2f096eb72520
Author: mchung
Date: 2012-01-17 15:55 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2f096eb72520

7117570: Warnings in sun.mangement.* and its subpackages
Reviewed-by: mchung, dsamersoff
Contributed-by: kurchi.subhra.hazra at oracle.com

! src/share/classes/sun/management/Agent.java
! src/share/classes/sun/management/ConnectorAddressLink.java
! src/share/classes/sun/management/Flag.java
! src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java
! src/share/classes/sun/management/GarbageCollectorImpl.java
! src/share/classes/sun/management/GcInfoBuilder.java
! src/share/classes/sun/management/GcInfoCompositeData.java
! src/share/classes/sun/management/HotSpotDiagnostic.java
! src/share/classes/sun/management/HotspotCompilation.java
! src/share/classes/sun/management/HotspotThread.java
! src/share/classes/sun/management/LazyCompositeData.java
! src/share/classes/sun/management/ManagementFactoryHelper.java
! src/share/classes/sun/management/MappedMXBeanType.java
! src/share/classes/sun/management/MonitorInfoCompositeData.java
! src/share/classes/sun/management/NotificationEmitterSupport.java
! src/share/classes/sun/management/RuntimeImpl.java
! src/share/classes/sun/management/ThreadInfoCompositeData.java
! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java
! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java
! src/share/classes/sun/management/snmp/AdaptorBootstrap.java
! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemGCTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java
! src/share/classes/sun/management/snmp/jvminstr/JvmThreadingMetaImpl.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java
! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java
! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIB.java
! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIBOidTable.java
! src/share/classes/sun/management/snmp/jvmmib/JvmClassLoadingMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmCompilationMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmOSMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmRuntimeMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceEntryMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceTableMeta.java
! src/share/classes/sun/management/snmp/jvmmib/JvmThreadingMeta.java
! src/share/classes/sun/management/snmp/util/MibLogger.java
! src/share/classes/sun/management/snmp/util/SnmpListTableCache.java
! src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java
! src/share/classes/sun/management/snmp/util/SnmpTableCache.java



From joe.darcy at oracle.com Wed Jan 18 02:54:44 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 17 Jan 2012 18:54:44 -0800
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <CACBEn45ZHo_=3WnKF6YvOBYHoO7H4idzeThivyCaiY1msmfWMg@mail.gmail.com>
References: <4F111201.3060407@oracle.com>
<CACBEn45ZHo_=3WnKF6YvOBYHoO7H4idzeThivyCaiY1msmfWMg@mail.gmail.com>
Message-ID: <4F163474.7060908@oracle.com>

Hi Eamonn,

On 01/15/2012 09:53 AM, Eamonn McManus wrote:
> It's great to see this!

I agree :-)

I've posted a revised webrev at

http://cr.openjdk.java.net/~darcy/4504839.2

More detailed responses inline.

> The API looks reasonable to me.
>
> > For the first cut, I've favored keeping the code straightforward
> over trickier but potentially faster algorithms.
>
> The code looks clean and correct to me. But I think we could afford
> one or two cheap improvements to Long without diving into the
> full-blown Hacker's Delight algorithms:
>
> In toUnsignedBigInteger(i) we could check whether i is nonnegative and
> use plain BigInteger.valueOf(i) in that case. Also, although the
> difference is sure to be unmeasurable, I think (int) (i >>> 32) would
> be better than (int) ((i >> 32) & 0xffffffff).

Good points; changed.

>
> In parseUnsignedLong, we can avoid using BigInteger by parsing all but
> the last digit as a positive number and then adding in that digit:
> long first = parseLong(s.substring(0, len - 1), radix);
> int second = Character.digit(s.charAt(len - 1), radix);
> if (second < 0) {
> throw new NumberFormatException("Bad digit at end of " + s);
> }
> long result = first * radix + second;
> if (compareUnsigned(result, first) < 0) {
> throw new NumberFormatException(String.format("String value %s
> exceeds " +
> "range of
> unsigned long.", s));
> }
> By my measurements this speeds up the parsing of random decimal
> unsigned longs by about 2.5 times. Changing the existing code to move
> the limit constant to a field or to test for overflow using
> bi.bitLength() instead still leaves it about twice as slow.

Changed.

Also from some off-list comments from Mike, I've modified the first
sentence of the parseUnsignedLong methods to explicitly mention the
"long" type; this is consistent with the phrasing of the signed
parseLong methods in java.lang.Long.

>
> In divideUnsigned, after eliminating negative divisors we could check
> whether the dividend is also nonnegative and use plain division in
> that case.

Changed.

>
> In remainderUnsigned, we could check whether both arguments are
> nonnegative and use plain % in that case, and we could also check
> whether the divisor is unsigned-less than the dividend, and return it
> directly in that case.

Changed.

I've also added test cases for the unsigned divide and remainder methods.

Thanks again,

-Joe

>
> ?amonn
>
>
> On 13 January 2012 21:26, Joe Darcy <joe.darcy at oracle.com
> <mailto:joe.darcy at oracle.com>> wrote:
>
> Hello,
>
> Polishing up some work I've had *almost* done for a long time,
> please review an initial take on providing library support for
> unsigned integer arithmetic:
>
> 4504839 Java libraries should provide support for unsigned
> integer arithmetic
> 4215269 Some Integer.toHexString(int) results cannot be decoded
> back to an int
> 6322074 Converting integers to string as if unsigned
>
> http://cr.openjdk.java.net/~darcy/4504839.1/
> <http://cr.openjdk.java.net/%7Edarcy/4504839.1/>
>
> For the first cut, I've favored keeping the code straightforward
> over trickier but potentially faster algorithms. Tests need to be
> written for the unsigned divide and remainder methods, but
> otherwise the regression tests are fairly extensive.
>
> To avoid the overhead of having to deal with boxed objects, the
> unsigned functionality is implemented as static methods on Integer
> and Long, etc. as opposed to introducing new types like
> UnsignedInteger and UnsignedLong.
>
> (This work is not meant to preclude other integer arithmetic
> enhancements from going into JDK 8, such as
> add/subtract/multiply/divide methods that throw exceptions on
> overflow.)
>
> Thanks,
>
> -Joe
>
>
>



From eamonn at mcmanus.net Wed Jan 18 05:08:07 2012
From: eamonn at mcmanus.net (Eamonn McManus)
Date: Tue, 17 Jan 2012 21:08:07 -0800
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <4F163474.7060908@oracle.com>
References: <4F111201.3060407@oracle.com>
<CACBEn45ZHo_=3WnKF6YvOBYHoO7H4idzeThivyCaiY1msmfWMg@mail.gmail.com>
<4F163474.7060908@oracle.com>
Message-ID: <CACBEn479wxLKxpJZAS3Fvmvkv_kr4hqf0XdaqMhSbt4iUzUKZw@mail.gmail.com>

Hi Joe,

That looks great to me (emcmanus). One thing I noticed is that the
behaviour is not explicitly specified when parseUnsignedLong is given a
null String reference. But I see that is also true of the existing
parseLong and valueOf(String) and decode(String), so perhaps there should
be a separate bug to update the spec there. The phrase "If the string
cannot be parsed as a long" does not cover this case as obviously as it
might.

Cheers,
?amonn


On 17 January 2012 18:54, Joe Darcy <joe.darcy at oracle.com> wrote:

> Hi Eamonn,
>
>
> On 01/15/2012 09:53 AM, Eamonn McManus wrote:
>
> It's great to see this!
>
>
> I agree :-)
>
> I've posted a revised webrev at
>
> http://cr.openjdk.java.net/~darcy/4504839.2
>
> More detailed responses inline.
>
>
> The API looks reasonable to me.
>
> > For the first cut, I've favored keeping the code straightforward over
> trickier but potentially faster algorithms.
>
> The code looks clean and correct to me. But I think we could afford one
> or two cheap improvements to Long without diving into the full-blown
> Hacker's Delight algorithms:
>
> In toUnsignedBigInteger(i) we could check whether i is nonnegative and
> use plain BigInteger.valueOf(i) in that case. Also, although the difference
> is sure to be unmeasurable, I think (int) (i >>> 32) would be better
> than (int) ((i >> 32) & 0xffffffff).
>
>
> Good points; changed.
>
>
>
> In parseUnsignedLong, we can avoid using BigInteger by parsing all but
> the last digit as a positive number and then adding in that digit:
> long first = parseLong(s.substring(0, len - 1), radix);
> int second = Character.digit(s.charAt(len - 1), radix);
> if (second < 0) {
> throw new NumberFormatException("Bad digit at end of " + s);
> }
> long result = first * radix + second;
> if (compareUnsigned(result, first) < 0) {
> throw new NumberFormatException(String.format("String value %s
> exceeds " +
> "range of unsigned
> long.", s));
> }
> By my measurements this speeds up the parsing of random decimal unsigned
> longs by about 2.5 times. Changing the existing code to move the limit
> constant to a field or to test for overflow using bi.bitLength() instead
> still leaves it about twice as slow.
>
>
> Changed.
>
> Also from some off-list comments from Mike, I've modified the first
> sentence of the parseUnsignedLong methods to explicitly mention the "long"
> type; this is consistent with the phrasing of the signed parseLong methods
> in java.lang.Long.
>
>
>
> In divideUnsigned, after eliminating negative divisors we could check
> whether the dividend is also nonnegative and use plain division in that
> case.
>
>
> Changed.
>
>
>
> In remainderUnsigned, we could check whether both arguments are
> nonnegative and use plain % in that case, and we could also check whether
> the divisor is unsigned-less than the dividend, and return it directly in
> that case.
>
>
> Changed.
>
> I've also added test cases for the unsigned divide and remainder methods.
>
> Thanks again,
>
> -Joe
>
>
>
> ?amonn
>
>
> On 13 January 2012 21:26, Joe Darcy <joe.darcy at oracle.com> wrote:
>
>> Hello,
>>
>> Polishing up some work I've had *almost* done for a long time, please
>> review an initial take on providing library support for unsigned integer
>> arithmetic:
>>
>> 4504839 Java libraries should provide support for unsigned integer
>> arithmetic
>> 4215269 Some Integer.toHexString(int) results cannot be decoded back
>> to an int
>> 6322074 Converting integers to string as if unsigned
>>
>> http://cr.openjdk.java.net/~darcy/4504839.1/
>>
>> For the first cut, I've favored keeping the code straightforward over
>> trickier but potentially faster algorithms. Tests need to be written for
>> the unsigned divide and remainder methods, but otherwise the regression
>> tests are fairly extensive.
>>
>> To avoid the overhead of having to deal with boxed objects, the unsigned
>> functionality is implemented as static methods on Integer and Long, etc. as
>> opposed to introducing new types like UnsignedInteger and UnsignedLong.
>>
>> (This work is not meant to preclude other integer arithmetic enhancements
>> from going into JDK 8, such as add/subtract/multiply/divide methods that
>> throw exceptions on overflow.)
>>
>> Thanks,
>>
>> -Joe
>>
>>
>>
>
>


From joe.darcy at oracle.com Wed Jan 18 05:41:35 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 17 Jan 2012 21:41:35 -0800
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <CACBEn479wxLKxpJZAS3Fvmvkv_kr4hqf0XdaqMhSbt4iUzUKZw@mail.gmail.com>
References: <4F111201.3060407@oracle.com>
<CACBEn45ZHo_=3WnKF6YvOBYHoO7H4idzeThivyCaiY1msmfWMg@mail.gmail.com>
<4F163474.7060908@oracle.com>
<CACBEn479wxLKxpJZAS3Fvmvkv_kr4hqf0XdaqMhSbt4iUzUKZw@mail.gmail.com>
Message-ID: <4F165B8F.1030604@oracle.com>

Hi Eamonn,

The body javadoc text of the two-argument parseUnsignedLong method does
state

620 * <p>An exception of type {@code NumberFormatException} is
621 * thrown if any of the following situations occurs:
622 * <ul>
623 * <li>The first argument is {@code null} or is a string of
624 * length zero.
...

However, it is true that the method does not have an explicit @throws
clause detailing this condition and that somewhat unconventionally an
NPE is *not* throw for an nonsensical null input. The behavior of the
one-argument version of parseUnsignedLong is defined in terms of the
two-argument version so strictly from a specification perspective, I
think the existing text is okay as-is even if suboptimal.

Thanks for the reviews,

-Joe

On 01/17/2012 09:08 PM, Eamonn McManus wrote:
> Hi Joe,
>
> That looks great to me (emcmanus). One thing I noticed is that the
> behaviour is not explicitly specified when parseUnsignedLong is given
> a null String reference. But I see that is also true of the existing
> parseLong and valueOf(String) and decode(String), so perhaps there
> should be a separate bug to update the spec there. The phrase "If the
> string cannot be parsed as a long" does not cover this case as
> obviously as it might.
>
> Cheers,
> ?amonn
>
>
> On 17 January 2012 18:54, Joe Darcy <joe.darcy at oracle.com
> <mailto:joe.darcy at oracle.com>> wrote:
>
> Hi Eamonn,
>
>
> On 01/15/2012 09:53 AM, Eamonn McManus wrote:
>> It's great to see this!
>
> I agree :-)
>
> I've posted a revised webrev at
>
> http://cr.openjdk.java.net/~darcy/4504839.2
> <http://cr.openjdk.java.net/%7Edarcy/4504839.2>
>
> More detailed responses inline.
>
>
>> The API looks reasonable to me.
>>
>> > For the first cut, I've favored keeping the code
>> straightforward over trickier but potentially faster algorithms.
>>
>> The code looks clean and correct to me. But I think we could
>> afford one or two cheap improvements to Long without diving into
>> the full-blown Hacker's Delight algorithms:
>>
>> In toUnsignedBigInteger(i) we could check whether i is
>> nonnegative and use plain BigInteger.valueOf(i) in that case.
>> Also, although the difference is sure to be unmeasurable, I think
>> (int) (i >>> 32) would be better than (int) ((i >> 32) & 0xffffffff).
>
> Good points; changed.
>
>
>>
>> In parseUnsignedLong, we can avoid using BigInteger by parsing
>> all but the last digit as a positive number and then adding in
>> that digit:
>> long first = parseLong(s.substring(0, len - 1), radix);
>> int second = Character.digit(s.charAt(len - 1), radix);
>> if (second < 0) {
>> throw new NumberFormatException("Bad digit at end of " + s);
>> }
>> long result = first * radix + second;
>> if (compareUnsigned(result, first) < 0) {
>> throw new NumberFormatException(String.format("String
>> value %s exceeds " +
>> "range of
>> unsigned long.", s));
>> }
>> By my measurements this speeds up the parsing of random decimal
>> unsigned longs by about 2.5 times. Changing the existing code to
>> move the limit constant to a field or to test for overflow using
>> bi.bitLength() instead still leaves it about twice as slow.
>
> Changed.
>
> Also from some off-list comments from Mike, I've modified the
> first sentence of the parseUnsignedLong methods to explicitly
> mention the "long" type; this is consistent with the phrasing of
> the signed parseLong methods in java.lang.Long.
>
>
>>
>> In divideUnsigned, after eliminating negative divisors we could
>> check whether the dividend is also nonnegative and use plain
>> division in that case.
>
> Changed.
>
>
>>
>> In remainderUnsigned, we could check whether both arguments are
>> nonnegative and use plain % in that case, and we could also check
>> whether the divisor is unsigned-less than the dividend, and
>> return it directly in that case.
>
> Changed.
>
> I've also added test cases for the unsigned divide and remainder
> methods.
>
> Thanks again,
>
> -Joe
>
>
>>
>> ?amonn
>>
>>
>> On 13 January 2012 21:26, Joe Darcy <joe.darcy at oracle.com
>> <mailto:joe.darcy at oracle.com>> wrote:
>>
>> Hello,
>>
>> Polishing up some work I've had *almost* done for a long
>> time, please review an initial take on providing library
>> support for unsigned integer arithmetic:
>>
>> 4504839 Java libraries should provide support for unsigned
>> integer arithmetic
>> 4215269 Some Integer.toHexString(int) results cannot be
>> decoded back to an int
>> 6322074 Converting integers to string as if unsigned
>>
>> http://cr.openjdk.java.net/~darcy/4504839.1/
>> <http://cr.openjdk.java.net/%7Edarcy/4504839.1/>
>>
>> For the first cut, I've favored keeping the code
>> straightforward over trickier but potentially faster
>> algorithms. Tests need to be written for the unsigned divide
>> and remainder methods, but otherwise the regression tests are
>> fairly extensive.
>>
>> To avoid the overhead of having to deal with boxed objects,
>> the unsigned functionality is implemented as static methods
>> on Integer and Long, etc. as opposed to introducing new types
>> like UnsignedInteger and UnsignedLong.
>>
>> (This work is not meant to preclude other integer arithmetic
>> enhancements from going into JDK 8, such as
>> add/subtract/multiply/divide methods that throw exceptions on
>> overflow.)
>>
>> Thanks,
>>
>> -Joe
>>
>>
>>
>
>



From luchsh at linux.vnet.ibm.com Wed Jan 18 08:19:16 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Wed, 18 Jan 2012 16:19:16 +0800
Subject: Problem of using malloc() without including stdlib.h
Message-ID: <4F168084.4080305@linux.vnet.ibm.com>

Hi core-libs-dev,

I found that for some native code of OpenJDK code base, malloc() is used
without including header file stdlib.h, such as following files,
./src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c
./src/solaris/native/sun/java2d/x11/XRBackendNative.c
....

I assume that there's no hacking tricks involved here, right? because
this may cause problem for some C compilers, which assumes 'int' as the
default return type of a function if it cannot find the function's
declaration during compiling. Under such a condition, actual return
result of type 'void*' from malloc() will be converted to 'int', which
may result in truncated pointers in 64bit platforms. If the application
tries to dereference such a broken pointer, error will occur.

Indeed I found some indirect includes of stdlib.h, but there're still
some I do not see a stdlib.h get included from any of the
direct/indirect included headers. I think in order to fix this problem,
two approaches may be considered here,
a) add "#include <stdlib.h>" to every missing .c file.
b) add "#include <stdlib.h>" to a commonly referenced header file, such
as jni_util.h. but it would not be easy to find such a file for all and
creating one is the same as approach a).

But both methods need to change many files, any other ideas about how to
fix it more elegantly?

Thanks and best regards!
- Jonathan



From Alan.Bateman at oracle.com Wed Jan 18 08:31:10 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Jan 2012 08:31:10 +0000
Subject: Problem of using malloc() without including stdlib.h
In-Reply-To: <4F168084.4080305@linux.vnet.ibm.com>
References: <4F168084.4080305@linux.vnet.ibm.com>
Message-ID: <4F16834E.2060105@oracle.com>

On 18/01/2012 08:19, Jonathan Lu wrote:
> Hi core-libs-dev,
>
> I found that for some native code of OpenJDK code base, malloc() is
> used without including header file stdlib.h, such as following files,
> ./src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c
> ./src/solaris/native/sun/java2d/x11/XRBackendNative.c
> ....
>
> I assume that there's no hacking tricks involved here, right? because
> this may cause problem for some C compilers, which assumes 'int' as
> the default return type of a function if it cannot find the function's
> declaration during compiling. Under such a condition, actual return
> result of type 'void*' from malloc() will be converted to 'int', which
> may result in truncated pointers in 64bit platforms. If the
> application tries to dereference such a broken pointer, error will occur.
>
> Indeed I found some indirect includes of stdlib.h, but there're still
> some I do not see a stdlib.h get included from any of the
> direct/indirect included headers. I think in order to fix this
> problem, two approaches may be considered here,
> a) add "#include <stdlib.h>" to every missing .c file.
> b) add "#include <stdlib.h>" to a commonly referenced header file,
> such as jni_util.h. but it would not be easy to find such a file for
> all and creating one is the same as approach a).
>
> But both methods need to change many files, any other ideas about how
> to fix it more elegantly?
>
> Thanks and best regards!
> - Jonathan
>
I would suggest bringing this up on the 2d-dev list so that the folks
that maintain this area can help.

-Alan.


From luchsh at linux.vnet.ibm.com Wed Jan 18 08:53:04 2012
From: luchsh at linux.vnet.ibm.com (Jonathan Lu)
Date: Wed, 18 Jan 2012 16:53:04 +0800
Subject: Problem of using malloc() without including stdlib.h
In-Reply-To: <4F16834E.2060105@oracle.com>
References: <4F168084.4080305@linux.vnet.ibm.com> <4F16834E.2060105@oracle.com>
Message-ID: <4F168870.7090900@linux.vnet.ibm.com>

On 01/18/2012 04:31 PM, Alan Bateman wrote:
> On 18/01/2012 08:19, Jonathan Lu wrote:
>> Hi core-libs-dev,
>>
>> I found that for some native code of OpenJDK code base, malloc() is
>> used without including header file stdlib.h, such as following files,
>> ./src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c
>> ./src/solaris/native/sun/java2d/x11/XRBackendNative.c
>> ....
>>
>> I assume that there's no hacking tricks involved here, right? because
>> this may cause problem for some C compilers, which assumes 'int' as
>> the default return type of a function if it cannot find the
>> function's declaration during compiling. Under such a condition,
>> actual return result of type 'void*' from malloc() will be converted
>> to 'int', which may result in truncated pointers in 64bit platforms.
>> If the application tries to dereference such a broken pointer, error
>> will occur.
>>
>> Indeed I found some indirect includes of stdlib.h, but there're still
>> some I do not see a stdlib.h get included from any of the
>> direct/indirect included headers. I think in order to fix this
>> problem, two approaches may be considered here,
>> a) add "#include <stdlib.h>" to every missing .c file.
>> b) add "#include <stdlib.h>" to a commonly referenced header file,
>> such as jni_util.h. but it would not be easy to find such a file for
>> all and creating one is the same as approach a).
>>
>> But both methods need to change many files, any other ideas about how
>> to fix it more elegantly?
>>
>> Thanks and best regards!
>> - Jonathan
>>
> I would suggest bringing this up on the 2d-dev list so that the folks
> that maintain this area can help.
>
> -Alan.

Actually some core files are also involved in this problem, such as
./src/windows/native/java/io/io_util_md.c
./src/share/back/debugInit.c

And this problem seems very generic, so I guess core-libs-dev list might
be the place to raise it.

-Jonathan



From Alan.Bateman at oracle.com Wed Jan 18 10:26:43 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Jan 2012 10:26:43 +0000
Subject: Problem of using malloc() without including stdlib.h
In-Reply-To: <4F168870.7090900@linux.vnet.ibm.com>
References: <4F168084.4080305@linux.vnet.ibm.com> <4F16834E.2060105@oracle.com>
<4F168870.7090900@linux.vnet.ibm.com>
Message-ID: <4F169E63.4060405@oracle.com>

On 18/01/2012 08:53, Jonathan Lu wrote:
> :
> Actually some core files are also involved in this problem, such as
> ./src/windows/native/java/io/io_util_md.c
> ./src/share/back/debugInit.c
>
> And this problem seems very generic, so I guess core-libs-dev list
> might be the place to raise it.
>
> -Jonathan
>
64-bit would be a concern although I would expect compiler warnings in
that case. Are you seeing compiler warnings? There may be cases where
stdlib is being included by some other header files. Also do you have a
complete list of the files (your original mail listed 2D files which is
why I suggested bringing it up on 2d-dev).

-Alan






From kelly.ohair at oracle.com Wed Jan 18 16:26:42 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 18 Jan 2012 08:26:42 -0800
Subject: Problem of using malloc() without including stdlib.h
In-Reply-To: <4F168084.4080305@linux.vnet.ibm.com>
References: <4F168084.4080305@linux.vnet.ibm.com>
Message-ID: <CEB47CF9-298F-4A2A-9AC5-6E4205A5D6E0@oracle.com>


On Jan 18, 2012, at 12:19 AM, Jonathan Lu wrote:

> Hi core-libs-dev,
>
> I found that for some native code of OpenJDK code base, malloc() is used without including header file stdlib.h, such as following files,
> ./src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c
> ./src/solaris/native/sun/java2d/x11/XRBackendNative.c
> ....
>
> I assume that there's no hacking tricks involved here, right? because this may cause problem for some C compilers, which assumes 'int' as the default return type of a function if it cannot find the function's declaration during compiling. Under such a condition, actual return result of type 'void*' from malloc() will be converted to 'int', which may result in truncated pointers in 64bit platforms. If the application tries to dereference such a broken pointer, error will occur.
>
> Indeed I found some indirect includes of stdlib.h, but there're still some I do not see a stdlib.h get included from any of the direct/indirect included headers. I think in order to fix this problem, two approaches may be considered here,
> a) add "#include <stdlib.h>" to every missing .c file.
> b) add "#include <stdlib.h>" to a commonly referenced header file, such as jni_util.h. but it would not be easy to find such a file for all and creating one is the same as approach a).
>

I suggest a) It should be harmless and is the right thing to do.

It's been a while since I studied the C standard, but I vaguely recall that there was another standard C include file
that would cause the malloc() prototype declaration to show up.
Or maybe it wasn't a standard one. In any case, I think your a) approach is correct and I don't see much a need
for detailed discussions on this, as long as it builds correctly with no warnings on all platforms. It should be fine and correct.
That's my 2 cents.

-kto

> But both methods need to change many files, any other ideas about how to fix it more elegantly?
>
> Thanks and best regards!
> - Jonathan
>



From philip.race at oracle.com Wed Jan 18 17:56:06 2012
From: philip.race at oracle.com (Phil Race)
Date: Wed, 18 Jan 2012 09:56:06 -0800
Subject: Problem of using malloc() without including stdlib.h
In-Reply-To: <CEB47CF9-298F-4A2A-9AC5-6E4205A5D6E0@oracle.com>
References: <4F168084.4080305@linux.vnet.ibm.com>
<CEB47CF9-298F-4A2A-9AC5-6E4205A5D6E0@oracle.com>
Message-ID: <4F1707B6.4060302@oracle.com>

Its arguable, whether harmless or not, that each file needs to include it.
Its not unreasonable for an area of the code to have a header file such
as "awt.h"
that is supposed to be the one that's included by the other files in
that area of
the code, and which takes care of common includes. jni_util.h is not
necessarily it.
There isn't a need for every file to include that.
Also many files are 3rd party libs and I don't like editing those as the
changes
really belong upstream.
So a one size fits all approach might be the answer but I'd want to make
sure
of that first.

So I'd like to see the list of files that generate actual warnings as
well as the list
of files that reference malloc but don't include stdlib.h.

We are well aware that returning int as a default is bad in 64 bit ..
I'd expect
instant death so I'd like to see those actual warnings rather than just the
theoretical ones.

My grep of a current JDK 8 build log for 64 bit Linux shows the only
malloc warnings
are in hotspot management code. So I am waiting for the proof of the
real problem

And I can speak for 2d, and if there's 2D files touched I would like to
see any changes
to those files, and the reasoning discussed on 2d-dev ..

-phil.

On 1/18/2012 8:26 AM, Kelly O'Hair wrote:
> On Jan 18, 2012, at 12:19 AM, Jonathan Lu wrote:
>
>> Hi core-libs-dev,
>>
>> I found that for some native code of OpenJDK code base, malloc() is used without including header file stdlib.h, such as following files,
>> ./src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c
>> ./src/solaris/native/sun/java2d/x11/XRBackendNative.c
>> ....
>>
>> I assume that there's no hacking tricks involved here, right? because this may cause problem for some C compilers, which assumes 'int' as the default return type of a function if it cannot find the function's declaration during compiling. Under such a condition, actual return result of type 'void*' from malloc() will be converted to 'int', which may result in truncated pointers in 64bit platforms. If the application tries to dereference such a broken pointer, error will occur.
>>
>> Indeed I found some indirect includes of stdlib.h, but there're still some I do not see a stdlib.h get included from any of the direct/indirect included headers. I think in order to fix this problem, two approaches may be considered here,
>> a) add "#include<stdlib.h>" to every missing .c file.
>> b) add "#include<stdlib.h>" to a commonly referenced header file, such as jni_util.h. but it would not be easy to find such a file for all and creating one is the same as approach a).
>>
> I suggest a) It should be harmless and is the right thing to do.
>
> It's been a while since I studied the C standard, but I vaguely recall that there was another standard C include file
> that would cause the malloc() prototype declaration to show up.
> Or maybe it wasn't a standard one. In any case, I think your a) approach is correct and I don't see much a need
> for detailed discussions on this, as long as it builds correctly with no warnings on all platforms. It should be fine and correct.
> That's my 2 cents.
>
> -kto
>
>> But both methods need to change many files, any other ideas about how to fix it more elegantly?
>>
>> Thanks and best regards!
>> - Jonathan
>>



From michael.x.mcmahon at oracle.com Wed Jan 18 18:06:56 2012
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 18 Jan 2012 18:06:56 +0000
Subject: Code review: 7126979 (props) JCK test
java_lang/System/GetProperties.java failing [macosx]
In-Reply-To: <4F0ED9E5.9070800@oracle.com>
References: <4F0EC260.1050605@oracle.com>
<4F0EC988.5030405@oracle.com> <4F0ED6BC.3070405@oracle.com>
<4F0ED9E5.9070800@oracle.com>
Message-ID: <4F170A40.3080004@oracle.com>

On 12/01/12 13:02, David Holmes wrote:
> On 12/01/2012 10:49 PM, Michael McMahon wrote:
>> Thanks David. Just found it now (Alan noticed it too). Scott sent his
>> webrev yesterday.
>>
>> It looks like both solutions fix the problem. The difference is that
>> Scott's re-initializes
>> the properties from native code each time System.initProperties() is
>> called.
>> On the other platforms, we only call it once.
>>
>> So, do we want Macos to diverge slightly from the other platforms in
>> this respect?
>
> I haven't compared things in detail but If there is no need to diverge
> then I would not diverge.
>
I've discussed this with Scott and we're agreed we will go with the
minimal change to the shared
code to begin with. I have created a CR (7131142) to track providing
what the Apple code did
originally, which was that it dynamically updates the system proxy
properties. The best way
to do this is through the DefaultProxySelector class rather than in the
common property initialization
code though.

- Michael.

> David
> -----
>
>> My preference is to keep the platforms as similar as possible,
>> minimising the changes
>> with jdk7u ...
>>
>> - Michael.
>>
>> On 12/01/12 11:52, David Holmes wrote:
>>> Michael,
>>>
>>> There was a different patch for this posted earlier today where the
>>> props fields were all nulled out so they didn't reference the freed
>>> locations amy more. (I didn't keep the email)
>>>
>>> ???
>>>
>>> David
>>>
>>> On 12/01/2012 9:22 PM, Michael McMahon wrote:
>>>> Could I get the following change for jdk7u-osx reviewed please?
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/7126979/webrev.1/
>>>>
>>>> The freeProps() call added by mac port can only be called once. Issue
>>>> seen if System.setProperties(null) is called.
>>>> GetJavaProperties() called a second time, which is supposed to return
>>>> the statically populated information
>>>> from first call. But some of it has been freed already.
>>>>
>>>> Fix is to remove the freeProps() code added in the original port
>>>> changeset. The fix reverts the mac specific code
>>>> to the original version.
>>>>
>>>> - Michael
>>>>
>>



From kelly.ohair at oracle.com Wed Jan 18 18:31:45 2012
From: kelly.ohair at oracle.com (Kelly O'Hair)
Date: Wed, 18 Jan 2012 10:31:45 -0800
Subject: Problem of using malloc() without including stdlib.h
In-Reply-To: <4F1707B6.4060302@oracle.com>
References: <4F168084.4080305@linux.vnet.ibm.com>
<CEB47CF9-298F-4A2A-9AC5-6E4205A5D6E0@oracle.com>
<4F1707B6.4060302@oracle.com>
Message-ID: <E292C7E2-5A67-4A65-BAB9-E140B244D664@oracle.com>

A webrev and a code review from the appropriate teams is indeed needed.

-kto

On Jan 18, 2012, at 9:56 AM, Phil Race wrote:

> Its arguable, whether harmless or not, that each file needs to include it.
> Its not unreasonable for an area of the code to have a header file such as "awt.h"
> that is supposed to be the one that's included by the other files in that area of
> the code, and which takes care of common includes. jni_util.h is not necessarily it.
> There isn't a need for every file to include that.
> Also many files are 3rd party libs and I don't like editing those as the changes
> really belong upstream.
> So a one size fits all approach might be the answer but I'd want to make sure
> of that first.
>
> So I'd like to see the list of files that generate actual warnings as well as the list
> of files that reference malloc but don't include stdlib.h.
>
> We are well aware that returning int as a default is bad in 64 bit .. I'd expect
> instant death so I'd like to see those actual warnings rather than just the
> theoretical ones.
>
> My grep of a current JDK 8 build log for 64 bit Linux shows the only malloc warnings
> are in hotspot management code. So I am waiting for the proof of the real problem
>
> And I can speak for 2d, and if there's 2D files touched I would like to see any changes
> to those files, and the reasoning discussed on 2d-dev ..
>
> -phil.
>
> On 1/18/2012 8:26 AM, Kelly O'Hair wrote:
>> On Jan 18, 2012, at 12:19 AM, Jonathan Lu wrote:
>>
>>> Hi core-libs-dev,
>>>
>>> I found that for some native code of OpenJDK code base, malloc() is used without including header file stdlib.h, such as following files,
>>> ./src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c
>>> ./src/solaris/native/sun/java2d/x11/XRBackendNative.c
>>> ....
>>>
>>> I assume that there's no hacking tricks involved here, right? because this may cause problem for some C compilers, which assumes 'int' as the default return type of a function if it cannot find the function's declaration during compiling. Under such a condition, actual return result of type 'void*' from malloc() will be converted to 'int', which may result in truncated pointers in 64bit platforms. If the application tries to dereference such a broken pointer, error will occur.
>>>
>>> Indeed I found some indirect includes of stdlib.h, but there're still some I do not see a stdlib.h get included from any of the direct/indirect included headers. I think in order to fix this problem, two approaches may be considered here,
>>> a) add "#include<stdlib.h>" to every missing .c file.
>>> b) add "#include<stdlib.h>" to a commonly referenced header file, such as jni_util.h. but it would not be easy to find such a file for all and creating one is the same as approach a).
>>>
>> I suggest a) It should be harmless and is the right thing to do.
>>
>> It's been a while since I studied the C standard, but I vaguely recall that there was another standard C include file
>> that would cause the malloc() prototype declaration to show up.
>> Or maybe it wasn't a standard one. In any case, I think your a) approach is correct and I don't see much a need
>> for detailed discussions on this, as long as it builds correctly with no warnings on all platforms. It should be fine and correct.
>> That's my 2 cents.
>>
>> -kto
>>
>>> But both methods need to change many files, any other ideas about how to fix it more elegantly?
>>>
>>> Thanks and best regards!
>>> - Jonathan
>>>
>



From Roger.Riggs at oracle.com Wed Jan 18 19:21:49 2012
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 18 Jan 2012 14:21:49 -0500
Subject: JDK 8 code review request for initial unsigned integer
In-Reply-To: <mailman.19014.1326865303.8505.core-libs-dev@openjdk.java.net>
References: <mailman.19014.1326865303.8505.core-libs-dev@openjdk.java.net>
Message-ID: <4F171BCD.2070500@oracle.com>

A comment or two on the webrev for unsigned:

http://cr.openjdk.java.net/~darcy/4504839.2

1. In the new parsing methods, could the String arguments be changed to
the more general
java.lang.CharSequence? For many parsing applications, it could be more
convenient
to pass a CharSequence than to create a new String.

For consistency, should all of the parse methods be converted from
String to CharSequence?

2. To be consistent, the new thrown exception messages should not end
with a period (".")

Roger





From forax at univ-mlv.fr Wed Jan 18 19:47:12 2012
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 18 Jan 2012 20:47:12 +0100
Subject: JDK 8 code review request for initial unsigned integer
In-Reply-To: <4F171BCD.2070500@oracle.com>
References: <mailman.19014.1326865303.8505.core-libs-dev@openjdk.java.net>
<4F171BCD.2070500@oracle.com>
Message-ID: <4F1721C0.9080409@univ-mlv.fr>

On 01/18/2012 08:21 PM, Roger Riggs wrote:
> A comment or two on the webrev for unsigned:
>
> http://cr.openjdk.java.net/~darcy/4504839.2
>
> 1. In the new parsing methods, could the String arguments be changed
> to the more general
> java.lang.CharSequence? For many parsing applications, it could be
> more convenient
> to pass a CharSequence than to create a new String.
>
> For consistency, should all of the parse methods be converted from
> String to CharSequence?

Good idea !
I've written a simple parser generator and after analyzing the perf of
an HTTP parser
generated by that tool a colleague of mine wrote a set of methods to convert
a CharSequence to primitive value to avoid to allocate transient String
objects.

>
> 2. To be consistent, the new thrown exception messages should not end
> with a period (".")
>
> Roger
>
>
>

R?mi



From joe.darcy at oracle.com Wed Jan 18 20:09:46 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 18 Jan 2012 12:09:46 -0800
Subject: JDK 8 code review request for initial unsigned integer
In-Reply-To: <4F171BCD.2070500@oracle.com>
References: <mailman.19014.1326865303.8505.core-libs-dev@openjdk.java.net>
<4F171BCD.2070500@oracle.com>
Message-ID: <4F17270A.5030502@oracle.com>

Hi Roger,

On 01/18/2012 11:21 AM, Roger Riggs wrote:
> A comment or two on the webrev for unsigned:
>
> http://cr.openjdk.java.net/~darcy/4504839.2
>
> 1. In the new parsing methods, could the String arguments be changed
> to the more general
> java.lang.CharSequence? For many parsing applications, it could be
> more convenient
> to pass a CharSequence than to create a new String.

I don't think that would be very helpful in this case. If the methods
were changed to take a CharSequence, the first action I'd write in the
method would be to call toString on the argument; this is necessary to
guard against the class of time-of-check-versus-time-of-use problems
because the CharSequence objects can be mutable.

>
> For consistency, should all of the parse methods be converted from
> String to CharSequence?

Given the timing of the introduction of String and CharSequence to the
platform, I don't think a bulk introduction of CharSequence parsing
methods now is necessary.

>
> 2. To be consistent, the new thrown exception messages should not end
> with a period (".")
>
>

I'll look over the exception messages to see that they are formatted
consistently.

Thanks,

-Joe



From lana.steuck at oracle.com Wed Jan 18 20:17:07 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 18 Jan 2012 20:17:07 +0000
Subject: hg: jdk8/tl: 3 new changesets
Message-ID: <20120118201708.06880479C2@hg.openjdk.java.net>

Changeset: 5a5eaf6374bc
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/rev/5a5eaf6374bc

Added tag jdk8-b19 for changeset 237bc29afbfc

! .hgtags

Changeset: cc771d92284f
Author: katleman
Date: 2012-01-05 08:42 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/rev/cc771d92284f

Added tag jdk8-b20 for changeset 5a5eaf6374bc

! .hgtags

Changeset: 7ad075c80995
Author: katleman
Date: 2012-01-13 10:05 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/rev/7ad075c80995

Added tag jdk8-b21 for changeset cc771d92284f

! .hgtags



From lana.steuck at oracle.com Wed Jan 18 20:17:06 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 18 Jan 2012 20:17:06 +0000
Subject: hg: jdk8/tl/corba: 3 new changesets
Message-ID: <20120118201711.0B5BA479C3@hg.openjdk.java.net>

Changeset: 51d8b6cb18c0
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/51d8b6cb18c0

Added tag jdk8-b19 for changeset e1366c5d84ef

! .hgtags

Changeset: f157fc2a71a3
Author: katleman
Date: 2012-01-05 08:42 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/f157fc2a71a3

Added tag jdk8-b20 for changeset 51d8b6cb18c0

! .hgtags

Changeset: a11d0062c445
Author: katleman
Date: 2012-01-13 10:05 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a11d0062c445

Added tag jdk8-b21 for changeset f157fc2a71a3

! .hgtags



From lana.steuck at oracle.com Wed Jan 18 20:17:12 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 18 Jan 2012 20:17:12 +0000
Subject: hg: jdk8/tl/jaxws: 5 new changesets
Message-ID: <20120118201712.59F05479C4@hg.openjdk.java.net>

Changeset: 2b2818e3386f
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/2b2818e3386f

Added tag jdk8-b19 for changeset b73b733214aa

! .hgtags

Changeset: dc2ee8b87884
Author: katleman
Date: 2012-01-05 08:42 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/dc2ee8b87884

Added tag jdk8-b20 for changeset 2b2818e3386f

! .hgtags

Changeset: e67d51254533
Author: ohair
Date: 2012-01-09 09:22 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e67d51254533

7096063: /META-INF/mimetypes.default missing in jre\lib\resources.jar
Reviewed-by: dholmes

! build-defs.xml

Changeset: c266cab0e3ff
Author: katleman
Date: 2012-01-11 16:12 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c266cab0e3ff

Merge


Changeset: 8d3df89b0f2d
Author: katleman
Date: 2012-01-13 10:05 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/8d3df89b0f2d

Added tag jdk8-b21 for changeset c266cab0e3ff

! .hgtags



From lana.steuck at oracle.com Wed Jan 18 20:17:13 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 18 Jan 2012 20:17:13 +0000
Subject: hg: jdk8/tl/jaxp: 3 new changesets
Message-ID: <20120118201713.20293479C5@hg.openjdk.java.net>

Changeset: f052abb8f374
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f052abb8f374

Added tag jdk8-b19 for changeset dffeb62b1a7f

! .hgtags

Changeset: d41eeadf5c13
Author: katleman
Date: 2012-01-05 08:42 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d41eeadf5c13

Added tag jdk8-b20 for changeset f052abb8f374

! .hgtags

Changeset: cf9d6ec44f89
Author: katleman
Date: 2012-01-13 10:05 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cf9d6ec44f89

Added tag jdk8-b21 for changeset d41eeadf5c13

! .hgtags



From lana.steuck at oracle.com Wed Jan 18 20:17:07 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 18 Jan 2012 20:17:07 +0000
Subject: hg: jdk8/tl/hotspot: 3 new changesets
Message-ID: <20120118201718.53D4F479C6@hg.openjdk.java.net>

Changeset: fe2c87649981
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe2c87649981

Added tag jdk8-b19 for changeset 9232e0ecbc2c

! .hgtags

Changeset: 9952d1c439d6
Author: katleman
Date: 2012-01-05 08:42 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9952d1c439d6

Added tag jdk8-b20 for changeset fe2c87649981

! .hgtags

Changeset: ed621d125d02
Author: katleman
Date: 2012-01-13 10:05 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed621d125d02

Added tag jdk8-b21 for changeset 9952d1c439d6

! .hgtags



From lana.steuck at oracle.com Wed Jan 18 20:17:19 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 18 Jan 2012 20:17:19 +0000
Subject: hg: jdk8/tl/langtools: 6 new changesets
Message-ID: <20120118201731.998B6479C7@hg.openjdk.java.net>

Changeset: ffd294128a48
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ffd294128a48

Added tag jdk8-b19 for changeset 77b2c066084c

! .hgtags

Changeset: 020819eb56d2
Author: katleman
Date: 2012-01-05 08:42 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/020819eb56d2

Added tag jdk8-b20 for changeset ffd294128a48

! .hgtags

Changeset: 4e8aa6eca726
Author: lana
Date: 2012-01-04 10:58 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4e8aa6eca726

Merge


Changeset: bcb21abf1c41
Author: lana
Date: 2012-01-09 19:13 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bcb21abf1c41

Merge


Changeset: 390a7828ae18
Author: katleman
Date: 2012-01-13 10:05 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/390a7828ae18

Added tag jdk8-b21 for changeset bcb21abf1c41

! .hgtags

Changeset: f00afa80f1f0
Author: lana
Date: 2012-01-18 11:00 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f00afa80f1f0

Merge




From lana.steuck at oracle.com Wed Jan 18 20:18:17 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 18 Jan 2012 20:18:17 +0000
Subject: hg: jdk8/tl/jdk: 20 new changesets
Message-ID: <20120118202131.6962A479C8@hg.openjdk.java.net>

Changeset: 60dd940eb58e
Author: yhuang
Date: 2011-12-12 18:21 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60dd940eb58e

7003124: In Bulgarian Locale DateFormat is wrong
Reviewed-by: naoto, peytoia

! src/share/classes/sun/text/resources/FormatData_bg.java
! test/sun/text/resources/LocaleData
! test/sun/text/resources/LocaleDataTest.java

Changeset: cd03cd0e0965
Author: mfang
Date: 2011-12-15 11:29 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd03cd0e0965

Merge


Changeset: 3778f8577305
Author: katleman
Date: 2011-12-28 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3778f8577305

Merge


Changeset: 80350ee39fa8
Author: katleman
Date: 2011-12-29 15:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80350ee39fa8

Added tag jdk8-b19 for changeset 3778f8577305

! .hgtags

Changeset: 172d70c50c65
Author: cgruszka
Date: 2011-09-15 13:59 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/172d70c50c65

7066713: Separate demos from the bundles on Solaris and Linux
Summary: add new license files to demos and samples, new directory for bundling
Reviewed-by: katleman, ohair, billyh

! make/common/Release.gmk
! make/common/shared/Defs-control.gmk

Changeset: eaf967fd25c5
Author: cgruszka
Date: 2011-10-18 14:21 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eaf967fd25c5

7099017: jdk7u2-dev does not build
Summary: changes to skip demo/DEMOS_LICENSE and sample/SAMPLES_LICENSE when building OPENJDK
Reviewed-by: ohair, billyh

! make/common/Release.gmk

Changeset: 39b7f01203c9
Author: cgruszka
Date: 2011-11-17 16:57 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b7f01203c9

Merge


Changeset: b64e7263b4fd
Author: cgruszka
Date: 2011-11-18 01:03 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b64e7263b4fd

Merge


Changeset: e98869ff9f1e
Author: cgruszka
Date: 2011-12-05 12:41 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e98869ff9f1e

Merge

- test/java/io/FileDescriptor/FileChannelFDTest.java
- test/java/io/etc/FileDescriptorSharing.java

Changeset: ffa36a6a46f5
Author: cgruszka
Date: 2011-12-16 15:01 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ffa36a6a46f5

Merge

- make/sun/motif12/reorder-i586
- make/sun/motif12/reorder-sparc
- make/sun/motif12/reorder-sparcv9
- src/share/native/java/util/zip/zlib-1.2.3/ChangeLog
- src/share/native/java/util/zip/zlib-1.2.3/README
- src/share/native/java/util/zip/zlib-1.2.3/compress.c
- src/share/native/java/util/zip/zlib-1.2.3/crc32.h
- src/share/native/java/util/zip/zlib-1.2.3/deflate.c
- src/share/native/java/util/zip/zlib-1.2.3/deflate.h
- src/share/native/java/util/zip/zlib-1.2.3/gzio.c
- src/share/native/java/util/zip/zlib-1.2.3/infback.c
- src/share/native/java/util/zip/zlib-1.2.3/inffast.c
- src/share/native/java/util/zip/zlib-1.2.3/inffast.h
- src/share/native/java/util/zip/zlib-1.2.3/inffixed.h
- src/share/native/java/util/zip/zlib-1.2.3/inflate.c
- src/share/native/java/util/zip/zlib-1.2.3/inflate.h
- src/share/native/java/util/zip/zlib-1.2.3/inftrees.c
- src/share/native/java/util/zip/zlib-1.2.3/inftrees.h
- src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java
- src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff
- src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff
- src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff
- src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff
- src/share/native/java/util/zip/zlib-1.2.3/trees.c
- src/share/native/java/util/zip/zlib-1.2.3/trees.h
- src/share/native/java/util/zip/zlib-1.2.3/uncompr.c
- src/share/native/java/util/zip/zlib-1.2.3/zadler32.c
- src/share/native/java/util/zip/zlib-1.2.3/zconf.h
- src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c
- src/share/native/java/util/zip/zlib-1.2.3/zlib.h
- src/share/native/java/util/zip/zlib-1.2.3/zutil.c
- src/share/native/java/util/zip/zlib-1.2.3/zutil.h
- src/solaris/classes/sun/awt/motif/AWTLockAccess.java
- src/solaris/classes/sun/awt/motif/MFontPeer.java
- src/solaris/classes/sun/awt/motif/MToolkit.java
- src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java
- src/solaris/classes/sun/awt/motif/MWindowAttributes.java
- src/solaris/classes/sun/awt/motif/X11FontMetrics.java
- src/solaris/native/sun/awt/MouseInfo.c
- src/solaris/native/sun/awt/XDrawingArea.c
- src/solaris/native/sun/awt/XDrawingArea.h
- src/solaris/native/sun/awt/XDrawingAreaP.h
- src/solaris/native/sun/awt/awt_Cursor.h
- src/solaris/native/sun/awt/awt_KeyboardFocusManager.h
- src/solaris/native/sun/awt/awt_MToolkit.c
- src/solaris/native/sun/awt/awt_MToolkit.h
- src/solaris/native/sun/awt/awt_MenuItem.h
- src/solaris/native/sun/awt/awt_PopupMenu.h
- src/solaris/native/sun/awt/awt_TopLevel.h
- src/solaris/native/sun/awt/awt_Window.h
- src/solaris/native/sun/awt/awt_mgrsel.c
- src/solaris/native/sun/awt/awt_mgrsel.h
- src/solaris/native/sun/awt/awt_motif.h
- src/solaris/native/sun/awt/awt_wm.c
- src/solaris/native/sun/awt/awt_wm.h
- src/solaris/native/sun/awt/awt_xembed.h
- src/solaris/native/sun/awt/awt_xembed_server.c
- src/solaris/native/sun/awt/awt_xembed_server.h
- test/java/util/ResourceBundle/Control/ExpirationTest.java
- test/java/util/ResourceBundle/Control/ExpirationTest.sh

Changeset: 5fe1525e6e2c
Author: cgruszka
Date: 2011-12-23 10:43 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5fe1525e6e2c

Merge


Changeset: 39e938cd1b82
Author: cgruszka
Date: 2012-01-03 14:34 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39e938cd1b82

Merge


Changeset: fc050750f8a0
Author: katleman
Date: 2012-01-05 08:42 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc050750f8a0

Added tag jdk8-b20 for changeset 39e938cd1b82

! .hgtags

Changeset: 38a318502e19
Author: lana
Date: 2012-01-04 10:57 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38a318502e19

Merge

! make/common/Release.gmk
- test/tools/launcher/DefaultLocaleTest.sh

Changeset: 93ab1df09d11
Author: lana
Date: 2012-01-09 19:12 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93ab1df09d11

Merge

- test/tools/launcher/DefaultLocaleTest.sh

Changeset: ddb97d4fa83d
Author: ohair
Date: 2012-01-04 17:42 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ddb97d4fa83d

7127104: Build issue with prtconf and zones, also using := to avoid extra execs
Reviewed-by: katleman

! make/common/shared/Platform.gmk

Changeset: 7c8c16f2c05e
Author: ohair
Date: 2012-01-09 09:18 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c8c16f2c05e

7128320: Fix freetype sanity check to make it more generic
Reviewed-by: luchsh, katleman
Contributed-by: Jonathan Lu <luchsh at linux.vnet.ibm.com>

! make/common/Defs-linux.gmk
! make/common/Defs-solaris.gmk
! make/common/Defs-windows.gmk
! make/common/Demo.gmk
! make/tools/freetypecheck/Makefile

Changeset: 664fa4fb0ee4
Author: katleman
Date: 2012-01-11 16:13 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/664fa4fb0ee4

Merge


Changeset: dda27c73d8db
Author: katleman
Date: 2012-01-13 10:05 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dda27c73d8db

Added tag jdk8-b21 for changeset 664fa4fb0ee4

! .hgtags

Changeset: b14e13237498
Author: lana
Date: 2012-01-18 11:00 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b14e13237498

Merge




From Roger.Riggs at oracle.com Wed Jan 18 21:20:05 2012
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 18 Jan 2012 16:20:05 -0500
Subject: JDK 8 code review request for initial unsigned integer
In-Reply-To: <4F17270A.5030502@oracle.com>
References: <mailman.19014.1326865303.8505.core-libs-dev@openjdk.java.net>
<4F171BCD.2070500@oracle.com> <4F17270A.5030502@oracle.com>
Message-ID: <4F173785.3040000@oracle.com>

On 01/18/2012 03:09 PM, Joe Darcy wrote:
>
>> 1. In the new parsing methods, could the String arguments be changed
>> to the more general
>> java.lang.CharSequence? For many parsing applications, it could be
>> more convenient
>> to pass a CharSequence than to create a new String.
>
>
> I don't think that would be very helpful in this case. If the methods
> were changed to take a CharSequence, the first action I'd write in the
> method would be to call toString on the argument; this is necessary to
> guard against the class of time-of-check-versus-time-of-use problems
> because the CharSequence objects can be mutable.

Though the existing methods do operate on immutable inputs, there is no
expectation of synchronization provided by the parsing methods of
Integer, etc.

Making the change would not break any existing code because it continues
to pass
immutable inputs.

New code that calls the methods using CharSequences, in full knowledge
of the
mutability of CharSequences, would manage or avoid the concurrency issues,
most likely by keeping the computation to a single thread or otherwise
synchronizing
changes to the object that implement CharSequence.

Since Integer makes no assurances about being multi-thread safe it can
operate
under those assumptions and does not need to make copies of the arguments.
In any case, the copy operation itself could run afoul of concurrency
faults, and it
doesn't matter where the copy occurs, inside or outside of the Integer
methods.

Please consider the necessity of extra steps by the developer (to
produce strings)
and the potential savings in the load on the heap by not creating copies
of strings.

Roger




From scolebourne at joda.org Wed Jan 18 21:51:58 2012
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 18 Jan 2012 21:51:58 +0000
Subject: JDK 8 code review request for initial unsigned integer
In-Reply-To: <4F17270A.5030502@oracle.com>
References: <mailman.19014.1326865303.8505.core-libs-dev@openjdk.java.net>
<4F171BCD.2070500@oracle.com> <4F17270A.5030502@oracle.com>
Message-ID: <CACzrW9A6PWFNZ97ciceYtSjikgSqefi0tvs24jqU7gR2fmTWfg@mail.gmail.com>

On 18 January 2012 20:09, Joe Darcy <joe.darcy at oracle.com> wrote:

>
> On 01/18/2012 11:21 AM, Roger Riggs wrote:
>
>> A comment or two on the webrev for unsigned:
>>
>> http://cr.openjdk.java.net/~darcy/4504839.2
>>
>> 1. In the new parsing methods, could the String arguments be changed to
>> the more general
>> java.lang.CharSequence? For many parsing applications, it could be more
>> convenient
>> to pass a CharSequence than to create a new String.
>>
>
>
> I don't think that would be very helpful in this case. If the methods
> were changed to take a CharSequence, the first action I'd write in the
> method would be to call toString on the argument; this is necessary to
> guard against the class of time-of-check-versus-time-of-use problems
> because the CharSequence objects can be mutable.


FWIW, JSR-310 and Joda-Time users have both requested CharSequence for
parsing. A key use case was apparantly reading streams in Scala, although I
didn't really follow that in detail.

Stephen


From mark.reinhold at oracle.com Wed Jan 18 23:07:34 2012
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 18 Jan 2012 15:07:34 -0800 (PST)
Subject: JEP 134: Intuitive Semantics for Nested Reference Objects
Message-ID: <20120118230734.828B65F1@eggemoggin.niobe.net>

Posted: http://openjdk.java.net/jeps/134

- Mark


From Ulf.Zibis at gmx.de Thu Jan 19 00:38:11 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 19 Jan 2012 01:38:11 +0100
Subject: JDK 8 code review request for initial unsigned integer
In-Reply-To: <4F17270A.5030502@oracle.com>
References: <mailman.19014.1326865303.8505.core-libs-dev@openjdk.java.net>
<4F171BCD.2070500@oracle.com> <4F17270A.5030502@oracle.com>
Message-ID: <4F1765F3.4060709@gmx.de>

Am 18.01.2012 21:09, schrieb Joe Darcy:
> Hi Roger,
>
> On 01/18/2012 11:21 AM, Roger Riggs wrote:
>> 1. In the new parsing methods, could the String arguments be changed to the more general
>> java.lang.CharSequence? For many parsing applications, it could be more convenient
>> to pass a CharSequence than to create a new String.
>
> I don't think that would be very helpful in this case. If the methods were changed to take a
> CharSequence, the first action I'd write in the method would be to call toString on the argument;
> this is necessary to guard against the class of time-of-check-versus-time-of-use problems because
> the CharSequence objects can be mutable.
Doesn't this argument make the usage of CharSequence in most other API's inappropriate at all?

-Ulf



From joe.darcy at oracle.com Thu Jan 19 00:44:40 2012
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Thu, 19 Jan 2012 00:44:40 +0000
Subject: hg: jdk8/tl/langtools: 7130768: Clarify behavior of
Element.getEnclosingElements in subtypes
Message-ID: <20120119004442.815EC479E3@hg.openjdk.java.net>

Changeset: cf2496340fef
Author: darcy
Date: 2012-01-18 16:43 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cf2496340fef

7130768: Clarify behavior of Element.getEnclosingElements in subtypes
Reviewed-by: mcimadamore, jjg

! src/share/classes/javax/lang/model/element/Element.java
! src/share/classes/javax/lang/model/element/PackageElement.java
! src/share/classes/javax/lang/model/element/TypeElement.java



From jim.holmlund at sun.com Thu Jan 19 02:27:52 2012
From: jim.holmlund at sun.com (jim.holmlund at sun.com)
Date: Thu, 19 Jan 2012 02:27:52 +0000
Subject: hg: jdk8/tl/langtools: 7131308: Three regression tests fail due to
bad fix for 7127924
Message-ID: <20120119022754.7DDE5479E4@hg.openjdk.java.net>

Changeset: 99261fc7d95d
Author: jjh
Date: 2012-01-18 18:26 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/99261fc7d95d

7131308: Three regression tests fail due to bad fix for 7127924
Reviewed-by: jjg

! test/tools/javac/diags/CheckExamples.java
! test/tools/javac/diags/MessageInfo.java
! test/tools/javac/diags/RunExamples.java



From Ulf.Zibis at gmx.de Thu Jan 19 03:52:21 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 19 Jan 2012 04:52:21 +0100
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <4F163474.7060908@oracle.com>
References: <4F111201.3060407@oracle.com>
<CACBEn45ZHo_=3WnKF6YvOBYHoO7H4idzeThivyCaiY1msmfWMg@mail.gmail.com>
<4F163474.7060908@oracle.com>
Message-ID: <4F179375.7040700@gmx.de>

Am 18.01.2012 03:54, schrieb Joe Darcy:
> I've posted a revised webrev at
>
> http://cr.openjdk.java.net/~darcy/4504839.2

Instead
<code>'&#92;u0030'</code>
you can use
{@code '\u005Cu0030'}

Byte:
=====
459 public static int toUnsignedInt(byte x) {
460 return ((int) x) & 0xff;
461 }
This should be good enough (similar at Short, Integer):
459 public static int toUnsignedInt(byte x) {
460 return x & 0xff;
461 }
(This notation if regularly used in sun.nio.cs coders.)

missing:
public static short toUnsignedShort(byte x)

superfluous:
public static long toUnsignedInt(byte x)
public static long toUnsignedLong(byte x) (similar at Short)
one can use:
int i = toUnsignedShort(x)
long l = toUnsignedShort(x) (similar at Short)

Integer:
========
623 * <li>The value represented by the string is larger than the
624 * largest unsigned {@code int}, 2<sup>32</sup>-1.
If you format {@code int}, then you speak about the java type int, which is always signed, never
unsigned.
IMO you should better write 'unsigned 32-bit integer".
(similar at Long)

598 * Parses the string argument as an unsigned integer in the radix
599 * specified by the second argument.
IMHO, there should be a note about what happens on values above 2^31 - 1.

672 * Parses the string argument as an unsigned decimal integer. The
673 * characters in the string must all be decimal digits, except
Better, like lines 598ff, or contrariwise (similar at Long):
672 * Parses the string argument as an unsigned decimal integer.
673 *
674 * The characters in the string must all be decimal digits, except

Long:
=====
What about:
private static final BigInteger BEYOND_UNSIGNED_LONG = BigInteger.valueOf(1).shiftLeft(64);
private static BigInteger toUnsignedBigInteger(long i) {
BigInteger result = BigInteger.valueOf(i);
if (i < 0L)
result = result.add(BEYOND_UNSIGNED_LONG);
return result;
}

Instead
private static BigInteger toUnsignedBigInteger(long i)
at class BigInteger we more generally could have:
public static BigInteger unsignedValueOf(long i)

610 * Parses the string argument as an unsigned {@code long} in the
611 * radix specified by the second argument.
IMHO, there should be a note about what happens on values above 2^63 - 1.

-Ulf



From eamonn at mcmanus.net Thu Jan 19 06:43:18 2012
From: eamonn at mcmanus.net (Eamonn McManus)
Date: Wed, 18 Jan 2012 22:43:18 -0800
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <4F179375.7040700@gmx.de>
References: <4F111201.3060407@oracle.com>
<CACBEn45ZHo_=3WnKF6YvOBYHoO7H4idzeThivyCaiY1msmfWMg@mail.gmail.com>
<4F163474.7060908@oracle.com> <4F179375.7040700@gmx.de>
Message-ID: <CACBEn47WX=NpPYYQBaijk7gi-LFq2rFMsT3FQ_VRwiyrd-CNDw@mail.gmail.com>

Ulf Zibis writes:
> What about:
> private static final BigInteger BEYOND_UNSIGNED_LONG =
BigInteger.valueOf(1).**shiftLeft(64);
> private static BigInteger toUnsignedBigInteger(long i) {
> BigInteger result = BigInteger.valueOf(i);
> if (i < 0L)
> result = result.add(BEYOND_UNSIGNED_**LONG);
> return result;
> }

That's a nice idea! But the problem is that it would mean that
BigInteger.class would be loaded as soon as Long.class is, which I think is
undesirable. However it does make me think that we could change this:

if (i >= 0L)
return BigInteger.valueOf(i);
else {
int upper = (int) (i >>> 32);
int lower = (int) i;

// return (upper << 32) + lower
return
(BigInteger.valueOf(Integer.toUnsignedLong(upper))).shiftLeft(32).
add(BigInteger.valueOf(Integer.toUnsignedLong(lower)));
}

to this:

if (i >= 0L) {
return BigInteger.valueOf(i);
} else {
return BigInteger.valueOf(i & Long.MAX_VALUE).setBit(63);
}

?amonn


On 18 January 2012 19:52, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

> Am 18.01.2012 03:54, schrieb Joe Darcy:
>
> I've posted a revised webrev at
>>
>> http://cr.openjdk.java.net/~**darcy/4504839.2<http://cr.openjdk.java.net/~darcy/4504839.2>
>>
>
> Instead
> <code>'&#92;u0030'</code>
> you can use
> {@code '\u005Cu0030'}
>
> Byte:
> =====
> 459 public static int toUnsignedInt(byte x) {
> 460 return ((int) x) & 0xff;
> 461 }
> This should be good enough (similar at Short, Integer):
> 459 public static int toUnsignedInt(byte x) {
> 460 return x & 0xff;
> 461 }
> (This notation if regularly used in sun.nio.cs coders.)
>
> missing:
> public static short toUnsignedShort(byte x)
>
> superfluous:
> public static long toUnsignedInt(byte x)
> public static long toUnsignedLong(byte x) (similar at Short)
> one can use:
> int i = toUnsignedShort(x)
> long l = toUnsignedShort(x) (similar at Short)
>
> Integer:
> ========
> 623 * <li>The value represented by the string is larger than the
> 624 * largest unsigned {@code int}, 2<sup>32</sup>-1.
> If you format {@code int}, then you speak about the java type int, which
> is always signed, never unsigned.
> IMO you should better write 'unsigned 32-bit integer".
> (similar at Long)
>
> 598 * Parses the string argument as an unsigned integer in the radix
> 599 * specified by the second argument.
> IMHO, there should be a note about what happens on values above 2^31 - 1.
>
> 672 * Parses the string argument as an unsigned decimal integer. The
> 673 * characters in the string must all be decimal digits, except
> Better, like lines 598ff, or contrariwise (similar at Long):
> 672 * Parses the string argument as an unsigned decimal integer.
> 673 *
> 674 * The characters in the string must all be decimal digits, except
>
> Long:
> =====
> What about:
> private static final BigInteger BEYOND_UNSIGNED_LONG =
> BigInteger.valueOf(1).**shiftLeft(64);
> private static BigInteger toUnsignedBigInteger(long i) {
> BigInteger result = BigInteger.valueOf(i);
> if (i < 0L)
> result = result.add(BEYOND_UNSIGNED_**LONG);
> return result;
> }
>
> Instead
> private static BigInteger toUnsignedBigInteger(long i)
> at class BigInteger we more generally could have:
> public static BigInteger unsignedValueOf(long i)
>
> 610 * Parses the string argument as an unsigned {@code long} in the
> 611 * radix specified by the second argument.
> IMHO, there should be a note about what happens on values above 2^63 - 1.
>
> -Ulf
>
>


From Alan.Bateman at oracle.com Thu Jan 19 12:53:12 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Jan 2012 12:53:12 +0000
Subject: Result: New core-libs Group Member: Brian Goetz
Message-ID: <4F181238.8030502@oracle.com>


The vote for Brian Goetz [1] is now closed.

Yes: 7
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient
to approve the nomination.

- Alan (nominator)

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008836.html



From Alan.Bateman at oracle.com Thu Jan 19 12:53:20 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Jan 2012 12:53:20 +0000
Subject: Result: New core-libs Group Member: David Holmes
Message-ID: <4F181240.2000604@oracle.com>


The vote for David Holmes [1] is now closed.

Yes: 7
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient
to approve the nomination.

- Alan (nominator)

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008839.html



From Alan.Bateman at oracle.com Thu Jan 19 12:58:29 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Jan 2012 12:58:29 +0000
Subject: JDK 8 code review request for initial unsigned integer
In-Reply-To: <4F1765F3.4060709@gmx.de>
References: <mailman.19014.1326865303.8505.core-libs-dev@openjdk.java.net>
<4F171BCD.2070500@oracle.com> <4F17270A.5030502@oracle.com>
<4F1765F3.4060709@gmx.de>
Message-ID: <4F181375.1040806@oracle.com>

On 19/01/2012 00:38, Ulf Zibis wrote:
> Am 18.01.2012 21:09, schrieb Joe Darcy:
>> Hi Roger,
>>
>> On 01/18/2012 11:21 AM, Roger Riggs wrote:
>>> 1. In the new parsing methods, could the String arguments be changed
>>> to the more general
>>> java.lang.CharSequence? For many parsing applications, it could be
>>> more convenient
>>> to pass a CharSequence than to create a new String.
>>
>> I don't think that would be very helpful in this case. If the
>> methods were changed to take a CharSequence, the first action I'd
>> write in the method would be to call toString on the argument; this
>> is necessary to guard against the class of
>> time-of-check-versus-time-of-use problems because the CharSequence
>> objects can be mutable.
> Doesn't this argument make the usage of CharSequence in most other
> API's inappropriate at all?
It depends. If the parsing requires backtracking then you have to be
careful or else parse a copy.

-Alan.


From Ulf.Zibis at gmx.de Thu Jan 19 16:05:16 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 19 Jan 2012 17:05:16 +0100
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <CACBEn47WX=NpPYYQBaijk7gi-LFq2rFMsT3FQ_VRwiyrd-CNDw@mail.gmail.com>
References: <4F111201.3060407@oracle.com>
<CACBEn45ZHo_=3WnKF6YvOBYHoO7H4idzeThivyCaiY1msmfWMg@mail.gmail.com>
<4F163474.7060908@oracle.com> <4F179375.7040700@gmx.de>
<CACBEn47WX=NpPYYQBaijk7gi-LFq2rFMsT3FQ_VRwiyrd-CNDw@mail.gmail.com>
Message-ID: <4F183F3C.4010308@gmx.de>

Am 19.01.2012 07:43, schrieb Eamonn McManus:
> Ulf Zibis writes:
> > What about:
> > private static final BigInteger BEYOND_UNSIGNED_LONG = BigInteger.valueOf(1).shiftLeft(64);
> > private static BigInteger toUnsignedBigInteger(long i) {
> > BigInteger result = BigInteger.valueOf(i);
> > if (i < 0L)
> > result = result.add(BEYOND_UNSIGNED_LONG);
> > return result;
> > }
>
> That's a nice idea! But the problem is that it would mean that BigInteger.class would be loaded as
> soon as Long.class is, which I think is undesirable.
Thanks for the critic. I didn't see that.
The problem could be easily avoided if method toUnsignedBigInteger(long i) would be moved to class
BigInteger as unsignedValueOf(long i), as I additionally noted in my last post.

> However it does make me think that we could change...to this:
>
> if (i >= 0L) {
> return BigInteger.valueOf(i);
> } else {
> return BigInteger.valueOf(i & Long.MAX_VALUE).setBit(63);
> }
Another nice idea!
But again, moving the entire method to BigInteger would additionally avoid to clown around with the
available BigInteger's public APIs. Having the method at BigInteger would allow elegant direct
access to the private value fields.

-Ulf



From Roger.Riggs at oracle.com Thu Jan 19 16:17:03 2012
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 19 Jan 2012 11:17:03 -0500
Subject: JDK 8 code review request for initial unsigned integer
In-Reply-To: <4F183B87.80208@gmx.de>
References: <mailman.19014.1326865303.8505.core-libs-dev@openjdk.java.net>
<4F171BCD.2070500@oracle.com> <4F17270A.5030502@oracle.com>
<4F173785.3040000@oracle.com> <4F183B87.80208@gmx.de>
Message-ID: <4F1841FF.8030000@oracle.com>

The scope of CR 4504839 doesn't cover broader changes to APIs, so
the suggestion to upgrade String to CharSequence should be a separate CR
to be examined and reviewed separately.


The new (and some old) NumberFormatExceptions contain English text
preformatted with arguments. From an I18n localization view, that's
hard to localize.
A fixed string, though less informative could be localized more easily.


On 01/19/2012 10:49 AM, Ulf Zibis wrote:
> Am 18.01.2012 22:20, schrieb Roger Riggs:
>> On 01/18/2012 03:09 PM, Joe Darcy wrote:
>>>
>>>> 1. In the new parsing methods, could the String arguments be
>>>> changed to the more general
>>>> java.lang.CharSequence? For many parsing applications, it could be
>>>> more convenient
>>>> to pass a CharSequence than to create a new String.
>>>
>>>
>>> I don't think that would be very helpful in this case. If the
>>> methods were changed to take a CharSequence, the first action I'd
>>> write in the method would be to call toString on the argument; this
>>> is necessary to guard against the class of
>>> time-of-check-versus-time-of-use problems because the CharSequence
>>> objects can be mutable.
>>
>> Though the existing methods do operate on immutable inputs, there is no
>> expectation of synchronization provided by the parsing methods of
>> Integer, etc.
>>
>> Making the change would not break any existing code because it
>> continues to pass
>> immutable inputs.
>>
>> New code that calls the methods using CharSequences, in full
>> knowledge of the
>> mutability of CharSequences, would manage or avoid the concurrency
>> issues,
>> most likely by keeping the computation to a single thread or
>> otherwise synchronizing
>> changes to the object that implement CharSequence.
>>
>> Since Integer makes no assurances about being multi-thread safe it
>> can operate
>> under those assumptions and does not need to make copies of the
>> arguments.
>> In any case, the copy operation itself could run afoul of concurrency
>> faults, and it
>> doesn't matter where the copy occurs, inside or outside of the
>> Integer methods.
>>
>> Please consider the necessity of extra steps by the developer (to
>> produce strings)
>> and the potential savings in the load on the heap by not creating
>> copies of strings.
>>
>> Roger
>
> +1
>
> -Ulf
>



From Ulf.Zibis at gmx.de Thu Jan 19 15:49:27 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 19 Jan 2012 16:49:27 +0100
Subject: JDK 8 code review request for initial unsigned integer
In-Reply-To: <4F173785.3040000@oracle.com>
References: <mailman.19014.1326865303.8505.core-libs-dev@openjdk.java.net>
<4F171BCD.2070500@oracle.com> <4F17270A.5030502@oracle.com>
<4F173785.3040000@oracle.com>
Message-ID: <4F183B87.80208@gmx.de>

Am 18.01.2012 22:20, schrieb Roger Riggs:
> On 01/18/2012 03:09 PM, Joe Darcy wrote:
>>
>>> 1. In the new parsing methods, could the String arguments be changed to the more general
>>> java.lang.CharSequence? For many parsing applications, it could be more convenient
>>> to pass a CharSequence than to create a new String.
>>
>>
>> I don't think that would be very helpful in this case. If the methods were changed to take a
>> CharSequence, the first action I'd write in the method would be to call toString on the argument;
>> this is necessary to guard against the class of time-of-check-versus-time-of-use problems because
>> the CharSequence objects can be mutable.
>
> Though the existing methods do operate on immutable inputs, there is no
> expectation of synchronization provided by the parsing methods of Integer, etc.
>
> Making the change would not break any existing code because it continues to pass
> immutable inputs.
>
> New code that calls the methods using CharSequences, in full knowledge of the
> mutability of CharSequences, would manage or avoid the concurrency issues,
> most likely by keeping the computation to a single thread or otherwise synchronizing
> changes to the object that implement CharSequence.
>
> Since Integer makes no assurances about being multi-thread safe it can operate
> under those assumptions and does not need to make copies of the arguments.
> In any case, the copy operation itself could run afoul of concurrency faults, and it
> doesn't matter where the copy occurs, inside or outside of the Integer methods.
>
> Please consider the necessity of extra steps by the developer (to produce strings)
> and the potential savings in the load on the heap by not creating copies of strings.
>
> Roger

+1

-Ulf



From joe.darcy at oracle.com Thu Jan 19 17:24:43 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 19 Jan 2012 09:24:43 -0800
Subject: JDK 8 code review request for initial unsigned integer
In-Reply-To: <4F1841FF.8030000@oracle.com>
References: <mailman.19014.1326865303.8505.core-libs-dev@openjdk.java.net> <4F171BCD.2070500@oracle.com>
<4F17270A.5030502@oracle.com> <4F173785.3040000@oracle.com>
<4F183B87.80208@gmx.de> <4F1841FF.8030000@oracle.com>
Message-ID: <4F1851DB.5020502@oracle.com>

On 1/19/2012 8:17 AM, Roger Riggs wrote:
[snip]
>
> The new (and some old) NumberFormatExceptions contain English text
> preformatted with arguments. From an I18n localization view, that's
> hard to localize.
> A fixed string, though less informative could be localized more easily.
>

That is true, but in the JDK to date we have not treated exception
messages as text subject to localization.

-Joe


From Alan.Bateman at oracle.com Thu Jan 19 17:32:29 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 19 Jan 2012 17:32:29 +0000
Subject: JDK 8 code review request for initial unsigned integer
In-Reply-To: <4F1841FF.8030000@oracle.com>
References: <mailman.19014.1326865303.8505.core-libs-dev@openjdk.java.net>
<4F171BCD.2070500@oracle.com> <4F17270A.5030502@oracle.com>
<4F173785.3040000@oracle.com> <4F183B87.80208@gmx.de>
<4F1841FF.8030000@oracle.com>
Message-ID: <4F1853AD.4070000@oracle.com>

On 19/01/2012 16:17, Roger Riggs wrote:
> :
>
> The new (and some old) NumberFormatExceptions contain English text
> preformatted with arguments. From an I18n localization view, that's
> hard to localize.
> A fixed string, though less informative could be localized more easily.
>
Right but we don't localize exception messages.

-Alan



From valerie.peng at oracle.com Thu Jan 19 20:06:58 2012
From: valerie.peng at oracle.com (valerie.peng at oracle.com)
Date: Thu, 19 Jan 2012 20:06:58 +0000
Subject: hg: jdk8/tl/jdk: 7092825: javax.crypto.Cipher.Transform.patternCache
is synchronizedMap and became scalability bottleneck.
Message-ID: <20120119200711.C17CC470A0@hg.openjdk.java.net>

Changeset: 313da5d059bf
Author: valeriep
Date: 2012-01-19 12:01 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/313da5d059bf

7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck.
Summary: Changed patternCache from synchronizedMap to ConcurrentHashMap.
Reviewed-by: mullan

! src/share/classes/javax/crypto/Cipher.java



From mark.reinhold at oracle.com Fri Jan 20 05:38:36 2012
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 19 Jan 2012 21:38:36 -0800 (PST)
Subject: JEP 135: Base64 Encoding and Decoding
Message-ID: <20120120053836.79363DC0@eggemoggin.niobe.net>

Posted: http://openjdk.java.net/jeps/135

- Mark


From Ulf.Zibis at gmx.de Fri Jan 20 15:12:56 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 20 Jan 2012 16:12:56 +0100
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <4F111201.3060407@oracle.com>
References: <4F111201.3060407@oracle.com>
Message-ID: <4F198478.1080209@gmx.de>

A little different approach...

I worry about the wording of e.g. toUnsignedInt(x).
At first look, it claims to return an unsigned integer, which fairly doesn't exist in Java for now.
1. Better: unsignedIntValueOf(x)
2. We could have a naming problem if unsigned integers were introduced in any future for Java. Then
e.g. toUnsignedInt(x) could have a very different meaning.

Instead e.g.
int Byte.unsignedIntValueOf(byte x) aka int Byte.toUnsignedInt(byte x)
I would vote for
int Integer.unsignedValueOf(byte x)

At least, we only need:
short Short.unsignedValueOf(byte x)
int Integer.unsignedValueOf(short x)
long Long.unsignedValueOf(int x)
BigInteger BigInteger.unsignedValueOf(long x)

-Ulf



Am 14.01.2012 06:26, schrieb Joe Darcy:
> Hello,
>
> Polishing up some work I've had *almost* done for a long time, please review an initial take on
> providing library support for unsigned integer arithmetic:
>
> 4504839 Java libraries should provide support for unsigned integer arithmetic
> 4215269 Some Integer.toHexString(int) results cannot be decoded back to an int
> 6322074 Converting integers to string as if unsigned
>
> http://cr.openjdk.java.net/~darcy/4504839.1/
>


From darryl.mocek at oracle.com Fri Jan 20 17:55:52 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Fri, 20 Jan 2012 09:55:52 -0800
Subject: Code Review Request for Bug #7129285
Message-ID: <4F19AAA8.1080403@oracle.com>

Please review this patch to fix Bug #7129285. This fix addresses
comments made by Jason Mehrens to the commit of the fix for bug
#4533691, including adding a Collections.emptyNavigableSet method.
Tests are included.

Webrev, can be found here:
http://cr.openjdk.java.net/~dmocek/7129285/webrev.00

Thanks,
Darryl


From brandon.passanisi at oracle.com Fri Jan 20 18:19:56 2012
From: brandon.passanisi at oracle.com (Brandon Passanisi)
Date: Fri, 20 Jan 2012 10:19:56 -0800
Subject: Code review request for #6469160, #7088271
Message-ID: <4F19B04C.8040104@oracle.com>

Resending again...

Hello core-libs. I was wondering of somebody could be please review the
following fix for #6469160 and #7088271. The changes in the webrev fix
both bugs. Information is below:

Webrev URL: http://cr.openjdk.java.net/~bpassani/6469160_7088271/1/
<http://cr.openjdk.java.net/%7Ebpassani/6469160_7088271/1/>
Bug #6469160: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469160
Bug #7088271: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7088271

Both bugs uncover the current behavior where using a 0 or 1 precision
value with a float zero causes an ArrayIndexOutOfBoundsException. The
current code in FormattedFloatingDecimal.java interprets the float zero
as "0.0" in the case where precision is 0 or 1 and returns the length of
it's characters as 3. Later in Formatter.addZeros(), the character
array "0.0" is passed in, but a new array of only 1 character is
allocated. When an System.arraycopy() is performed, the
ArrayIndexOutOfBoundsException occurs. In fact, when run with "-esa" an
AssertionError occurs at "assert (outPrec <= prec);" on line 3393 of
Formatter.java. The fix is for FormatedFloatingDecimal.java to
interpret the float zero as a single "0" because of the precision being
set to 0 or 1.

Since java has been throwing exceptions in these cases, I consulted with
the output of C's printf to make sure that the outputted strings are the
same. I updated the Formatter's Basic-X template of tests with a little
over 20 test format strings that were causing exceptions without the
change and the output of each is compared with the output from C's
printf with the same format string. And, I ran all of the Basic-X tests
to make sure there weren't any regressions in behavior.

Thanks.
--
Oracle <http://www.oracle.com>
Brandon Passanisi | Principle Member of Technical Staff


Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment


From joe.darcy at oracle.com Fri Jan 20 18:30:42 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 20 Jan 2012 10:30:42 -0800
Subject: Code review request for #6469160, #7088271
In-Reply-To: <4F19B04C.8040104@oracle.com>
References: <4F19B04C.8040104@oracle.com>
Message-ID: <4F19B2D2.3010604@oracle.com>

As a general comment, I find a seven-digit bug id in isolation
extremely uninformative in terms of letting me know whether or not an
issue is of interest to me. For the messages I send to the list, I
always try to include the synopsis of the bugs in question in at least
one of the subject line and the body of the message.

-Joe

On 1/20/2012 10:19 AM, Brandon Passanisi wrote:
> Resending again...
>
> Hello core-libs. I was wondering of somebody could be please review
> the following fix for #6469160 and #7088271. The changes in the
> webrev fix both bugs. Information is below:
>
> Webrev URL: http://cr.openjdk.java.net/~bpassani/6469160_7088271/1/
> <http://cr.openjdk.java.net/%7Ebpassani/6469160_7088271/1/>
> Bug #6469160:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469160
> Bug #7088271:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7088271
>
> Both bugs uncover the current behavior where using a 0 or 1 precision
> value with a float zero causes an ArrayIndexOutOfBoundsException. The
> current code in FormattedFloatingDecimal.java interprets the float
> zero as "0.0" in the case where precision is 0 or 1 and returns the
> length of it's characters as 3. Later in Formatter.addZeros(), the
> character array "0.0" is passed in, but a new array of only 1
> character is allocated. When an System.arraycopy() is performed, the
> ArrayIndexOutOfBoundsException occurs. In fact, when run with "-esa"
> an AssertionError occurs at "assert (outPrec <= prec);" on line 3393
> of Formatter.java. The fix is for FormatedFloatingDecimal.java to
> interpret the float zero as a single "0" because of the precision
> being set to 0 or 1.
>
> Since java has been throwing exceptions in these cases, I consulted
> with the output of C's printf to make sure that the outputted strings
> are the same. I updated the Formatter's Basic-X template of tests
> with a little over 20 test format strings that were causing exceptions
> without the change and the output of each is compared with the output
> from C's printf with the same format string. And, I ran all of the
> Basic-X tests to make sure there weren't any regressions in behavior.
>
> Thanks.



From Ulf.Zibis at gmx.de Fri Jan 20 20:27:24 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 20 Jan 2012 21:27:24 +0100
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <4F198478.1080209@gmx.de>
References: <4F111201.3060407@oracle.com> <4F198478.1080209@gmx.de>
Message-ID: <4F19CE2C.90204@gmx.de>

Am 20.01.2012 16:12, schrieb Ulf Zibis:
> A little different approach...
>
> Instead e.g.
> int Byte.unsignedIntValueOf(byte x) aka int Byte.toUnsignedInt(byte x)
> I would vote for
> int Integer.unsignedValueOf(byte x)

Alternative:
int Integer.valueAsUnsigned(byte x)

-Ulf



From joe.darcy at oracle.com Sat Jan 21 00:31:20 2012
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Fri, 20 Jan 2012 16:31:20 -0800
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <4F179375.7040700@gmx.de>
References: <4F111201.3060407@oracle.com>
<CACBEn45ZHo_=3WnKF6YvOBYHoO7H4idzeThivyCaiY1msmfWMg@mail.gmail.com>
<4F163474.7060908@oracle.com> <4F179375.7040700@gmx.de>
Message-ID: <4F1A0758.5020808@oracle.com>

On 1/18/2012 7:52 PM, Ulf Zibis wrote:
> Am 18.01.2012 03:54, schrieb Joe Darcy:
>> I've posted a revised webrev at
>>
>> http://cr.openjdk.java.net/~darcy/4504839.2
>
> Instead
> <code>'&#92;u0030'</code>
> you can use
> {@code '\u005Cu0030'}

That is a fine cleanup, but I'll do a bulk conversion of all the
instances of that pattern later on under another bug.

>
> Byte:
> =====
> 459 public static int toUnsignedInt(byte x) {
> 460 return ((int) x) & 0xff;
> 461 }
> This should be good enough (similar at Short, Integer):
> 459 public static int toUnsignedInt(byte x) {
> 460 return x & 0xff;
> 461 }
> (This notation if regularly used in sun.nio.cs coders.)

I think the current code more explicitly indicates the intention of the
method's operation to more casual readers less familiar with the details
of primitive widening conversions, etc.


>
> missing:
> public static short toUnsignedShort(byte x)

That omission was intentional. The language and VM only really support
arithmetic on int and long values, not short or byte, so I only
providing methods to widen to int and long.

>
> superfluous:
> public static long toUnsignedInt(byte x)
> public static long toUnsignedLong(byte x) (similar at Short)
> one can use:
> int i = toUnsignedShort(x)
> long l = toUnsignedShort(x) (similar at Short)
>
> Integer:
> ========
> 623 * <li>The value represented by the string is larger than the
> 624 * largest unsigned {@code int}, 2<sup>32</sup>-1.
> If you format {@code int}, then you speak about the java type int,
> which is always signed, never unsigned.
> IMO you should better write 'unsigned 32-bit integer".
> (similar at Long)

Due to similar feedback, I've made various clarifications to the
javadoc, but the basic situation is that the "fooUnsigned" methods
interpret the bits as unsigned values, as already done in toHexString
and related methods.

Thanks,

-Joe



From joe.darcy at oracle.com Sat Jan 21 00:35:30 2012
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Fri, 20 Jan 2012 16:35:30 -0800
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <4F183F3C.4010308@gmx.de>
References: <4F111201.3060407@oracle.com>
<CACBEn45ZHo_=3WnKF6YvOBYHoO7H4idzeThivyCaiY1msmfWMg@mail.gmail.com>
<4F163474.7060908@oracle.com> <4F179375.7040700@gmx.de>
<CACBEn47WX=NpPYYQBaijk7gi-LFq2rFMsT3FQ_VRwiyrd-CNDw@mail.gmail.com>
<4F183F3C.4010308@gmx.de>
Message-ID: <4F1A0852.3030701@oracle.com>

On 1/19/2012 8:05 AM, Ulf Zibis wrote:
> Am 19.01.2012 07:43, schrieb Eamonn McManus:
>> Ulf Zibis writes:
>> > What about:
>> > private static final BigInteger BEYOND_UNSIGNED_LONG =
>> BigInteger.valueOf(1).shiftLeft(64);
>> > private static BigInteger toUnsignedBigInteger(long i) {
>> > BigInteger result = BigInteger.valueOf(i);
>> > if (i < 0L)
>> > result = result.add(BEYOND_UNSIGNED_LONG);
>> > return result;
>> > }
>>
>> That's a nice idea! But the problem is that it would mean that
>> BigInteger.class would be loaded as soon as Long.class is, which I
>> think is undesirable.
> Thanks for the critic. I didn't see that.
> The problem could be easily avoided if method
> toUnsignedBigInteger(long i) would be moved to class BigInteger as
> unsignedValueOf(long i), as I additionally noted in my last post.
>
>> However it does make me think that we could change...to this:
>>
>> if (i >= 0L) {
>> return BigInteger.valueOf(i);
>> } else {
>> return BigInteger.valueOf(i & Long.MAX_VALUE).setBit(63);
>> }
> Another nice idea!
> But again, moving the entire method to BigInteger would additionally
> avoid to clown around with the available BigInteger's public APIs.
> Having the method at BigInteger would allow elegant direct access to
> the private value fields.
>
>

If the operation in question starts becoming a bottleneck, these
alternate implementations can be explored. In the meantime, I plan to
stick with the straightforward code and not setup the infrastructure
needed to get at BigInteger internals.

Thanks,

-Joe


From Ulf.Zibis at gmx.de Sat Jan 21 01:39:50 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 21 Jan 2012 02:39:50 +0100
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <4F1A0758.5020808@oracle.com>
References: <4F111201.3060407@oracle.com>
<CACBEn45ZHo_=3WnKF6YvOBYHoO7H4idzeThivyCaiY1msmfWMg@mail.gmail.com>
<4F163474.7060908@oracle.com> <4F179375.7040700@gmx.de>
<4F1A0758.5020808@oracle.com>
Message-ID: <4F1A1766.4070804@gmx.de>

Thanks for your feedback.

Am 21.01.2012 01:31, schrieb Joseph Darcy:
> On 1/18/2012 7:52 PM, Ulf Zibis wrote:
>> Am 18.01.2012 03:54, schrieb Joe Darcy:
>>> I've posted a revised webrev at
>>>
>>> http://cr.openjdk.java.net/~darcy/4504839.2
>>
>> Instead
>> <code>'&#92;u0030'</code>
>> you can use
>> {@code '\u005Cu0030'}
>
> That is a fine cleanup, but I'll do a bulk conversion of all the instances of that pattern later
> on under another bug.
I only meant the new lines, where you have a mixture of {@code...} and <code>...</code>.
Then IMHO better exclusively use <code>...</code>.

>
>>
>> Byte:
>> =====
>> 459 public static int toUnsignedInt(byte x) {
>> 460 return ((int) x) & 0xff;
>> 461 }
>> This should be good enough (similar at Short, Integer):
>> 459 public static int toUnsignedInt(byte x) {
>> 460 return x & 0xff;
>> 461 }
>> (This notation if regularly used in sun.nio.cs coders.)
>
> I think the current code more explicitly indicates the intention of the method's operation to more
> casual readers less familiar with the details of primitive widening conversions, etc.
Aha! But I think, people who deal with unsigned bits know that, and otherwise they puzzle, what
about the hack is the miracle behind the cast, like me ;-)

>
>
>>
>> missing:
>> public static short toUnsignedShort(byte x)
>
> That omission was intentional. The language and VM only really support arithmetic on int and long
> values, not short or byte, so I only providing methods to widen to int and long.
I think, this is the VM's deal. Otherwise, people, who intentionally use short type, would have to cast:
short s = (short)toUnsignedInt(byte x);

>
>>
>> superfluous:
>> public static int toUnsignedInt(byte x)
>> public static long toUnsignedLong(byte x) (similar at Short)
>> one can use:
>> int i = toUnsignedShort(x)
>> long l = toUnsignedShort(x) (similar at Short)
>>
>> Integer:
>> ========
>> 623 * <li>The value represented by the string is larger than the
>> 624 * largest unsigned {@code int}, 2<sup>32</sup>-1.
>> If you format {@code int}, then you speak about the java type int, which is always signed, never
>> unsigned.
>> IMO you should better write 'unsigned 32-bit integer".
>> (similar at Long)
>
> Due to similar feedback, I've made various clarifications to the javadoc, but the basic situation
> is that the "fooUnsigned" methods interpret the bits as unsigned values, as already done in
> toHexString and related methods.
There is a difference:
toHexString performs: transform _to_ hex string
but...
toUnsignedInt performs: transform _as/from_ unsigned

-Ulf



From Ulf.Zibis at gmx.de Sat Jan 21 01:53:22 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sat, 21 Jan 2012 02:53:22 +0100
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <4F1A0852.3030701@oracle.com>
References: <4F111201.3060407@oracle.com>
<CACBEn45ZHo_=3WnKF6YvOBYHoO7H4idzeThivyCaiY1msmfWMg@mail.gmail.com>
<4F163474.7060908@oracle.com> <4F179375.7040700@gmx.de>
<CACBEn47WX=NpPYYQBaijk7gi-LFq2rFMsT3FQ_VRwiyrd-CNDw@mail.gmail.com>
<4F183F3C.4010308@gmx.de> <4F1A0852.3030701@oracle.com>
Message-ID: <4F1A1A92.9090705@gmx.de>

Am 21.01.2012 01:35, schrieb Joseph Darcy:
> On 1/19/2012 8:05 AM, Ulf Zibis wrote:
>> But again, moving the entire method to BigInteger would additionally avoid to clown around with
>> the available BigInteger's public APIs. Having the method at BigInteger would allow elegant
>> direct access to the private value fields.
>
> If the operation in question starts becoming a bottleneck, these alternate implementations can be
> explored.
But the alternatives for potentially faster algorithms would be limited if you stick BigInteger
toUnsignedBigInteger(long i) to class Long.

-Ulf



From joe.darcy at oracle.com Sat Jan 21 01:56:53 2012
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Sat, 21 Jan 2012 01:56:53 +0000
Subject: hg: jdk8/tl/jdk: 4504839: Java libraries should provide support for
unsigned integer arithmetic; ...
Message-ID: <20120121015731.6C9D7470EE@hg.openjdk.java.net>

Changeset: 71200c517524
Author: darcy
Date: 2012-01-20 17:56 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71200c517524

4504839: Java libraries should provide support for unsigned integer arithmetic
4215269: Some Integer.toHexString(int) results cannot be decoded back to an int
6322074: Converting integers to string as if unsigned
Reviewed-by: mduigou, emcmanus, flar

! src/share/classes/java/lang/Byte.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/lang/Short.java
+ test/java/lang/Integer/Unsigned.java
+ test/java/lang/Long/Unsigned.java



From eamonn at mcmanus.net Sat Jan 21 02:32:37 2012
From: eamonn at mcmanus.net (Eamonn McManus)
Date: Fri, 20 Jan 2012 18:32:37 -0800
Subject: JDK 8 code review request for initial unsigned integer arithmetic
library support
In-Reply-To: <4F1A1A92.9090705@gmx.de>
References: <4F111201.3060407@oracle.com>
<CACBEn45ZHo_=3WnKF6YvOBYHoO7H4idzeThivyCaiY1msmfWMg@mail.gmail.com>
<4F163474.7060908@oracle.com> <4F179375.7040700@gmx.de>
<CACBEn47WX=NpPYYQBaijk7gi-LFq2rFMsT3FQ_VRwiyrd-CNDw@mail.gmail.com>
<4F183F3C.4010308@gmx.de> <4F1A0852.3030701@oracle.com>
<4F1A1A92.9090705@gmx.de>
Message-ID: <CACBEn47g+iR4MAYt7wnd1RMB1pTrAJN8BTXBwHwHcexUYHJJyA@mail.gmail.com>

On 20 January 2012 17:53, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

> Am 21.01.2012 01:35, schrieb Joseph Darcy:
>
>> On 1/19/2012 8:05 AM, Ulf Zibis wrote:
>>
>>> But again, moving the entire method to BigInteger would additionally
>>> avoid to clown around with the available BigInteger's public APIs. Having
>>> the method at BigInteger would allow elegant direct access to the private
>>> value fields.
>>>
>>
>> If the operation in question starts becoming a bottleneck, these
>> alternate implementations can be explored.
>>
> But the alternatives for potentially faster algorithms would be limited if
> you stick BigInteger toUnsignedBigInteger(long i) to class Long.


There's no reason Long and BigInteger can't conspire to achieve this
without changing their APIs, if it proves interesting. It's not completely
straightforward since they are in different packages, but perfectly
possible using a sun.* intermediary.

?amonn


From alexlamsl at gmail.com Sat Jan 21 18:11:46 2012
From: alexlamsl at gmail.com (Alex Lam S.L.)
Date: Sat, 21 Jan 2012 18:11:46 +0000
Subject: java.io.File.LazyInitialization
Message-ID: <CAGpACNuM7UqjzqT+-ZEPC5e6ve4DKqRSDqxz-qrwPyjBd0ZO5A@mail.gmail.com>

Hi there,

Whilst reading the JDK6 source code for java.io.File.createTempFile(),
I noticed that:

...
private static class LazyInitialization {
...
static final String temporaryDirectory = temporaryDirectory();
static String temporaryDirectory() {...}
...
}
...
public static File createTempFile(String prefix, String suffix, File
directory) throws IOException {
...
if (directory == null) {
String tmpDir = LazyInitialization.temporaryDirectory();
...

Shouldn't the last line use the static field instead of the static method?

The static field "temporaryDirectory" is not used anywhere else in the
class, which also make this seem suspicious.


Alex.


From Alan.Bateman at oracle.com Sat Jan 21 19:01:47 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 21 Jan 2012 19:01:47 +0000
Subject: java.io.File.LazyInitialization
In-Reply-To: <CAGpACNuM7UqjzqT+-ZEPC5e6ve4DKqRSDqxz-qrwPyjBd0ZO5A@mail.gmail.com>
References: <CAGpACNuM7UqjzqT+-ZEPC5e6ve4DKqRSDqxz-qrwPyjBd0ZO5A@mail.gmail.com>
Message-ID: <4F1B0B9B.7060403@oracle.com>

On 21/01/2012 18:11, Alex Lam S.L. wrote:
> Hi there,
>
> Whilst reading the JDK6 source code for java.io.File.createTempFile(),
> I noticed that:
>
> ...
> private static class LazyInitialization {
> ...
> static final String temporaryDirectory = temporaryDirectory();
> static String temporaryDirectory() {...}
> ...
> }
> ...
> public static File createTempFile(String prefix, String suffix, File
> directory) throws IOException {
> ...
> if (directory == null) {
> String tmpDir = LazyInitialization.temporaryDirectory();
> ...
>
> Shouldn't the last line use the static field instead of the static method?
>
> The static field "temporaryDirectory" is not used anywhere else in the
> class, which also make this seem suspicious.
>
>
> Alex.
Yes indeed, and this was pointed out some time ago too [1]. This is code
that has been replaced in jdk7 and it's just that we didn't go back to
jdk6 to clean it up.

-Alan

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-January/003515.html


From joe.darcy at oracle.com Mon Jan 23 08:23:07 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 23 Jan 2012 00:23:07 -0800
Subject: JDK 8 code review request for 7132338 Use @code friendly idiom for
'\' in javadoc
Message-ID: <4F1D18EB.3090601@oracle.com>

Hello,

Responding to some of code review feedback from Ulf about the unsigned
API work, I've taken a pass at purging

<code>'&#92;u0030'</code>

from the jdk repo's javadoc and replacing it with

{@code '\u005Cu0030'}

since {@code} is generally preferable.

Webrev with these changes and other <code></code> => {@code}
transformations at

http://cr.openjdk.java.net/~darcy/7132338.0/

With these changes, the javadoc builds runs without additional warnings
and a specdiff against a reference copy of the javadoc shows no
unexpected changes.

Thanks,

-Joe


From Alan.Bateman at oracle.com Mon Jan 23 10:33:57 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Jan 2012 10:33:57 +0000
Subject: JDK 8 code review request for 7132338 Use @code friendly idiom
for '\' in javadoc
In-Reply-To: <4F1D18EB.3090601@oracle.com>
References: <4F1D18EB.3090601@oracle.com>
Message-ID: <4F1D3795.5090808@oracle.com>

On 23/01/2012 08:23, Joe Darcy wrote:
> Hello,
>
> Responding to some of code review feedback from Ulf about the unsigned
> API work, I've taken a pass at purging
>
> <code>'&#92;u0030'</code>
>
> from the jdk repo's javadoc and replacing it with
>
> {@code '\u005Cu0030'}
>
> since {@code} is generally preferable.
>
> Webrev with these changes and other <code></code> => {@code}
> transformations at
>
> http://cr.openjdk.java.net/~darcy/7132338.0/
>
> With these changes, the javadoc builds runs without additional
> warnings and a specdiff against a reference copy of the javadoc shows
> no unexpected changes.
>
> Thanks,
>
> -Joe
I looked through the patch. Looks like there is an issue in
java.io.RandomAccessFile where all <code> usages have been changed to
</code>. In java.io.DataInput I see that the javadoc doesn't go beyond
about column 40 in many cases and maybe it would be good to clean this
up while you are there.

-Alan.



From xuelei.fan at oracle.com Mon Jan 23 12:45:29 2012
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Mon, 23 Jan 2012 12:45:29 +0000
Subject: hg: jdk8/tl/jdk: 7132248:
sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java
failing
Message-ID: <20120123124542.588494712C@hg.openjdk.java.net>

Changeset: d383b5d128e3
Author: xuelei
Date: 2012-01-23 04:44 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d383b5d128e3

7132248: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing
Reviewed-by: alanb

! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java



From Ulf.Zibis at gmx.de Mon Jan 23 13:11:59 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Mon, 23 Jan 2012 14:11:59 +0100
Subject: JDK 8 code review request for 7132338 Use @code friendly idiom
for '\' in javadoc
In-Reply-To: <4F1D3795.5090808@oracle.com>
References: <4F1D18EB.3090601@oracle.com> <4F1D3795.5090808@oracle.com>
Message-ID: <4F1D5C9F.70101@gmx.de>

Am 23.01.2012 11:33, schrieb Alan Bateman:
> On 23/01/2012 08:23, Joe Darcy wrote:
>> With these changes, the javadoc builds runs without additional warnings and a specdiff against a
>> reference copy of the javadoc shows no unexpected changes.
I'm wondering because of </code>...</code> error, Alan pointed out.

> In java.io.DataInput I see that the javadoc doesn't go beyond about column 40 in many cases and
> maybe it would be good to clean this up while you are there.
+1
It would be good, to have a place at jdk repo for such cosmetic scripts (preferably for Unix +
Windows). anyone could contribute for enhancement + check the result at areas, one is working on,
e.g. to avoid unwanted changes like intentional line breaks outside the column 80 rule.

Joe, thanks for catching my change proposal.
Would like to see me as contributor :-)

I'm wondering, that you only found 14 classes to change.
IIRC, there are at least usages of old <code>...</code> tags in java.lang.Character +
java.lang.AbstractStringBuilder.

Please refer the 'cosmetic' patches at [1] for additional javadoc + indentation + spacing corrections.

I think, it is good style, to have 2 spaces after period '.' in javadoc.

[1] https://bugs.openjdk.java.net/show_bug.cgi?id=100104

-Ulf



From chris.hegarty at oracle.com Mon Jan 23 15:26:21 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 23 Jan 2012 15:26:21 +0000
Subject: RFR 7132378: Race in FutureTask if used with explicit set ( not
Runnable )
Message-ID: <4F1D7C1D.6030902@oracle.com>

This issue was raised on the jdk7u-dev mailing list [1].

The change is to update the FutureTask implementation to what is in
Doug's CVS. The old implementation using AbstractQueuedSynchronizer is
replaced with a control "state" field that is updated by CAS to track
completion, along with a Treiber stack to hold waiting threads.

http://cr.openjdk.java.net/~chegar/7132378/webrev.00/webrev/

I have already reviewed this change. The diffs in the webrev are not all
that useful, I reviewed it by going through the new file.

Doug,
I added a new test for this. It fails about 1 in every 3-4 runs on
some of the boxes I have access to. Is this useful? Would you want to
take it into your CVS?

-Chris.

[1]
http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-January/001439.html


From joe.darcy at oracle.com Mon Jan 23 17:41:06 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 23 Jan 2012 09:41:06 -0800
Subject: JDK 8 code review request for 7132338 Use @code friendly idiom
for '\' in javadoc
In-Reply-To: <4F1D3795.5090808@oracle.com>
References: <4F1D18EB.3090601@oracle.com> <4F1D3795.5090808@oracle.com>
Message-ID: <4F1D9BB2.305@oracle.com>

On 01/23/2012 02:33 AM, Alan Bateman wrote:
> On 23/01/2012 08:23, Joe Darcy wrote:
>> Hello,
>>
>> Responding to some of code review feedback from Ulf about the
>> unsigned API work, I've taken a pass at purging
>>
>> <code>'&#92;u0030'</code>
>>
>> from the jdk repo's javadoc and replacing it with
>>
>> {@code '\u005Cu0030'}
>>
>> since {@code} is generally preferable.
>>
>> Webrev with these changes and other <code></code> => {@code}
>> transformations at
>>
>> http://cr.openjdk.java.net/~darcy/7132338.0/
>>
>> With these changes, the javadoc builds runs without additional
>> warnings and a specdiff against a reference copy of the javadoc shows
>> no unexpected changes.
>>
>> Thanks,
>>
>> -Joe
> I looked through the patch. Looks like there is an issue in
> java.io.RandomAccessFile where all <code> usages have been changed to
> </code>. In java.io.DataInput I see that the javadoc doesn't go beyond
> about column 40 in many cases and maybe it would be good to clean this
> up while you are there.
>

Hi Alan,

Not sure what happened in RandomAccessFile; specdiff caught various
problems with earlier versions of the work before I send the webrev out
for review. In any case, thanks for the catching the problem; an
updated webrev with a corrected (but not re-columned) RandomAccessFile
is at:

http://cr.openjdk.java.net/~darcy/7132338.1/

-Joe


From joe.darcy at oracle.com Mon Jan 23 17:53:40 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 23 Jan 2012 09:53:40 -0800
Subject: JDK 8 code review request for 7132338 Use @code friendly idiom
for '\' in javadoc
In-Reply-To: <4F1D5C9F.70101@gmx.de>
References: <4F1D18EB.3090601@oracle.com> <4F1D3795.5090808@oracle.com>
<4F1D5C9F.70101@gmx.de>
Message-ID: <4F1D9EA4.8030406@oracle.com>

On 01/23/2012 05:11 AM, Ulf Zibis wrote:
> Am 23.01.2012 11:33, schrieb Alan Bateman:
>> On 23/01/2012 08:23, Joe Darcy wrote:
>>> With these changes, the javadoc builds runs without additional
>>> warnings and a specdiff against a reference copy of the javadoc
>>> shows no unexpected changes.
> I'm wondering because of </code>...</code> error, Alan pointed out.
>
>> In java.io.DataInput I see that the javadoc doesn't go beyond about
>> column 40 in many cases and maybe it would be good to clean this up
>> while you are there.
> +1
> It would be good, to have a place at jdk repo for such cosmetic
> scripts (preferably for Unix + Windows). anyone could contribute for
> enhancement + check the result at areas, one is working on, e.g. to
> avoid unwanted changes like intentional line breaks outside the column
> 80 rule.

Well, there is the make/scripts directory in the the top-level JDK
repository forest.

>
> Joe, thanks for catching my change proposal.
> Would like to see me as contributor :-)
>
> I'm wondering, that you only found 14 classes to change.
> IIRC, there are at least usages of old <code>...</code> tags in
> java.lang.Character + java.lang.AbstractStringBuilder.

I was not trying to replace all the <code></code> tags with {@code}!
Although others may attempt that later in JDK 8. (For the classes I
directly maintain, I long ago migrated to using {@code}.)

I was only attempting to replace the awkward HTML with <code></code>
used to render "\u..." with less awkward javadoc just using {@code}, but
if I was in a file, I replaced the other <code></code> usages to.

Cheers,

-Joe


From Ulf.Zibis at gmx.de Mon Jan 23 18:29:01 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Mon, 23 Jan 2012 19:29:01 +0100
Subject: JDK 8 code review request for 7132338 Use @code friendly idiom
for '\' in javadoc
In-Reply-To: <4F1D9EA4.8030406@oracle.com>
References: <4F1D18EB.3090601@oracle.com> <4F1D3795.5090808@oracle.com>
<4F1D5C9F.70101@gmx.de> <4F1D9EA4.8030406@oracle.com>
Message-ID: <4F1DA6ED.5050000@gmx.de>

Am 23.01.2012 18:53, schrieb Joe Darcy:
> Well, there is the make/scripts directory in the the top-level JDK repository forest.
Could you please publish your script there? (maybe via this patch)

>
>>
>> Joe, thanks for catching my change proposal.
>> Would like to see me as contributor :-)
I meant via the "contributed-by" line in the final HG change set.

> I was only attempting to replace the awkward HTML with <code></code> used to render "\u..." with
> less awkward javadoc just using {@code}, but if I was in a file, I replaced the other
> <code></code> usages to.

Thanks, ok. Was not obvious from the bugs subject line.

Additionally I see inconsistent indentations e.g. in AbstractStringBuilder:
lines 838-846
lines 1241-1244 vs. 1259-1265

... and I still think, using 'unsigned {@code int}' in e.g. Integer.java line 628 is not correct, as
there is no unsigned int in Java for now. Suggestion: 'unsigned 32-bit integer'


-Ulf



From joe.darcy at oracle.com Mon Jan 23 18:32:38 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 23 Jan 2012 10:32:38 -0800
Subject: JDK 8 code review request for 7132338 Use @code friendly idiom
for '\' in javadoc
In-Reply-To: <4F1DA6ED.5050000@gmx.de>
References: <4F1D18EB.3090601@oracle.com> <4F1D3795.5090808@oracle.com>
<4F1D5C9F.70101@gmx.de> <4F1D9EA4.8030406@oracle.com>
<4F1DA6ED.5050000@gmx.de>
Message-ID: <4F1DA7C6.8030300@oracle.com>

On 01/23/2012 10:29 AM, Ulf Zibis wrote:
> Am 23.01.2012 18:53, schrieb Joe Darcy:
>> Well, there is the make/scripts directory in the the top-level JDK
>> repository forest.
> Could you please publish your script there? (maybe via this patch)

I just used some semi-automated search and replace in emacs so no
stand-alone script at this point.

>>
>>>
>>> Joe, thanks for catching my change proposal.
>>> Would like to see me as contributor :-)
> I meant via the "contributed-by" line in the final HG change set.

But you didn't work on generating the patch! Getting credit for filing
the bug and getting credit for fixing it are different :-)

-Joe



From sean.mullan at oracle.com Mon Jan 23 18:40:27 2012
From: sean.mullan at oracle.com (sean.mullan at oracle.com)
Date: Mon, 23 Jan 2012 18:40:27 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20120123184046.6976E4713A@hg.openjdk.java.net>

Changeset: 3df0bd3ed880
Author: mullan
Date: 2012-01-23 12:17 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3df0bd3ed880

7131084: XMLDSig XPathFilter2Transform regression involving intersect filter
Reviewed-by: xuelei

! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java
! test/javax/xml/crypto/dsig/KeySelectors.java
! test/javax/xml/crypto/dsig/ValidationTests.java
! test/javax/xml/crypto/dsig/X509KeySelector.java
+ test/javax/xml/crypto/dsig/data/xmldsig-xfilter2.xml

Changeset: 5e1ad6ad41b7
Author: mullan
Date: 2012-01-23 13:23 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e1ad6ad41b7

Merge




From Alan.Bateman at oracle.com Mon Jan 23 20:06:56 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Jan 2012 20:06:56 +0000
Subject: JDK 8 code review request for 7132338 Use @code friendly idiom
for '\' in javadoc
In-Reply-To: <4F1D9BB2.305@oracle.com>
References: <4F1D18EB.3090601@oracle.com> <4F1D3795.5090808@oracle.com>
<4F1D9BB2.305@oracle.com>
Message-ID: <4F1DBDE0.3050309@oracle.com>

On 23/01/2012 17:41, Joe Darcy wrote:
>
> Hi Alan,
>
> Not sure what happened in RandomAccessFile; specdiff caught various
> problems with earlier versions of the work before I send the webrev
> out for review. In any case, thanks for the catching the problem; an
> updated webrev with a corrected (but not re-columned) RandomAccessFile
> is at:
>
> http://cr.openjdk.java.net/~darcy/7132338.1/
Updated webrev looks fine. It would be nice to get java.io.DataInput
re-formatted but understand if you won't want to don't want to take it
while you are there.

-Alan


From joe.darcy at oracle.com Mon Jan 23 20:17:44 2012
From: joe.darcy at oracle.com (joe.darcy at oracle.com)
Date: Mon, 23 Jan 2012 20:17:44 +0000
Subject: hg: jdk8/tl/jdk: 7132338: Use @code friendly idiom for '\' in javadoc
Message-ID: <20120123201754.053A04713D@hg.openjdk.java.net>

Changeset: 914711cccc60
Author: darcy
Date: 2012-01-23 12:17 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/914711cccc60

7132338: Use @code friendly idiom for '\' in javadoc
Reviewed-by: alanb

! src/share/classes/java/io/DataInput.java
! src/share/classes/java/io/LineNumberInputStream.java
! src/share/classes/java/io/RandomAccessFile.java
! src/share/classes/java/io/StreamTokenizer.java
! src/share/classes/java/lang/AbstractStringBuilder.java
! src/share/classes/java/lang/Byte.java
! src/share/classes/java/lang/Double.java
! src/share/classes/java/lang/Float.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/lang/Short.java
! src/share/classes/java/lang/String.java
! src/share/classes/java/util/Properties.java



From darryl.mocek at oracle.com Mon Jan 23 23:19:01 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Mon, 23 Jan 2012 15:19:01 -0800
Subject: Code Review Request Bug #7129185:(coll) Please add
Collections.emptyNavigableSet()
Message-ID: <4F1DEAE5.5090900@oracle.com>

Re-sending this with the synopsis in the subject line (and the correct
bug #).

Hello core-libs. Please review this patch to fix Bug #7129185. This
fix addresses comments made by Jason Mehrens to the commit of the fix
for bug #4533691, including adding a Collections.emptyNavigableSet
method. Tests are included.

Webrev, can be found here:
http://cr.openjdk.java.net/~dmocek/7129185/webrev.00

Thanks,
Darryl


From joe.darcy at oracle.com Mon Jan 23 23:44:31 2012
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Mon, 23 Jan 2012 15:44:31 -0800
Subject: Code Review Request Bug #7129185:(coll) Please add
Collections.emptyNavigableSet()
In-Reply-To: <4F1DEAE5.5090900@oracle.com>
References: <4F1DEAE5.5090900@oracle.com>
Message-ID: <4F1DF0DF.9050008@oracle.com>

Hello Darryl,

On 1/23/2012 3:19 PM, Darryl Mocek wrote:
> Re-sending this with the synopsis in the subject line (and the correct
> bug #).
>
> Hello core-libs. Please review this patch to fix Bug #7129185. This
> fix addresses comments made by Jason Mehrens to the commit of the fix
> for bug #4533691, including adding a Collections.emptyNavigableSet
> method. Tests are included.
>
> Webrev, can be found here:
> http://cr.openjdk.java.net/~dmocek/7129185/webrev.00
>
>

I recommend using some different javadoc idioms. For example, I'd replace

3209 * <pre>
3210 * NavigableSet&lt;String&gt; ns =
Collections.emptyNavigableSet();
3211 * </pre>


with

<blockquote>
{@code NavigableSet<String> ns = Collections.emptyNavigableSet();}
</blockquote>

and replace <tt>Foo</tt> with {@code Foo}.

-Joe


From david.holmes at oracle.com Tue Jan 24 02:46:42 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Jan 2012 12:46:42 +1000
Subject: RFR 7132378: Race in FutureTask if used with explicit set ( not
Runnable )
In-Reply-To: <4F1D7C1D.6030902@oracle.com>
References: <4F1D7C1D.6030902@oracle.com>
Message-ID: <4F1E1B92.5000503@oracle.com>

Hi Chris,

Hard to evaluate a completely new design like this as the devil is
always in the details.

I don't understand the purpose of handlePossibleCancellationInterrupt.
Given it doesn't clear the interrupt state why does it need to wait?

Otherwise it looks okay.

Thanks,
David

On 24/01/2012 1:26 AM, Chris Hegarty wrote:
> This issue was raised on the jdk7u-dev mailing list [1].
>
> The change is to update the FutureTask implementation to what is in
> Doug's CVS. The old implementation using AbstractQueuedSynchronizer is
> replaced with a control "state" field that is updated by CAS to track
> completion, along with a Treiber stack to hold waiting threads.
>
> http://cr.openjdk.java.net/~chegar/7132378/webrev.00/webrev/
>
> I have already reviewed this change. The diffs in the webrev are not all
> that useful, I reviewed it by going through the new file.
>
> Doug,
> I added a new test for this. It fails about 1 in every 3-4 runs on some
> of the boxes I have access to. Is this useful? Would you want to take it
> into your CVS?
>
> -Chris.
>
> [1]
> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-January/001439.html


From kumar.x.srinivasan at oracle.COM Tue Jan 24 04:36:45 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Mon, 23 Jan 2012 20:36:45 -0800
Subject: 7132270: tools/launcher/DefaultLocaleTestRun.java failing (win)
Message-ID: <4F1E355D.1090804@oracle.COM>

Hi,

Fixes spurious test failure noticed on Windows 64, for some
reason the env variable CLASSPATH either is not set in the
child environment or it is wrong.

This solution eliminates the need to depend on the env variable,
instead the classpath (defined by jtreg) is set on the command
line of the child's java process.

http://cr.openjdk.java.net/~ksrini/7132270/webrev.0/

Alan, it looks like you have added this to the Problems.lst,
but I don't see it yet.

Thanks
Kumar




From david.holmes at oracle.com Tue Jan 24 05:56:41 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Jan 2012 15:56:41 +1000
Subject: Code review request for #6469160, #7088271
In-Reply-To: <4F19B04C.8040104@oracle.com>
References: <4F19B04C.8040104@oracle.com>
Message-ID: <4F1E4819.5080505@oracle.com>

Hi Brandon,

On 21/01/2012 4:19 AM, Brandon Passanisi wrote:
> Resending again...
>
> Hello core-libs. I was wondering of somebody could be please review the
> following fix for #6469160 and #7088271. The changes in the webrev fix
> both bugs. Information is below:
>
> Webrev URL: http://cr.openjdk.java.net/~bpassani/6469160_7088271/1/
> <http://cr.openjdk.java.net/%7Ebpassani/6469160_7088271/1/>
> Bug #6469160: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469160
> Bug #7088271: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7088271

Seems to me that 7088271 should be closed as a duplicate of 6469160.

> Both bugs uncover the current behavior where using a 0 or 1 precision
> value with a float zero causes an ArrayIndexOutOfBoundsException. The
> current code in FormattedFloatingDecimal.java interprets the float zero
> as "0.0" in the case where precision is 0 or 1 and returns the length of
> it's characters as 3. Later in Formatter.addZeros(), the character array
> "0.0" is passed in, but a new array of only 1 character is allocated.
> When an System.arraycopy() is performed, the
> ArrayIndexOutOfBoundsException occurs. In fact, when run with "-esa" an
> AssertionError occurs at "assert (outPrec <= prec);" on line 3393 of
> Formatter.java. The fix is for FormatedFloatingDecimal.java to interpret
> the float zero as a single "0" because of the precision being set to 0
> or 1.

This isn't an area I'm familiar with so please excuse me if I'm missing
something obvious. I'm confused about the fix in regards to the two
cases reported in the CRs. In one case we have:

String.format("%3.0g", 0.0);

where the precision is 0. But in your fix you only special case the
situation where precision is 1:

+ if (digits.length == 1 && digits[0] == '0'
+ && precision == 1) {
+ // When the number is zero and precision is 1, set the
+ // precision to 0 so that a decimal point and digits
+ // are not added by code later in this method.
+ precision--;
+ } else {

so I don't understand how this fixes %3.0g ?

More generally it is not clear to me that putting in this special case
is the right way to fix this. Though I admit I don't really understand
what the specification requires when you give a precision of 0 with a
'g' conversion:

"If the conversion is 'g' or 'G', then the precision is the total number
of digits in the resulting magnitude after rounding."

So we asked for zero digits? What should that mean?

David
-----

> Since java has been throwing exceptions in these cases, I consulted with
> the output of C's printf to make sure that the outputted strings are the
> same. I updated the Formatter's Basic-X template of tests with a little
> over 20 test format strings that were causing exceptions without the
> change and the output of each is compared with the output from C's
> printf with the same format string. And, I ran all of the Basic-X tests
> to make sure there weren't any regressions in behavior.
>
> Thanks.


From alan.bateman at oracle.com Tue Jan 24 09:23:06 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 24 Jan 2012 09:23:06 +0000
Subject: hg: jdk8/tl: 7132204: Default testset in JPRT should not run all tests
Message-ID: <20120124092307.001B84715A@hg.openjdk.java.net>

Changeset: 0f653ee93477
Author: alanb
Date: 2012-01-24 09:08 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/rev/0f653ee93477

7132204: Default testset in JPRT should not run all tests
Reviewed-by: ohair

! make/jprt.properties



From alan.bateman at oracle.com Tue Jan 24 09:24:05 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 24 Jan 2012 09:24:05 +0000
Subject: hg: jdk8/tl/jdk: 7132204: Default testset in JPRT should not run all
tests
Message-ID: <20120124092421.4ABED4715B@hg.openjdk.java.net>

Changeset: 237319a01a9a
Author: alanb
Date: 2012-01-24 09:09 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/237319a01a9a

7132204: Default testset in JPRT should not run all tests
Reviewed-by: ohair

! make/jprt.properties
! test/ProblemList.txt



From chris.hegarty at oracle.com Tue Jan 24 09:43:27 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Jan 2012 09:43:27 +0000
Subject: 7132270: tools/launcher/DefaultLocaleTestRun.java failing (win)
In-Reply-To: <4F1E355D.1090804@oracle.COM>
References: <4F1E355D.1090804@oracle.COM>
Message-ID: <4F1E7D3F.6080601@oracle.com>

The change looks fine to me.

I don't see this test on the problem list either.

-Chris.

On 01/24/12 04:36 AM, Kumar Srinivasan wrote:
> Hi,
>
> Fixes spurious test failure noticed on Windows 64, for some
> reason the env variable CLASSPATH either is not set in the
> child environment or it is wrong.
>
> This solution eliminates the need to depend on the env variable,
> instead the classpath (defined by jtreg) is set on the command
> line of the child's java process.
>
> http://cr.openjdk.java.net/~ksrini/7132270/webrev.0/
>
> Alan, it looks like you have added this to the Problems.lst,
> but I don't see it yet.
>
> Thanks
> Kumar
>
>


From Alan.Bateman at oracle.com Tue Jan 24 09:55:03 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Jan 2012 09:55:03 +0000
Subject: 7132270: tools/launcher/DefaultLocaleTestRun.java failing (win)
In-Reply-To: <4F1E355D.1090804@oracle.COM>
References: <4F1E355D.1090804@oracle.COM>
Message-ID: <4F1E7FF7.7010807@oracle.com>

On 24/01/2012 04:36, Kumar Srinivasan wrote:
> Hi,
>
> Fixes spurious test failure noticed on Windows 64, for some
> reason the env variable CLASSPATH either is not set in the
> child environment or it is wrong.
>
> This solution eliminates the need to depend on the env variable,
> instead the classpath (defined by jtreg) is set on the command
> line of the child's java process.
>
> http://cr.openjdk.java.net/~ksrini/7132270/webrev.0/
>
> Alan, it looks like you have added this to the Problems.lst,
> but I don't see it yet.
I didn't get a chance to push 7132204 yesterday so the ProblemList
wasn't updated. Given that you have a fix to 7132270 coming I removed
tools/launcher/DefaultLocaleTestRun.java before pushing.

The changes in your webrev look fine.

-Alan.





From Alan.Bateman at oracle.com Tue Jan 24 10:15:06 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Jan 2012 10:15:06 +0000
Subject: Request for review: 7123229: (coll) EnumMap.containsValue(null)
returns true
In-Reply-To: <1326157533.18727.31.camel@chalkhill>
References: <1326157533.18727.31.camel@chalkhill>
Message-ID: <4F1E84AA.6060308@oracle.com>


Neil - are you still planning to push this to jdk8/tl? As it's
regression, albeit small, it seems like a good candidate for jdk7u too.

-Alan.

On 10/01/2012 01:05, Neil Richards wrote:
> Hi all,
> When proposing the change for 6312706 [1], I erroneously managed to
> convince myself (and others!) that it would be safe to use 'new
> Integer(0)' for java.util.EnumMap.NULL (the object used to mark null
> values for entries in the map) [2].
>
> This was on the basis that I thought it was only compared by identity.
> However, on closer inspection, this turns out not to be the case.
>
> 7123229 was raised to report the bug that was introduced based on this
> invalid assumption.
>
> I've created a webrev with a suggested fix for 7123229 [3], which
> changes NULL to be an Object which:
> * will only return 'true' from equals(Object) for itself
> * returns 0 from hashCode()
>
> For good measure, it also returns a sensible value from toString().
>
> Please review this fix and let me know your thoughts,
> Thanks,
> Neil
>
> [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c1e87a18e46a
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-March/006353.html
> [3] http://cr.openjdk.java.net/~ngmr/7123229/webrev.00/
>



From chris.hegarty at oracle.com Tue Jan 24 11:00:48 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Jan 2012 11:00:48 +0000
Subject: RFR 7132378: Race in FutureTask if used with explicit set ( not
Runnable )
In-Reply-To: <4F1E1B92.5000503@oracle.com>
References: <4F1D7C1D.6030902@oracle.com> <4F1E1B92.5000503@oracle.com>
Message-ID: <4F1E8F60.7000103@oracle.com>

On 01/24/12 02:46 AM, David Holmes wrote:
> Hi Chris,
>
> Hard to evaluate a completely new design like this as the devil is
> always in the details.
>
> I don't understand the purpose of handlePossibleCancellationInterrupt.
> Given it doesn't clear the interrupt state why does it need to wait?

Yes, this is true. I can't see any need for it to wait now since it
doesn't clear the threads interrupt state. I felt this was more of a
marker/place holder to determine the correct course of action here.

That said, the previous implementation did not attempt to clear the
threads interrupt state either. If Doug agrees that this code is
unlikely to every be reinstated, then I think it can probably be removed.

-Chris.

> Otherwise it looks okay.
>
> Thanks,
> David
>
> On 24/01/2012 1:26 AM, Chris Hegarty wrote:
>> This issue was raised on the jdk7u-dev mailing list [1].
>>
>> The change is to update the FutureTask implementation to what is in
>> Doug's CVS. The old implementation using AbstractQueuedSynchronizer is
>> replaced with a control "state" field that is updated by CAS to track
>> completion, along with a Treiber stack to hold waiting threads.
>>
>> http://cr.openjdk.java.net/~chegar/7132378/webrev.00/webrev/
>>
>> I have already reviewed this change. The diffs in the webrev are not all
>> that useful, I reviewed it by going through the new file.
>>
>> Doug,
>> I added a new test for this. It fails about 1 in every 3-4 runs on some
>> of the boxes I have access to. Is this useful? Would you want to take it
>> into your CVS?
>>
>> -Chris.
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2012-January/001439.html


From rickard.backman at oracle.com Tue Jan 24 13:00:42 2012
From: rickard.backman at oracle.com (rickard.backman at oracle.com)
Date: Tue, 24 Jan 2012 13:00:42 +0000
Subject: hg: jdk8/tl/jdk: 7132386: makefile support for tracing/Java Flight
Recorder framework phase I
Message-ID: <20120124130105.1320547160@hg.openjdk.java.net>

Changeset: 718bca4e685f
Author: rbackman
Date: 2012-01-17 16:20 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/718bca4e685f

7132386: makefile support for tracing/Java Flight Recorder framework phase I
Reviewed-by: ohair, dholmes, rottenha
Contributed-by: Markus Gronlund <markus.gronlund at oracle.com>, Erik Gahlin <erik.gahlin at oracle.com>, Nils Loodin <nils.loodin at oracle.com>, Rickard Backman <rickard.backman at oracle.com>, Staffan Larsen <staffan.larsen at oracle.com>

! make/com/oracle/Makefile
+ make/com/oracle/jfr/Makefile
! make/common/Defs.gmk
! make/common/Release.gmk



From kumar.x.srinivasan at oracle.COM Tue Jan 24 16:21:30 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Tue, 24 Jan 2012 08:21:30 -0800
Subject: 7132270: tools/launcher/DefaultLocaleTestRun.java failing (win)
In-Reply-To: <4F1E7FF7.7010807@oracle.com>
References: <4F1E355D.1090804@oracle.COM> <4F1E7FF7.7010807@oracle.com>
Message-ID: <4F1EDA8A.7090006@oracle.COM>

Cool thanks.

Kumar

> On 24/01/2012 04:36, Kumar Srinivasan wrote:
>> Hi,
>>
>> Fixes spurious test failure noticed on Windows 64, for some
>> reason the env variable CLASSPATH either is not set in the
>> child environment or it is wrong.
>>
>> This solution eliminates the need to depend on the env variable,
>> instead the classpath (defined by jtreg) is set on the command
>> line of the child's java process.
>>
>> http://cr.openjdk.java.net/~ksrini/7132270/webrev.0/
>>
>> Alan, it looks like you have added this to the Problems.lst,
>> but I don't see it yet.
> I didn't get a chance to push 7132204 yesterday so the ProblemList
> wasn't updated. Given that you have a fix to 7132270 coming I removed
> tools/launcher/DefaultLocaleTestRun.java before pushing.
>
> The changes in your webrev look fine.
>
> -Alan.
>
>
>



From Roger.Riggs at oracle.com Tue Jan 24 15:16:18 2012
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 24 Jan 2012 10:16:18 -0500
Subject: Code Review Request Bug #7129185:(coll) Please add
Collections.emptyNavigableSet()
In-Reply-To: <4F1DF0DF.9050008@oracle.com>
References: <4F1DEAE5.5090900@oracle.com> <4F1DF0DF.9050008@oracle.com>
Message-ID: <4F1ECB42.4090704@oracle.com>

The html accessibility guidelines do not support using <blockquote> for
indentation.

http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#gl-structure-presentation
See section 3.7

Using blockquote for indentation is flagged by Oracle's html
accessibility checker.


On 01/23/2012 06:44 PM, Joseph Darcy wrote:
> Hello Darryl,
>
> On 1/23/2012 3:19 PM, Darryl Mocek wrote:
>> Re-sending this with the synopsis in the subject line (and the
>> correct bug #).
>>
>> Hello core-libs. Please review this patch to fix Bug #7129185. This
>> fix addresses comments made by Jason Mehrens to the commit of the fix
>> for bug #4533691, including adding a Collections.emptyNavigableSet
>> method. Tests are included.
>>
>> Webrev, can be found here:
>> http://cr.openjdk.java.net/~dmocek/7129185/webrev.00
>>
>>
>
> I recommend using some different javadoc idioms. For example, I'd
> replace
>
> 3209 * <pre>
> 3210 * NavigableSet&lt;String&gt; ns =
> Collections.emptyNavigableSet();
> 3211 * </pre>
>
>
> with
>
> <blockquote>
> {@code NavigableSet<String> ns = Collections.emptyNavigableSet();}
> </blockquote>
>
> and replace <tt>Foo</tt> with {@code Foo}.
>
> -Joe



From maurizio.cimadamore at oracle.com Tue Jan 24 17:54:26 2012
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Tue, 24 Jan 2012 17:54:26 +0000
Subject: hg: jdk8/tl/langtools: 7129801: Merge the two method applicability
routines
Message-ID: <20120124175432.C36B84716E@hg.openjdk.java.net>

Changeset: 51fb17abfc32
Author: mcimadamore
Date: 2012-01-24 17:52 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/51fb17abfc32

7129801: Merge the two method applicability routines
Summary: Resolve.java and Infer.java should reuse the same method applicability check routine
Reviewed-by: dlsmith, jjg

! 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/diags/examples/InferVarargsArgumentMismatch.java



From jason_mehrens at hotmail.com Tue Jan 24 17:54:52 2012
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Tue, 24 Jan 2012 11:54:52 -0600
Subject: Code Review Request Bug #7129185:(coll) Please add
Collections.emptyNavigableSet()
In-Reply-To: <4F1DEAE5.5090900@oracle.com>
References: <4F1DEAE5.5090900@oracle.com>
Message-ID: <SNT114-W58C0511424B9CB0733DDFD838B0@phx.gbl>


Darryl,

Here is my list of bugs:
1. The comparator method is using raw types. Should be Comparator<? super E>.
2. The readResolve method comment is just wrong and the method implementation is redundant of the default behavior.
3. What if I want to create an empty set navigable set with supplied comparator? Extending is not an option.

Here are my lists of RFEs:
5. Why not extend EmptySet so you don't have to reimplement the optimized methods?
6. Why not create a default access static final reference named EMPTY_NAVIGABLE_SET inside of the EmptyNavigableSet and use that in readResolve and in Collections.emptyNavigableSet? That gives you the nice singleton behavior and on demand class loading.
7. CCE lacks a descriptive message that you normally get if you used Class.cast or just an implicit cast.

Jason



> Date: Mon, 23 Jan 2012 15:19:01 -0800
> From: darryl.mocek at oracle.com
> To: core-libs-dev at openjdk.java.net
> Subject: Code Review Request Bug #7129185:(coll) Please add Collections.emptyNavigableSet()
>
> Re-sending this with the synopsis in the subject line (and the correct
> bug #).
>
> Hello core-libs. Please review this patch to fix Bug #7129185. This
> fix addresses comments made by Jason Mehrens to the commit of the fix
> for bug #4533691, including adding a Collections.emptyNavigableSet
> method. Tests are included.
>
> Webrev, can be found here:
> http://cr.openjdk.java.net/~dmocek/7129185/webrev.00
>
> Thanks,
> Darryl


From kumar.x.srinivasan at oracle.com Tue Jan 24 18:02:10 2012
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Tue, 24 Jan 2012 18:02:10 +0000
Subject: hg: jdk8/tl/jdk: 7132270: tools/launcher/DefaultLocaleTestRun.java
failing (win)
Message-ID: <20120124180231.8A5A04716F@hg.openjdk.java.net>

Changeset: f64ea40293db
Author: ksrini
Date: 2012-01-24 09:58 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f64ea40293db

7132270: tools/launcher/DefaultLocaleTestRun.java failing (win)
Reviewed-by: alanb, chegar

! test/tools/launcher/DefaultLocaleTestRun.java
! test/tools/launcher/TestHelper.java



From lance.andersen at oracle.com Tue Jan 24 18:18:35 2012
From: lance.andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 24 Jan 2012 13:18:35 -0500
Subject: Review needed for 7132879 to address the findbug errors in
WebRowSetXmlWriter
Message-ID: <26EC77EC-400B-432B-ACC7-FCB0E43EC65E@oracle.com>

Hi,

Looking for a reviewer for http://cr.openjdk.java.net/~lancea/7132879/webrev.00/

this is a small change to address 2 findbug errors for this class. The findbug issues being addressed:

Inefficient use of keySet iterator instead of entrySet iterator

and

non-serializable instance field in serializable class


Best,
Lance

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 forax at univ-mlv.fr Tue Jan 24 18:29:09 2012
From: forax at univ-mlv.fr (=?utf-8?B?UmVtaSBGb3JheA==?=)
Date: Tue, 24 Jan 2012 19:29:09 +0100
Subject: =?utf-8?B?UmU6IFJldmlldyBuZWVkZWQgZm9yIDcxMzI4NzkgdG8gYWRkcmVzcyB0aGUgZmluZGJ1ZyBlcnJvcnMgaW4JV2ViUm93U2V0WG1sV3JpdGVy?=
Message-ID: <201201241829.q0OIT9Tt009359@monge.univ-mlv.fr>

Looks good.
The only weird thing is the use of java.util.Map instead of Map. Because Map is used in when referencing Map.Entry just after.

R?mi


----- Reply message -----
From: "Lance Andersen - Oracle" <lance.andersen at oracle.com>
To: "core-libs-dev Libs" <core-libs-dev at openjdk.java.net>
Subject: Review needed for 7132879 to address the findbug errors in WebRowSetXmlWriter
Date: Tue, Jan 24, 2012 19:18


Hi,

Looking for a reviewer for http://cr.openjdk.java.net/~lancea/7132879/webrev.00/

this is a small change to address 2 findbug errors for this class. The findbug issues being addressed:

Inefficient use of keySet iterator instead of entrySet iterator

and

non-serializable instance field in serializable class


Best,
Lance

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 Tue Jan 24 18:50:22 2012
From: lance.andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 24 Jan 2012 13:50:22 -0500
Subject: Review needed for 7132879 to address the findbug errors
in WebRowSetXmlWriter
In-Reply-To: <201201241829.q0OIT9Tt009359@monge.univ-mlv.fr>
References: <201201241829.q0OIT9Tt009359@monge.univ-mlv.fr>
Message-ID: <E539386A-58A0-441B-83A2-C9860D205F93@oracle.com>

You are suggesting changing

java.util.Map<?,?> typeMap = caller.getTypeMap();

to

Map<?,?> typeMap = caller.getTypeMap();


Which I can do. I probably did not think about it much as it was their previously but I agree that would be the way to go.

Please let me know if I am on point with your suggestion

Best
Lance
On Jan 24, 2012, at 1:29 PM, Remi Forax wrote:

> Looks good.
> The only weird thing is the use of java.util.Map instead of Map. Because Map is used in when referencing Map.Entry just after.
>
> R?mi
>
>
> ----- Reply message -----
> From: "Lance Andersen - Oracle" <lance.andersen at oracle.com>
> To: "core-libs-dev Libs" <core-libs-dev at openjdk.java.net>
> Subject: Review needed for 7132879 to address the findbug errors in WebRowSetXmlWriter
> Date: Tue, Jan 24, 2012 19:18
>
>
> Hi,
>
> Looking for a reviewer for http://cr.openjdk.java.net/~lancea/7132879/webrev.00/
>
> this is a small change to address 2 findbug errors for this class. The findbug issues being addressed:
>
> Inefficient use of keySet iterator instead of entrySet iterator
>
> and
>
> non-serializable instance field in serializable class
>
>
> Best,
> Lance
>
> 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 darryl.mocek at oracle.com Tue Jan 24 18:51:27 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Tue, 24 Jan 2012 10:51:27 -0800
Subject: Code Review Request Bug #7129185:(coll) Please add
Collections.emptyNavigableSet()
In-Reply-To: <SNT114-W58C0511424B9CB0733DDFD838B0@phx.gbl>
References: <4F1DEAE5.5090900@oracle.com>
<SNT114-W58C0511424B9CB0733DDFD838B0@phx.gbl>
Message-ID: <4F1EFDAF.2030100@oracle.com>

Jason,

see inline and updated webrev:
http://cr.openjdk.java.net/~dmocek/7129185/webrev.01

Darryl

On Tue 24 Jan 2012 09:54:52 AM PST, Jason Mehrens wrote:
>
> Darryl,
>
> Here is my list of bugs:
> 1. The comparator method is using raw types. Should be Comparator<?
> super E>.
The webrev didn't pick up on this change. The method is this:
public Comparator<? super E> comparator() {
return null;
}
> 2. The readResolve method comment is just wrong and the method
> implementation is redundant of the default behavior.
readResolve has been removed.
> 3. What if I want to create an empty set navigable set with supplied
> comparator? Extending is not an option.
This is the one issue I wanted to discuss...is this necessary? I was
thinking about how this would be implemented. You would need to supply
a comparator to the emptyNavigableSet. Other empty* methods don't take
parameters and adding a method to supply a comparator would require an
additional method.

Darryl
>
> Here are my lists of RFEs:
> 5. Why not extend EmptySet so you don't have to reimplement the
> optimized methods?
> 6. Why not create a default access static final reference named
> EMPTY_NAVIGABLE_SET inside of the EmptyNavigableSet and use that in
> readResolve and in Collections.emptyNavigableSet? That gives you the
> nice singleton behavior and on demand class loading.
> 7. CCE lacks a descriptive message that you normally get if you used
> Class.cast or just an implicit cast.
>
> Jason
>
>
> > Date: Mon, 23 Jan 2012 15:19:01 -0800
> > From: darryl.mocek at oracle.com
> > To: core-libs-dev at openjdk.java.net
> > Subject: Code Review Request Bug #7129185:(coll) Please add
> Collections.emptyNavigableSet()
> >
> > Re-sending this with the synopsis in the subject line (and the correct
> > bug #).
> >
> > Hello core-libs. Please review this patch to fix Bug #7129185. This
> > fix addresses comments made by Jason Mehrens to the commit of the fix
> > for bug #4533691, including adding a Collections.emptyNavigableSet
> > method. Tests are included.
> >
> > Webrev, can be found here:
> > http://cr.openjdk.java.net/~dmocek/7129185/webrev.00
> >
> > Thanks,
> > Darryl


From forax at univ-mlv.fr Tue Jan 24 18:58:47 2012
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 24 Jan 2012 19:58:47 +0100
Subject: Review needed for 7132879 to address the findbug errors
in WebRowSetXmlWriter
In-Reply-To: <E539386A-58A0-441B-83A2-C9860D205F93@oracle.com>
References: <201201241829.q0OIT9Tt009359@monge.univ-mlv.fr>
<E539386A-58A0-441B-83A2-C9860D205F93@oracle.com>
Message-ID: <4F1EFF67.9000900@univ-mlv.fr>

On 01/24/2012 07:50 PM, Lance Andersen - Oracle wrote:
> You are suggesting changing
>
> java.util.Map<?,?> typeMap = caller.getTypeMap();
>
> to
>
> Map<?,?> typeMap = caller.getTypeMap();
>
>
> Which I can do. I probably did not think about it much as it was
> their previously but I agree that would be the way to go.
>
> Please let me know if I am on point with your suggestion

Yes.

Map<String, Class<?>> typeMap = ...


>
> Best
> Lance

rgds,
R?mi

> On Jan 24, 2012, at 1:29 PM, Remi Forax wrote:
>
>> Looks good.
>> The only weird thing is the use of java.util.Map instead of Map.
>> Because Map is used in when referencing Map.Entry just after.
>>
>> R?mi
>>
>>
>> ----- Reply message -----
>> From: "Lance Andersen - Oracle" <lance.andersen at oracle.com
>> <mailto:lance.andersen at oracle.com>>
>> To: "core-libs-dev Libs" <core-libs-dev at openjdk.java.net
>> <mailto:core-libs-dev at openjdk.java.net>>
>> Subject: Review needed for 7132879 to address the findbug errors in
>> WebRowSetXmlWriter
>> Date: Tue, Jan 24, 2012 19:18
>>
>>
>> Hi,
>>
>> Looking for a reviewer for
>> http://cr.openjdk.java.net/~lancea/7132879/webrev.00/
>> <http://cr.openjdk.java.net/%7Elancea/7132879/webrev.00/>
>>
>> this is a small change to address 2 findbug errors for this class.
>> The findbug issues being addressed:
>>
>> Inefficient use of keySet iterator instead of entrySet iterator
>>
>> and
>>
>> non-serializable instance field in serializable class
>>
>>
>> Best,
>> Lance
>>
>> 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 <mailto:Lance.Andersen at oracle.com>
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto:Lance.Andersen at oracle.com>
>



From dl at cs.oswego.edu Tue Jan 24 18:56:29 2012
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 24 Jan 2012 13:56:29 -0500
Subject: RFR 7132378: Race in FutureTask if used with explicit set ( not
Runnable )
In-Reply-To: <4F1E8F60.7000103@oracle.com>
References: <4F1D7C1D.6030902@oracle.com> <4F1E1B92.5000503@oracle.com>
<4F1E8F60.7000103@oracle.com>
Message-ID: <4F1EFEDD.5010600@cs.oswego.edu>

Sorry for delay; swamped...

On 01/24/12 06:00, Chris Hegarty wrote:

>> I don't understand the purpose of handlePossibleCancellationInterrupt.
>> Given it doesn't clear the interrupt state why does it need to wait?
>
> Yes, this is true. I can't see any need for it to wait now since it doesn't
> clear the threads interrupt state. I felt this was more of a marker/place holder
> to determine the correct course of action here.

The underlying issue is that when run() etc are directly
invoked in the same thread as the caller, we (should? must?)
ensure that the results of Future status method invocations by that
caller agree with each other, even if racing with an asynchronous
cancel/interrupt. The only possible inconsistency is the rare case
where we know that the task will be cancelled but hasn't been interrupted
yet. So we just wait out the transient state. While it is
arguably legal not to do this, adding this precaution
will probably avoid getting a bug report about this someday.
As the further comment mentions, it would be even
nicer to force Thread interrupt status to agree with task status,
but we can't actually do this, so I left a note in case
anyone is tempted.

>
> Doug,
> I added a new test for this. It fails about 1 in every 3-4 runs on some of the boxes I have access to. Is this useful? Would you want to take it into your CVS?

Thanks. I had made some tests for this but at the moment don't see them.
If you'd like to send me what you have, I'll locate others and
add to the jtreg test.

-Doug


From lance.andersen at oracle.com Tue Jan 24 19:02:31 2012
From: lance.andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 24 Jan 2012 14:02:31 -0500
Subject: Review needed for 7132879 to address the findbug errors in
WebRowSetXmlWriter
In-Reply-To: <4F1EFF67.9000900@univ-mlv.fr>
References: <201201241829.q0OIT9Tt009359@monge.univ-mlv.fr>
<E539386A-58A0-441B-83A2-C9860D205F93@oracle.com>
<4F1EFF67.9000900@univ-mlv.fr>
Message-ID: <F02ECE21-B484-4C75-A4E3-1CB280F8F6ED@oracle.com>

Here is the change removing the java.util.Map

thanks for the feedback.


new-host-4:internal lanceandersen$ hg diff
diff -r b14e13237498 src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java
--- a/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Wed Jan 18 11:00:20 2012 -0800
+++ b/src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java Tue Jan 24 14:01:20 2012 -0500
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2003, 2010, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -48,7 +48,7 @@
* for this field is set with the <code>java.io.Writer</code> object given
* as the second argument to the <code>writeXML</code> method.
*/
- private java.io.Writer writer;
+ private transient java.io.Writer writer;

/**
* The <code>java.util.Stack</code> object that this <code>WebRowSetXmlWriter</code>
@@ -205,17 +205,12 @@

//Changed to beginSection and endSection for maps for proper indentation
beginSection("map");
- java.util.Map<?,?> typeMap = caller.getTypeMap();
- if (typeMap != null) {
- Iterator<?> i = typeMap.keySet().iterator();
- Class<?> c;
- String type;
- while (i.hasNext()) {
- type = (String)i.next();
- c = (Class)typeMap.get(type);
- propString("type", type);
- propString("class", c.getName());
- }
+ Map<String, Class<?>> typeMap = caller.getTypeMap();
+ if(typeMap != null) {
+ for(Map.Entry<String, Class<?>> mm : typeMap.entrySet()) {
+ propString("type", mm.getKey());
+ propString("class", mm.getValue().getName());
+ }
}
endSection("map");

On Jan 24, 2012, at 1:58 PM, R?mi Forax wrote:

> On 01/24/2012 07:50 PM, Lance Andersen - Oracle wrote:
>> You are suggesting changing
>>
>> java.util.Map<?,?> typeMap = caller.getTypeMap();
>>
>> to
>>
>> Map<?,?> typeMap = caller.getTypeMap();
>>
>>
>> Which I can do. I probably did not think about it much as it was their previously but I agree that would be the way to go.
>>
>> Please let me know if I am on point with your suggestion
>
> Yes.
>
> Map<String, Class<?>> typeMap = ...
>
>
>>
>> Best
>> Lance
>
> rgds,
> R?mi
>
>> On Jan 24, 2012, at 1:29 PM, Remi Forax wrote:
>>
>>> Looks good.
>>> The only weird thing is the use of java.util.Map instead of Map. Because Map is used in when referencing Map.Entry just after.
>>>
>>> R?mi
>>>
>>>
>>> ----- Reply message -----
>>> From: "Lance Andersen - Oracle" <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>>
>>> To: "core-libs-dev Libs" <core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>>
>>> Subject: Review needed for 7132879 to address the findbug errors in WebRowSetXmlWriter
>>> Date: Tue, Jan 24, 2012 19:18
>>>
>>>
>>> Hi,
>>>
>>> Looking for a reviewer for http://cr.openjdk.java.net/~lancea/7132879/webrev.00/ <http://cr.openjdk.java.net/%7Elancea/7132879/webrev.00/>
>>>
>>> this is a small change to address 2 findbug errors for this class. The findbug issues being addressed:
>>>
>>> Inefficient use of keySet iterator instead of entrySet iterator
>>>
>>> and
>>>
>>> non-serializable instance field in serializable class
>>>
>>>
>>> Best,
>>> Lance
>>>
>>> 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 <mailto:Lance.Andersen at oracle.com>
>>>
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>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 <mailto: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 lance.andersen at oracle.com Tue Jan 24 20:13:54 2012
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Tue, 24 Jan 2012 20:13:54 +0000
Subject: hg: jdk8/tl/jdk: 7132879: address Findbugs issue in WebRowSetXmlWriter
Message-ID: <20120124201403.CD26347173@hg.openjdk.java.net>

Changeset: 303b67074666
Author: lancea
Date: 2012-01-24 15:13 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/303b67074666

7132879: address Findbugs issue in WebRowSetXmlWriter
Reviewed-by: forax

! src/share/classes/com/sun/rowset/internal/WebRowSetXmlWriter.java



From jason_mehrens at hotmail.com Tue Jan 24 21:29:30 2012
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Tue, 24 Jan 2012 15:29:30 -0600
Subject: Code Review Request Bug #7129185:(coll) Please add
Collections.emptyNavigableSet()
In-Reply-To: <4F1EFDAF.2030100@oracle.com>
References: <4F1DEAE5.5090900@oracle.com>
<SNT114-W58C0511424B9CB0733DDFD838B0@phx.gbl>,
<4F1EFDAF.2030100@oracle.com>
Message-ID: <SNT114-W445B5413DDB865A0D2A111838B0@phx.gbl>


> > 3. What if I want to create an empty set navigable set with supplied
> > comparator? Extending is not an option.
> This is the one issue I wanted to discuss...is this necessary? I was
> thinking about how this would be implemented. You would need to supply
> a comparator to the emptyNavigableSet. Other empty* methods don't take
> parameters and adding a method to supply a comparator would require an
> additional method.

I think you have little choice but to add the parameter because the current implementation of emptyNavigableSet().descendingSet().comparator() returns the wrong value. Which should mean that the bounds checking is incorrect in the descendingSet too. Am I correct on that? So by adding that feature you don't have to create a special subclass to correctly implement EmptyNavigableSet.

Jason

From darryl.mocek at oracle.com Tue Jan 24 22:18:55 2012
From: darryl.mocek at oracle.com (Darryl Mocek)
Date: Tue, 24 Jan 2012 14:18:55 -0800
Subject: Code Review Request Bug #7129185:(coll) Please add
Collections.emptyNavigableSet()
In-Reply-To: <SNT114-W445B5413DDB865A0D2A111838B0@phx.gbl>
References: <4F1DEAE5.5090900@oracle.com>
<SNT114-W58C0511424B9CB0733DDFD838B0@phx.gbl>
<4F1EFDAF.2030100@oracle.com>
<SNT114-W445B5413DDB865A0D2A111838B0@phx.gbl>
Message-ID: <4F1F2E4F.3070700@oracle.com>

emptyNavigableSet().descendingSet().comparator() returns null. Isn't
this what's expected? The bounds checking should be correct.

Darryl

On Tue 24 Jan 2012 01:29:30 PM PST, Jason Mehrens wrote:
> > > 3. What if I want to create an empty set navigable set with supplied
> > > comparator? Extending is not an option.
> > This is the one issue I wanted to discuss...is this necessary? I was
> > thinking about how this would be implemented. You would need to supply
> > a comparator to the emptyNavigableSet. Other empty* methods don't take
> > parameters and adding a method to supply a comparator would require an
> > additional method.
>
> I think you have little choice but to add the parameter because the
> current implementation of
> emptyNavigableSet().descendingSet().comparator() returns the wrong
> value. Which should mean that the bounds checking is incorrect in the
> descendingSet too. Am I correct on that? So by adding that feature you
> don't have to create a special subclass to correctly implement
> EmptyNavigableSet.
>
> Jason


From jason_mehrens at hotmail.com Tue Jan 24 22:58:39 2012
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Tue, 24 Jan 2012 16:58:39 -0600
Subject: Code Review Request Bug #7129185:(coll) Please add
Collections.emptyNavigableSet()
In-Reply-To: <4F1F2E4F.3070700@oracle.com>
References: <4F1DEAE5.5090900@oracle.com>
<SNT114-W58C0511424B9CB0733DDFD838B0@phx.gbl>
<4F1EFDAF.2030100@oracle.com>
<SNT114-W445B5413DDB865A0D2A111838B0@phx.gbl>,
<4F1F2E4F.3070700@oracle.com>
Message-ID: <SNT114-W5126110C6776A355F317D1838B0@phx.gbl>


Darryl,

Per the SortedSet docs: .....null if this set uses the natural ordering of its elements.
Per the NavigableSet.descendingSet docs: "The returned set has an ordering equivalent to Collections.reverseOrder(comparator())"

=====================================
NavigableSet<String> fwd = new TreeSet<String>();
NavigableSet<String> rev = fwd.descendingSet();
System.out.println(fwd.comparator() +" "+ rev.comparator());
=====================================
null java.util.Collections$ReverseComparator at 4b71bbc9

I don't think the spec allows 'null' to mean reverse natural ordering and natural ordering.

Jason




> Date: Tue, 24 Jan 2012 14:18:55 -0800
> From: darryl.mocek at oracle.com
> To: jason_mehrens at hotmail.com
> CC: core-libs-dev at openjdk.java.net
> Subject: Re: Code Review Request Bug #7129185:(coll) Please add Collections.emptyNavigableSet()
>
> emptyNavigableSet().descendingSet().comparator() returns null. Isn't
> this what's expected? The bounds checking should be correct.
>
> Darryl


From jim.holmlund at sun.com Tue Jan 24 23:52:32 2012
From: jim.holmlund at sun.com (jim.holmlund at sun.com)
Date: Tue, 24 Jan 2012 23:52:32 +0000
Subject: hg: jdk8/tl/langtools: 7126832:
com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager
cannot be cast
Message-ID: <20120124235237.28C944717A@hg.openjdk.java.net>

Changeset: ac36176b7de0
Author: jjh
Date: 2012-01-24 15:51 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ac36176b7de0

7126832: com.sun.tools.javac.api.ClientCodeWrapper$WrappedJavaFileManager cannot be cast
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java
! src/share/classes/com/sun/tools/javac/main/Main.java
+ test/tools/javah/T7126832/T7126832.java
+ test/tools/javah/T7126832/java.java



From jim.holmlund at sun.com Wed Jan 25 00:31:39 2012
From: jim.holmlund at sun.com (jim.holmlund at sun.com)
Date: Wed, 25 Jan 2012 00:31:39 +0000
Subject: hg: jdk8/tl/langtools: 7129225: javac fails to run annotation
processors when star import of package of gensrc
Message-ID: <20120125003141.674D94717B@hg.openjdk.java.net>

Changeset: d16b464e742c
Author: jjh
Date: 2012-01-24 16:31 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d16b464e742c

7129225: javac fails to run annotation processors when star import of package of gensrc
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
+ test/tools/javac/7129225/Anno.java
+ test/tools/javac/7129225/AnnoProcessor.java
+ test/tools/javac/7129225/NegTest.ref
+ test/tools/javac/7129225/TestImportStar.java
+ test/tools/javac/7129225/TestImportStar.ref



From david.holmes at oracle.com Wed Jan 25 04:22:20 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Jan 2012 14:22:20 +1000
Subject: RFR 7132378: Race in FutureTask if used with explicit set ( not
Runnable )
In-Reply-To: <4F1EFEDD.5010600@cs.oswego.edu>
References: <4F1D7C1D.6030902@oracle.com> <4F1E1B92.5000503@oracle.com>
<4F1E8F60.7000103@oracle.com> <4F1EFEDD.5010600@cs.oswego.edu>
Message-ID: <4F1F837C.80806@oracle.com>

On 25/01/2012 4:56 AM, Doug Lea wrote:
> Sorry for delay; swamped...
>
> On 01/24/12 06:00, Chris Hegarty wrote:
>
>>> I don't understand the purpose of handlePossibleCancellationInterrupt.
>>> Given it doesn't clear the interrupt state why does it need to wait?
>>
>> Yes, this is true. I can't see any need for it to wait now since it
>> doesn't
>> clear the threads interrupt state. I felt this was more of a
>> marker/place holder
>> to determine the correct course of action here.
>
> The underlying issue is that when run() etc are directly
> invoked in the same thread as the caller, we (should? must?)
> ensure that the results of Future status method invocations by that
> caller agree with each other, even if racing with an asynchronous
> cancel/interrupt. The only possible inconsistency is the rare case
> where we know that the task will be cancelled but hasn't been interrupted

Okay I get it now.

> yet. So we just wait out the transient state. While it is
> arguably legal not to do this, adding this precaution
> will probably avoid getting a bug report about this someday.
> As the further comment mentions, it would be even
> nicer to force Thread interrupt status to agree with task status,
> but we can't actually do this, so I left a note in case
> anyone is tempted.

Expected/desired semantics here are somewhat vague.

David
-----

>>
>> Doug,
>> I added a new test for this. It fails about 1 in every 3-4 runs on
>> some of the boxes I have access to. Is this useful? Would you want to
>> take it into your CVS?
>
> Thanks. I had made some tests for this but at the moment don't see them.
> If you'd like to send me what you have, I'll locate others and
> add to the jtreg test.
>
> -Doug


From brandon.passanisi at oracle.com Wed Jan 25 07:03:05 2012
From: brandon.passanisi at oracle.com (Brandon Passanisi)
Date: Tue, 24 Jan 2012 23:03:05 -0800
Subject: Code review request for #6469160, #7088271
In-Reply-To: <4F1E4819.5080505@oracle.com>
References: <4F19B04C.8040104@oracle.com> <4F1E4819.5080505@oracle.com>
Message-ID: <4F1FA929.4020303@oracle.com>

Hi David. Thank you for your review comments. My answers to your
questions are below:

On 1/23/2012 9:56 PM, David Holmes wrote:
> Hi Brandon,
>
> On 21/01/2012 4:19 AM, Brandon Passanisi wrote:
>> Resending again...
>>
>> Hello core-libs. I was wondering of somebody could be please review the
>> following fix for #6469160 and #7088271. The changes in the webrev fix
>> both bugs. Information is below:
>>
>> Webrev URL: http://cr.openjdk.java.net/~bpassani/6469160_7088271/1/
>> <http://cr.openjdk.java.net/%7Ebpassani/6469160_7088271/1/>
>> Bug #6469160: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6469160
>> Bug #7088271: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7088271
>
> Seems to me that 7088271 should be closed as a duplicate of 6469160.
>

Ok, I'll go ahead and close 7088271 as a duplicate.


>> Both bugs uncover the current behavior where using a 0 or 1 precision
>> value with a float zero causes an ArrayIndexOutOfBoundsException. The
>> current code in FormattedFloatingDecimal.java interprets the float zero
>> as "0.0" in the case where precision is 0 or 1 and returns the length of
>> it's characters as 3. Later in Formatter.addZeros(), the character array
>> "0.0" is passed in, but a new array of only 1 character is allocated.
>> When an System.arraycopy() is performed, the
>> ArrayIndexOutOfBoundsException occurs. In fact, when run with "-esa" an
>> AssertionError occurs at "assert (outPrec <= prec);" on line 3393 of
>> Formatter.java. The fix is for FormatedFloatingDecimal.java to interpret
>> the float zero as a single "0" because of the precision being set to 0
>> or 1.
>
> This isn't an area I'm familiar with so please excuse me if I'm
> missing something obvious. I'm confused about the fix in regards to
> the two cases reported in the CRs. In one case we have:
>
> String.format("%3.0g", 0.0);
>
> where the precision is 0. But in your fix you only special case the
> situation where precision is 1:
>
> + if (digits.length == 1 && digits[0] == '0'
> + && precision == 1) {
> + // When the number is zero and precision is 1, set the
> + // precision to 0 so that a decimal point and digits
> + // are not added by code later in this method.
> + precision--;
> + } else {
>
> so I don't understand how this fixes %3.0g ?
>
> More generally it is not clear to me that putting in this special case
> is the right way to fix this. Though I admit I don't really understand
> what the specification requires when you give a precision of 0 with a
> 'g' conversion:
>
> "If the conversion is 'g' or 'G', then the precision is the total
> number of digits in the resulting magnitude after rounding."
>
> So we asked for zero digits? What should that mean?

The Formatter javadoc, within the "Float and Double" section, describes
the following regarding a value of 0 for precision and the 'g'/'G'
conversion [1]:

"If the precision is 0, then it is taken to be 1"

The following code block within Formatter.java near line 3278 is run to
do this:

if (precision == -1)
prec = 6;
else if (precision == 0)
prec = 1;

And the precision value "prec" is given to FormattedFloatingDecimal.
Therefore, when this particular error condition is seen and the proposed
code fix is reached in FormattedFloatingDecimal.java, the precision will
be 1. So, the proposed code fix ends up supporting a precision value of
0 and 1.


[1]: http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html


Thanks.

>
> David
> -----
>
>> Since java has been throwing exceptions in these cases, I consulted with
>> the output of C's printf to make sure that the outputted strings are the
>> same. I updated the Formatter's Basic-X template of tests with a little
>> over 20 test format strings that were causing exceptions without the
>> change and the output of each is compared with the output from C's
>> printf with the same format string. And, I ran all of the Basic-X tests
>> to make sure there weren't any regressions in behavior.
>>
>> Thanks.

--
Oracle <http://www.oracle.com>
Brandon Passanisi | Principle Member of Technical Staff


Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment


From david.holmes at oracle.com Wed Jan 25 07:58:27 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Jan 2012 17:58:27 +1000
Subject: Code review request for #6469160, #7088271
In-Reply-To: <4F1FA929.4020303@oracle.com>
References: <4F19B04C.8040104@oracle.com> <4F1E4819.5080505@oracle.com>
<4F1FA929.4020303@oracle.com>
Message-ID: <4F1FB623.8080905@oracle.com>

Hi Brandon,

On 25/01/2012 5:03 PM, Brandon Passanisi wrote:
> Hi David. Thank you for your review comments. My answers to your
> questions are below:
>
> On 1/23/2012 9:56 PM, David Holmes wrote:
>> More generally it is not clear to me that putting in this special case
>> is the right way to fix this. Though I admit I don't really understand
>> what the specification requires when you give a precision of 0 with a
>> 'g' conversion:
>>
>> "If the conversion is 'g' or 'G', then the precision is the total
>> number of digits in the resulting magnitude after rounding."
>>
>> So we asked for zero digits? What should that mean?
>
> The Formatter javadoc, within the "Float and Double" section, describes
> the following regarding a value of 0 for precision and the 'g'/'G'
> conversion [1]:
>
> "If the precision is 0, then it is taken to be 1"

Ah! Thanks. I hadn't seen that (wish they wouldn't split up the spec for
this across different sections!).

Okay that explains the 0/1 situation.

But that makes me question the "rightness" of the fix even more. We took
steps to change a precision of 0 to 1, but then the fix changes it back
to 0 because otherwise something else breaks. Seems to me that the
"something else" that handles the precision of 1 incorrectly is the code
that really needs to be fixed. Further it suggest that there may be
assumptions in later code that precision is in fact never 0.

David
-----


> The following code block within Formatter.java near line 3278 is run to
> do this:
>
> if (precision == -1)
> prec = 6;
> else if (precision == 0)
> prec = 1;
>
> And the precision value "prec" is given to FormattedFloatingDecimal.
> Therefore, when this particular error condition is seen and the proposed
> code fix is reached in FormattedFloatingDecimal.java, the precision will
> be 1. So, the proposed code fix ends up supporting a precision value of
> 0 and 1.
>
>
> [1]: http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html
>
>
> Thanks.
>
>>
>> David
>> -----
>>
>>> Since java has been throwing exceptions in these cases, I consulted with
>>> the output of C's printf to make sure that the outputted strings are the
>>> same. I updated the Formatter's Basic-X template of tests with a little
>>> over 20 test format strings that were causing exceptions without the
>>> change and the output of each is compared with the output from C's
>>> printf with the same format string. And, I ran all of the Basic-X tests
>>> to make sure there weren't any regressions in behavior.
>>>
>>> Thanks.
>


From david.holmes at oracle.com Wed Jan 25 07:58:42 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Jan 2012 17:58:42 +1000
Subject: Code review request for #6469160, #7088271
In-Reply-To: <4F1FA929.4020303@oracle.com>
References: <4F19B04C.8040104@oracle.com> <4F1E4819.5080505@oracle.com>
<4F1FA929.4020303@oracle.com>
Message-ID: <4F1FB632.4070802@oracle.com>

Hi Brandon,

On 25/01/2012 5:03 PM, Brandon Passanisi wrote:
> Hi David. Thank you for your review comments. My answers to your
> questions are below:
>
> On 1/23/2012 9:56 PM, David Holmes wrote:
>> More generally it is not clear to me that putting in this special case
>> is the right way to fix this. Though I admit I don't really understand
>> what the specification requires when you give a precision of 0 with a
>> 'g' conversion:
>>
>> "If the conversion is 'g' or 'G', then the precision is the total
>> number of digits in the resulting magnitude after rounding."
>>
>> So we asked for zero digits? What should that mean?
>
> The Formatter javadoc, within the "Float and Double" section, describes
> the following regarding a value of 0 for precision and the 'g'/'G'
> conversion [1]:
>
> "If the precision is 0, then it is taken to be 1"

Ah! Thanks. I hadn't seen that (wish they wouldn't split up the spec for
this across different sections!).

Okay that explains the 0/1 situation.

But that makes me question the "rightness" of the fix even more. We took
steps to change a precision of 0 to 1, but then the fix changes it back
to 0 because otherwise something else breaks. Seems to me that the
"something else" that handles the precision of 1 incorrectly is the code
that really needs to be fixed. Further it suggest that there may be
assumptions in later code that precision is in fact never 0.

David
-----


> The following code block within Formatter.java near line 3278 is run to
> do this:
>
> if (precision == -1)
> prec = 6;
> else if (precision == 0)
> prec = 1;
>
> And the precision value "prec" is given to FormattedFloatingDecimal.
> Therefore, when this particular error condition is seen and the proposed
> code fix is reached in FormattedFloatingDecimal.java, the precision will
> be 1. So, the proposed code fix ends up supporting a precision value of
> 0 and 1.
>
>
> [1]: http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html
>
>
> Thanks.
>
>>
>> David
>> -----
>>
>>> Since java has been throwing exceptions in these cases, I consulted with
>>> the output of C's printf to make sure that the outputted strings are the
>>> same. I updated the Formatter's Basic-X template of tests with a little
>>> over 20 test format strings that were causing exceptions without the
>>> change and the output of each is compared with the output from C's
>>> printf with the same format string. And, I ran all of the Basic-X tests
>>> to make sure there weren't any regressions in behavior.
>>>
>>> Thanks.
>


From Alan.Bateman at oracle.com Wed Jan 25 18:21:05 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Jan 2012 18:21:05 +0000
Subject: POSIX compatibility change for including wait.h in
UNIXProcess_md.c
In-Reply-To: <4F0FDF85.1060406@linux.vnet.ibm.com>
References: <4F0EA969.5000600@linux.vnet.ibm.com> <4F0EC525.4070507@oracle.com>
<4F0FDF85.1060406@linux.vnet.ibm.com>
Message-ID: <4F204811.6070707@oracle.com>

On 13/01/2012 07:38, Jonathan Lu wrote:
> Hello David and Alan,
>
> Thanks for the review.
> Do you plan to push it?
>
I think we forgot to create a bug for this, I've created it now:

7133301: (process) UNIXProcess_md.c should include sys/wait.h rather
than wait.h

I don't mind pushing it for you but maybe this is something that Neil
wants to do?

-Alan


From jim.holmlund at sun.com Wed Jan 25 20:20:33 2012
From: jim.holmlund at sun.com (jim.holmlund at sun.com)
Date: Wed, 25 Jan 2012 20:20:33 +0000
Subject: hg: jdk8/tl/langtools: 7133314: The regression test for 7129225 fails
when run with jtreg -samevm or jtreg -agentvm
Message-ID: <20120125202036.616FC4719D@hg.openjdk.java.net>

Changeset: 332dfa0f91df
Author: jjh
Date: 2012-01-25 12:20 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/332dfa0f91df

7133314: The regression test for 7129225 fails when run with jtreg -samevm or jtreg -agentvm
Reviewed-by: jjg

! test/tools/javac/7129225/AnnoProcessor.java
! test/tools/javac/7129225/NegTest.ref
! test/tools/javac/7129225/TestImportStar.java
! test/tools/javac/7129225/TestImportStar.ref



From joe.darcy at oracle.com Thu Jan 26 04:37:13 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 25 Jan 2012 20:37:13 -0800
Subject: Using unsigned library work in the JDK
Message-ID: <4F20D879.8010800@oracle.com>

Hello,

As a follow-up to the recent push of unsigned library support in the JDK
[1], I grepped -i for "0xff" in the JDK code base to look for candidate
locations to use the new methods. I choose to first tackle some jar/zip
code.

Sherman, can you review the changes below?

diff -r 303b67074666 src/share/classes/java/util/jar/JarOutputStream.java
--- a/src/share/classes/java/util/jar/JarOutputStream.java Tue Jan 24
15:13:27 2012 -0500
+++ b/src/share/classes/java/util/jar/JarOutputStream.java Wed Jan 25
20:31:05 2012 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -135,7 +135,7 @@
* The bytes are assumed to be in Intel (little-endian) byte order.
*/
private static int get16(byte[] b, int off) {
- return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8);
+ return Byte.toUnsignedInt(b[off]) | (
Byte.toUnsignedInt(b[off+1]) << 8);
}

/*
diff -r 303b67074666 src/share/classes/java/util/jar/Manifest.java
--- a/src/share/classes/java/util/jar/Manifest.java Tue Jan 24
15:13:27 2012 -0500
+++ b/src/share/classes/java/util/jar/Manifest.java Wed Jan 25
20:31:05 2012 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -339,7 +339,7 @@
return -1;
}
}
- return buf[pos++] & 0xff;
+ return Byte.toUnsignedInt(buf[pos++]);
}

public int read(byte[] b, int off, int len) throws IOException {
diff -r 303b67074666
src/share/classes/java/util/zip/InflaterInputStream.java
--- a/src/share/classes/java/util/zip/InflaterInputStream.java Tue
Jan 24 15:13:27 2012 -0500
+++ b/src/share/classes/java/util/zip/InflaterInputStream.java Wed
Jan 25 20:31:05 2012 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -119,7 +119,7 @@
*/
public int read() throws IOException {
ensureOpen();
- return read(singleByteBuf, 0, 1) == -1 ? -1 : singleByteBuf[0]
& 0xff;
+ return read(singleByteBuf, 0, 1) == -1 ? -1 :
Byte.toUnsignedInt(singleByteBuf[0]);
}

/**
diff -r 303b67074666 src/share/classes/java/util/zip/ZipInputStream.java
--- a/src/share/classes/java/util/zip/ZipInputStream.java Tue Jan 24
15:13:27 2012 -0500
+++ b/src/share/classes/java/util/zip/ZipInputStream.java Wed Jan 25
20:31:05 2012 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -435,7 +435,7 @@
* The bytes are assumed to be in Intel (little-endian) byte order.
*/
private static final int get16(byte b[], int off) {
- return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8);
+ return Byte.toUnsignedInt(b[off]) |
(Byte.toUnsignedInt(b[off+1]) << 8);
}

/*
diff -r 303b67074666
src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
---
a/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
Tue Jan 24 15:13:27 2012 -0500
+++
b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
Wed Jan 25 20:31:05 2012 -0800
@@ -185,11 +185,11 @@
*/
///////////////////////////////////////////////////////
static final int CH(byte[] b, int n) {
- return b[n] & 0xff;
+ return Byte.toUnsignedInt(b[n]);
}

static final int SH(byte[] b, int n) {
- return (b[n] & 0xff) | ((b[n + 1] & 0xff) << 8);
+ return Byte.toUnsignedInt(b[n]) | (Byte.toUnsignedInt(b[n + 1])
<< 8);
}

static final long LG(byte[] b, int n) {

If the changes look good, I'll file a bug for them, etc.

In case other people want to look over candidates sites in different
areas, I've included the list of JDK files using "0xff" below.

Thanks,

-Joe

[1] 4504839: Java libraries should provide support for unsigned integer
arithmetic
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008926.html

./solaris/classes/java/util/prefs/FileSystemPreferences.java
./solaris/classes/sun/print/AttributeClass.java
./solaris/classes/sun/net/sdp/SdpProvider.java
./solaris/classes/sun/awt/X11/XIconInfo.java
./solaris/classes/sun/awt/X11/XKeySymConstants.java
./solaris/classes/sun/awt/X11/MotifDnDConstants.java
./solaris/classes/sun/awt/X11/XIconWindow.java
./solaris/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java
./solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java
./solaris/classes/sun/awt/X11/XAtom.java
./solaris/classes/sun/awt/X11/MotifColorUtilities.java
./solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java
./solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java
./solaris/classes/sun/awt/X11/Native.java
./solaris/classes/sun/awt/X11/XKeysym.java
./solaris/classes/sun/awt/X11/XToolkit.java
./solaris/classes/sun/awt/X11/XDnDConstants.java
./solaris/classes/sun/awt/X11/XWM.java
./solaris/classes/sun/awt/X11/XWindowPeer.java
./solaris/classes/sun/awt/X11GraphicsConfig.java
./solaris/classes/sun/awt/motif/X11KSC5601.java
./solaris/classes/sun/awt/motif/X11GB2312.java
./solaris/classes/sun/awt/motif/X11CNS11643.java
./solaris/classes/sun/awt/motif/X11JIS0201.java
./solaris/classes/sun/awt/X11CustomCursor.java
./solaris/classes/sun/awt/XSettings.java
./solaris/classes/sun/nio/fs/UnixPath.java
./solaris/classes/sun/nio/fs/UnixUriUtils.java
./solaris/classes/sun/nio/cs/ext/CompoundTextSupport.java
./solaris/classes/sun/nio/cs/ext/COMPOUND_TEXT_Decoder.java
./solaris/classes/sun/font/XMap.java
./solaris/classes/sun/font/XRGlyphCacheEntry.java
./solaris/classes/sun/font/NativeStrike.java
./solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
./solaris/classes/sun/java2d/xr/XRSurfaceData.java
./solaris/classes/sun/java2d/xr/XRPaints.java
./solaris/classes/sun/java2d/xr/XRColor.java
./solaris/classes/sun/java2d/xr/XRCompositeManager.java
./solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java
./solaris/classes/sun/java2d/x11/X11SurfaceDataProxy.java
./solaris/classes/sun/java2d/x11/X11SurfaceData.java
./solaris/classes/sun/tools/attach/SolarisVirtualMachine.java
./solaris/classes/sun/tools/attach/LinuxVirtualMachine.java
./windows/classes/java/util/prefs/WindowsPreferences.java
./windows/classes/com/sun/tools/jdi/SharedMemoryTransportService.java
./windows/classes/sun/awt/Win32GraphicsConfig.java
./windows/classes/sun/awt/windows/WPathGraphics.java
./windows/classes/sun/awt/windows/WCustomCursor.java
./windows/classes/sun/awt/windows/WWindowPeer.java
./windows/classes/sun/awt/windows/WTrayIconPeer.java
./windows/classes/sun/awt/windows/WPrinterJob.java
./windows/classes/sun/nio/fs/WindowsFileAttributes.java
./windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java
./windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java
./windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java
./windows/classes/sun/tools/attach/WindowsVirtualMachine.java
./share/demo/applets/WireFrame/ThreeD.java
./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java
./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java
./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java
./share/demo/jfc/Font2DTest/FontPanel.java
./share/demo/jfc/Font2DTest/RangeMenu.java
./share/demo/jfc/Font2DTest/Font2DTest.java
./share/demo/jfc/CodePointIM/CodePointInputMethod.java
./share/demo/java2d/J2DBench/src/j2dbench/tests/PixelTests.java
./share/demo/java2d/J2DBench/src/j2dbench/tests/iio/IIOTests.java
./share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java
./share/classes/java/rmi/dgc/VMID.java
./share/classes/java/beans/XMLEncoder.java
./share/classes/java/net/URLConnection.java
./share/classes/java/net/Inet6Address.java
./share/classes/java/net/Inet4Address.java
./share/classes/java/net/DatagramPacket.java
./share/classes/java/net/SocketInputStream.java
./share/classes/java/net/MulticastSocket.java
./share/classes/java/net/SocksSocketImpl.java
./share/classes/java/net/SocketPermission.java
./share/classes/java/net/DatagramSocket.java
./share/classes/java/net/ServerSocket.java
./share/classes/java/net/InetSocketAddress.java
./share/classes/java/net/URI.java
./share/classes/java/lang/Character.java
./share/classes/java/lang/Byte.java
./share/classes/java/lang/Float.java
./share/classes/java/lang/Double.java
./share/classes/java/lang/Long.java
./share/classes/java/lang/CharacterData.java
./share/classes/java/lang/String.java
./share/classes/java/lang/invoke/MethodType.java
./share/classes/java/lang/invoke/MethodTypeForm.java
./share/classes/java/lang/invoke/MethodHandle.java
./share/classes/java/lang/invoke/MemberName.java
./share/classes/java/lang/CharacterName.java
./share/classes/java/lang/Integer.java
./share/classes/java/lang/Short.java
./share/classes/java/text/BreakIterator.java
./share/classes/java/text/CollationElementIterator.java
./share/classes/java/text/RuleBasedCollator.java
./share/classes/java/text/RBCollationTables.java
./share/classes/java/text/SimpleDateFormat.java
./share/classes/java/text/RBTableBuilder.java
./share/classes/java/io/ByteArrayOutputStream.java
./share/classes/java/io/DataOutputStream.java
./share/classes/java/io/DataInputStream.java
./share/classes/java/io/Reader.java
./share/classes/java/io/StringBufferInputStream.java
./share/classes/java/io/PushbackInputStream.java
./share/classes/java/io/Bits.java
./share/classes/java/io/DataOutput.java
./share/classes/java/io/RandomAccessFile.java
./share/classes/java/io/BufferedReader.java
./share/classes/java/io/ObjectInputStream.java
./share/classes/java/io/ByteArrayInputStream.java
./share/classes/java/io/DataInput.java
./share/classes/java/io/BufferedInputStream.java
./share/classes/java/io/ObjectStreamClass.java
./share/classes/java/io/ObjectOutputStream.java
./share/classes/java/io/PipedInputStream.java
./share/classes/java/util/regex/UnicodeProp.java
./share/classes/java/util/regex/Pattern.java
./share/classes/java/util/regex/ASCII.java
./share/classes/java/util/Properties.java
./share/classes/java/util/jar/JarOutputStream.java
./share/classes/java/util/jar/Manifest.java
./share/classes/java/util/jar/JarEntry.java
./share/classes/java/util/BitSet.java
./share/classes/java/util/concurrent/Phaser.java
./share/classes/java/util/concurrent/Exchanger.java
./share/classes/java/util/concurrent/ForkJoinPool.java
./share/classes/java/util/concurrent/ConcurrentHashMap.java
./share/classes/java/util/concurrent/ForkJoinWorkerThread.java
./share/classes/java/util/zip/DeflaterOutputStream.java
./share/classes/java/util/zip/InflaterInputStream.java
./share/classes/java/util/zip/GZIPInputStream.java
./share/classes/java/util/zip/DeflaterInputStream.java
./share/classes/java/util/zip/ZipConstants64.java
./share/classes/java/util/zip/ZipInputStream.java
./share/classes/java/util/zip/ZipOutputStream.java
./share/classes/java/util/zip/ZipFile.java
./share/classes/java/util/zip/CRC32.java
./share/classes/java/util/zip/Adler32.java
./share/classes/java/util/zip/GZIPOutputStream.java
./share/classes/java/util/zip/ZipEntry.java
./share/classes/java/util/UUID.java
./share/classes/java/util/prefs/Base64.java
./share/classes/java/security/SecureRandom.java
./share/classes/java/awt/Color.java
./share/classes/java/awt/GradientPaintContext.java
./share/classes/java/awt/TexturePaintContext.java
./share/classes/java/awt/AlphaComposite.java
./share/classes/java/awt/event/KeyEvent.java
./share/classes/java/awt/SystemColor.java
./share/classes/java/awt/image/DataBufferByte.java
./share/classes/java/awt/image/ByteLookupTable.java
./share/classes/java/awt/image/MultiPixelPackedSampleModel.java
./share/classes/java/awt/image/ComponentSampleModel.java
./share/classes/java/awt/image/ComponentColorModel.java
./share/classes/java/awt/image/DataBuffer.java
./share/classes/java/awt/image/DataBufferUShort.java
./share/classes/java/awt/image/SinglePixelPackedSampleModel.java
./share/classes/java/awt/image/BufferedImageFilter.java
./share/classes/java/awt/image/RescaleOp.java
./share/classes/java/awt/image/ColorConvertOp.java
./share/classes/java/awt/image/IndexColorModel.java
./share/classes/java/awt/image/AreaAveragingScaleFilter.java
./share/classes/java/awt/image/BandedSampleModel.java
./share/classes/java/awt/image/BufferedImage.java
./share/classes/java/awt/image/ShortLookupTable.java
./share/classes/java/awt/image/DirectColorModel.java
./share/classes/java/awt/image/RGBImageFilter.java
./share/classes/java/awt/image/PixelGrabber.java
./share/classes/java/awt/image/ColorModel.java
./share/classes/java/awt/MultipleGradientPaint.java
./share/classes/java/awt/color/ICC_ProfileRGB.java
./share/classes/java/awt/color/ICC_ProfileGray.java
./share/classes/java/awt/color/ICC_Profile.java
./share/classes/java/awt/color/ICC_ColorSpace.java
./share/classes/java/awt/MultipleGradientPaintContext.java
./share/classes/java/awt/FontMetrics.java
./share/classes/java/awt/font/NumericShaper.java
./share/classes/java/awt/GradientPaint.java
./share/classes/java/nio/Bits.java
./share/classes/java/nio/channels/Channels.java
./share/classes/java/math/BigInteger.java
./share/classes/com/sun/beans/decoder/LongElementHandler.java
./share/classes/com/sun/jmx/snmp/SnmpIpAddress.java
./share/classes/com/sun/jmx/snmp/SnmpString.java
./share/classes/com/sun/jmx/snmp/IPAcl/ASCII_CharStream.java
./share/classes/com/sun/jmx/snmp/IPAcl/ParserTokenManager.java
./share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java
./share/classes/com/sun/jmx/snmp/SnmpEngineId.java
./share/classes/com/sun/jmx/snmp/SnmpMsg.java
./share/classes/com/sun/java/swing/plaf/gtk/GTKColorType.java
./share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java
./share/classes/com/sun/java/swing/plaf/gtk/Metacity.java
./share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java
./share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
./share/classes/com/sun/java/util/jar/pack/PackageWriter.java
./share/classes/com/sun/java/util/jar/pack/Coding.java
./share/classes/com/sun/java/util/jar/pack/PackageReader.java
./share/classes/com/sun/java/util/jar/pack/Histogram.java
./share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java
./share/classes/com/sun/java/util/jar/pack/PopulationCoding.java
./share/classes/com/sun/java/util/jar/pack/Attribute.java
./share/classes/com/sun/java/util/jar/pack/Fixups.java
./share/classes/com/sun/java/util/jar/pack/BandStructure.java
./share/classes/com/sun/java/util/jar/pack/Instruction.java
./share/classes/com/sun/net/httpserver/BasicAuthenticator.java
./share/classes/com/sun/crypto/provider/BlowfishCrypt.java
./share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
./share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
./share/classes/com/sun/crypto/provider/ISO10126Padding.java
./share/classes/com/sun/crypto/provider/RC2Crypt.java
./share/classes/com/sun/crypto/provider/AESCrypt.java
./share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java
./share/classes/com/sun/crypto/provider/ARCFOURCipher.java
./share/classes/com/sun/crypto/provider/PKCS5Padding.java
./share/classes/com/sun/crypto/provider/RC2Parameters.java
./share/classes/com/sun/security/ntlm/NTLM.java
./share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java
./share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
./share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
./share/classes/com/sun/imageio/plugins/png/RowFilter.java
./share/classes/com/sun/imageio/plugins/png/PNGMetadata.java
./share/classes/com/sun/imageio/plugins/jpeg/DHTMarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/DQTMarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/AdobeMarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/DRIMarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReaderSpi.java
./share/classes/com/sun/imageio/plugins/jpeg/JPEGBuffer.java
./share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
./share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/MarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java
./share/classes/com/sun/imageio/plugins/gif/GIFImageMetadata.java
./share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
./share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java
./share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java
./share/classes/com/sun/imageio/plugins/common/LZWCompressor.java
./share/classes/com/sun/imageio/plugins/common/PaletteBuilder.java
./share/classes/com/sun/imageio/plugins/common/LZWStringTable.java
./share/classes/com/sun/imageio/plugins/common/ImageUtil.java
./share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java
./share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java
./share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java
./share/classes/com/sun/media/sound/AudioFloatConverter.java
./share/classes/com/sun/media/sound/StandardMidiFileWriter.java
./share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java
./share/classes/com/sun/media/sound/SunFileReader.java
./share/classes/com/sun/media/sound/MidiInDevice.java
./share/classes/com/sun/media/sound/FastSysexMessage.java
./share/classes/com/sun/media/sound/SunFileWriter.java
./share/classes/com/sun/media/sound/SF2Region.java
./share/classes/com/sun/media/sound/AlawCodec.java
./share/classes/com/sun/media/sound/MidiOutDevice.java
./share/classes/com/sun/media/sound/UlawCodec.java
./share/classes/com/sun/media/sound/AudioFloatFormatConverter.java
./share/classes/com/sun/media/sound/FastShortMessage.java
./share/classes/com/sun/media/sound/SoftJitterCorrector.java
./share/classes/com/sun/media/sound/SoftMixingMainMixer.java
./share/classes/com/sun/media/sound/SoftMainMixer.java
./share/classes/com/sun/media/sound/RIFFWriter.java
./share/classes/com/sun/media/sound/StandardMidiFileReader.java
./share/classes/com/sun/media/sound/SoftTuning.java
./share/classes/com/sun/media/sound/SoftMixingClip.java
./share/classes/com/sun/media/sound/WaveExtensibleFileReader.java
./share/classes/com/sun/media/sound/ModelByteBufferWavetable.java
./share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java
./share/classes/com/sun/media/sound/SoftSynthesizer.java
./share/classes/com/sun/media/sound/PortMixer.java
./share/classes/com/sun/media/sound/MidiUtils.java
./share/classes/com/sun/media/sound/RealTimeSequencer.java
./share/classes/com/sun/media/sound/AbstractMidiDevice.java
./share/classes/com/sun/jndi/dns/Header.java
./share/classes/com/sun/jndi/dns/DnsClient.java
./share/classes/com/sun/jndi/dns/ResourceRecord.java
./share/classes/com/sun/jndi/dns/DnsName.java
./share/classes/com/sun/jndi/ldap/BerEncoder.java
./share/classes/com/sun/jndi/ldap/BerDecoder.java
./share/classes/com/sun/jndi/ldap/Connection.java
./share/classes/com/sun/jndi/ldap/sasl/SaslOutputStream.java
./share/classes/com/sun/jndi/ldap/sasl/SaslInputStream.java
./share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java
./share/classes/com/sun/tools/hat/internal/model/JavaByte.java
./share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java
./share/classes/com/sun/tools/hat/internal/util/Misc.java
./share/classes/com/sun/tools/hat/internal/parser/HprofReader.java
./share/classes/com/sun/tools/example/debug/expr/ASCII_UCodeESC_CharStream.java
./share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java
./share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java
./share/classes/com/sun/tools/example/debug/gui/Icons.java
./share/classes/com/sun/tools/example/debug/tty/Commands.java
./share/classes/com/sun/tools/jdi/Packet.java
./share/classes/com/sun/tools/jdi/TargetVM.java
./share/classes/com/sun/tools/jdi/PacketStream.java
./share/classes/com/sun/tools/jdi/SocketTransportService.java
./share/classes/sun/rmi/rmic/newrmic/jrmp/RemoteClass.java
./share/classes/sun/rmi/rmic/RemoteClass.java
./share/classes/sun/rmi/server/Util.java
./share/classes/sun/rmi/transport/tcp/MultiplexInputStream.java
./share/classes/sun/rmi/transport/proxy/CGIHandler.java
./share/classes/sun/print/PrinterGraphicsConfig.java
./share/classes/sun/print/PathGraphics.java
./share/classes/sun/print/PSPrinterJob.java
./share/classes/sun/net/util/IPAddressUtil.java
./share/classes/sun/net/ftp/impl/FtpClient.java
./share/classes/sun/net/httpserver/SSLStreams.java
./share/classes/sun/net/httpserver/LeftOverInputStream.java
./share/classes/sun/net/httpserver/Request.java
./share/classes/sun/net/idn/Punycode.java
./share/classes/sun/net/idn/StringPrep.java
./share/classes/sun/net/spi/nameservice/dns/DNSNameService.java
./share/classes/sun/net/www/http/ChunkedInputStream.java
./share/classes/sun/net/www/ParseUtil.java
./share/classes/sun/text/IntHashtable.java
./share/classes/sun/text/UCompactIntArray.java
./share/classes/sun/text/normalizer/UCharacterProperty.java
./share/classes/sun/text/normalizer/UCharacter.java
./share/classes/sun/text/normalizer/Utility.java
./share/classes/sun/text/normalizer/NormalizerBase.java
./share/classes/sun/text/normalizer/NormalizerDataReader.java
./share/classes/sun/text/normalizer/NormalizerImpl.java
./share/classes/sun/text/normalizer/UCharacterIterator.java
./share/classes/sun/text/normalizer/UnicodeSet.java
./share/classes/sun/text/bidi/BidiBase.java
./share/classes/sun/text/SupplementaryCharacterData.java
./share/classes/sun/text/CompactByteArray.java
./share/classes/sun/misc/UCEncoder.java
./share/classes/sun/misc/FormattedFloatingDecimal.java
./share/classes/sun/misc/CRC16.java
./share/classes/sun/misc/UCDecoder.java
./share/classes/sun/misc/ProxyGenerator.java
./share/classes/sun/misc/BASE64Decoder.java
./share/classes/sun/misc/UUDecoder.java
./share/classes/sun/misc/FloatingDecimal.java
./share/classes/sun/misc/HexDumpEncoder.java
./share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java
./share/classes/sun/util/calendar/ZoneInfoFile.java
./share/classes/sun/security/krb5/EncryptedData.java
./share/classes/sun/security/krb5/internal/ccache/CCacheOutputStream.java
./share/classes/sun/security/krb5/internal/crypto/crc32.java
./share/classes/sun/security/krb5/internal/crypto/Des.java
./share/classes/sun/security/krb5/internal/crypto/dk/ArcFourCrypto.java
./share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java
./share/classes/sun/security/krb5/internal/crypto/dk/AesDkCrypto.java
./share/classes/sun/security/krb5/internal/crypto/Crc32CksumType.java
./share/classes/sun/security/krb5/internal/util/KrbDataOutputStream.java
./share/classes/sun/security/krb5/internal/util/KrbDataInputStream.java
./share/classes/sun/security/krb5/internal/NetClient.java
./share/classes/sun/security/krb5/internal/LocalSeqNumber.java
./share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java
./share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java
./share/classes/sun/security/pkcs11/SunPKCS11.java
./share/classes/sun/security/pkcs11/wrapper/CK_VERSION.java
./share/classes/sun/security/pkcs11/wrapper/Functions.java
./share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java
./share/classes/sun/security/pkcs11/P11Key.java
./share/classes/sun/security/pkcs11/P11Util.java
./share/classes/sun/security/x509/X509Key.java
./share/classes/sun/security/jgss/krb5/MessageToken_v2.java
./share/classes/sun/security/jgss/krb5/MessageToken.java
./share/classes/sun/security/jgss/wrapper/GSSNameElement.java
./share/classes/sun/security/jgss/GSSNameImpl.java
./share/classes/sun/security/jgss/GSSToken.java
./share/classes/sun/security/util/Debug.java
./share/classes/sun/security/util/ByteArrayLexOrder.java
./share/classes/sun/security/util/BitArray.java
./share/classes/sun/security/util/DerOutputStream.java
./share/classes/sun/security/util/Cache.java
./share/classes/sun/security/util/DerValue.java
./share/classes/sun/security/util/DerIndefLenConverter.java
./share/classes/sun/security/util/DerInputStream.java
./share/classes/sun/security/util/DerInputBuffer.java
./share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
./share/classes/sun/security/ssl/OutputRecord.java
./share/classes/sun/security/ssl/ProtocolVersion.java
./share/classes/sun/security/ssl/CipherBox.java
./share/classes/sun/security/ssl/HelloExtensions.java
./share/classes/sun/security/ssl/InputRecord.java
./share/classes/sun/security/ssl/HandshakeMessage.java
./share/classes/sun/security/ssl/EngineInputRecord.java
./share/classes/sun/security/ssl/MAC.java
./share/classes/sun/security/ssl/AppInputStream.java
./share/classes/sun/security/ssl/CipherSuite.java
./share/classes/sun/security/rsa/RSAPadding.java
./share/classes/sun/security/ec/NamedCurve.java
./share/classes/sun/security/provider/MD2.java
./share/classes/sun/security/provider/MD5.java
./share/classes/sun/security/provider/DSA.java
./share/classes/sun/security/provider/ByteArrayAccess.java
./share/classes/sun/security/smartcardio/PCSC.java
./share/classes/sun/security/smartcardio/CardImpl.java
./share/classes/sun/security/smartcardio/ChannelImpl.java
./share/classes/sun/reflect/UTF8.java
./share/classes/sun/reflect/ClassFileAssembler.java
./share/classes/sun/reflect/annotation/AnnotationParser.java
./share/classes/sun/invoke/anon/ConstantPoolPatch.java
./share/classes/sun/invoke/anon/ConstantPoolParser.java
./share/classes/sun/invoke/anon/ConstantPoolVisitor.java
./share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java
./share/classes/sun/management/ManagementFactoryHelper.java
./share/classes/sun/awt/FontConfiguration.java
./share/classes/sun/awt/image/ImageRepresentation.java
./share/classes/sun/awt/image/PixelConverter.java
./share/classes/sun/awt/image/PNGImageDecoder.java
./share/classes/sun/awt/image/GifImageDecoder.java
./share/classes/sun/awt/image/BytePackedRaster.java
./share/classes/sun/awt/image/BufferedImageGraphicsConfig.java
./share/classes/sun/awt/image/JPEGImageDecoder.java
./share/classes/sun/awt/image/ByteInterleavedRaster.java
./share/classes/sun/awt/image/BufImgSurfaceData.java
./share/classes/sun/awt/image/OffScreenImageSource.java
./share/classes/sun/awt/datatransfer/DataTransferer.java
./share/classes/sun/awt/PlatformFont.java
./share/classes/sun/nio/cs/UnicodeEncoder.java
./share/classes/sun/nio/cs/ISO_8859_1.java
./share/classes/sun/nio/cs/UTF_8.java
./share/classes/sun/nio/cs/UTF_32Coder.java
./share/classes/sun/nio/cs/CharsetMapping.java
./share/classes/sun/nio/cs/ext/DoubleByte.java
./share/classes/sun/nio/cs/ext/SimpleEUCEncoder.java
./share/classes/sun/nio/cs/ext/ISO2022_JP.java
./share/classes/sun/nio/cs/ext/IBM33722.java
./share/classes/sun/nio/cs/ext/EUC_TW.java
./share/classes/sun/nio/cs/ext/ISO2022_CN.java
./share/classes/sun/nio/cs/ext/IBM943C.java
./share/classes/sun/nio/cs/ext/HKSCS.java
./share/classes/sun/nio/cs/ext/IBM949C.java
./share/classes/sun/nio/cs/ext/DoubleByteDecoder.java
./share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java
./share/classes/sun/nio/cs/ext/DoubleByteEncoder.java
./share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java
./share/classes/sun/nio/cs/ext/SJIS.java
./share/classes/sun/nio/cs/ext/JISAutoDetect.java
./share/classes/sun/nio/cs/ext/EUC_JP.java
./share/classes/sun/nio/cs/ext/IBM964.java
./share/classes/sun/nio/cs/ext/GB18030.java
./share/classes/sun/nio/cs/ext/PCK.java
./share/classes/sun/nio/cs/ext/JIS_X_0201.java
./share/classes/sun/nio/cs/ext/EUC_JP_Open.java
./share/classes/sun/nio/cs/ext/SJIS_0213.java
./share/classes/sun/nio/cs/ext/Big5_Solaris.java
./share/classes/sun/nio/cs/ext/ISO2022.java
./share/classes/sun/nio/cs/SingleByte.java
./share/classes/sun/nio/cs/UnicodeDecoder.java
./share/classes/sun/nio/cs/CESU_8.java
./share/classes/sun/nio/ch/DatagramSocketAdaptor.java
./share/classes/sun/nio/ch/ChannelInputStream.java
./share/classes/sun/nio/ch/Net.java
./share/classes/sun/font/FileFontStrike.java
./share/classes/sun/font/ExtendedTextSourceLabel.java
./share/classes/sun/font/TrueTypeFont.java
./share/classes/sun/font/CompositeStrike.java
./share/classes/sun/font/TrueTypeGlyphMapper.java
./share/classes/sun/font/Type1Font.java
./share/classes/sun/font/GlyphList.java
./share/classes/sun/font/CMap.java
./share/classes/sun/font/PhysicalStrike.java
./share/classes/sun/font/Type1GlyphMapper.java
./share/classes/sun/font/FontDesignMetrics.java
./share/classes/sun/font/StandardGlyphVector.java
./share/classes/sun/font/CharToGlyphMapper.java
./share/classes/sun/font/CompositeGlyphMapper.java
./share/classes/sun/applet/AppletPanel.java
./share/classes/sun/launcher/LauncherHelper.java
./share/classes/sun/java2d/pisces/PiscesTileGenerator.java
./share/classes/sun/java2d/pipe/BufferedPaints.java
./share/classes/sun/java2d/pipe/AATileGenerator.java
./share/classes/sun/java2d/pipe/AAShapePipe.java
./share/classes/sun/java2d/pipe/BufferedTextPipe.java
./share/classes/sun/java2d/loops/MaskFill.java
./share/classes/sun/java2d/loops/MaskBlit.java
./share/classes/sun/java2d/loops/BlitBg.java
./share/classes/sun/java2d/SunGraphics2D.java
./share/classes/sun/java2d/cmm/CMSManager.java
./share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
./share/classes/sun/tools/java/Constants.java
./share/classes/sun/tools/java/Scanner.java
./share/classes/sun/tools/java/BinaryConstantPool.java
./share/classes/sun/tools/jconsole/ConnectDialog.java
./share/classes/sun/tools/jconsole/JConsole.java
./share/classes/sun/tools/jconsole/AboutDialog.java
./share/classes/sun/tools/jconsole/HTMLPane.java
./share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java
./share/classes/javax/sound/midi/MidiMessage.java
./share/classes/javax/sound/midi/ShortMessage.java
./share/classes/javax/sound/midi/MetaMessage.java
./share/classes/javax/sound/midi/SysexMessage.java
./share/classes/javax/sound/sampled/AudioInputStream.java
./share/classes/javax/crypto/CipherInputStream.java
./share/classes/javax/crypto/spec/DESKeySpec.java
./share/classes/javax/swing/DebugGraphicsFilter.java
./share/classes/javax/swing/JComponent.java
./share/classes/javax/swing/text/html/parser/Parser.java
./share/classes/javax/swing/text/html/parser/Entity.java
./share/classes/javax/swing/plaf/metal/MetalUtils.java
./share/classes/javax/swing/plaf/metal/OceanTheme.java
./share/classes/javax/swing/plaf/metal/MetalTheme.java
./share/classes/javax/swing/plaf/ColorUIResource.java
./share/classes/javax/swing/plaf/nimbus/DropShadowEffect.java
./share/classes/javax/swing/plaf/nimbus/EffectUtils.java
./share/classes/javax/swing/plaf/nimbus/InnerShadowEffect.java
./share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
./share/classes/javax/swing/plaf/nimbus/NimbusStyle.java
./share/classes/javax/swing/plaf/nimbus/DerivedColor.java
./share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java
./share/classes/javax/swing/JColorChooser.java
./share/classes/javax/swing/colorchooser/ColorChooserPanel.java
./share/classes/javax/swing/colorchooser/ColorModel.java
./share/classes/javax/swing/GrayFilter.java
./share/classes/javax/management/remote/rmi/RMIConnectorServer.java
./share/classes/javax/imageio/stream/ImageOutputStreamImpl.java
./share/classes/javax/imageio/stream/ImageOutputStream.java
./share/classes/javax/imageio/stream/ImageInputStream.java
./share/classes/javax/imageio/stream/ImageInputStreamImpl.java
./share/classes/javax/imageio/stream/MemoryCache.java
./share/classes/javax/imageio/ImageTypeSpecifier.java
./share/classes/javax/imageio/metadata/IIOMetadataNode.java
./share/classes/javax/smartcardio/ResponseAPDU.java
./share/classes/javax/smartcardio/CommandAPDU.java
./solaris/classes/java/util/prefs/FileSystemPreferences.java
./solaris/classes/sun/print/AttributeClass.java
./solaris/classes/sun/net/sdp/SdpProvider.java
./solaris/classes/sun/awt/X11/XIconInfo.java
./solaris/classes/sun/awt/X11/XKeySymConstants.java
./solaris/classes/sun/awt/X11/MotifDnDConstants.java
./solaris/classes/sun/awt/X11/XIconWindow.java
./solaris/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java
./solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java
./solaris/classes/sun/awt/X11/XAtom.java
./solaris/classes/sun/awt/X11/MotifColorUtilities.java
./solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java
./solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java
./solaris/classes/sun/awt/X11/Native.java
./solaris/classes/sun/awt/X11/XKeysym.java
./solaris/classes/sun/awt/X11/XToolkit.java
./solaris/classes/sun/awt/X11/XDnDConstants.java
./solaris/classes/sun/awt/X11/XWM.java
./solaris/classes/sun/awt/X11/XWindowPeer.java
./solaris/classes/sun/awt/X11GraphicsConfig.java
./solaris/classes/sun/awt/motif/X11KSC5601.java
./solaris/classes/sun/awt/motif/X11GB2312.java
./solaris/classes/sun/awt/motif/X11CNS11643.java
./solaris/classes/sun/awt/motif/X11JIS0201.java
./solaris/classes/sun/awt/X11CustomCursor.java
./solaris/classes/sun/awt/XSettings.java
./solaris/classes/sun/nio/fs/UnixPath.java
./solaris/classes/sun/nio/fs/UnixUriUtils.java
./solaris/classes/sun/nio/cs/ext/CompoundTextSupport.java
./solaris/classes/sun/nio/cs/ext/COMPOUND_TEXT_Decoder.java
./solaris/classes/sun/font/XMap.java
./solaris/classes/sun/font/XRGlyphCacheEntry.java
./solaris/classes/sun/font/NativeStrike.java
./solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
./solaris/classes/sun/java2d/xr/XRSurfaceData.java
./solaris/classes/sun/java2d/xr/XRPaints.java
./solaris/classes/sun/java2d/xr/XRColor.java
./solaris/classes/sun/java2d/xr/XRCompositeManager.java
./solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java
./solaris/classes/sun/java2d/x11/X11SurfaceDataProxy.java
./solaris/classes/sun/java2d/x11/X11SurfaceData.java
./solaris/classes/sun/tools/attach/SolarisVirtualMachine.java
./solaris/classes/sun/tools/attach/LinuxVirtualMachine.java
./windows/classes/java/util/prefs/WindowsPreferences.java
./windows/classes/com/sun/tools/jdi/SharedMemoryTransportService.java
./windows/classes/sun/awt/Win32GraphicsConfig.java
./windows/classes/sun/awt/windows/WPathGraphics.java
./windows/classes/sun/awt/windows/WCustomCursor.java
./windows/classes/sun/awt/windows/WWindowPeer.java
./windows/classes/sun/awt/windows/WTrayIconPeer.java
./windows/classes/sun/awt/windows/WPrinterJob.java
./windows/classes/sun/nio/fs/WindowsFileAttributes.java
./windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java
./windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java
./windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java
./windows/classes/sun/tools/attach/WindowsVirtualMachine.java
./share/demo/applets/WireFrame/ThreeD.java
./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java
./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java
./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java
./share/demo/jfc/Font2DTest/FontPanel.java
./share/demo/jfc/Font2DTest/RangeMenu.java
./share/demo/jfc/Font2DTest/Font2DTest.java
./share/demo/jfc/CodePointIM/CodePointInputMethod.java
./share/demo/java2d/J2DBench/src/j2dbench/tests/PixelTests.java
./share/demo/java2d/J2DBench/src/j2dbench/tests/iio/IIOTests.java
./share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java
./share/classes/java/rmi/dgc/VMID.java
./share/classes/java/beans/XMLEncoder.java
./share/classes/java/net/URLConnection.java
./share/classes/java/net/Inet6Address.java
./share/classes/java/net/Inet4Address.java
./share/classes/java/net/DatagramPacket.java
./share/classes/java/net/SocketInputStream.java
./share/classes/java/net/MulticastSocket.java
./share/classes/java/net/SocksSocketImpl.java
./share/classes/java/net/SocketPermission.java
./share/classes/java/net/DatagramSocket.java
./share/classes/java/net/ServerSocket.java
./share/classes/java/net/InetSocketAddress.java
./share/classes/java/net/URI.java
./share/classes/java/lang/Character.java
./share/classes/java/lang/Byte.java
./share/classes/java/lang/Float.java
./share/classes/java/lang/Double.java
./share/classes/java/lang/Long.java
./share/classes/java/lang/CharacterData.java
./share/classes/java/lang/String.java
./share/classes/java/lang/invoke/MethodType.java
./share/classes/java/lang/invoke/MethodTypeForm.java
./share/classes/java/lang/invoke/MethodHandle.java
./share/classes/java/lang/invoke/MemberName.java
./share/classes/java/lang/CharacterName.java
./share/classes/java/lang/Integer.java
./share/classes/java/lang/Short.java
./share/classes/java/text/BreakIterator.java
./share/classes/java/text/CollationElementIterator.java
./share/classes/java/text/RuleBasedCollator.java
./share/classes/java/text/RBCollationTables.java
./share/classes/java/text/SimpleDateFormat.java
./share/classes/java/text/RBTableBuilder.java
./share/classes/java/io/ByteArrayOutputStream.java
./share/classes/java/io/DataOutputStream.java
./share/classes/java/io/DataInputStream.java
./share/classes/java/io/Reader.java
./share/classes/java/io/StringBufferInputStream.java
./share/classes/java/io/PushbackInputStream.java
./share/classes/java/io/Bits.java
./share/classes/java/io/DataOutput.java
./share/classes/java/io/RandomAccessFile.java
./share/classes/java/io/BufferedReader.java
./share/classes/java/io/ObjectInputStream.java
./share/classes/java/io/ByteArrayInputStream.java
./share/classes/java/io/DataInput.java
./share/classes/java/io/BufferedInputStream.java
./share/classes/java/io/ObjectStreamClass.java
./share/classes/java/io/ObjectOutputStream.java
./share/classes/java/io/PipedInputStream.java
./share/classes/java/util/regex/UnicodeProp.java
./share/classes/java/util/regex/Pattern.java
./share/classes/java/util/regex/ASCII.java
./share/classes/java/util/Properties.java
./share/classes/java/util/jar/JarOutputStream.java
./share/classes/java/util/jar/Manifest.java
./share/classes/java/util/jar/JarEntry.java
./share/classes/java/util/BitSet.java
./share/classes/java/util/concurrent/Phaser.java
./share/classes/java/util/concurrent/Exchanger.java
./share/classes/java/util/concurrent/ForkJoinPool.java
./share/classes/java/util/concurrent/ConcurrentHashMap.java
./share/classes/java/util/concurrent/ForkJoinWorkerThread.java
./share/classes/java/util/zip/DeflaterOutputStream.java
./share/classes/java/util/zip/InflaterInputStream.java
./share/classes/java/util/zip/GZIPInputStream.java
./share/classes/java/util/zip/DeflaterInputStream.java
./share/classes/java/util/zip/ZipConstants64.java
./share/classes/java/util/zip/ZipInputStream.java
./share/classes/java/util/zip/ZipOutputStream.java
./share/classes/java/util/zip/ZipFile.java
./share/classes/java/util/zip/CRC32.java
./share/classes/java/util/zip/Adler32.java
./share/classes/java/util/zip/GZIPOutputStream.java
./share/classes/java/util/zip/ZipEntry.java
./share/classes/java/util/UUID.java
./share/classes/java/util/prefs/Base64.java
./share/classes/java/security/SecureRandom.java
./share/classes/java/awt/Color.java
./share/classes/java/awt/GradientPaintContext.java
./share/classes/java/awt/TexturePaintContext.java
./share/classes/java/awt/AlphaComposite.java
./share/classes/java/awt/event/KeyEvent.java
./share/classes/java/awt/SystemColor.java
./share/classes/java/awt/image/DataBufferByte.java
./share/classes/java/awt/image/ByteLookupTable.java
./share/classes/java/awt/image/MultiPixelPackedSampleModel.java
./share/classes/java/awt/image/ComponentSampleModel.java
./share/classes/java/awt/image/ComponentColorModel.java
./share/classes/java/awt/image/DataBuffer.java
./share/classes/java/awt/image/DataBufferUShort.java
./share/classes/java/awt/image/SinglePixelPackedSampleModel.java
./share/classes/java/awt/image/BufferedImageFilter.java
./share/classes/java/awt/image/RescaleOp.java
./share/classes/java/awt/image/ColorConvertOp.java
./share/classes/java/awt/image/IndexColorModel.java
./share/classes/java/awt/image/AreaAveragingScaleFilter.java
./share/classes/java/awt/image/BandedSampleModel.java
./share/classes/java/awt/image/BufferedImage.java
./share/classes/java/awt/image/ShortLookupTable.java
./share/classes/java/awt/image/DirectColorModel.java
./share/classes/java/awt/image/RGBImageFilter.java
./share/classes/java/awt/image/PixelGrabber.java
./share/classes/java/awt/image/ColorModel.java
./share/classes/java/awt/MultipleGradientPaint.java
./share/classes/java/awt/color/ICC_ProfileRGB.java
./share/classes/java/awt/color/ICC_ProfileGray.java
./share/classes/java/awt/color/ICC_Profile.java
./share/classes/java/awt/color/ICC_ColorSpace.java
./share/classes/java/awt/MultipleGradientPaintContext.java
./share/classes/java/awt/FontMetrics.java
./share/classes/java/awt/font/NumericShaper.java
./share/classes/java/awt/GradientPaint.java
./share/classes/java/nio/Bits.java
./share/classes/java/nio/channels/Channels.java
./share/classes/java/math/BigInteger.java
./share/classes/com/sun/beans/decoder/LongElementHandler.java
./share/classes/com/sun/jmx/snmp/SnmpIpAddress.java
./share/classes/com/sun/jmx/snmp/SnmpString.java
./share/classes/com/sun/jmx/snmp/IPAcl/ASCII_CharStream.java
./share/classes/com/sun/jmx/snmp/IPAcl/ParserTokenManager.java
./share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java
./share/classes/com/sun/jmx/snmp/SnmpEngineId.java
./share/classes/com/sun/jmx/snmp/SnmpMsg.java
./share/classes/com/sun/java/swing/plaf/gtk/GTKColorType.java
./share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java
./share/classes/com/sun/java/swing/plaf/gtk/Metacity.java
./share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java
./share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
./share/classes/com/sun/java/util/jar/pack/PackageWriter.java
./share/classes/com/sun/java/util/jar/pack/Coding.java
./share/classes/com/sun/java/util/jar/pack/PackageReader.java
./share/classes/com/sun/java/util/jar/pack/Histogram.java
./share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java
./share/classes/com/sun/java/util/jar/pack/PopulationCoding.java
./share/classes/com/sun/java/util/jar/pack/Attribute.java
./share/classes/com/sun/java/util/jar/pack/Fixups.java
./share/classes/com/sun/java/util/jar/pack/BandStructure.java
./share/classes/com/sun/java/util/jar/pack/Instruction.java
./share/classes/com/sun/net/httpserver/BasicAuthenticator.java
./share/classes/com/sun/crypto/provider/BlowfishCrypt.java
./share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
./share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
./share/classes/com/sun/crypto/provider/ISO10126Padding.java
./share/classes/com/sun/crypto/provider/RC2Crypt.java
./share/classes/com/sun/crypto/provider/AESCrypt.java
./share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java
./share/classes/com/sun/crypto/provider/ARCFOURCipher.java
./share/classes/com/sun/crypto/provider/PKCS5Padding.java
./share/classes/com/sun/crypto/provider/RC2Parameters.java
./share/classes/com/sun/security/ntlm/NTLM.java
./share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java
./share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
./share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
./share/classes/com/sun/imageio/plugins/png/RowFilter.java
./share/classes/com/sun/imageio/plugins/png/PNGMetadata.java
./share/classes/com/sun/imageio/plugins/jpeg/DHTMarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/DQTMarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/AdobeMarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/DRIMarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReaderSpi.java
./share/classes/com/sun/imageio/plugins/jpeg/JPEGBuffer.java
./share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
./share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/MarkerSegment.java
./share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java
./share/classes/com/sun/imageio/plugins/gif/GIFImageMetadata.java
./share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
./share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java
./share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java
./share/classes/com/sun/imageio/plugins/common/LZWCompressor.java
./share/classes/com/sun/imageio/plugins/common/PaletteBuilder.java
./share/classes/com/sun/imageio/plugins/common/LZWStringTable.java
./share/classes/com/sun/imageio/plugins/common/ImageUtil.java
./share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java
./share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java
./share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java
./share/classes/com/sun/media/sound/AudioFloatConverter.java
./share/classes/com/sun/media/sound/StandardMidiFileWriter.java
./share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java
./share/classes/com/sun/media/sound/SunFileReader.java
./share/classes/com/sun/media/sound/MidiInDevice.java
./share/classes/com/sun/media/sound/FastSysexMessage.java
./share/classes/com/sun/media/sound/SunFileWriter.java
./share/classes/com/sun/media/sound/SF2Region.java
./share/classes/com/sun/media/sound/AlawCodec.java
./share/classes/com/sun/media/sound/MidiOutDevice.java
./share/classes/com/sun/media/sound/UlawCodec.java
./share/classes/com/sun/media/sound/AudioFloatFormatConverter.java
./share/classes/com/sun/media/sound/FastShortMessage.java
./share/classes/com/sun/media/sound/SoftJitterCorrector.java
./share/classes/com/sun/media/sound/SoftMixingMainMixer.java
./share/classes/com/sun/media/sound/SoftMainMixer.java
./share/classes/com/sun/media/sound/RIFFWriter.java
./share/classes/com/sun/media/sound/StandardMidiFileReader.java
./share/classes/com/sun/media/sound/SoftTuning.java
./share/classes/com/sun/media/sound/SoftMixingClip.java
./share/classes/com/sun/media/sound/WaveExtensibleFileReader.java
./share/classes/com/sun/media/sound/ModelByteBufferWavetable.java
./share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java
./share/classes/com/sun/media/sound/SoftSynthesizer.java
./share/classes/com/sun/media/sound/PortMixer.java
./share/classes/com/sun/media/sound/MidiUtils.java
./share/classes/com/sun/media/sound/RealTimeSequencer.java
./share/classes/com/sun/media/sound/AbstractMidiDevice.java
./share/classes/com/sun/jndi/dns/Header.java
./share/classes/com/sun/jndi/dns/DnsClient.java
./share/classes/com/sun/jndi/dns/ResourceRecord.java
./share/classes/com/sun/jndi/dns/DnsName.java
./share/classes/com/sun/jndi/ldap/BerEncoder.java
./share/classes/com/sun/jndi/ldap/BerDecoder.java
./share/classes/com/sun/jndi/ldap/Connection.java
./share/classes/com/sun/jndi/ldap/sasl/SaslOutputStream.java
./share/classes/com/sun/jndi/ldap/sasl/SaslInputStream.java
./share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java
./share/classes/com/sun/tools/hat/internal/model/JavaByte.java
./share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java
./share/classes/com/sun/tools/hat/internal/util/Misc.java
./share/classes/com/sun/tools/hat/internal/parser/HprofReader.java
./share/classes/com/sun/tools/example/debug/expr/ASCII_UCodeESC_CharStream.java
./share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java
./share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java
./share/classes/com/sun/tools/example/debug/gui/Icons.java
./share/classes/com/sun/tools/example/debug/tty/Commands.java
./share/classes/com/sun/tools/jdi/Packet.java
./share/classes/com/sun/tools/jdi/TargetVM.java
./share/classes/com/sun/tools/jdi/PacketStream.java
./share/classes/com/sun/tools/jdi/SocketTransportService.java
./share/classes/sun/rmi/rmic/newrmic/jrmp/RemoteClass.java
./share/classes/sun/rmi/rmic/RemoteClass.java
./share/classes/sun/rmi/server/Util.java
./share/classes/sun/rmi/transport/tcp/MultiplexInputStream.java
./share/classes/sun/rmi/transport/proxy/CGIHandler.java
./share/classes/sun/print/PrinterGraphicsConfig.java
./share/classes/sun/print/PathGraphics.java
./share/classes/sun/print/PSPrinterJob.java
./share/classes/sun/net/util/IPAddressUtil.java
./share/classes/sun/net/ftp/impl/FtpClient.java
./share/classes/sun/net/httpserver/SSLStreams.java
./share/classes/sun/net/httpserver/LeftOverInputStream.java
./share/classes/sun/net/httpserver/Request.java
./share/classes/sun/net/idn/Punycode.java
./share/classes/sun/net/idn/StringPrep.java
./share/classes/sun/net/spi/nameservice/dns/DNSNameService.java
./share/classes/sun/net/www/http/ChunkedInputStream.java
./share/classes/sun/net/www/ParseUtil.java
./share/classes/sun/text/IntHashtable.java
./share/classes/sun/text/UCompactIntArray.java
./share/classes/sun/text/normalizer/UCharacterProperty.java
./share/classes/sun/text/normalizer/UCharacter.java
./share/classes/sun/text/normalizer/Utility.java
./share/classes/sun/text/normalizer/NormalizerBase.java
./share/classes/sun/text/normalizer/NormalizerDataReader.java
./share/classes/sun/text/normalizer/NormalizerImpl.java
./share/classes/sun/text/normalizer/UCharacterIterator.java
./share/classes/sun/text/normalizer/UnicodeSet.java
./share/classes/sun/text/bidi/BidiBase.java
./share/classes/sun/text/SupplementaryCharacterData.java
./share/classes/sun/text/CompactByteArray.java
./share/classes/sun/misc/UCEncoder.java
./share/classes/sun/misc/FormattedFloatingDecimal.java
./share/classes/sun/misc/CRC16.java
./share/classes/sun/misc/UCDecoder.java
./share/classes/sun/misc/ProxyGenerator.java
./share/classes/sun/misc/BASE64Decoder.java
./share/classes/sun/misc/UUDecoder.java
./share/classes/sun/misc/FloatingDecimal.java
./share/classes/sun/misc/HexDumpEncoder.java
./share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java
./share/classes/sun/util/calendar/ZoneInfoFile.java
./share/classes/sun/security/krb5/EncryptedData.java
./share/classes/sun/security/krb5/internal/ccache/CCacheOutputStream.java
./share/classes/sun/security/krb5/internal/crypto/crc32.java
./share/classes/sun/security/krb5/internal/crypto/Des.java
./share/classes/sun/security/krb5/internal/crypto/dk/ArcFourCrypto.java
./share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java
./share/classes/sun/security/krb5/internal/crypto/dk/AesDkCrypto.java
./share/classes/sun/security/krb5/internal/crypto/Crc32CksumType.java
./share/classes/sun/security/krb5/internal/util/KrbDataOutputStream.java
./share/classes/sun/security/krb5/internal/util/KrbDataInputStream.java
./share/classes/sun/security/krb5/internal/NetClient.java
./share/classes/sun/security/krb5/internal/LocalSeqNumber.java
./share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java
./share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java
./share/classes/sun/security/pkcs11/SunPKCS11.java
./share/classes/sun/security/pkcs11/wrapper/CK_VERSION.java
./share/classes/sun/security/pkcs11/wrapper/Functions.java
./share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java
./share/classes/sun/security/pkcs11/P11Key.java
./share/classes/sun/security/pkcs11/P11Util.java
./share/classes/sun/security/x509/X509Key.java
./share/classes/sun/security/jgss/krb5/MessageToken_v2.java
./share/classes/sun/security/jgss/krb5/MessageToken.java
./share/classes/sun/security/jgss/wrapper/GSSNameElement.java
./share/classes/sun/security/jgss/GSSNameImpl.java
./share/classes/sun/security/jgss/GSSToken.java
./share/classes/sun/security/util/Debug.java
./share/classes/sun/security/util/ByteArrayLexOrder.java
./share/classes/sun/security/util/BitArray.java
./share/classes/sun/security/util/DerOutputStream.java
./share/classes/sun/security/util/Cache.java
./share/classes/sun/security/util/DerValue.java
./share/classes/sun/security/util/DerIndefLenConverter.java
./share/classes/sun/security/util/DerInputStream.java
./share/classes/sun/security/util/DerInputBuffer.java
./share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
./share/classes/sun/security/ssl/OutputRecord.java
./share/classes/sun/security/ssl/ProtocolVersion.java
./share/classes/sun/security/ssl/CipherBox.java
./share/classes/sun/security/ssl/HelloExtensions.java
./share/classes/sun/security/ssl/InputRecord.java
./share/classes/sun/security/ssl/HandshakeMessage.java
./share/classes/sun/security/ssl/EngineInputRecord.java
./share/classes/sun/security/ssl/MAC.java
./share/classes/sun/security/ssl/AppInputStream.java
./share/classes/sun/security/ssl/CipherSuite.java
./share/classes/sun/security/rsa/RSAPadding.java
./share/classes/sun/security/ec/NamedCurve.java
./share/classes/sun/security/provider/MD2.java
./share/classes/sun/security/provider/MD5.java
./share/classes/sun/security/provider/DSA.java
./share/classes/sun/security/provider/ByteArrayAccess.java
./share/classes/sun/security/smartcardio/PCSC.java
./share/classes/sun/security/smartcardio/CardImpl.java
./share/classes/sun/security/smartcardio/ChannelImpl.java
./share/classes/sun/reflect/UTF8.java
./share/classes/sun/reflect/ClassFileAssembler.java
./share/classes/sun/reflect/annotation/AnnotationParser.java
./share/classes/sun/invoke/anon/ConstantPoolPatch.java
./share/classes/sun/invoke/anon/ConstantPoolParser.java
./share/classes/sun/invoke/anon/ConstantPoolVisitor.java
./share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java
./share/classes/sun/management/ManagementFactoryHelper.java
./share/classes/sun/awt/FontConfiguration.java
./share/classes/sun/awt/image/ImageRepresentation.java
./share/classes/sun/awt/image/PixelConverter.java
./share/classes/sun/awt/image/PNGImageDecoder.java
./share/classes/sun/awt/image/GifImageDecoder.java
./share/classes/sun/awt/image/BytePackedRaster.java
./share/classes/sun/awt/image/BufferedImageGraphicsConfig.java
./share/classes/sun/awt/image/JPEGImageDecoder.java
./share/classes/sun/awt/image/ByteInterleavedRaster.java
./share/classes/sun/awt/image/BufImgSurfaceData.java
./share/classes/sun/awt/image/OffScreenImageSource.java
./share/classes/sun/awt/datatransfer/DataTransferer.java
./share/classes/sun/awt/PlatformFont.java
./share/classes/sun/nio/cs/UnicodeEncoder.java
./share/classes/sun/nio/cs/ISO_8859_1.java
./share/classes/sun/nio/cs/UTF_8.java
./share/classes/sun/nio/cs/UTF_32Coder.java
./share/classes/sun/nio/cs/CharsetMapping.java
./share/classes/sun/nio/cs/ext/DoubleByte.java
./share/classes/sun/nio/cs/ext/SimpleEUCEncoder.java
./share/classes/sun/nio/cs/ext/ISO2022_JP.java
./share/classes/sun/nio/cs/ext/IBM33722.java
./share/classes/sun/nio/cs/ext/EUC_TW.java
./share/classes/sun/nio/cs/ext/ISO2022_CN.java
./share/classes/sun/nio/cs/ext/IBM943C.java
./share/classes/sun/nio/cs/ext/HKSCS.java
./share/classes/sun/nio/cs/ext/IBM949C.java
./share/classes/sun/nio/cs/ext/DoubleByteDecoder.java
./share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java
./share/classes/sun/nio/cs/ext/DoubleByteEncoder.java
./share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java
./share/classes/sun/nio/cs/ext/SJIS.java
./share/classes/sun/nio/cs/ext/JISAutoDetect.java
./share/classes/sun/nio/cs/ext/EUC_JP.java
./share/classes/sun/nio/cs/ext/IBM964.java
./share/classes/sun/nio/cs/ext/GB18030.java
./share/classes/sun/nio/cs/ext/PCK.java
./share/classes/sun/nio/cs/ext/JIS_X_0201.java
./share/classes/sun/nio/cs/ext/EUC_JP_Open.java
./share/classes/sun/nio/cs/ext/SJIS_0213.java
./share/classes/sun/nio/cs/ext/Big5_Solaris.java
./share/classes/sun/nio/cs/ext/ISO2022.java
./share/classes/sun/nio/cs/SingleByte.java
./share/classes/sun/nio/cs/UnicodeDecoder.java
./share/classes/sun/nio/cs/CESU_8.java
./share/classes/sun/nio/ch/DatagramSocketAdaptor.java
./share/classes/sun/nio/ch/ChannelInputStream.java
./share/classes/sun/nio/ch/Net.java
./share/classes/sun/font/FileFontStrike.java
./share/classes/sun/font/ExtendedTextSourceLabel.java
./share/classes/sun/font/TrueTypeFont.java
./share/classes/sun/font/CompositeStrike.java
./share/classes/sun/font/TrueTypeGlyphMapper.java
./share/classes/sun/font/Type1Font.java
./share/classes/sun/font/GlyphList.java
./share/classes/sun/font/CMap.java
./share/classes/sun/font/PhysicalStrike.java
./share/classes/sun/font/Type1GlyphMapper.java
./share/classes/sun/font/FontDesignMetrics.java
./share/classes/sun/font/StandardGlyphVector.java
./share/classes/sun/font/CharToGlyphMapper.java
./share/classes/sun/font/CompositeGlyphMapper.java
./share/classes/sun/applet/AppletPanel.java
./share/classes/sun/launcher/LauncherHelper.java
./share/classes/sun/java2d/pisces/PiscesTileGenerator.java
./share/classes/sun/java2d/pipe/BufferedPaints.java
./share/classes/sun/java2d/pipe/AATileGenerator.java
./share/classes/sun/java2d/pipe/AAShapePipe.java
./share/classes/sun/java2d/pipe/BufferedTextPipe.java
./share/classes/sun/java2d/loops/MaskFill.java
./share/classes/sun/java2d/loops/MaskBlit.java
./share/classes/sun/java2d/loops/BlitBg.java
./share/classes/sun/java2d/SunGraphics2D.java
./share/classes/sun/java2d/cmm/CMSManager.java
./share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
./share/classes/sun/tools/java/Constants.java
./share/classes/sun/tools/java/Scanner.java
./share/classes/sun/tools/java/BinaryConstantPool.java
./share/classes/sun/tools/jconsole/ConnectDialog.java
./share/classes/sun/tools/jconsole/JConsole.java
./share/classes/sun/tools/jconsole/AboutDialog.java
./share/classes/sun/tools/jconsole/HTMLPane.java
./share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java
./share/classes/javax/sound/midi/MidiMessage.java
./share/classes/javax/sound/midi/ShortMessage.java
./share/classes/javax/sound/midi/MetaMessage.java
./share/classes/javax/sound/midi/SysexMessage.java
./share/classes/javax/sound/sampled/AudioInputStream.java
./share/classes/javax/crypto/CipherInputStream.java
./share/classes/javax/crypto/spec/DESKeySpec.java
./share/classes/javax/swing/DebugGraphicsFilter.java
./share/classes/javax/swing/JComponent.java
./share/classes/javax/swing/text/html/parser/Parser.java
./share/classes/javax/swing/text/html/parser/Entity.java
./share/classes/javax/swing/plaf/metal/MetalUtils.java
./share/classes/javax/swing/plaf/metal/OceanTheme.java
./share/classes/javax/swing/plaf/metal/MetalTheme.java
./share/classes/javax/swing/plaf/ColorUIResource.java
./share/classes/javax/swing/plaf/nimbus/DropShadowEffect.java
./share/classes/javax/swing/plaf/nimbus/EffectUtils.java
./share/classes/javax/swing/plaf/nimbus/InnerShadowEffect.java
./share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
./share/classes/javax/swing/plaf/nimbus/NimbusStyle.java
./share/classes/javax/swing/plaf/nimbus/DerivedColor.java
./share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java
./share/classes/javax/swing/JColorChooser.java
./share/classes/javax/swing/colorchooser/ColorChooserPanel.java
./share/classes/javax/swing/colorchooser/ColorModel.java
./share/classes/javax/swing/GrayFilter.java
./share/classes/javax/management/remote/rmi/RMIConnectorServer.java
./share/classes/javax/imageio/stream/ImageOutputStreamImpl.java
./share/classes/javax/imageio/stream/ImageOutputStream.java
./share/classes/javax/imageio/stream/ImageInputStream.java
./share/classes/javax/imageio/stream/ImageInputStreamImpl.java
./share/classes/javax/imageio/stream/MemoryCache.java
./share/classes/javax/imageio/ImageTypeSpecifier.java
./share/classes/javax/imageio/metadata/IIOMetadataNode.java
./share/classes/javax/smartcardio/ResponseAPDU.java
./share/classes/javax/smartcardio/CommandAPDU.java



From yuka.kamiya at oracle.com Thu Jan 26 08:08:38 2012
From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com)
Date: Thu, 26 Jan 2012 08:08:38 +0000
Subject: hg: jdk8/tl/jdk: 7017458: (cal) Multithreaded deserialization of
Calendar leads to ClassCastException
Message-ID: <20120126080847.A0FEA471C1@hg.openjdk.java.net>

Changeset: ceab7e149581
Author: peytoia
Date: 2012-01-26 17:06 +0900
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ceab7e149581

7017458: (cal) Multithreaded deserialization of Calendar leads to ClassCastException
Reviewed-by: okutsu

! src/share/classes/java/util/Calendar.java
+ test/java/util/Calendar/Bug7017458.java



From chuanshenglu at gmail.com Thu Jan 26 09:45:55 2012
From: chuanshenglu at gmail.com (Jonathan Lu)
Date: Thu, 26 Jan 2012 17:45:55 +0800
Subject: POSIX compatibility change for including wait.h in
UNIXProcess_md.c
In-Reply-To: <4F204811.6070707@oracle.com>
References: <4F0EA969.5000600@linux.vnet.ibm.com> <4F0EC525.4070507@oracle.com>
<4F0FDF85.1060406@linux.vnet.ibm.com> <4F204811.6070707@oracle.com>
Message-ID: <CAC-GWLca94Cnej-Ct0kPQ0ghCFg1YRtT+MMKC_KmorwMD8EPVA@mail.gmail.com>

> I think we forgot to create a bug for this, I've created it now:
>
> 7133301: (process) UNIXProcess_md.c should include sys/wait.h rather than
> wait.h
>

Thanks a lot, Alan!


>
> I don't mind pushing it for you but maybe this is something that Neil
> wants to do?
>
>
Hi Neil, could you please help to push it?


> -Alan
>

Cheers!
- Jonathan


From rickard.backman at oracle.com Thu Jan 26 13:08:59 2012
From: rickard.backman at oracle.com (rickard.backman at oracle.com)
Date: Thu, 26 Jan 2012 13:08:59 +0000
Subject: hg: jdk8/tl/jdk: 7133124: Remove redundant packages from JAR command
line
Message-ID: <20120126130920.71D86471CB@hg.openjdk.java.net>

Changeset: 350971f50949
Author: rbackman
Date: 2012-01-26 09:51 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/350971f50949

7133124: Remove redundant packages from JAR command line
Reviewed-by: acorn, alanb, dholmes, rottenha

! make/common/Release.gmk



From Roger.Riggs at oracle.com Thu Jan 26 16:11:16 2012
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 26 Jan 2012 11:11:16 -0500
Subject: Using unsigned library work in the JDK
In-Reply-To: <4F20D879.8010800@oracle.com>
References: <4F20D879.8010800@oracle.com>
Message-ID: <4F217B24.3030405@oracle.com>

Is there any performance impact of the method call vs the &0xff?
Hotspot will in-line the code but for VMs with less sophisticated
optimizations it will be a net loss.

Its unfortunate that between the method name and need to qualify
with the class (or use static imports) that the code is longer and not
always clearer.

The existing idiom for unsigned byte is easy enough to recognize.
For the places where multiple bytes are assembled into short or integer,
a new method with a specific purpose would be a clearer modification to
the code.

Seeing the use in the IO context, the method names may be more useful if
they reflect the data taken from the argument. For example,
asUnsignedByte(buffer[i]) .
But I/O is more about assembling bytes and less about unsigned arithmetic.

Roger




On 01/25/2012 11:37 PM, Joe Darcy wrote:
> Hello,
>
> As a follow-up to the recent push of unsigned library support in the
> JDK [1], I grepped -i for "0xff" in the JDK code base to look for
> candidate locations to use the new methods. I choose to first tackle
> some jar/zip code.
>
> Sherman, can you review the changes below?
>
> diff -r 303b67074666 src/share/classes/java/util/jar/JarOutputStream.java
> --- a/src/share/classes/java/util/jar/JarOutputStream.java Tue Jan
> 24 15:13:27 2012 -0500
> +++ b/src/share/classes/java/util/jar/JarOutputStream.java Wed Jan
> 25 20:31:05 2012 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -135,7 +135,7 @@
> * The bytes are assumed to be in Intel (little-endian) byte order.
> */
> private static int get16(byte[] b, int off) {
> - return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8);
> + return Byte.toUnsignedInt(b[off]) | (
> Byte.toUnsignedInt(b[off+1]) << 8);
> }
>
> /*
> diff -r 303b67074666 src/share/classes/java/util/jar/Manifest.java
> --- a/src/share/classes/java/util/jar/Manifest.java Tue Jan 24
> 15:13:27 2012 -0500
> +++ b/src/share/classes/java/util/jar/Manifest.java Wed Jan 25
> 20:31:05 2012 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -339,7 +339,7 @@
> return -1;
> }
> }
> - return buf[pos++] & 0xff;
> + return Byte.toUnsignedInt(buf[pos++]);
> }
>
> public int read(byte[] b, int off, int len) throws IOException {
> diff -r 303b67074666
> src/share/classes/java/util/zip/InflaterInputStream.java
> --- a/src/share/classes/java/util/zip/InflaterInputStream.java Tue
> Jan 24 15:13:27 2012 -0500
> +++ b/src/share/classes/java/util/zip/InflaterInputStream.java Wed
> Jan 25 20:31:05 2012 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -119,7 +119,7 @@
> */
> public int read() throws IOException {
> ensureOpen();
> - return read(singleByteBuf, 0, 1) == -1 ? -1 :
> singleByteBuf[0] & 0xff;
> + return read(singleByteBuf, 0, 1) == -1 ? -1 :
> Byte.toUnsignedInt(singleByteBuf[0]);
> }
>
> /**
> diff -r 303b67074666 src/share/classes/java/util/zip/ZipInputStream.java
> --- a/src/share/classes/java/util/zip/ZipInputStream.java Tue Jan
> 24 15:13:27 2012 -0500
> +++ b/src/share/classes/java/util/zip/ZipInputStream.java Wed Jan
> 25 20:31:05 2012 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -435,7 +435,7 @@
> * The bytes are assumed to be in Intel (little-endian) byte order.
> */
> private static final int get16(byte b[], int off) {
> - return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8);
> + return Byte.toUnsignedInt(b[off]) |
> (Byte.toUnsignedInt(b[off+1]) << 8);
> }
>
> /*
> diff -r 303b67074666
> src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
> ---
> a/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
> Tue Jan 24 15:13:27 2012 -0500
> +++
> b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
> Wed Jan 25 20:31:05 2012 -0800
> @@ -185,11 +185,11 @@
> */
> ///////////////////////////////////////////////////////
> static final int CH(byte[] b, int n) {
> - return b[n] & 0xff;
> + return Byte.toUnsignedInt(b[n]);
> }
>
> static final int SH(byte[] b, int n) {
> - return (b[n] & 0xff) | ((b[n + 1] & 0xff) << 8);
> + return Byte.toUnsignedInt(b[n]) | (Byte.toUnsignedInt(b[n +
> 1]) << 8);
> }
>
> static final long LG(byte[] b, int n) {
>
> If the changes look good, I'll file a bug for them, etc.
>
> In case other people want to look over candidates sites in different
> areas, I've included the list of JDK files using "0xff" below.
>
> Thanks,
>
> -Joe
>
> [1] 4504839: Java libraries should provide support for unsigned
> integer arithmetic
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008926.html
>
>
> ./solaris/classes/java/util/prefs/FileSystemPreferences.java
> ./solaris/classes/sun/print/AttributeClass.java
> ./solaris/classes/sun/net/sdp/SdpProvider.java
> ./solaris/classes/sun/awt/X11/XIconInfo.java
> ./solaris/classes/sun/awt/X11/XKeySymConstants.java
> ./solaris/classes/sun/awt/X11/MotifDnDConstants.java
> ./solaris/classes/sun/awt/X11/XIconWindow.java
> ./solaris/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java
> ./solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java
> ./solaris/classes/sun/awt/X11/XAtom.java
> ./solaris/classes/sun/awt/X11/MotifColorUtilities.java
> ./solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java
> ./solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java
> ./solaris/classes/sun/awt/X11/Native.java
> ./solaris/classes/sun/awt/X11/XKeysym.java
> ./solaris/classes/sun/awt/X11/XToolkit.java
> ./solaris/classes/sun/awt/X11/XDnDConstants.java
> ./solaris/classes/sun/awt/X11/XWM.java
> ./solaris/classes/sun/awt/X11/XWindowPeer.java
> ./solaris/classes/sun/awt/X11GraphicsConfig.java
> ./solaris/classes/sun/awt/motif/X11KSC5601.java
> ./solaris/classes/sun/awt/motif/X11GB2312.java
> ./solaris/classes/sun/awt/motif/X11CNS11643.java
> ./solaris/classes/sun/awt/motif/X11JIS0201.java
> ./solaris/classes/sun/awt/X11CustomCursor.java
> ./solaris/classes/sun/awt/XSettings.java
> ./solaris/classes/sun/nio/fs/UnixPath.java
> ./solaris/classes/sun/nio/fs/UnixUriUtils.java
> ./solaris/classes/sun/nio/cs/ext/CompoundTextSupport.java
> ./solaris/classes/sun/nio/cs/ext/COMPOUND_TEXT_Decoder.java
> ./solaris/classes/sun/font/XMap.java
> ./solaris/classes/sun/font/XRGlyphCacheEntry.java
> ./solaris/classes/sun/font/NativeStrike.java
> ./solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
> ./solaris/classes/sun/java2d/xr/XRSurfaceData.java
> ./solaris/classes/sun/java2d/xr/XRPaints.java
> ./solaris/classes/sun/java2d/xr/XRColor.java
> ./solaris/classes/sun/java2d/xr/XRCompositeManager.java
> ./solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java
> ./solaris/classes/sun/java2d/x11/X11SurfaceDataProxy.java
> ./solaris/classes/sun/java2d/x11/X11SurfaceData.java
> ./solaris/classes/sun/tools/attach/SolarisVirtualMachine.java
> ./solaris/classes/sun/tools/attach/LinuxVirtualMachine.java
> ./windows/classes/java/util/prefs/WindowsPreferences.java
> ./windows/classes/com/sun/tools/jdi/SharedMemoryTransportService.java
> ./windows/classes/sun/awt/Win32GraphicsConfig.java
> ./windows/classes/sun/awt/windows/WPathGraphics.java
> ./windows/classes/sun/awt/windows/WCustomCursor.java
> ./windows/classes/sun/awt/windows/WWindowPeer.java
> ./windows/classes/sun/awt/windows/WTrayIconPeer.java
> ./windows/classes/sun/awt/windows/WPrinterJob.java
> ./windows/classes/sun/nio/fs/WindowsFileAttributes.java
> ./windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java
> ./windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java
> ./windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java
> ./windows/classes/sun/tools/attach/WindowsVirtualMachine.java
> ./share/demo/applets/WireFrame/ThreeD.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java
> ./share/demo/jfc/Font2DTest/FontPanel.java
> ./share/demo/jfc/Font2DTest/RangeMenu.java
> ./share/demo/jfc/Font2DTest/Font2DTest.java
> ./share/demo/jfc/CodePointIM/CodePointInputMethod.java
> ./share/demo/java2d/J2DBench/src/j2dbench/tests/PixelTests.java
> ./share/demo/java2d/J2DBench/src/j2dbench/tests/iio/IIOTests.java
> ./share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java
> ./share/classes/java/rmi/dgc/VMID.java
> ./share/classes/java/beans/XMLEncoder.java
> ./share/classes/java/net/URLConnection.java
> ./share/classes/java/net/Inet6Address.java
> ./share/classes/java/net/Inet4Address.java
> ./share/classes/java/net/DatagramPacket.java
> ./share/classes/java/net/SocketInputStream.java
> ./share/classes/java/net/MulticastSocket.java
> ./share/classes/java/net/SocksSocketImpl.java
> ./share/classes/java/net/SocketPermission.java
> ./share/classes/java/net/DatagramSocket.java
> ./share/classes/java/net/ServerSocket.java
> ./share/classes/java/net/InetSocketAddress.java
> ./share/classes/java/net/URI.java
> ./share/classes/java/lang/Character.java
> ./share/classes/java/lang/Byte.java
> ./share/classes/java/lang/Float.java
> ./share/classes/java/lang/Double.java
> ./share/classes/java/lang/Long.java
> ./share/classes/java/lang/CharacterData.java
> ./share/classes/java/lang/String.java
> ./share/classes/java/lang/invoke/MethodType.java
> ./share/classes/java/lang/invoke/MethodTypeForm.java
> ./share/classes/java/lang/invoke/MethodHandle.java
> ./share/classes/java/lang/invoke/MemberName.java
> ./share/classes/java/lang/CharacterName.java
> ./share/classes/java/lang/Integer.java
> ./share/classes/java/lang/Short.java
> ./share/classes/java/text/BreakIterator.java
> ./share/classes/java/text/CollationElementIterator.java
> ./share/classes/java/text/RuleBasedCollator.java
> ./share/classes/java/text/RBCollationTables.java
> ./share/classes/java/text/SimpleDateFormat.java
> ./share/classes/java/text/RBTableBuilder.java
> ./share/classes/java/io/ByteArrayOutputStream.java
> ./share/classes/java/io/DataOutputStream.java
> ./share/classes/java/io/DataInputStream.java
> ./share/classes/java/io/Reader.java
> ./share/classes/java/io/StringBufferInputStream.java
> ./share/classes/java/io/PushbackInputStream.java
> ./share/classes/java/io/Bits.java
> ./share/classes/java/io/DataOutput.java
> ./share/classes/java/io/RandomAccessFile.java
> ./share/classes/java/io/BufferedReader.java
> ./share/classes/java/io/ObjectInputStream.java
> ./share/classes/java/io/ByteArrayInputStream.java
> ./share/classes/java/io/DataInput.java
> ./share/classes/java/io/BufferedInputStream.java
> ./share/classes/java/io/ObjectStreamClass.java
> ./share/classes/java/io/ObjectOutputStream.java
> ./share/classes/java/io/PipedInputStream.java
> ./share/classes/java/util/regex/UnicodeProp.java
> ./share/classes/java/util/regex/Pattern.java
> ./share/classes/java/util/regex/ASCII.java
> ./share/classes/java/util/Properties.java
> ./share/classes/java/util/jar/JarOutputStream.java
> ./share/classes/java/util/jar/Manifest.java
> ./share/classes/java/util/jar/JarEntry.java
> ./share/classes/java/util/BitSet.java
> ./share/classes/java/util/concurrent/Phaser.java
> ./share/classes/java/util/concurrent/Exchanger.java
> ./share/classes/java/util/concurrent/ForkJoinPool.java
> ./share/classes/java/util/concurrent/ConcurrentHashMap.java
> ./share/classes/java/util/concurrent/ForkJoinWorkerThread.java
> ./share/classes/java/util/zip/DeflaterOutputStream.java
> ./share/classes/java/util/zip/InflaterInputStream.java
> ./share/classes/java/util/zip/GZIPInputStream.java
> ./share/classes/java/util/zip/DeflaterInputStream.java
> ./share/classes/java/util/zip/ZipConstants64.java
> ./share/classes/java/util/zip/ZipInputStream.java
> ./share/classes/java/util/zip/ZipOutputStream.java
> ./share/classes/java/util/zip/ZipFile.java
> ./share/classes/java/util/zip/CRC32.java
> ./share/classes/java/util/zip/Adler32.java
> ./share/classes/java/util/zip/GZIPOutputStream.java
> ./share/classes/java/util/zip/ZipEntry.java
> ./share/classes/java/util/UUID.java
> ./share/classes/java/util/prefs/Base64.java
> ./share/classes/java/security/SecureRandom.java
> ./share/classes/java/awt/Color.java
> ./share/classes/java/awt/GradientPaintContext.java
> ./share/classes/java/awt/TexturePaintContext.java
> ./share/classes/java/awt/AlphaComposite.java
> ./share/classes/java/awt/event/KeyEvent.java
> ./share/classes/java/awt/SystemColor.java
> ./share/classes/java/awt/image/DataBufferByte.java
> ./share/classes/java/awt/image/ByteLookupTable.java
> ./share/classes/java/awt/image/MultiPixelPackedSampleModel.java
> ./share/classes/java/awt/image/ComponentSampleModel.java
> ./share/classes/java/awt/image/ComponentColorModel.java
> ./share/classes/java/awt/image/DataBuffer.java
> ./share/classes/java/awt/image/DataBufferUShort.java
> ./share/classes/java/awt/image/SinglePixelPackedSampleModel.java
> ./share/classes/java/awt/image/BufferedImageFilter.java
> ./share/classes/java/awt/image/RescaleOp.java
> ./share/classes/java/awt/image/ColorConvertOp.java
> ./share/classes/java/awt/image/IndexColorModel.java
> ./share/classes/java/awt/image/AreaAveragingScaleFilter.java
> ./share/classes/java/awt/image/BandedSampleModel.java
> ./share/classes/java/awt/image/BufferedImage.java
> ./share/classes/java/awt/image/ShortLookupTable.java
> ./share/classes/java/awt/image/DirectColorModel.java
> ./share/classes/java/awt/image/RGBImageFilter.java
> ./share/classes/java/awt/image/PixelGrabber.java
> ./share/classes/java/awt/image/ColorModel.java
> ./share/classes/java/awt/MultipleGradientPaint.java
> ./share/classes/java/awt/color/ICC_ProfileRGB.java
> ./share/classes/java/awt/color/ICC_ProfileGray.java
> ./share/classes/java/awt/color/ICC_Profile.java
> ./share/classes/java/awt/color/ICC_ColorSpace.java
> ./share/classes/java/awt/MultipleGradientPaintContext.java
> ./share/classes/java/awt/FontMetrics.java
> ./share/classes/java/awt/font/NumericShaper.java
> ./share/classes/java/awt/GradientPaint.java
> ./share/classes/java/nio/Bits.java
> ./share/classes/java/nio/channels/Channels.java
> ./share/classes/java/math/BigInteger.java
> ./share/classes/com/sun/beans/decoder/LongElementHandler.java
> ./share/classes/com/sun/jmx/snmp/SnmpIpAddress.java
> ./share/classes/com/sun/jmx/snmp/SnmpString.java
> ./share/classes/com/sun/jmx/snmp/IPAcl/ASCII_CharStream.java
> ./share/classes/com/sun/jmx/snmp/IPAcl/ParserTokenManager.java
> ./share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java
> ./share/classes/com/sun/jmx/snmp/SnmpEngineId.java
> ./share/classes/com/sun/jmx/snmp/SnmpMsg.java
> ./share/classes/com/sun/java/swing/plaf/gtk/GTKColorType.java
> ./share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java
> ./share/classes/com/sun/java/swing/plaf/gtk/Metacity.java
> ./share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java
> ./share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
> ./share/classes/com/sun/java/util/jar/pack/PackageWriter.java
> ./share/classes/com/sun/java/util/jar/pack/Coding.java
> ./share/classes/com/sun/java/util/jar/pack/PackageReader.java
> ./share/classes/com/sun/java/util/jar/pack/Histogram.java
> ./share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java
> ./share/classes/com/sun/java/util/jar/pack/PopulationCoding.java
> ./share/classes/com/sun/java/util/jar/pack/Attribute.java
> ./share/classes/com/sun/java/util/jar/pack/Fixups.java
> ./share/classes/com/sun/java/util/jar/pack/BandStructure.java
> ./share/classes/com/sun/java/util/jar/pack/Instruction.java
> ./share/classes/com/sun/net/httpserver/BasicAuthenticator.java
> ./share/classes/com/sun/crypto/provider/BlowfishCrypt.java
> ./share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
> ./share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
> ./share/classes/com/sun/crypto/provider/ISO10126Padding.java
> ./share/classes/com/sun/crypto/provider/RC2Crypt.java
> ./share/classes/com/sun/crypto/provider/AESCrypt.java
> ./share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java
> ./share/classes/com/sun/crypto/provider/ARCFOURCipher.java
> ./share/classes/com/sun/crypto/provider/PKCS5Padding.java
> ./share/classes/com/sun/crypto/provider/RC2Parameters.java
> ./share/classes/com/sun/security/ntlm/NTLM.java
> ./share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java
> ./share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
> ./share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
> ./share/classes/com/sun/imageio/plugins/png/RowFilter.java
> ./share/classes/com/sun/imageio/plugins/png/PNGMetadata.java
> ./share/classes/com/sun/imageio/plugins/jpeg/DHTMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/DQTMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/AdobeMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/DRIMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReaderSpi.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGBuffer.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/MarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFImageMetadata.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java
> ./share/classes/com/sun/imageio/plugins/common/LZWCompressor.java
> ./share/classes/com/sun/imageio/plugins/common/PaletteBuilder.java
> ./share/classes/com/sun/imageio/plugins/common/LZWStringTable.java
> ./share/classes/com/sun/imageio/plugins/common/ImageUtil.java
> ./share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java
> ./share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java
> ./share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java
> ./share/classes/com/sun/media/sound/AudioFloatConverter.java
> ./share/classes/com/sun/media/sound/StandardMidiFileWriter.java
> ./share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java
> ./share/classes/com/sun/media/sound/SunFileReader.java
> ./share/classes/com/sun/media/sound/MidiInDevice.java
> ./share/classes/com/sun/media/sound/FastSysexMessage.java
> ./share/classes/com/sun/media/sound/SunFileWriter.java
> ./share/classes/com/sun/media/sound/SF2Region.java
> ./share/classes/com/sun/media/sound/AlawCodec.java
> ./share/classes/com/sun/media/sound/MidiOutDevice.java
> ./share/classes/com/sun/media/sound/UlawCodec.java
> ./share/classes/com/sun/media/sound/AudioFloatFormatConverter.java
> ./share/classes/com/sun/media/sound/FastShortMessage.java
> ./share/classes/com/sun/media/sound/SoftJitterCorrector.java
> ./share/classes/com/sun/media/sound/SoftMixingMainMixer.java
> ./share/classes/com/sun/media/sound/SoftMainMixer.java
> ./share/classes/com/sun/media/sound/RIFFWriter.java
> ./share/classes/com/sun/media/sound/StandardMidiFileReader.java
> ./share/classes/com/sun/media/sound/SoftTuning.java
> ./share/classes/com/sun/media/sound/SoftMixingClip.java
> ./share/classes/com/sun/media/sound/WaveExtensibleFileReader.java
> ./share/classes/com/sun/media/sound/ModelByteBufferWavetable.java
> ./share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java
> ./share/classes/com/sun/media/sound/SoftSynthesizer.java
> ./share/classes/com/sun/media/sound/PortMixer.java
> ./share/classes/com/sun/media/sound/MidiUtils.java
> ./share/classes/com/sun/media/sound/RealTimeSequencer.java
> ./share/classes/com/sun/media/sound/AbstractMidiDevice.java
> ./share/classes/com/sun/jndi/dns/Header.java
> ./share/classes/com/sun/jndi/dns/DnsClient.java
> ./share/classes/com/sun/jndi/dns/ResourceRecord.java
> ./share/classes/com/sun/jndi/dns/DnsName.java
> ./share/classes/com/sun/jndi/ldap/BerEncoder.java
> ./share/classes/com/sun/jndi/ldap/BerDecoder.java
> ./share/classes/com/sun/jndi/ldap/Connection.java
> ./share/classes/com/sun/jndi/ldap/sasl/SaslOutputStream.java
> ./share/classes/com/sun/jndi/ldap/sasl/SaslInputStream.java
> ./share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java
> ./share/classes/com/sun/tools/hat/internal/model/JavaByte.java
> ./share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java
> ./share/classes/com/sun/tools/hat/internal/util/Misc.java
> ./share/classes/com/sun/tools/hat/internal/parser/HprofReader.java
> ./share/classes/com/sun/tools/example/debug/expr/ASCII_UCodeESC_CharStream.java
>
> ./share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java
>
> ./share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java
> ./share/classes/com/sun/tools/example/debug/gui/Icons.java
> ./share/classes/com/sun/tools/example/debug/tty/Commands.java
> ./share/classes/com/sun/tools/jdi/Packet.java
> ./share/classes/com/sun/tools/jdi/TargetVM.java
> ./share/classes/com/sun/tools/jdi/PacketStream.java
> ./share/classes/com/sun/tools/jdi/SocketTransportService.java
> ./share/classes/sun/rmi/rmic/newrmic/jrmp/RemoteClass.java
> ./share/classes/sun/rmi/rmic/RemoteClass.java
> ./share/classes/sun/rmi/server/Util.java
> ./share/classes/sun/rmi/transport/tcp/MultiplexInputStream.java
> ./share/classes/sun/rmi/transport/proxy/CGIHandler.java
> ./share/classes/sun/print/PrinterGraphicsConfig.java
> ./share/classes/sun/print/PathGraphics.java
> ./share/classes/sun/print/PSPrinterJob.java
> ./share/classes/sun/net/util/IPAddressUtil.java
> ./share/classes/sun/net/ftp/impl/FtpClient.java
> ./share/classes/sun/net/httpserver/SSLStreams.java
> ./share/classes/sun/net/httpserver/LeftOverInputStream.java
> ./share/classes/sun/net/httpserver/Request.java
> ./share/classes/sun/net/idn/Punycode.java
> ./share/classes/sun/net/idn/StringPrep.java
> ./share/classes/sun/net/spi/nameservice/dns/DNSNameService.java
> ./share/classes/sun/net/www/http/ChunkedInputStream.java
> ./share/classes/sun/net/www/ParseUtil.java
> ./share/classes/sun/text/IntHashtable.java
> ./share/classes/sun/text/UCompactIntArray.java
> ./share/classes/sun/text/normalizer/UCharacterProperty.java
> ./share/classes/sun/text/normalizer/UCharacter.java
> ./share/classes/sun/text/normalizer/Utility.java
> ./share/classes/sun/text/normalizer/NormalizerBase.java
> ./share/classes/sun/text/normalizer/NormalizerDataReader.java
> ./share/classes/sun/text/normalizer/NormalizerImpl.java
> ./share/classes/sun/text/normalizer/UCharacterIterator.java
> ./share/classes/sun/text/normalizer/UnicodeSet.java
> ./share/classes/sun/text/bidi/BidiBase.java
> ./share/classes/sun/text/SupplementaryCharacterData.java
> ./share/classes/sun/text/CompactByteArray.java
> ./share/classes/sun/misc/UCEncoder.java
> ./share/classes/sun/misc/FormattedFloatingDecimal.java
> ./share/classes/sun/misc/CRC16.java
> ./share/classes/sun/misc/UCDecoder.java
> ./share/classes/sun/misc/ProxyGenerator.java
> ./share/classes/sun/misc/BASE64Decoder.java
> ./share/classes/sun/misc/UUDecoder.java
> ./share/classes/sun/misc/FloatingDecimal.java
> ./share/classes/sun/misc/HexDumpEncoder.java
> ./share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java
> ./share/classes/sun/util/calendar/ZoneInfoFile.java
> ./share/classes/sun/security/krb5/EncryptedData.java
> ./share/classes/sun/security/krb5/internal/ccache/CCacheOutputStream.java
> ./share/classes/sun/security/krb5/internal/crypto/crc32.java
> ./share/classes/sun/security/krb5/internal/crypto/Des.java
> ./share/classes/sun/security/krb5/internal/crypto/dk/ArcFourCrypto.java
> ./share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java
> ./share/classes/sun/security/krb5/internal/crypto/dk/AesDkCrypto.java
> ./share/classes/sun/security/krb5/internal/crypto/Crc32CksumType.java
> ./share/classes/sun/security/krb5/internal/util/KrbDataOutputStream.java
> ./share/classes/sun/security/krb5/internal/util/KrbDataInputStream.java
> ./share/classes/sun/security/krb5/internal/NetClient.java
> ./share/classes/sun/security/krb5/internal/LocalSeqNumber.java
> ./share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java
> ./share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java
> ./share/classes/sun/security/pkcs11/SunPKCS11.java
> ./share/classes/sun/security/pkcs11/wrapper/CK_VERSION.java
> ./share/classes/sun/security/pkcs11/wrapper/Functions.java
> ./share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java
> ./share/classes/sun/security/pkcs11/P11Key.java
> ./share/classes/sun/security/pkcs11/P11Util.java
> ./share/classes/sun/security/x509/X509Key.java
> ./share/classes/sun/security/jgss/krb5/MessageToken_v2.java
> ./share/classes/sun/security/jgss/krb5/MessageToken.java
> ./share/classes/sun/security/jgss/wrapper/GSSNameElement.java
> ./share/classes/sun/security/jgss/GSSNameImpl.java
> ./share/classes/sun/security/jgss/GSSToken.java
> ./share/classes/sun/security/util/Debug.java
> ./share/classes/sun/security/util/ByteArrayLexOrder.java
> ./share/classes/sun/security/util/BitArray.java
> ./share/classes/sun/security/util/DerOutputStream.java
> ./share/classes/sun/security/util/Cache.java
> ./share/classes/sun/security/util/DerValue.java
> ./share/classes/sun/security/util/DerIndefLenConverter.java
> ./share/classes/sun/security/util/DerInputStream.java
> ./share/classes/sun/security/util/DerInputBuffer.java
> ./share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
> ./share/classes/sun/security/ssl/OutputRecord.java
> ./share/classes/sun/security/ssl/ProtocolVersion.java
> ./share/classes/sun/security/ssl/CipherBox.java
> ./share/classes/sun/security/ssl/HelloExtensions.java
> ./share/classes/sun/security/ssl/InputRecord.java
> ./share/classes/sun/security/ssl/HandshakeMessage.java
> ./share/classes/sun/security/ssl/EngineInputRecord.java
> ./share/classes/sun/security/ssl/MAC.java
> ./share/classes/sun/security/ssl/AppInputStream.java
> ./share/classes/sun/security/ssl/CipherSuite.java
> ./share/classes/sun/security/rsa/RSAPadding.java
> ./share/classes/sun/security/ec/NamedCurve.java
> ./share/classes/sun/security/provider/MD2.java
> ./share/classes/sun/security/provider/MD5.java
> ./share/classes/sun/security/provider/DSA.java
> ./share/classes/sun/security/provider/ByteArrayAccess.java
> ./share/classes/sun/security/smartcardio/PCSC.java
> ./share/classes/sun/security/smartcardio/CardImpl.java
> ./share/classes/sun/security/smartcardio/ChannelImpl.java
> ./share/classes/sun/reflect/UTF8.java
> ./share/classes/sun/reflect/ClassFileAssembler.java
> ./share/classes/sun/reflect/annotation/AnnotationParser.java
> ./share/classes/sun/invoke/anon/ConstantPoolPatch.java
> ./share/classes/sun/invoke/anon/ConstantPoolParser.java
> ./share/classes/sun/invoke/anon/ConstantPoolVisitor.java
> ./share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java
>
> ./share/classes/sun/management/ManagementFactoryHelper.java
> ./share/classes/sun/awt/FontConfiguration.java
> ./share/classes/sun/awt/image/ImageRepresentation.java
> ./share/classes/sun/awt/image/PixelConverter.java
> ./share/classes/sun/awt/image/PNGImageDecoder.java
> ./share/classes/sun/awt/image/GifImageDecoder.java
> ./share/classes/sun/awt/image/BytePackedRaster.java
> ./share/classes/sun/awt/image/BufferedImageGraphicsConfig.java
> ./share/classes/sun/awt/image/JPEGImageDecoder.java
> ./share/classes/sun/awt/image/ByteInterleavedRaster.java
> ./share/classes/sun/awt/image/BufImgSurfaceData.java
> ./share/classes/sun/awt/image/OffScreenImageSource.java
> ./share/classes/sun/awt/datatransfer/DataTransferer.java
> ./share/classes/sun/awt/PlatformFont.java
> ./share/classes/sun/nio/cs/UnicodeEncoder.java
> ./share/classes/sun/nio/cs/ISO_8859_1.java
> ./share/classes/sun/nio/cs/UTF_8.java
> ./share/classes/sun/nio/cs/UTF_32Coder.java
> ./share/classes/sun/nio/cs/CharsetMapping.java
> ./share/classes/sun/nio/cs/ext/DoubleByte.java
> ./share/classes/sun/nio/cs/ext/SimpleEUCEncoder.java
> ./share/classes/sun/nio/cs/ext/ISO2022_JP.java
> ./share/classes/sun/nio/cs/ext/IBM33722.java
> ./share/classes/sun/nio/cs/ext/EUC_TW.java
> ./share/classes/sun/nio/cs/ext/ISO2022_CN.java
> ./share/classes/sun/nio/cs/ext/IBM943C.java
> ./share/classes/sun/nio/cs/ext/HKSCS.java
> ./share/classes/sun/nio/cs/ext/IBM949C.java
> ./share/classes/sun/nio/cs/ext/DoubleByteDecoder.java
> ./share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java
> ./share/classes/sun/nio/cs/ext/DoubleByteEncoder.java
> ./share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java
> ./share/classes/sun/nio/cs/ext/SJIS.java
> ./share/classes/sun/nio/cs/ext/JISAutoDetect.java
> ./share/classes/sun/nio/cs/ext/EUC_JP.java
> ./share/classes/sun/nio/cs/ext/IBM964.java
> ./share/classes/sun/nio/cs/ext/GB18030.java
> ./share/classes/sun/nio/cs/ext/PCK.java
> ./share/classes/sun/nio/cs/ext/JIS_X_0201.java
> ./share/classes/sun/nio/cs/ext/EUC_JP_Open.java
> ./share/classes/sun/nio/cs/ext/SJIS_0213.java
> ./share/classes/sun/nio/cs/ext/Big5_Solaris.java
> ./share/classes/sun/nio/cs/ext/ISO2022.java
> ./share/classes/sun/nio/cs/SingleByte.java
> ./share/classes/sun/nio/cs/UnicodeDecoder.java
> ./share/classes/sun/nio/cs/CESU_8.java
> ./share/classes/sun/nio/ch/DatagramSocketAdaptor.java
> ./share/classes/sun/nio/ch/ChannelInputStream.java
> ./share/classes/sun/nio/ch/Net.java
> ./share/classes/sun/font/FileFontStrike.java
> ./share/classes/sun/font/ExtendedTextSourceLabel.java
> ./share/classes/sun/font/TrueTypeFont.java
> ./share/classes/sun/font/CompositeStrike.java
> ./share/classes/sun/font/TrueTypeGlyphMapper.java
> ./share/classes/sun/font/Type1Font.java
> ./share/classes/sun/font/GlyphList.java
> ./share/classes/sun/font/CMap.java
> ./share/classes/sun/font/PhysicalStrike.java
> ./share/classes/sun/font/Type1GlyphMapper.java
> ./share/classes/sun/font/FontDesignMetrics.java
> ./share/classes/sun/font/StandardGlyphVector.java
> ./share/classes/sun/font/CharToGlyphMapper.java
> ./share/classes/sun/font/CompositeGlyphMapper.java
> ./share/classes/sun/applet/AppletPanel.java
> ./share/classes/sun/launcher/LauncherHelper.java
> ./share/classes/sun/java2d/pisces/PiscesTileGenerator.java
> ./share/classes/sun/java2d/pipe/BufferedPaints.java
> ./share/classes/sun/java2d/pipe/AATileGenerator.java
> ./share/classes/sun/java2d/pipe/AAShapePipe.java
> ./share/classes/sun/java2d/pipe/BufferedTextPipe.java
> ./share/classes/sun/java2d/loops/MaskFill.java
> ./share/classes/sun/java2d/loops/MaskBlit.java
> ./share/classes/sun/java2d/loops/BlitBg.java
> ./share/classes/sun/java2d/SunGraphics2D.java
> ./share/classes/sun/java2d/cmm/CMSManager.java
> ./share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
> ./share/classes/sun/tools/java/Constants.java
> ./share/classes/sun/tools/java/Scanner.java
> ./share/classes/sun/tools/java/BinaryConstantPool.java
> ./share/classes/sun/tools/jconsole/ConnectDialog.java
> ./share/classes/sun/tools/jconsole/JConsole.java
> ./share/classes/sun/tools/jconsole/AboutDialog.java
> ./share/classes/sun/tools/jconsole/HTMLPane.java
> ./share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java
> ./share/classes/javax/sound/midi/MidiMessage.java
> ./share/classes/javax/sound/midi/ShortMessage.java
> ./share/classes/javax/sound/midi/MetaMessage.java
> ./share/classes/javax/sound/midi/SysexMessage.java
> ./share/classes/javax/sound/sampled/AudioInputStream.java
> ./share/classes/javax/crypto/CipherInputStream.java
> ./share/classes/javax/crypto/spec/DESKeySpec.java
> ./share/classes/javax/swing/DebugGraphicsFilter.java
> ./share/classes/javax/swing/JComponent.java
> ./share/classes/javax/swing/text/html/parser/Parser.java
> ./share/classes/javax/swing/text/html/parser/Entity.java
> ./share/classes/javax/swing/plaf/metal/MetalUtils.java
> ./share/classes/javax/swing/plaf/metal/OceanTheme.java
> ./share/classes/javax/swing/plaf/metal/MetalTheme.java
> ./share/classes/javax/swing/plaf/ColorUIResource.java
> ./share/classes/javax/swing/plaf/nimbus/DropShadowEffect.java
> ./share/classes/javax/swing/plaf/nimbus/EffectUtils.java
> ./share/classes/javax/swing/plaf/nimbus/InnerShadowEffect.java
> ./share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
> ./share/classes/javax/swing/plaf/nimbus/NimbusStyle.java
> ./share/classes/javax/swing/plaf/nimbus/DerivedColor.java
> ./share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java
> ./share/classes/javax/swing/JColorChooser.java
> ./share/classes/javax/swing/colorchooser/ColorChooserPanel.java
> ./share/classes/javax/swing/colorchooser/ColorModel.java
> ./share/classes/javax/swing/GrayFilter.java
> ./share/classes/javax/management/remote/rmi/RMIConnectorServer.java
> ./share/classes/javax/imageio/stream/ImageOutputStreamImpl.java
> ./share/classes/javax/imageio/stream/ImageOutputStream.java
> ./share/classes/javax/imageio/stream/ImageInputStream.java
> ./share/classes/javax/imageio/stream/ImageInputStreamImpl.java
> ./share/classes/javax/imageio/stream/MemoryCache.java
> ./share/classes/javax/imageio/ImageTypeSpecifier.java
> ./share/classes/javax/imageio/metadata/IIOMetadataNode.java
> ./share/classes/javax/smartcardio/ResponseAPDU.java
> ./share/classes/javax/smartcardio/CommandAPDU.java
> ./solaris/classes/java/util/prefs/FileSystemPreferences.java
> ./solaris/classes/sun/print/AttributeClass.java
> ./solaris/classes/sun/net/sdp/SdpProvider.java
> ./solaris/classes/sun/awt/X11/XIconInfo.java
> ./solaris/classes/sun/awt/X11/XKeySymConstants.java
> ./solaris/classes/sun/awt/X11/MotifDnDConstants.java
> ./solaris/classes/sun/awt/X11/XIconWindow.java
> ./solaris/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java
> ./solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java
> ./solaris/classes/sun/awt/X11/XAtom.java
> ./solaris/classes/sun/awt/X11/MotifColorUtilities.java
> ./solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java
> ./solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java
> ./solaris/classes/sun/awt/X11/Native.java
> ./solaris/classes/sun/awt/X11/XKeysym.java
> ./solaris/classes/sun/awt/X11/XToolkit.java
> ./solaris/classes/sun/awt/X11/XDnDConstants.java
> ./solaris/classes/sun/awt/X11/XWM.java
> ./solaris/classes/sun/awt/X11/XWindowPeer.java
> ./solaris/classes/sun/awt/X11GraphicsConfig.java
> ./solaris/classes/sun/awt/motif/X11KSC5601.java
> ./solaris/classes/sun/awt/motif/X11GB2312.java
> ./solaris/classes/sun/awt/motif/X11CNS11643.java
> ./solaris/classes/sun/awt/motif/X11JIS0201.java
> ./solaris/classes/sun/awt/X11CustomCursor.java
> ./solaris/classes/sun/awt/XSettings.java
> ./solaris/classes/sun/nio/fs/UnixPath.java
> ./solaris/classes/sun/nio/fs/UnixUriUtils.java
> ./solaris/classes/sun/nio/cs/ext/CompoundTextSupport.java
> ./solaris/classes/sun/nio/cs/ext/COMPOUND_TEXT_Decoder.java
> ./solaris/classes/sun/font/XMap.java
> ./solaris/classes/sun/font/XRGlyphCacheEntry.java
> ./solaris/classes/sun/font/NativeStrike.java
> ./solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
> ./solaris/classes/sun/java2d/xr/XRSurfaceData.java
> ./solaris/classes/sun/java2d/xr/XRPaints.java
> ./solaris/classes/sun/java2d/xr/XRColor.java
> ./solaris/classes/sun/java2d/xr/XRCompositeManager.java
> ./solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java
> ./solaris/classes/sun/java2d/x11/X11SurfaceDataProxy.java
> ./solaris/classes/sun/java2d/x11/X11SurfaceData.java
> ./solaris/classes/sun/tools/attach/SolarisVirtualMachine.java
> ./solaris/classes/sun/tools/attach/LinuxVirtualMachine.java
> ./windows/classes/java/util/prefs/WindowsPreferences.java
> ./windows/classes/com/sun/tools/jdi/SharedMemoryTransportService.java
> ./windows/classes/sun/awt/Win32GraphicsConfig.java
> ./windows/classes/sun/awt/windows/WPathGraphics.java
> ./windows/classes/sun/awt/windows/WCustomCursor.java
> ./windows/classes/sun/awt/windows/WWindowPeer.java
> ./windows/classes/sun/awt/windows/WTrayIconPeer.java
> ./windows/classes/sun/awt/windows/WPrinterJob.java
> ./windows/classes/sun/nio/fs/WindowsFileAttributes.java
> ./windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java
> ./windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java
> ./windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java
> ./windows/classes/sun/tools/attach/WindowsVirtualMachine.java
> ./share/demo/applets/WireFrame/ThreeD.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java
> ./share/demo/jfc/Font2DTest/FontPanel.java
> ./share/demo/jfc/Font2DTest/RangeMenu.java
> ./share/demo/jfc/Font2DTest/Font2DTest.java
> ./share/demo/jfc/CodePointIM/CodePointInputMethod.java
> ./share/demo/java2d/J2DBench/src/j2dbench/tests/PixelTests.java
> ./share/demo/java2d/J2DBench/src/j2dbench/tests/iio/IIOTests.java
> ./share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java
> ./share/classes/java/rmi/dgc/VMID.java
> ./share/classes/java/beans/XMLEncoder.java
> ./share/classes/java/net/URLConnection.java
> ./share/classes/java/net/Inet6Address.java
> ./share/classes/java/net/Inet4Address.java
> ./share/classes/java/net/DatagramPacket.java
> ./share/classes/java/net/SocketInputStream.java
> ./share/classes/java/net/MulticastSocket.java
> ./share/classes/java/net/SocksSocketImpl.java
> ./share/classes/java/net/SocketPermission.java
> ./share/classes/java/net/DatagramSocket.java
> ./share/classes/java/net/ServerSocket.java
> ./share/classes/java/net/InetSocketAddress.java
> ./share/classes/java/net/URI.java
> ./share/classes/java/lang/Character.java
> ./share/classes/java/lang/Byte.java
> ./share/classes/java/lang/Float.java
> ./share/classes/java/lang/Double.java
> ./share/classes/java/lang/Long.java
> ./share/classes/java/lang/CharacterData.java
> ./share/classes/java/lang/String.java
> ./share/classes/java/lang/invoke/MethodType.java
> ./share/classes/java/lang/invoke/MethodTypeForm.java
> ./share/classes/java/lang/invoke/MethodHandle.java
> ./share/classes/java/lang/invoke/MemberName.java
> ./share/classes/java/lang/CharacterName.java
> ./share/classes/java/lang/Integer.java
> ./share/classes/java/lang/Short.java
> ./share/classes/java/text/BreakIterator.java
> ./share/classes/java/text/CollationElementIterator.java
> ./share/classes/java/text/RuleBasedCollator.java
> ./share/classes/java/text/RBCollationTables.java
> ./share/classes/java/text/SimpleDateFormat.java
> ./share/classes/java/text/RBTableBuilder.java
> ./share/classes/java/io/ByteArrayOutputStream.java
> ./share/classes/java/io/DataOutputStream.java
> ./share/classes/java/io/DataInputStream.java
> ./share/classes/java/io/Reader.java
> ./share/classes/java/io/StringBufferInputStream.java
> ./share/classes/java/io/PushbackInputStream.java
> ./share/classes/java/io/Bits.java
> ./share/classes/java/io/DataOutput.java
> ./share/classes/java/io/RandomAccessFile.java
> ./share/classes/java/io/BufferedReader.java
> ./share/classes/java/io/ObjectInputStream.java
> ./share/classes/java/io/ByteArrayInputStream.java
> ./share/classes/java/io/DataInput.java
> ./share/classes/java/io/BufferedInputStream.java
> ./share/classes/java/io/ObjectStreamClass.java
> ./share/classes/java/io/ObjectOutputStream.java
> ./share/classes/java/io/PipedInputStream.java
> ./share/classes/java/util/regex/UnicodeProp.java
> ./share/classes/java/util/regex/Pattern.java
> ./share/classes/java/util/regex/ASCII.java
> ./share/classes/java/util/Properties.java
> ./share/classes/java/util/jar/JarOutputStream.java
> ./share/classes/java/util/jar/Manifest.java
> ./share/classes/java/util/jar/JarEntry.java
> ./share/classes/java/util/BitSet.java
> ./share/classes/java/util/concurrent/Phaser.java
> ./share/classes/java/util/concurrent/Exchanger.java
> ./share/classes/java/util/concurrent/ForkJoinPool.java
> ./share/classes/java/util/concurrent/ConcurrentHashMap.java
> ./share/classes/java/util/concurrent/ForkJoinWorkerThread.java
> ./share/classes/java/util/zip/DeflaterOutputStream.java
> ./share/classes/java/util/zip/InflaterInputStream.java
> ./share/classes/java/util/zip/GZIPInputStream.java
> ./share/classes/java/util/zip/DeflaterInputStream.java
> ./share/classes/java/util/zip/ZipConstants64.java
> ./share/classes/java/util/zip/ZipInputStream.java
> ./share/classes/java/util/zip/ZipOutputStream.java
> ./share/classes/java/util/zip/ZipFile.java
> ./share/classes/java/util/zip/CRC32.java
> ./share/classes/java/util/zip/Adler32.java
> ./share/classes/java/util/zip/GZIPOutputStream.java
> ./share/classes/java/util/zip/ZipEntry.java
> ./share/classes/java/util/UUID.java
> ./share/classes/java/util/prefs/Base64.java
> ./share/classes/java/security/SecureRandom.java
> ./share/classes/java/awt/Color.java
> ./share/classes/java/awt/GradientPaintContext.java
> ./share/classes/java/awt/TexturePaintContext.java
> ./share/classes/java/awt/AlphaComposite.java
> ./share/classes/java/awt/event/KeyEvent.java
> ./share/classes/java/awt/SystemColor.java
> ./share/classes/java/awt/image/DataBufferByte.java
> ./share/classes/java/awt/image/ByteLookupTable.java
> ./share/classes/java/awt/image/MultiPixelPackedSampleModel.java
> ./share/classes/java/awt/image/ComponentSampleModel.java
> ./share/classes/java/awt/image/ComponentColorModel.java
> ./share/classes/java/awt/image/DataBuffer.java
> ./share/classes/java/awt/image/DataBufferUShort.java
> ./share/classes/java/awt/image/SinglePixelPackedSampleModel.java
> ./share/classes/java/awt/image/BufferedImageFilter.java
> ./share/classes/java/awt/image/RescaleOp.java
> ./share/classes/java/awt/image/ColorConvertOp.java
> ./share/classes/java/awt/image/IndexColorModel.java
> ./share/classes/java/awt/image/AreaAveragingScaleFilter.java
> ./share/classes/java/awt/image/BandedSampleModel.java
> ./share/classes/java/awt/image/BufferedImage.java
> ./share/classes/java/awt/image/ShortLookupTable.java
> ./share/classes/java/awt/image/DirectColorModel.java
> ./share/classes/java/awt/image/RGBImageFilter.java
> ./share/classes/java/awt/image/PixelGrabber.java
> ./share/classes/java/awt/image/ColorModel.java
> ./share/classes/java/awt/MultipleGradientPaint.java
> ./share/classes/java/awt/color/ICC_ProfileRGB.java
> ./share/classes/java/awt/color/ICC_ProfileGray.java
> ./share/classes/java/awt/color/ICC_Profile.java
> ./share/classes/java/awt/color/ICC_ColorSpace.java
> ./share/classes/java/awt/MultipleGradientPaintContext.java
> ./share/classes/java/awt/FontMetrics.java
> ./share/classes/java/awt/font/NumericShaper.java
> ./share/classes/java/awt/GradientPaint.java
> ./share/classes/java/nio/Bits.java
> ./share/classes/java/nio/channels/Channels.java
> ./share/classes/java/math/BigInteger.java
> ./share/classes/com/sun/beans/decoder/LongElementHandler.java
> ./share/classes/com/sun/jmx/snmp/SnmpIpAddress.java
> ./share/classes/com/sun/jmx/snmp/SnmpString.java
> ./share/classes/com/sun/jmx/snmp/IPAcl/ASCII_CharStream.java
> ./share/classes/com/sun/jmx/snmp/IPAcl/ParserTokenManager.java
> ./share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java
> ./share/classes/com/sun/jmx/snmp/SnmpEngineId.java
> ./share/classes/com/sun/jmx/snmp/SnmpMsg.java
> ./share/classes/com/sun/java/swing/plaf/gtk/GTKColorType.java
> ./share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java
> ./share/classes/com/sun/java/swing/plaf/gtk/Metacity.java
> ./share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java
> ./share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
> ./share/classes/com/sun/java/util/jar/pack/PackageWriter.java
> ./share/classes/com/sun/java/util/jar/pack/Coding.java
> ./share/classes/com/sun/java/util/jar/pack/PackageReader.java
> ./share/classes/com/sun/java/util/jar/pack/Histogram.java
> ./share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java
> ./share/classes/com/sun/java/util/jar/pack/PopulationCoding.java
> ./share/classes/com/sun/java/util/jar/pack/Attribute.java
> ./share/classes/com/sun/java/util/jar/pack/Fixups.java
> ./share/classes/com/sun/java/util/jar/pack/BandStructure.java
> ./share/classes/com/sun/java/util/jar/pack/Instruction.java
> ./share/classes/com/sun/net/httpserver/BasicAuthenticator.java
> ./share/classes/com/sun/crypto/provider/BlowfishCrypt.java
> ./share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
> ./share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
> ./share/classes/com/sun/crypto/provider/ISO10126Padding.java
> ./share/classes/com/sun/crypto/provider/RC2Crypt.java
> ./share/classes/com/sun/crypto/provider/AESCrypt.java
> ./share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java
> ./share/classes/com/sun/crypto/provider/ARCFOURCipher.java
> ./share/classes/com/sun/crypto/provider/PKCS5Padding.java
> ./share/classes/com/sun/crypto/provider/RC2Parameters.java
> ./share/classes/com/sun/security/ntlm/NTLM.java
> ./share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java
> ./share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
> ./share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
> ./share/classes/com/sun/imageio/plugins/png/RowFilter.java
> ./share/classes/com/sun/imageio/plugins/png/PNGMetadata.java
> ./share/classes/com/sun/imageio/plugins/jpeg/DHTMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/DQTMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/AdobeMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/DRIMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReaderSpi.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGBuffer.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/MarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFImageMetadata.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java
> ./share/classes/com/sun/imageio/plugins/common/LZWCompressor.java
> ./share/classes/com/sun/imageio/plugins/common/PaletteBuilder.java
> ./share/classes/com/sun/imageio/plugins/common/LZWStringTable.java
> ./share/classes/com/sun/imageio/plugins/common/ImageUtil.java
> ./share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java
> ./share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java
> ./share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java
> ./share/classes/com/sun/media/sound/AudioFloatConverter.java
> ./share/classes/com/sun/media/sound/StandardMidiFileWriter.java
> ./share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java
> ./share/classes/com/sun/media/sound/SunFileReader.java
> ./share/classes/com/sun/media/sound/MidiInDevice.java
> ./share/classes/com/sun/media/sound/FastSysexMessage.java
> ./share/classes/com/sun/media/sound/SunFileWriter.java
> ./share/classes/com/sun/media/sound/SF2Region.java
> ./share/classes/com/sun/media/sound/AlawCodec.java
> ./share/classes/com/sun/media/sound/MidiOutDevice.java
> ./share/classes/com/sun/media/sound/UlawCodec.java
> ./share/classes/com/sun/media/sound/AudioFloatFormatConverter.java
> ./share/classes/com/sun/media/sound/FastShortMessage.java
> ./share/classes/com/sun/media/sound/SoftJitterCorrector.java
> ./share/classes/com/sun/media/sound/SoftMixingMainMixer.java
> ./share/classes/com/sun/media/sound/SoftMainMixer.java
> ./share/classes/com/sun/media/sound/RIFFWriter.java
> ./share/classes/com/sun/media/sound/StandardMidiFileReader.java
> ./share/classes/com/sun/media/sound/SoftTuning.java
> ./share/classes/com/sun/media/sound/SoftMixingClip.java
> ./share/classes/com/sun/media/sound/WaveExtensibleFileReader.java
> ./share/classes/com/sun/media/sound/ModelByteBufferWavetable.java
> ./share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java
> ./share/classes/com/sun/media/sound/SoftSynthesizer.java
> ./share/classes/com/sun/media/sound/PortMixer.java
> ./share/classes/com/sun/media/sound/MidiUtils.java
> ./share/classes/com/sun/media/sound/RealTimeSequencer.java
> ./share/classes/com/sun/media/sound/AbstractMidiDevice.java
> ./share/classes/com/sun/jndi/dns/Header.java
> ./share/classes/com/sun/jndi/dns/DnsClient.java
> ./share/classes/com/sun/jndi/dns/ResourceRecord.java
> ./share/classes/com/sun/jndi/dns/DnsName.java
> ./share/classes/com/sun/jndi/ldap/BerEncoder.java
> ./share/classes/com/sun/jndi/ldap/BerDecoder.java
> ./share/classes/com/sun/jndi/ldap/Connection.java
> ./share/classes/com/sun/jndi/ldap/sasl/SaslOutputStream.java
> ./share/classes/com/sun/jndi/ldap/sasl/SaslInputStream.java
> ./share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java
> ./share/classes/com/sun/tools/hat/internal/model/JavaByte.java
> ./share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java
> ./share/classes/com/sun/tools/hat/internal/util/Misc.java
> ./share/classes/com/sun/tools/hat/internal/parser/HprofReader.java
> ./share/classes/com/sun/tools/example/debug/expr/ASCII_UCodeESC_CharStream.java
>
> ./share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java
>
> ./share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java
> ./share/classes/com/sun/tools/example/debug/gui/Icons.java
> ./share/classes/com/sun/tools/example/debug/tty/Commands.java
> ./share/classes/com/sun/tools/jdi/Packet.java
> ./share/classes/com/sun/tools/jdi/TargetVM.java
> ./share/classes/com/sun/tools/jdi/PacketStream.java
> ./share/classes/com/sun/tools/jdi/SocketTransportService.java
> ./share/classes/sun/rmi/rmic/newrmic/jrmp/RemoteClass.java
> ./share/classes/sun/rmi/rmic/RemoteClass.java
> ./share/classes/sun/rmi/server/Util.java
> ./share/classes/sun/rmi/transport/tcp/MultiplexInputStream.java
> ./share/classes/sun/rmi/transport/proxy/CGIHandler.java
> ./share/classes/sun/print/PrinterGraphicsConfig.java
> ./share/classes/sun/print/PathGraphics.java
> ./share/classes/sun/print/PSPrinterJob.java
> ./share/classes/sun/net/util/IPAddressUtil.java
> ./share/classes/sun/net/ftp/impl/FtpClient.java
> ./share/classes/sun/net/httpserver/SSLStreams.java
> ./share/classes/sun/net/httpserver/LeftOverInputStream.java
> ./share/classes/sun/net/httpserver/Request.java
> ./share/classes/sun/net/idn/Punycode.java
> ./share/classes/sun/net/idn/StringPrep.java
> ./share/classes/sun/net/spi/nameservice/dns/DNSNameService.java
> ./share/classes/sun/net/www/http/ChunkedInputStream.java
> ./share/classes/sun/net/www/ParseUtil.java
> ./share/classes/sun/text/IntHashtable.java
> ./share/classes/sun/text/UCompactIntArray.java
> ./share/classes/sun/text/normalizer/UCharacterProperty.java
> ./share/classes/sun/text/normalizer/UCharacter.java
> ./share/classes/sun/text/normalizer/Utility.java
> ./share/classes/sun/text/normalizer/NormalizerBase.java
> ./share/classes/sun/text/normalizer/NormalizerDataReader.java
> ./share/classes/sun/text/normalizer/NormalizerImpl.java
> ./share/classes/sun/text/normalizer/UCharacterIterator.java
> ./share/classes/sun/text/normalizer/UnicodeSet.java
> ./share/classes/sun/text/bidi/BidiBase.java
> ./share/classes/sun/text/SupplementaryCharacterData.java
> ./share/classes/sun/text/CompactByteArray.java
> ./share/classes/sun/misc/UCEncoder.java
> ./share/classes/sun/misc/FormattedFloatingDecimal.java
> ./share/classes/sun/misc/CRC16.java
> ./share/classes/sun/misc/UCDecoder.java
> ./share/classes/sun/misc/ProxyGenerator.java
> ./share/classes/sun/misc/BASE64Decoder.java
> ./share/classes/sun/misc/UUDecoder.java
> ./share/classes/sun/misc/FloatingDecimal.java
> ./share/classes/sun/misc/HexDumpEncoder.java
> ./share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java
> ./share/classes/sun/util/calendar/ZoneInfoFile.java
> ./share/classes/sun/security/krb5/EncryptedData.java
> ./share/classes/sun/security/krb5/internal/ccache/CCacheOutputStream.java
> ./share/classes/sun/security/krb5/internal/crypto/crc32.java
> ./share/classes/sun/security/krb5/internal/crypto/Des.java
> ./share/classes/sun/security/krb5/internal/crypto/dk/ArcFourCrypto.java
> ./share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java
> ./share/classes/sun/security/krb5/internal/crypto/dk/AesDkCrypto.java
> ./share/classes/sun/security/krb5/internal/crypto/Crc32CksumType.java
> ./share/classes/sun/security/krb5/internal/util/KrbDataOutputStream.java
> ./share/classes/sun/security/krb5/internal/util/KrbDataInputStream.java
> ./share/classes/sun/security/krb5/internal/NetClient.java
> ./share/classes/sun/security/krb5/internal/LocalSeqNumber.java
> ./share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java
> ./share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java
> ./share/classes/sun/security/pkcs11/SunPKCS11.java
> ./share/classes/sun/security/pkcs11/wrapper/CK_VERSION.java
> ./share/classes/sun/security/pkcs11/wrapper/Functions.java
> ./share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java
> ./share/classes/sun/security/pkcs11/P11Key.java
> ./share/classes/sun/security/pkcs11/P11Util.java
> ./share/classes/sun/security/x509/X509Key.java
> ./share/classes/sun/security/jgss/krb5/MessageToken_v2.java
> ./share/classes/sun/security/jgss/krb5/MessageToken.java
> ./share/classes/sun/security/jgss/wrapper/GSSNameElement.java
> ./share/classes/sun/security/jgss/GSSNameImpl.java
> ./share/classes/sun/security/jgss/GSSToken.java
> ./share/classes/sun/security/util/Debug.java
> ./share/classes/sun/security/util/ByteArrayLexOrder.java
> ./share/classes/sun/security/util/BitArray.java
> ./share/classes/sun/security/util/DerOutputStream.java
> ./share/classes/sun/security/util/Cache.java
> ./share/classes/sun/security/util/DerValue.java
> ./share/classes/sun/security/util/DerIndefLenConverter.java
> ./share/classes/sun/security/util/DerInputStream.java
> ./share/classes/sun/security/util/DerInputBuffer.java
> ./share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
> ./share/classes/sun/security/ssl/OutputRecord.java
> ./share/classes/sun/security/ssl/ProtocolVersion.java
> ./share/classes/sun/security/ssl/CipherBox.java
> ./share/classes/sun/security/ssl/HelloExtensions.java
> ./share/classes/sun/security/ssl/InputRecord.java
> ./share/classes/sun/security/ssl/HandshakeMessage.java
> ./share/classes/sun/security/ssl/EngineInputRecord.java
> ./share/classes/sun/security/ssl/MAC.java
> ./share/classes/sun/security/ssl/AppInputStream.java
> ./share/classes/sun/security/ssl/CipherSuite.java
> ./share/classes/sun/security/rsa/RSAPadding.java
> ./share/classes/sun/security/ec/NamedCurve.java
> ./share/classes/sun/security/provider/MD2.java
> ./share/classes/sun/security/provider/MD5.java
> ./share/classes/sun/security/provider/DSA.java
> ./share/classes/sun/security/provider/ByteArrayAccess.java
> ./share/classes/sun/security/smartcardio/PCSC.java
> ./share/classes/sun/security/smartcardio/CardImpl.java
> ./share/classes/sun/security/smartcardio/ChannelImpl.java
> ./share/classes/sun/reflect/UTF8.java
> ./share/classes/sun/reflect/ClassFileAssembler.java
> ./share/classes/sun/reflect/annotation/AnnotationParser.java
> ./share/classes/sun/invoke/anon/ConstantPoolPatch.java
> ./share/classes/sun/invoke/anon/ConstantPoolParser.java
> ./share/classes/sun/invoke/anon/ConstantPoolVisitor.java
> ./share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java
>
> ./share/classes/sun/management/ManagementFactoryHelper.java
> ./share/classes/sun/awt/FontConfiguration.java
> ./share/classes/sun/awt/image/ImageRepresentation.java
> ./share/classes/sun/awt/image/PixelConverter.java
> ./share/classes/sun/awt/image/PNGImageDecoder.java
> ./share/classes/sun/awt/image/GifImageDecoder.java
> ./share/classes/sun/awt/image/BytePackedRaster.java
> ./share/classes/sun/awt/image/BufferedImageGraphicsConfig.java
> ./share/classes/sun/awt/image/JPEGImageDecoder.java
> ./share/classes/sun/awt/image/ByteInterleavedRaster.java
> ./share/classes/sun/awt/image/BufImgSurfaceData.java
> ./share/classes/sun/awt/image/OffScreenImageSource.java
> ./share/classes/sun/awt/datatransfer/DataTransferer.java
> ./share/classes/sun/awt/PlatformFont.java
> ./share/classes/sun/nio/cs/UnicodeEncoder.java
> ./share/classes/sun/nio/cs/ISO_8859_1.java
> ./share/classes/sun/nio/cs/UTF_8.java
> ./share/classes/sun/nio/cs/UTF_32Coder.java
> ./share/classes/sun/nio/cs/CharsetMapping.java
> ./share/classes/sun/nio/cs/ext/DoubleByte.java
> ./share/classes/sun/nio/cs/ext/SimpleEUCEncoder.java
> ./share/classes/sun/nio/cs/ext/ISO2022_JP.java
> ./share/classes/sun/nio/cs/ext/IBM33722.java
> ./share/classes/sun/nio/cs/ext/EUC_TW.java
> ./share/classes/sun/nio/cs/ext/ISO2022_CN.java
> ./share/classes/sun/nio/cs/ext/IBM943C.java
> ./share/classes/sun/nio/cs/ext/HKSCS.java
> ./share/classes/sun/nio/cs/ext/IBM949C.java
> ./share/classes/sun/nio/cs/ext/DoubleByteDecoder.java
> ./share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java
> ./share/classes/sun/nio/cs/ext/DoubleByteEncoder.java
> ./share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java
> ./share/classes/sun/nio/cs/ext/SJIS.java
> ./share/classes/sun/nio/cs/ext/JISAutoDetect.java
> ./share/classes/sun/nio/cs/ext/EUC_JP.java
> ./share/classes/sun/nio/cs/ext/IBM964.java
> ./share/classes/sun/nio/cs/ext/GB18030.java
> ./share/classes/sun/nio/cs/ext/PCK.java
> ./share/classes/sun/nio/cs/ext/JIS_X_0201.java
> ./share/classes/sun/nio/cs/ext/EUC_JP_Open.java
> ./share/classes/sun/nio/cs/ext/SJIS_0213.java
> ./share/classes/sun/nio/cs/ext/Big5_Solaris.java
> ./share/classes/sun/nio/cs/ext/ISO2022.java
> ./share/classes/sun/nio/cs/SingleByte.java
> ./share/classes/sun/nio/cs/UnicodeDecoder.java
> ./share/classes/sun/nio/cs/CESU_8.java
> ./share/classes/sun/nio/ch/DatagramSocketAdaptor.java
> ./share/classes/sun/nio/ch/ChannelInputStream.java
> ./share/classes/sun/nio/ch/Net.java
> ./share/classes/sun/font/FileFontStrike.java
> ./share/classes/sun/font/ExtendedTextSourceLabel.java
> ./share/classes/sun/font/TrueTypeFont.java
> ./share/classes/sun/font/CompositeStrike.java
> ./share/classes/sun/font/TrueTypeGlyphMapper.java
> ./share/classes/sun/font/Type1Font.java
> ./share/classes/sun/font/GlyphList.java
> ./share/classes/sun/font/CMap.java
> ./share/classes/sun/font/PhysicalStrike.java
> ./share/classes/sun/font/Type1GlyphMapper.java
> ./share/classes/sun/font/FontDesignMetrics.java
> ./share/classes/sun/font/StandardGlyphVector.java
> ./share/classes/sun/font/CharToGlyphMapper.java
> ./share/classes/sun/font/CompositeGlyphMapper.java
> ./share/classes/sun/applet/AppletPanel.java
> ./share/classes/sun/launcher/LauncherHelper.java
> ./share/classes/sun/java2d/pisces/PiscesTileGenerator.java
> ./share/classes/sun/java2d/pipe/BufferedPaints.java
> ./share/classes/sun/java2d/pipe/AATileGenerator.java
> ./share/classes/sun/java2d/pipe/AAShapePipe.java
> ./share/classes/sun/java2d/pipe/BufferedTextPipe.java
> ./share/classes/sun/java2d/loops/MaskFill.java
> ./share/classes/sun/java2d/loops/MaskBlit.java
> ./share/classes/sun/java2d/loops/BlitBg.java
> ./share/classes/sun/java2d/SunGraphics2D.java
> ./share/classes/sun/java2d/cmm/CMSManager.java
> ./share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
> ./share/classes/sun/tools/java/Constants.java
> ./share/classes/sun/tools/java/Scanner.java
> ./share/classes/sun/tools/java/BinaryConstantPool.java
> ./share/classes/sun/tools/jconsole/ConnectDialog.java
> ./share/classes/sun/tools/jconsole/JConsole.java
> ./share/classes/sun/tools/jconsole/AboutDialog.java
> ./share/classes/sun/tools/jconsole/HTMLPane.java
> ./share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java
> ./share/classes/javax/sound/midi/MidiMessage.java
> ./share/classes/javax/sound/midi/ShortMessage.java
> ./share/classes/javax/sound/midi/MetaMessage.java
> ./share/classes/javax/sound/midi/SysexMessage.java
> ./share/classes/javax/sound/sampled/AudioInputStream.java
> ./share/classes/javax/crypto/CipherInputStream.java
> ./share/classes/javax/crypto/spec/DESKeySpec.java
> ./share/classes/javax/swing/DebugGraphicsFilter.java
> ./share/classes/javax/swing/JComponent.java
> ./share/classes/javax/swing/text/html/parser/Parser.java
> ./share/classes/javax/swing/text/html/parser/Entity.java
> ./share/classes/javax/swing/plaf/metal/MetalUtils.java
> ./share/classes/javax/swing/plaf/metal/OceanTheme.java
> ./share/classes/javax/swing/plaf/metal/MetalTheme.java
> ./share/classes/javax/swing/plaf/ColorUIResource.java
> ./share/classes/javax/swing/plaf/nimbus/DropShadowEffect.java
> ./share/classes/javax/swing/plaf/nimbus/EffectUtils.java
> ./share/classes/javax/swing/plaf/nimbus/InnerShadowEffect.java
> ./share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
> ./share/classes/javax/swing/plaf/nimbus/NimbusStyle.java
> ./share/classes/javax/swing/plaf/nimbus/DerivedColor.java
> ./share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java
> ./share/classes/javax/swing/JColorChooser.java
> ./share/classes/javax/swing/colorchooser/ColorChooserPanel.java
> ./share/classes/javax/swing/colorchooser/ColorModel.java
> ./share/classes/javax/swing/GrayFilter.java
> ./share/classes/javax/management/remote/rmi/RMIConnectorServer.java
> ./share/classes/javax/imageio/stream/ImageOutputStreamImpl.java
> ./share/classes/javax/imageio/stream/ImageOutputStream.java
> ./share/classes/javax/imageio/stream/ImageInputStream.java
> ./share/classes/javax/imageio/stream/ImageInputStreamImpl.java
> ./share/classes/javax/imageio/stream/MemoryCache.java
> ./share/classes/javax/imageio/ImageTypeSpecifier.java
> ./share/classes/javax/imageio/metadata/IIOMetadataNode.java
> ./share/classes/javax/smartcardio/ResponseAPDU.java
> ./share/classes/javax/smartcardio/CommandAPDU.java
>



From Ulf.Zibis at gmx.de Thu Jan 26 17:13:55 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 26 Jan 2012 18:13:55 +0100
Subject: Using unsigned library work in the JDK
In-Reply-To: <4F217B24.3030405@oracle.com>
References: <4F20D879.8010800@oracle.com> <4F217B24.3030405@oracle.com>
Message-ID: <4F2189D3.9080508@gmx.de>

Am 26.01.2012 17:11, schrieb Roger Riggs:
> Is there any performance impact of the method call vs the &0xff?
> Hotspot will in-line the code but for VMs with less sophisticated
> optimizations it will be a net loss.
+1
At least in interpreter and maybe -client compiler the new code would have performance impact.

> Its unfortunate that between the method name and need to qualify
> with the class (or use static imports) that the code is longer and not always clearer.
+1
- static import could become ambiguous using Byte.toUnsignedInt() + Short.toUnsignedInt() at same time.
+ The shortest I can think:
Short.unsigned(byte)
Integer.unsigned(short)
Long.unsigned(int)
BigInteger.unsigned(long)
+ Nothing would be ambiguous, using static import.

> The existing idiom for unsigned byte is easy enough to recognize.
> For the places where multiple bytes are assembled into short or integer,
> a new method with a specific purpose would be a clearer modification to the code.
+1
+ Would be an ideal candidate for intrinsification
+ See similar (vice versa): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6914113
- For type short a cast is needed using current implementation:
short s = (short) Byte.toUnsignedInt(byte)

> Seeing the use in the IO context, the method names may be more useful if they reflect the data
> taken from the argument. For example, asUnsignedByte(buffer[i]) .
+++ 1

> But I/O is more about assembling bytes and less about unsigned arithmetic.
Maybe java.io.Bits would be the right home for things like that.


-Ulf


From xueming.shen at oracle.com Thu Jan 26 17:52:03 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 26 Jan 2012 09:52:03 -0800
Subject: Using unsigned library work in the JDK
In-Reply-To: <4F20D879.8010800@oracle.com>
References: <4F20D879.8010800@oracle.com>
Message-ID: <4F2192C3.3080808@oracle.com>

Joe,

The changes look fine. However I have the same performance concern in
cases that the vm fails to inline the toUnsignedInt(), especially for those
"simple" one line utility methods, such as the get16(), CH(), SH(), my
guess is that it might have a performance impact. It might not be a big
deal for operation like creating or extracting a jar/zip file but
probably will
slow down the loc/cen table reading only operation such as list a jar/zip
file. I will try to get some performance data to see if the impact is
"significant" enough to be a real concern.

-Sherman

On 01/25/2012 08:37 PM, Joe Darcy wrote:
> Hello,
>
> As a follow-up to the recent push of unsigned library support in the
> JDK [1], I grepped -i for "0xff" in the JDK code base to look for
> candidate locations to use the new methods. I choose to first tackle
> some jar/zip code.
>
> Sherman, can you review the changes below?
>
> diff -r 303b67074666 src/share/classes/java/util/jar/JarOutputStream.java
> --- a/src/share/classes/java/util/jar/JarOutputStream.java Tue Jan
> 24 15:13:27 2012 -0500
> +++ b/src/share/classes/java/util/jar/JarOutputStream.java Wed Jan
> 25 20:31:05 2012 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -135,7 +135,7 @@
> * The bytes are assumed to be in Intel (little-endian) byte order.
> */
> private static int get16(byte[] b, int off) {
> - return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8);
> + return Byte.toUnsignedInt(b[off]) | (
> Byte.toUnsignedInt(b[off+1]) << 8);
> }
>
> /*
> diff -r 303b67074666 src/share/classes/java/util/jar/Manifest.java
> --- a/src/share/classes/java/util/jar/Manifest.java Tue Jan 24
> 15:13:27 2012 -0500
> +++ b/src/share/classes/java/util/jar/Manifest.java Wed Jan 25
> 20:31:05 2012 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -339,7 +339,7 @@
> return -1;
> }
> }
> - return buf[pos++] & 0xff;
> + return Byte.toUnsignedInt(buf[pos++]);
> }
>
> public int read(byte[] b, int off, int len) throws IOException {
> diff -r 303b67074666
> src/share/classes/java/util/zip/InflaterInputStream.java
> --- a/src/share/classes/java/util/zip/InflaterInputStream.java Tue
> Jan 24 15:13:27 2012 -0500
> +++ b/src/share/classes/java/util/zip/InflaterInputStream.java Wed
> Jan 25 20:31:05 2012 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -119,7 +119,7 @@
> */
> public int read() throws IOException {
> ensureOpen();
> - return read(singleByteBuf, 0, 1) == -1 ? -1 :
> singleByteBuf[0] & 0xff;
> + return read(singleByteBuf, 0, 1) == -1 ? -1 :
> Byte.toUnsignedInt(singleByteBuf[0]);
> }
>
> /**
> diff -r 303b67074666 src/share/classes/java/util/zip/ZipInputStream.java
> --- a/src/share/classes/java/util/zip/ZipInputStream.java Tue Jan
> 24 15:13:27 2012 -0500
> +++ b/src/share/classes/java/util/zip/ZipInputStream.java Wed Jan
> 25 20:31:05 2012 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights
> reserved.
> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> *
> * This code is free software; you can redistribute it and/or modify it
> @@ -435,7 +435,7 @@
> * The bytes are assumed to be in Intel (little-endian) byte order.
> */
> private static final int get16(byte b[], int off) {
> - return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8);
> + return Byte.toUnsignedInt(b[off]) |
> (Byte.toUnsignedInt(b[off+1]) << 8);
> }
>
> /*
> diff -r 303b67074666
> src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
> ---
> a/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
> Tue Jan 24 15:13:27 2012 -0500
> +++
> b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
> Wed Jan 25 20:31:05 2012 -0800
> @@ -185,11 +185,11 @@
> */
> ///////////////////////////////////////////////////////
> static final int CH(byte[] b, int n) {
> - return b[n] & 0xff;
> + return Byte.toUnsignedInt(b[n]);
> }
>
> static final int SH(byte[] b, int n) {
> - return (b[n] & 0xff) | ((b[n + 1] & 0xff) << 8);
> + return Byte.toUnsignedInt(b[n]) | (Byte.toUnsignedInt(b[n +
> 1]) << 8);
> }
>
> static final long LG(byte[] b, int n) {
>
> If the changes look good, I'll file a bug for them, etc.
>
> In case other people want to look over candidates sites in different
> areas, I've included the list of JDK files using "0xff" below.
>
> Thanks,
>
> -Joe
>
> [1] 4504839: Java libraries should provide support for unsigned
> integer arithmetic
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008926.html
>
>
> ./solaris/classes/java/util/prefs/FileSystemPreferences.java
> ./solaris/classes/sun/print/AttributeClass.java
> ./solaris/classes/sun/net/sdp/SdpProvider.java
> ./solaris/classes/sun/awt/X11/XIconInfo.java
> ./solaris/classes/sun/awt/X11/XKeySymConstants.java
> ./solaris/classes/sun/awt/X11/MotifDnDConstants.java
> ./solaris/classes/sun/awt/X11/XIconWindow.java
> ./solaris/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java
> ./solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java
> ./solaris/classes/sun/awt/X11/XAtom.java
> ./solaris/classes/sun/awt/X11/MotifColorUtilities.java
> ./solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java
> ./solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java
> ./solaris/classes/sun/awt/X11/Native.java
> ./solaris/classes/sun/awt/X11/XKeysym.java
> ./solaris/classes/sun/awt/X11/XToolkit.java
> ./solaris/classes/sun/awt/X11/XDnDConstants.java
> ./solaris/classes/sun/awt/X11/XWM.java
> ./solaris/classes/sun/awt/X11/XWindowPeer.java
> ./solaris/classes/sun/awt/X11GraphicsConfig.java
> ./solaris/classes/sun/awt/motif/X11KSC5601.java
> ./solaris/classes/sun/awt/motif/X11GB2312.java
> ./solaris/classes/sun/awt/motif/X11CNS11643.java
> ./solaris/classes/sun/awt/motif/X11JIS0201.java
> ./solaris/classes/sun/awt/X11CustomCursor.java
> ./solaris/classes/sun/awt/XSettings.java
> ./solaris/classes/sun/nio/fs/UnixPath.java
> ./solaris/classes/sun/nio/fs/UnixUriUtils.java
> ./solaris/classes/sun/nio/cs/ext/CompoundTextSupport.java
> ./solaris/classes/sun/nio/cs/ext/COMPOUND_TEXT_Decoder.java
> ./solaris/classes/sun/font/XMap.java
> ./solaris/classes/sun/font/XRGlyphCacheEntry.java
> ./solaris/classes/sun/font/NativeStrike.java
> ./solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
> ./solaris/classes/sun/java2d/xr/XRSurfaceData.java
> ./solaris/classes/sun/java2d/xr/XRPaints.java
> ./solaris/classes/sun/java2d/xr/XRColor.java
> ./solaris/classes/sun/java2d/xr/XRCompositeManager.java
> ./solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java
> ./solaris/classes/sun/java2d/x11/X11SurfaceDataProxy.java
> ./solaris/classes/sun/java2d/x11/X11SurfaceData.java
> ./solaris/classes/sun/tools/attach/SolarisVirtualMachine.java
> ./solaris/classes/sun/tools/attach/LinuxVirtualMachine.java
> ./windows/classes/java/util/prefs/WindowsPreferences.java
> ./windows/classes/com/sun/tools/jdi/SharedMemoryTransportService.java
> ./windows/classes/sun/awt/Win32GraphicsConfig.java
> ./windows/classes/sun/awt/windows/WPathGraphics.java
> ./windows/classes/sun/awt/windows/WCustomCursor.java
> ./windows/classes/sun/awt/windows/WWindowPeer.java
> ./windows/classes/sun/awt/windows/WTrayIconPeer.java
> ./windows/classes/sun/awt/windows/WPrinterJob.java
> ./windows/classes/sun/nio/fs/WindowsFileAttributes.java
> ./windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java
> ./windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java
> ./windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java
> ./windows/classes/sun/tools/attach/WindowsVirtualMachine.java
> ./share/demo/applets/WireFrame/ThreeD.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java
> ./share/demo/jfc/Font2DTest/FontPanel.java
> ./share/demo/jfc/Font2DTest/RangeMenu.java
> ./share/demo/jfc/Font2DTest/Font2DTest.java
> ./share/demo/jfc/CodePointIM/CodePointInputMethod.java
> ./share/demo/java2d/J2DBench/src/j2dbench/tests/PixelTests.java
> ./share/demo/java2d/J2DBench/src/j2dbench/tests/iio/IIOTests.java
> ./share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java
> ./share/classes/java/rmi/dgc/VMID.java
> ./share/classes/java/beans/XMLEncoder.java
> ./share/classes/java/net/URLConnection.java
> ./share/classes/java/net/Inet6Address.java
> ./share/classes/java/net/Inet4Address.java
> ./share/classes/java/net/DatagramPacket.java
> ./share/classes/java/net/SocketInputStream.java
> ./share/classes/java/net/MulticastSocket.java
> ./share/classes/java/net/SocksSocketImpl.java
> ./share/classes/java/net/SocketPermission.java
> ./share/classes/java/net/DatagramSocket.java
> ./share/classes/java/net/ServerSocket.java
> ./share/classes/java/net/InetSocketAddress.java
> ./share/classes/java/net/URI.java
> ./share/classes/java/lang/Character.java
> ./share/classes/java/lang/Byte.java
> ./share/classes/java/lang/Float.java
> ./share/classes/java/lang/Double.java
> ./share/classes/java/lang/Long.java
> ./share/classes/java/lang/CharacterData.java
> ./share/classes/java/lang/String.java
> ./share/classes/java/lang/invoke/MethodType.java
> ./share/classes/java/lang/invoke/MethodTypeForm.java
> ./share/classes/java/lang/invoke/MethodHandle.java
> ./share/classes/java/lang/invoke/MemberName.java
> ./share/classes/java/lang/CharacterName.java
> ./share/classes/java/lang/Integer.java
> ./share/classes/java/lang/Short.java
> ./share/classes/java/text/BreakIterator.java
> ./share/classes/java/text/CollationElementIterator.java
> ./share/classes/java/text/RuleBasedCollator.java
> ./share/classes/java/text/RBCollationTables.java
> ./share/classes/java/text/SimpleDateFormat.java
> ./share/classes/java/text/RBTableBuilder.java
> ./share/classes/java/io/ByteArrayOutputStream.java
> ./share/classes/java/io/DataOutputStream.java
> ./share/classes/java/io/DataInputStream.java
> ./share/classes/java/io/Reader.java
> ./share/classes/java/io/StringBufferInputStream.java
> ./share/classes/java/io/PushbackInputStream.java
> ./share/classes/java/io/Bits.java
> ./share/classes/java/io/DataOutput.java
> ./share/classes/java/io/RandomAccessFile.java
> ./share/classes/java/io/BufferedReader.java
> ./share/classes/java/io/ObjectInputStream.java
> ./share/classes/java/io/ByteArrayInputStream.java
> ./share/classes/java/io/DataInput.java
> ./share/classes/java/io/BufferedInputStream.java
> ./share/classes/java/io/ObjectStreamClass.java
> ./share/classes/java/io/ObjectOutputStream.java
> ./share/classes/java/io/PipedInputStream.java
> ./share/classes/java/util/regex/UnicodeProp.java
> ./share/classes/java/util/regex/Pattern.java
> ./share/classes/java/util/regex/ASCII.java
> ./share/classes/java/util/Properties.java
> ./share/classes/java/util/jar/JarOutputStream.java
> ./share/classes/java/util/jar/Manifest.java
> ./share/classes/java/util/jar/JarEntry.java
> ./share/classes/java/util/BitSet.java
> ./share/classes/java/util/concurrent/Phaser.java
> ./share/classes/java/util/concurrent/Exchanger.java
> ./share/classes/java/util/concurrent/ForkJoinPool.java
> ./share/classes/java/util/concurrent/ConcurrentHashMap.java
> ./share/classes/java/util/concurrent/ForkJoinWorkerThread.java
> ./share/classes/java/util/zip/DeflaterOutputStream.java
> ./share/classes/java/util/zip/InflaterInputStream.java
> ./share/classes/java/util/zip/GZIPInputStream.java
> ./share/classes/java/util/zip/DeflaterInputStream.java
> ./share/classes/java/util/zip/ZipConstants64.java
> ./share/classes/java/util/zip/ZipInputStream.java
> ./share/classes/java/util/zip/ZipOutputStream.java
> ./share/classes/java/util/zip/ZipFile.java
> ./share/classes/java/util/zip/CRC32.java
> ./share/classes/java/util/zip/Adler32.java
> ./share/classes/java/util/zip/GZIPOutputStream.java
> ./share/classes/java/util/zip/ZipEntry.java
> ./share/classes/java/util/UUID.java
> ./share/classes/java/util/prefs/Base64.java
> ./share/classes/java/security/SecureRandom.java
> ./share/classes/java/awt/Color.java
> ./share/classes/java/awt/GradientPaintContext.java
> ./share/classes/java/awt/TexturePaintContext.java
> ./share/classes/java/awt/AlphaComposite.java
> ./share/classes/java/awt/event/KeyEvent.java
> ./share/classes/java/awt/SystemColor.java
> ./share/classes/java/awt/image/DataBufferByte.java
> ./share/classes/java/awt/image/ByteLookupTable.java
> ./share/classes/java/awt/image/MultiPixelPackedSampleModel.java
> ./share/classes/java/awt/image/ComponentSampleModel.java
> ./share/classes/java/awt/image/ComponentColorModel.java
> ./share/classes/java/awt/image/DataBuffer.java
> ./share/classes/java/awt/image/DataBufferUShort.java
> ./share/classes/java/awt/image/SinglePixelPackedSampleModel.java
> ./share/classes/java/awt/image/BufferedImageFilter.java
> ./share/classes/java/awt/image/RescaleOp.java
> ./share/classes/java/awt/image/ColorConvertOp.java
> ./share/classes/java/awt/image/IndexColorModel.java
> ./share/classes/java/awt/image/AreaAveragingScaleFilter.java
> ./share/classes/java/awt/image/BandedSampleModel.java
> ./share/classes/java/awt/image/BufferedImage.java
> ./share/classes/java/awt/image/ShortLookupTable.java
> ./share/classes/java/awt/image/DirectColorModel.java
> ./share/classes/java/awt/image/RGBImageFilter.java
> ./share/classes/java/awt/image/PixelGrabber.java
> ./share/classes/java/awt/image/ColorModel.java
> ./share/classes/java/awt/MultipleGradientPaint.java
> ./share/classes/java/awt/color/ICC_ProfileRGB.java
> ./share/classes/java/awt/color/ICC_ProfileGray.java
> ./share/classes/java/awt/color/ICC_Profile.java
> ./share/classes/java/awt/color/ICC_ColorSpace.java
> ./share/classes/java/awt/MultipleGradientPaintContext.java
> ./share/classes/java/awt/FontMetrics.java
> ./share/classes/java/awt/font/NumericShaper.java
> ./share/classes/java/awt/GradientPaint.java
> ./share/classes/java/nio/Bits.java
> ./share/classes/java/nio/channels/Channels.java
> ./share/classes/java/math/BigInteger.java
> ./share/classes/com/sun/beans/decoder/LongElementHandler.java
> ./share/classes/com/sun/jmx/snmp/SnmpIpAddress.java
> ./share/classes/com/sun/jmx/snmp/SnmpString.java
> ./share/classes/com/sun/jmx/snmp/IPAcl/ASCII_CharStream.java
> ./share/classes/com/sun/jmx/snmp/IPAcl/ParserTokenManager.java
> ./share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java
> ./share/classes/com/sun/jmx/snmp/SnmpEngineId.java
> ./share/classes/com/sun/jmx/snmp/SnmpMsg.java
> ./share/classes/com/sun/java/swing/plaf/gtk/GTKColorType.java
> ./share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java
> ./share/classes/com/sun/java/swing/plaf/gtk/Metacity.java
> ./share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java
> ./share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
> ./share/classes/com/sun/java/util/jar/pack/PackageWriter.java
> ./share/classes/com/sun/java/util/jar/pack/Coding.java
> ./share/classes/com/sun/java/util/jar/pack/PackageReader.java
> ./share/classes/com/sun/java/util/jar/pack/Histogram.java
> ./share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java
> ./share/classes/com/sun/java/util/jar/pack/PopulationCoding.java
> ./share/classes/com/sun/java/util/jar/pack/Attribute.java
> ./share/classes/com/sun/java/util/jar/pack/Fixups.java
> ./share/classes/com/sun/java/util/jar/pack/BandStructure.java
> ./share/classes/com/sun/java/util/jar/pack/Instruction.java
> ./share/classes/com/sun/net/httpserver/BasicAuthenticator.java
> ./share/classes/com/sun/crypto/provider/BlowfishCrypt.java
> ./share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
> ./share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
> ./share/classes/com/sun/crypto/provider/ISO10126Padding.java
> ./share/classes/com/sun/crypto/provider/RC2Crypt.java
> ./share/classes/com/sun/crypto/provider/AESCrypt.java
> ./share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java
> ./share/classes/com/sun/crypto/provider/ARCFOURCipher.java
> ./share/classes/com/sun/crypto/provider/PKCS5Padding.java
> ./share/classes/com/sun/crypto/provider/RC2Parameters.java
> ./share/classes/com/sun/security/ntlm/NTLM.java
> ./share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java
> ./share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
> ./share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
> ./share/classes/com/sun/imageio/plugins/png/RowFilter.java
> ./share/classes/com/sun/imageio/plugins/png/PNGMetadata.java
> ./share/classes/com/sun/imageio/plugins/jpeg/DHTMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/DQTMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/AdobeMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/DRIMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReaderSpi.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGBuffer.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/MarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFImageMetadata.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java
> ./share/classes/com/sun/imageio/plugins/common/LZWCompressor.java
> ./share/classes/com/sun/imageio/plugins/common/PaletteBuilder.java
> ./share/classes/com/sun/imageio/plugins/common/LZWStringTable.java
> ./share/classes/com/sun/imageio/plugins/common/ImageUtil.java
> ./share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java
> ./share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java
> ./share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java
> ./share/classes/com/sun/media/sound/AudioFloatConverter.java
> ./share/classes/com/sun/media/sound/StandardMidiFileWriter.java
> ./share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java
> ./share/classes/com/sun/media/sound/SunFileReader.java
> ./share/classes/com/sun/media/sound/MidiInDevice.java
> ./share/classes/com/sun/media/sound/FastSysexMessage.java
> ./share/classes/com/sun/media/sound/SunFileWriter.java
> ./share/classes/com/sun/media/sound/SF2Region.java
> ./share/classes/com/sun/media/sound/AlawCodec.java
> ./share/classes/com/sun/media/sound/MidiOutDevice.java
> ./share/classes/com/sun/media/sound/UlawCodec.java
> ./share/classes/com/sun/media/sound/AudioFloatFormatConverter.java
> ./share/classes/com/sun/media/sound/FastShortMessage.java
> ./share/classes/com/sun/media/sound/SoftJitterCorrector.java
> ./share/classes/com/sun/media/sound/SoftMixingMainMixer.java
> ./share/classes/com/sun/media/sound/SoftMainMixer.java
> ./share/classes/com/sun/media/sound/RIFFWriter.java
> ./share/classes/com/sun/media/sound/StandardMidiFileReader.java
> ./share/classes/com/sun/media/sound/SoftTuning.java
> ./share/classes/com/sun/media/sound/SoftMixingClip.java
> ./share/classes/com/sun/media/sound/WaveExtensibleFileReader.java
> ./share/classes/com/sun/media/sound/ModelByteBufferWavetable.java
> ./share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java
> ./share/classes/com/sun/media/sound/SoftSynthesizer.java
> ./share/classes/com/sun/media/sound/PortMixer.java
> ./share/classes/com/sun/media/sound/MidiUtils.java
> ./share/classes/com/sun/media/sound/RealTimeSequencer.java
> ./share/classes/com/sun/media/sound/AbstractMidiDevice.java
> ./share/classes/com/sun/jndi/dns/Header.java
> ./share/classes/com/sun/jndi/dns/DnsClient.java
> ./share/classes/com/sun/jndi/dns/ResourceRecord.java
> ./share/classes/com/sun/jndi/dns/DnsName.java
> ./share/classes/com/sun/jndi/ldap/BerEncoder.java
> ./share/classes/com/sun/jndi/ldap/BerDecoder.java
> ./share/classes/com/sun/jndi/ldap/Connection.java
> ./share/classes/com/sun/jndi/ldap/sasl/SaslOutputStream.java
> ./share/classes/com/sun/jndi/ldap/sasl/SaslInputStream.java
> ./share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java
> ./share/classes/com/sun/tools/hat/internal/model/JavaByte.java
> ./share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java
> ./share/classes/com/sun/tools/hat/internal/util/Misc.java
> ./share/classes/com/sun/tools/hat/internal/parser/HprofReader.java
> ./share/classes/com/sun/tools/example/debug/expr/ASCII_UCodeESC_CharStream.java
>
> ./share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java
>
> ./share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java
> ./share/classes/com/sun/tools/example/debug/gui/Icons.java
> ./share/classes/com/sun/tools/example/debug/tty/Commands.java
> ./share/classes/com/sun/tools/jdi/Packet.java
> ./share/classes/com/sun/tools/jdi/TargetVM.java
> ./share/classes/com/sun/tools/jdi/PacketStream.java
> ./share/classes/com/sun/tools/jdi/SocketTransportService.java
> ./share/classes/sun/rmi/rmic/newrmic/jrmp/RemoteClass.java
> ./share/classes/sun/rmi/rmic/RemoteClass.java
> ./share/classes/sun/rmi/server/Util.java
> ./share/classes/sun/rmi/transport/tcp/MultiplexInputStream.java
> ./share/classes/sun/rmi/transport/proxy/CGIHandler.java
> ./share/classes/sun/print/PrinterGraphicsConfig.java
> ./share/classes/sun/print/PathGraphics.java
> ./share/classes/sun/print/PSPrinterJob.java
> ./share/classes/sun/net/util/IPAddressUtil.java
> ./share/classes/sun/net/ftp/impl/FtpClient.java
> ./share/classes/sun/net/httpserver/SSLStreams.java
> ./share/classes/sun/net/httpserver/LeftOverInputStream.java
> ./share/classes/sun/net/httpserver/Request.java
> ./share/classes/sun/net/idn/Punycode.java
> ./share/classes/sun/net/idn/StringPrep.java
> ./share/classes/sun/net/spi/nameservice/dns/DNSNameService.java
> ./share/classes/sun/net/www/http/ChunkedInputStream.java
> ./share/classes/sun/net/www/ParseUtil.java
> ./share/classes/sun/text/IntHashtable.java
> ./share/classes/sun/text/UCompactIntArray.java
> ./share/classes/sun/text/normalizer/UCharacterProperty.java
> ./share/classes/sun/text/normalizer/UCharacter.java
> ./share/classes/sun/text/normalizer/Utility.java
> ./share/classes/sun/text/normalizer/NormalizerBase.java
> ./share/classes/sun/text/normalizer/NormalizerDataReader.java
> ./share/classes/sun/text/normalizer/NormalizerImpl.java
> ./share/classes/sun/text/normalizer/UCharacterIterator.java
> ./share/classes/sun/text/normalizer/UnicodeSet.java
> ./share/classes/sun/text/bidi/BidiBase.java
> ./share/classes/sun/text/SupplementaryCharacterData.java
> ./share/classes/sun/text/CompactByteArray.java
> ./share/classes/sun/misc/UCEncoder.java
> ./share/classes/sun/misc/FormattedFloatingDecimal.java
> ./share/classes/sun/misc/CRC16.java
> ./share/classes/sun/misc/UCDecoder.java
> ./share/classes/sun/misc/ProxyGenerator.java
> ./share/classes/sun/misc/BASE64Decoder.java
> ./share/classes/sun/misc/UUDecoder.java
> ./share/classes/sun/misc/FloatingDecimal.java
> ./share/classes/sun/misc/HexDumpEncoder.java
> ./share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java
> ./share/classes/sun/util/calendar/ZoneInfoFile.java
> ./share/classes/sun/security/krb5/EncryptedData.java
> ./share/classes/sun/security/krb5/internal/ccache/CCacheOutputStream.java
> ./share/classes/sun/security/krb5/internal/crypto/crc32.java
> ./share/classes/sun/security/krb5/internal/crypto/Des.java
> ./share/classes/sun/security/krb5/internal/crypto/dk/ArcFourCrypto.java
> ./share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java
> ./share/classes/sun/security/krb5/internal/crypto/dk/AesDkCrypto.java
> ./share/classes/sun/security/krb5/internal/crypto/Crc32CksumType.java
> ./share/classes/sun/security/krb5/internal/util/KrbDataOutputStream.java
> ./share/classes/sun/security/krb5/internal/util/KrbDataInputStream.java
> ./share/classes/sun/security/krb5/internal/NetClient.java
> ./share/classes/sun/security/krb5/internal/LocalSeqNumber.java
> ./share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java
> ./share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java
> ./share/classes/sun/security/pkcs11/SunPKCS11.java
> ./share/classes/sun/security/pkcs11/wrapper/CK_VERSION.java
> ./share/classes/sun/security/pkcs11/wrapper/Functions.java
> ./share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java
> ./share/classes/sun/security/pkcs11/P11Key.java
> ./share/classes/sun/security/pkcs11/P11Util.java
> ./share/classes/sun/security/x509/X509Key.java
> ./share/classes/sun/security/jgss/krb5/MessageToken_v2.java
> ./share/classes/sun/security/jgss/krb5/MessageToken.java
> ./share/classes/sun/security/jgss/wrapper/GSSNameElement.java
> ./share/classes/sun/security/jgss/GSSNameImpl.java
> ./share/classes/sun/security/jgss/GSSToken.java
> ./share/classes/sun/security/util/Debug.java
> ./share/classes/sun/security/util/ByteArrayLexOrder.java
> ./share/classes/sun/security/util/BitArray.java
> ./share/classes/sun/security/util/DerOutputStream.java
> ./share/classes/sun/security/util/Cache.java
> ./share/classes/sun/security/util/DerValue.java
> ./share/classes/sun/security/util/DerIndefLenConverter.java
> ./share/classes/sun/security/util/DerInputStream.java
> ./share/classes/sun/security/util/DerInputBuffer.java
> ./share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
> ./share/classes/sun/security/ssl/OutputRecord.java
> ./share/classes/sun/security/ssl/ProtocolVersion.java
> ./share/classes/sun/security/ssl/CipherBox.java
> ./share/classes/sun/security/ssl/HelloExtensions.java
> ./share/classes/sun/security/ssl/InputRecord.java
> ./share/classes/sun/security/ssl/HandshakeMessage.java
> ./share/classes/sun/security/ssl/EngineInputRecord.java
> ./share/classes/sun/security/ssl/MAC.java
> ./share/classes/sun/security/ssl/AppInputStream.java
> ./share/classes/sun/security/ssl/CipherSuite.java
> ./share/classes/sun/security/rsa/RSAPadding.java
> ./share/classes/sun/security/ec/NamedCurve.java
> ./share/classes/sun/security/provider/MD2.java
> ./share/classes/sun/security/provider/MD5.java
> ./share/classes/sun/security/provider/DSA.java
> ./share/classes/sun/security/provider/ByteArrayAccess.java
> ./share/classes/sun/security/smartcardio/PCSC.java
> ./share/classes/sun/security/smartcardio/CardImpl.java
> ./share/classes/sun/security/smartcardio/ChannelImpl.java
> ./share/classes/sun/reflect/UTF8.java
> ./share/classes/sun/reflect/ClassFileAssembler.java
> ./share/classes/sun/reflect/annotation/AnnotationParser.java
> ./share/classes/sun/invoke/anon/ConstantPoolPatch.java
> ./share/classes/sun/invoke/anon/ConstantPoolParser.java
> ./share/classes/sun/invoke/anon/ConstantPoolVisitor.java
> ./share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java
>
> ./share/classes/sun/management/ManagementFactoryHelper.java
> ./share/classes/sun/awt/FontConfiguration.java
> ./share/classes/sun/awt/image/ImageRepresentation.java
> ./share/classes/sun/awt/image/PixelConverter.java
> ./share/classes/sun/awt/image/PNGImageDecoder.java
> ./share/classes/sun/awt/image/GifImageDecoder.java
> ./share/classes/sun/awt/image/BytePackedRaster.java
> ./share/classes/sun/awt/image/BufferedImageGraphicsConfig.java
> ./share/classes/sun/awt/image/JPEGImageDecoder.java
> ./share/classes/sun/awt/image/ByteInterleavedRaster.java
> ./share/classes/sun/awt/image/BufImgSurfaceData.java
> ./share/classes/sun/awt/image/OffScreenImageSource.java
> ./share/classes/sun/awt/datatransfer/DataTransferer.java
> ./share/classes/sun/awt/PlatformFont.java
> ./share/classes/sun/nio/cs/UnicodeEncoder.java
> ./share/classes/sun/nio/cs/ISO_8859_1.java
> ./share/classes/sun/nio/cs/UTF_8.java
> ./share/classes/sun/nio/cs/UTF_32Coder.java
> ./share/classes/sun/nio/cs/CharsetMapping.java
> ./share/classes/sun/nio/cs/ext/DoubleByte.java
> ./share/classes/sun/nio/cs/ext/SimpleEUCEncoder.java
> ./share/classes/sun/nio/cs/ext/ISO2022_JP.java
> ./share/classes/sun/nio/cs/ext/IBM33722.java
> ./share/classes/sun/nio/cs/ext/EUC_TW.java
> ./share/classes/sun/nio/cs/ext/ISO2022_CN.java
> ./share/classes/sun/nio/cs/ext/IBM943C.java
> ./share/classes/sun/nio/cs/ext/HKSCS.java
> ./share/classes/sun/nio/cs/ext/IBM949C.java
> ./share/classes/sun/nio/cs/ext/DoubleByteDecoder.java
> ./share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java
> ./share/classes/sun/nio/cs/ext/DoubleByteEncoder.java
> ./share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java
> ./share/classes/sun/nio/cs/ext/SJIS.java
> ./share/classes/sun/nio/cs/ext/JISAutoDetect.java
> ./share/classes/sun/nio/cs/ext/EUC_JP.java
> ./share/classes/sun/nio/cs/ext/IBM964.java
> ./share/classes/sun/nio/cs/ext/GB18030.java
> ./share/classes/sun/nio/cs/ext/PCK.java
> ./share/classes/sun/nio/cs/ext/JIS_X_0201.java
> ./share/classes/sun/nio/cs/ext/EUC_JP_Open.java
> ./share/classes/sun/nio/cs/ext/SJIS_0213.java
> ./share/classes/sun/nio/cs/ext/Big5_Solaris.java
> ./share/classes/sun/nio/cs/ext/ISO2022.java
> ./share/classes/sun/nio/cs/SingleByte.java
> ./share/classes/sun/nio/cs/UnicodeDecoder.java
> ./share/classes/sun/nio/cs/CESU_8.java
> ./share/classes/sun/nio/ch/DatagramSocketAdaptor.java
> ./share/classes/sun/nio/ch/ChannelInputStream.java
> ./share/classes/sun/nio/ch/Net.java
> ./share/classes/sun/font/FileFontStrike.java
> ./share/classes/sun/font/ExtendedTextSourceLabel.java
> ./share/classes/sun/font/TrueTypeFont.java
> ./share/classes/sun/font/CompositeStrike.java
> ./share/classes/sun/font/TrueTypeGlyphMapper.java
> ./share/classes/sun/font/Type1Font.java
> ./share/classes/sun/font/GlyphList.java
> ./share/classes/sun/font/CMap.java
> ./share/classes/sun/font/PhysicalStrike.java
> ./share/classes/sun/font/Type1GlyphMapper.java
> ./share/classes/sun/font/FontDesignMetrics.java
> ./share/classes/sun/font/StandardGlyphVector.java
> ./share/classes/sun/font/CharToGlyphMapper.java
> ./share/classes/sun/font/CompositeGlyphMapper.java
> ./share/classes/sun/applet/AppletPanel.java
> ./share/classes/sun/launcher/LauncherHelper.java
> ./share/classes/sun/java2d/pisces/PiscesTileGenerator.java
> ./share/classes/sun/java2d/pipe/BufferedPaints.java
> ./share/classes/sun/java2d/pipe/AATileGenerator.java
> ./share/classes/sun/java2d/pipe/AAShapePipe.java
> ./share/classes/sun/java2d/pipe/BufferedTextPipe.java
> ./share/classes/sun/java2d/loops/MaskFill.java
> ./share/classes/sun/java2d/loops/MaskBlit.java
> ./share/classes/sun/java2d/loops/BlitBg.java
> ./share/classes/sun/java2d/SunGraphics2D.java
> ./share/classes/sun/java2d/cmm/CMSManager.java
> ./share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
> ./share/classes/sun/tools/java/Constants.java
> ./share/classes/sun/tools/java/Scanner.java
> ./share/classes/sun/tools/java/BinaryConstantPool.java
> ./share/classes/sun/tools/jconsole/ConnectDialog.java
> ./share/classes/sun/tools/jconsole/JConsole.java
> ./share/classes/sun/tools/jconsole/AboutDialog.java
> ./share/classes/sun/tools/jconsole/HTMLPane.java
> ./share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java
> ./share/classes/javax/sound/midi/MidiMessage.java
> ./share/classes/javax/sound/midi/ShortMessage.java
> ./share/classes/javax/sound/midi/MetaMessage.java
> ./share/classes/javax/sound/midi/SysexMessage.java
> ./share/classes/javax/sound/sampled/AudioInputStream.java
> ./share/classes/javax/crypto/CipherInputStream.java
> ./share/classes/javax/crypto/spec/DESKeySpec.java
> ./share/classes/javax/swing/DebugGraphicsFilter.java
> ./share/classes/javax/swing/JComponent.java
> ./share/classes/javax/swing/text/html/parser/Parser.java
> ./share/classes/javax/swing/text/html/parser/Entity.java
> ./share/classes/javax/swing/plaf/metal/MetalUtils.java
> ./share/classes/javax/swing/plaf/metal/OceanTheme.java
> ./share/classes/javax/swing/plaf/metal/MetalTheme.java
> ./share/classes/javax/swing/plaf/ColorUIResource.java
> ./share/classes/javax/swing/plaf/nimbus/DropShadowEffect.java
> ./share/classes/javax/swing/plaf/nimbus/EffectUtils.java
> ./share/classes/javax/swing/plaf/nimbus/InnerShadowEffect.java
> ./share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
> ./share/classes/javax/swing/plaf/nimbus/NimbusStyle.java
> ./share/classes/javax/swing/plaf/nimbus/DerivedColor.java
> ./share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java
> ./share/classes/javax/swing/JColorChooser.java
> ./share/classes/javax/swing/colorchooser/ColorChooserPanel.java
> ./share/classes/javax/swing/colorchooser/ColorModel.java
> ./share/classes/javax/swing/GrayFilter.java
> ./share/classes/javax/management/remote/rmi/RMIConnectorServer.java
> ./share/classes/javax/imageio/stream/ImageOutputStreamImpl.java
> ./share/classes/javax/imageio/stream/ImageOutputStream.java
> ./share/classes/javax/imageio/stream/ImageInputStream.java
> ./share/classes/javax/imageio/stream/ImageInputStreamImpl.java
> ./share/classes/javax/imageio/stream/MemoryCache.java
> ./share/classes/javax/imageio/ImageTypeSpecifier.java
> ./share/classes/javax/imageio/metadata/IIOMetadataNode.java
> ./share/classes/javax/smartcardio/ResponseAPDU.java
> ./share/classes/javax/smartcardio/CommandAPDU.java
> ./solaris/classes/java/util/prefs/FileSystemPreferences.java
> ./solaris/classes/sun/print/AttributeClass.java
> ./solaris/classes/sun/net/sdp/SdpProvider.java
> ./solaris/classes/sun/awt/X11/XIconInfo.java
> ./solaris/classes/sun/awt/X11/XKeySymConstants.java
> ./solaris/classes/sun/awt/X11/MotifDnDConstants.java
> ./solaris/classes/sun/awt/X11/XIconWindow.java
> ./solaris/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java
> ./solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java
> ./solaris/classes/sun/awt/X11/XAtom.java
> ./solaris/classes/sun/awt/X11/MotifColorUtilities.java
> ./solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java
> ./solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java
> ./solaris/classes/sun/awt/X11/Native.java
> ./solaris/classes/sun/awt/X11/XKeysym.java
> ./solaris/classes/sun/awt/X11/XToolkit.java
> ./solaris/classes/sun/awt/X11/XDnDConstants.java
> ./solaris/classes/sun/awt/X11/XWM.java
> ./solaris/classes/sun/awt/X11/XWindowPeer.java
> ./solaris/classes/sun/awt/X11GraphicsConfig.java
> ./solaris/classes/sun/awt/motif/X11KSC5601.java
> ./solaris/classes/sun/awt/motif/X11GB2312.java
> ./solaris/classes/sun/awt/motif/X11CNS11643.java
> ./solaris/classes/sun/awt/motif/X11JIS0201.java
> ./solaris/classes/sun/awt/X11CustomCursor.java
> ./solaris/classes/sun/awt/XSettings.java
> ./solaris/classes/sun/nio/fs/UnixPath.java
> ./solaris/classes/sun/nio/fs/UnixUriUtils.java
> ./solaris/classes/sun/nio/cs/ext/CompoundTextSupport.java
> ./solaris/classes/sun/nio/cs/ext/COMPOUND_TEXT_Decoder.java
> ./solaris/classes/sun/font/XMap.java
> ./solaris/classes/sun/font/XRGlyphCacheEntry.java
> ./solaris/classes/sun/font/NativeStrike.java
> ./solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
> ./solaris/classes/sun/java2d/xr/XRSurfaceData.java
> ./solaris/classes/sun/java2d/xr/XRPaints.java
> ./solaris/classes/sun/java2d/xr/XRColor.java
> ./solaris/classes/sun/java2d/xr/XRCompositeManager.java
> ./solaris/classes/sun/java2d/opengl/GLXGraphicsConfig.java
> ./solaris/classes/sun/java2d/x11/X11SurfaceDataProxy.java
> ./solaris/classes/sun/java2d/x11/X11SurfaceData.java
> ./solaris/classes/sun/tools/attach/SolarisVirtualMachine.java
> ./solaris/classes/sun/tools/attach/LinuxVirtualMachine.java
> ./windows/classes/java/util/prefs/WindowsPreferences.java
> ./windows/classes/com/sun/tools/jdi/SharedMemoryTransportService.java
> ./windows/classes/sun/awt/Win32GraphicsConfig.java
> ./windows/classes/sun/awt/windows/WPathGraphics.java
> ./windows/classes/sun/awt/windows/WCustomCursor.java
> ./windows/classes/sun/awt/windows/WWindowPeer.java
> ./windows/classes/sun/awt/windows/WTrayIconPeer.java
> ./windows/classes/sun/awt/windows/WPrinterJob.java
> ./windows/classes/sun/nio/fs/WindowsFileAttributes.java
> ./windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java
> ./windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java
> ./windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java
> ./windows/classes/sun/tools/attach/WindowsVirtualMachine.java
> ./share/demo/applets/WireFrame/ThreeD.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
> ./share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java
> ./share/demo/jfc/Font2DTest/FontPanel.java
> ./share/demo/jfc/Font2DTest/RangeMenu.java
> ./share/demo/jfc/Font2DTest/Font2DTest.java
> ./share/demo/jfc/CodePointIM/CodePointInputMethod.java
> ./share/demo/java2d/J2DBench/src/j2dbench/tests/PixelTests.java
> ./share/demo/java2d/J2DBench/src/j2dbench/tests/iio/IIOTests.java
> ./share/demo/java2d/J2DBench/src/j2dbench/tests/ImageTests.java
> ./share/classes/java/rmi/dgc/VMID.java
> ./share/classes/java/beans/XMLEncoder.java
> ./share/classes/java/net/URLConnection.java
> ./share/classes/java/net/Inet6Address.java
> ./share/classes/java/net/Inet4Address.java
> ./share/classes/java/net/DatagramPacket.java
> ./share/classes/java/net/SocketInputStream.java
> ./share/classes/java/net/MulticastSocket.java
> ./share/classes/java/net/SocksSocketImpl.java
> ./share/classes/java/net/SocketPermission.java
> ./share/classes/java/net/DatagramSocket.java
> ./share/classes/java/net/ServerSocket.java
> ./share/classes/java/net/InetSocketAddress.java
> ./share/classes/java/net/URI.java
> ./share/classes/java/lang/Character.java
> ./share/classes/java/lang/Byte.java
> ./share/classes/java/lang/Float.java
> ./share/classes/java/lang/Double.java
> ./share/classes/java/lang/Long.java
> ./share/classes/java/lang/CharacterData.java
> ./share/classes/java/lang/String.java
> ./share/classes/java/lang/invoke/MethodType.java
> ./share/classes/java/lang/invoke/MethodTypeForm.java
> ./share/classes/java/lang/invoke/MethodHandle.java
> ./share/classes/java/lang/invoke/MemberName.java
> ./share/classes/java/lang/CharacterName.java
> ./share/classes/java/lang/Integer.java
> ./share/classes/java/lang/Short.java
> ./share/classes/java/text/BreakIterator.java
> ./share/classes/java/text/CollationElementIterator.java
> ./share/classes/java/text/RuleBasedCollator.java
> ./share/classes/java/text/RBCollationTables.java
> ./share/classes/java/text/SimpleDateFormat.java
> ./share/classes/java/text/RBTableBuilder.java
> ./share/classes/java/io/ByteArrayOutputStream.java
> ./share/classes/java/io/DataOutputStream.java
> ./share/classes/java/io/DataInputStream.java
> ./share/classes/java/io/Reader.java
> ./share/classes/java/io/StringBufferInputStream.java
> ./share/classes/java/io/PushbackInputStream.java
> ./share/classes/java/io/Bits.java
> ./share/classes/java/io/DataOutput.java
> ./share/classes/java/io/RandomAccessFile.java
> ./share/classes/java/io/BufferedReader.java
> ./share/classes/java/io/ObjectInputStream.java
> ./share/classes/java/io/ByteArrayInputStream.java
> ./share/classes/java/io/DataInput.java
> ./share/classes/java/io/BufferedInputStream.java
> ./share/classes/java/io/ObjectStreamClass.java
> ./share/classes/java/io/ObjectOutputStream.java
> ./share/classes/java/io/PipedInputStream.java
> ./share/classes/java/util/regex/UnicodeProp.java
> ./share/classes/java/util/regex/Pattern.java
> ./share/classes/java/util/regex/ASCII.java
> ./share/classes/java/util/Properties.java
> ./share/classes/java/util/jar/JarOutputStream.java
> ./share/classes/java/util/jar/Manifest.java
> ./share/classes/java/util/jar/JarEntry.java
> ./share/classes/java/util/BitSet.java
> ./share/classes/java/util/concurrent/Phaser.java
> ./share/classes/java/util/concurrent/Exchanger.java
> ./share/classes/java/util/concurrent/ForkJoinPool.java
> ./share/classes/java/util/concurrent/ConcurrentHashMap.java
> ./share/classes/java/util/concurrent/ForkJoinWorkerThread.java
> ./share/classes/java/util/zip/DeflaterOutputStream.java
> ./share/classes/java/util/zip/InflaterInputStream.java
> ./share/classes/java/util/zip/GZIPInputStream.java
> ./share/classes/java/util/zip/DeflaterInputStream.java
> ./share/classes/java/util/zip/ZipConstants64.java
> ./share/classes/java/util/zip/ZipInputStream.java
> ./share/classes/java/util/zip/ZipOutputStream.java
> ./share/classes/java/util/zip/ZipFile.java
> ./share/classes/java/util/zip/CRC32.java
> ./share/classes/java/util/zip/Adler32.java
> ./share/classes/java/util/zip/GZIPOutputStream.java
> ./share/classes/java/util/zip/ZipEntry.java
> ./share/classes/java/util/UUID.java
> ./share/classes/java/util/prefs/Base64.java
> ./share/classes/java/security/SecureRandom.java
> ./share/classes/java/awt/Color.java
> ./share/classes/java/awt/GradientPaintContext.java
> ./share/classes/java/awt/TexturePaintContext.java
> ./share/classes/java/awt/AlphaComposite.java
> ./share/classes/java/awt/event/KeyEvent.java
> ./share/classes/java/awt/SystemColor.java
> ./share/classes/java/awt/image/DataBufferByte.java
> ./share/classes/java/awt/image/ByteLookupTable.java
> ./share/classes/java/awt/image/MultiPixelPackedSampleModel.java
> ./share/classes/java/awt/image/ComponentSampleModel.java
> ./share/classes/java/awt/image/ComponentColorModel.java
> ./share/classes/java/awt/image/DataBuffer.java
> ./share/classes/java/awt/image/DataBufferUShort.java
> ./share/classes/java/awt/image/SinglePixelPackedSampleModel.java
> ./share/classes/java/awt/image/BufferedImageFilter.java
> ./share/classes/java/awt/image/RescaleOp.java
> ./share/classes/java/awt/image/ColorConvertOp.java
> ./share/classes/java/awt/image/IndexColorModel.java
> ./share/classes/java/awt/image/AreaAveragingScaleFilter.java
> ./share/classes/java/awt/image/BandedSampleModel.java
> ./share/classes/java/awt/image/BufferedImage.java
> ./share/classes/java/awt/image/ShortLookupTable.java
> ./share/classes/java/awt/image/DirectColorModel.java
> ./share/classes/java/awt/image/RGBImageFilter.java
> ./share/classes/java/awt/image/PixelGrabber.java
> ./share/classes/java/awt/image/ColorModel.java
> ./share/classes/java/awt/MultipleGradientPaint.java
> ./share/classes/java/awt/color/ICC_ProfileRGB.java
> ./share/classes/java/awt/color/ICC_ProfileGray.java
> ./share/classes/java/awt/color/ICC_Profile.java
> ./share/classes/java/awt/color/ICC_ColorSpace.java
> ./share/classes/java/awt/MultipleGradientPaintContext.java
> ./share/classes/java/awt/FontMetrics.java
> ./share/classes/java/awt/font/NumericShaper.java
> ./share/classes/java/awt/GradientPaint.java
> ./share/classes/java/nio/Bits.java
> ./share/classes/java/nio/channels/Channels.java
> ./share/classes/java/math/BigInteger.java
> ./share/classes/com/sun/beans/decoder/LongElementHandler.java
> ./share/classes/com/sun/jmx/snmp/SnmpIpAddress.java
> ./share/classes/com/sun/jmx/snmp/SnmpString.java
> ./share/classes/com/sun/jmx/snmp/IPAcl/ASCII_CharStream.java
> ./share/classes/com/sun/jmx/snmp/IPAcl/ParserTokenManager.java
> ./share/classes/com/sun/jmx/snmp/IPAcl/NetMaskImpl.java
> ./share/classes/com/sun/jmx/snmp/SnmpEngineId.java
> ./share/classes/com/sun/jmx/snmp/SnmpMsg.java
> ./share/classes/com/sun/java/swing/plaf/gtk/GTKColorType.java
> ./share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java
> ./share/classes/com/sun/java/swing/plaf/gtk/Metacity.java
> ./share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java
> ./share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
> ./share/classes/com/sun/java/util/jar/pack/PackageWriter.java
> ./share/classes/com/sun/java/util/jar/pack/Coding.java
> ./share/classes/com/sun/java/util/jar/pack/PackageReader.java
> ./share/classes/com/sun/java/util/jar/pack/Histogram.java
> ./share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java
> ./share/classes/com/sun/java/util/jar/pack/PopulationCoding.java
> ./share/classes/com/sun/java/util/jar/pack/Attribute.java
> ./share/classes/com/sun/java/util/jar/pack/Fixups.java
> ./share/classes/com/sun/java/util/jar/pack/BandStructure.java
> ./share/classes/com/sun/java/util/jar/pack/Instruction.java
> ./share/classes/com/sun/net/httpserver/BasicAuthenticator.java
> ./share/classes/com/sun/crypto/provider/BlowfishCrypt.java
> ./share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java
> ./share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
> ./share/classes/com/sun/crypto/provider/ISO10126Padding.java
> ./share/classes/com/sun/crypto/provider/RC2Crypt.java
> ./share/classes/com/sun/crypto/provider/AESCrypt.java
> ./share/classes/com/sun/crypto/provider/TlsMasterSecretGenerator.java
> ./share/classes/com/sun/crypto/provider/ARCFOURCipher.java
> ./share/classes/com/sun/crypto/provider/PKCS5Padding.java
> ./share/classes/com/sun/crypto/provider/RC2Parameters.java
> ./share/classes/com/sun/security/ntlm/NTLM.java
> ./share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java
> ./share/classes/com/sun/imageio/plugins/png/PNGImageReader.java
> ./share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
> ./share/classes/com/sun/imageio/plugins/png/RowFilter.java
> ./share/classes/com/sun/imageio/plugins/png/PNGMetadata.java
> ./share/classes/com/sun/imageio/plugins/jpeg/DHTMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/DQTMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/AdobeMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/DRIMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReaderSpi.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGBuffer.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/MarkerSegment.java
> ./share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFImageMetadata.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java
> ./share/classes/com/sun/imageio/plugins/gif/GIFStreamMetadata.java
> ./share/classes/com/sun/imageio/plugins/common/LZWCompressor.java
> ./share/classes/com/sun/imageio/plugins/common/PaletteBuilder.java
> ./share/classes/com/sun/imageio/plugins/common/LZWStringTable.java
> ./share/classes/com/sun/imageio/plugins/common/ImageUtil.java
> ./share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java
> ./share/classes/com/sun/imageio/plugins/bmp/BMPMetadata.java
> ./share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java
> ./share/classes/com/sun/media/sound/AudioFloatConverter.java
> ./share/classes/com/sun/media/sound/StandardMidiFileWriter.java
> ./share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java
> ./share/classes/com/sun/media/sound/SunFileReader.java
> ./share/classes/com/sun/media/sound/MidiInDevice.java
> ./share/classes/com/sun/media/sound/FastSysexMessage.java
> ./share/classes/com/sun/media/sound/SunFileWriter.java
> ./share/classes/com/sun/media/sound/SF2Region.java
> ./share/classes/com/sun/media/sound/AlawCodec.java
> ./share/classes/com/sun/media/sound/MidiOutDevice.java
> ./share/classes/com/sun/media/sound/UlawCodec.java
> ./share/classes/com/sun/media/sound/AudioFloatFormatConverter.java
> ./share/classes/com/sun/media/sound/FastShortMessage.java
> ./share/classes/com/sun/media/sound/SoftJitterCorrector.java
> ./share/classes/com/sun/media/sound/SoftMixingMainMixer.java
> ./share/classes/com/sun/media/sound/SoftMainMixer.java
> ./share/classes/com/sun/media/sound/RIFFWriter.java
> ./share/classes/com/sun/media/sound/StandardMidiFileReader.java
> ./share/classes/com/sun/media/sound/SoftTuning.java
> ./share/classes/com/sun/media/sound/SoftMixingClip.java
> ./share/classes/com/sun/media/sound/WaveExtensibleFileReader.java
> ./share/classes/com/sun/media/sound/ModelByteBufferWavetable.java
> ./share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java
> ./share/classes/com/sun/media/sound/SoftSynthesizer.java
> ./share/classes/com/sun/media/sound/PortMixer.java
> ./share/classes/com/sun/media/sound/MidiUtils.java
> ./share/classes/com/sun/media/sound/RealTimeSequencer.java
> ./share/classes/com/sun/media/sound/AbstractMidiDevice.java
> ./share/classes/com/sun/jndi/dns/Header.java
> ./share/classes/com/sun/jndi/dns/DnsClient.java
> ./share/classes/com/sun/jndi/dns/ResourceRecord.java
> ./share/classes/com/sun/jndi/dns/DnsName.java
> ./share/classes/com/sun/jndi/ldap/BerEncoder.java
> ./share/classes/com/sun/jndi/ldap/BerDecoder.java
> ./share/classes/com/sun/jndi/ldap/Connection.java
> ./share/classes/com/sun/jndi/ldap/sasl/SaslOutputStream.java
> ./share/classes/com/sun/jndi/ldap/sasl/SaslInputStream.java
> ./share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java
> ./share/classes/com/sun/tools/hat/internal/model/JavaByte.java
> ./share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java
> ./share/classes/com/sun/tools/hat/internal/util/Misc.java
> ./share/classes/com/sun/tools/hat/internal/parser/HprofReader.java
> ./share/classes/com/sun/tools/example/debug/expr/ASCII_UCodeESC_CharStream.java
>
> ./share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java
>
> ./share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java
> ./share/classes/com/sun/tools/example/debug/gui/Icons.java
> ./share/classes/com/sun/tools/example/debug/tty/Commands.java
> ./share/classes/com/sun/tools/jdi/Packet.java
> ./share/classes/com/sun/tools/jdi/TargetVM.java
> ./share/classes/com/sun/tools/jdi/PacketStream.java
> ./share/classes/com/sun/tools/jdi/SocketTransportService.java
> ./share/classes/sun/rmi/rmic/newrmic/jrmp/RemoteClass.java
> ./share/classes/sun/rmi/rmic/RemoteClass.java
> ./share/classes/sun/rmi/server/Util.java
> ./share/classes/sun/rmi/transport/tcp/MultiplexInputStream.java
> ./share/classes/sun/rmi/transport/proxy/CGIHandler.java
> ./share/classes/sun/print/PrinterGraphicsConfig.java
> ./share/classes/sun/print/PathGraphics.java
> ./share/classes/sun/print/PSPrinterJob.java
> ./share/classes/sun/net/util/IPAddressUtil.java
> ./share/classes/sun/net/ftp/impl/FtpClient.java
> ./share/classes/sun/net/httpserver/SSLStreams.java
> ./share/classes/sun/net/httpserver/LeftOverInputStream.java
> ./share/classes/sun/net/httpserver/Request.java
> ./share/classes/sun/net/idn/Punycode.java
> ./share/classes/sun/net/idn/StringPrep.java
> ./share/classes/sun/net/spi/nameservice/dns/DNSNameService.java
> ./share/classes/sun/net/www/http/ChunkedInputStream.java
> ./share/classes/sun/net/www/ParseUtil.java
> ./share/classes/sun/text/IntHashtable.java
> ./share/classes/sun/text/UCompactIntArray.java
> ./share/classes/sun/text/normalizer/UCharacterProperty.java
> ./share/classes/sun/text/normalizer/UCharacter.java
> ./share/classes/sun/text/normalizer/Utility.java
> ./share/classes/sun/text/normalizer/NormalizerBase.java
> ./share/classes/sun/text/normalizer/NormalizerDataReader.java
> ./share/classes/sun/text/normalizer/NormalizerImpl.java
> ./share/classes/sun/text/normalizer/UCharacterIterator.java
> ./share/classes/sun/text/normalizer/UnicodeSet.java
> ./share/classes/sun/text/bidi/BidiBase.java
> ./share/classes/sun/text/SupplementaryCharacterData.java
> ./share/classes/sun/text/CompactByteArray.java
> ./share/classes/sun/misc/UCEncoder.java
> ./share/classes/sun/misc/FormattedFloatingDecimal.java
> ./share/classes/sun/misc/CRC16.java
> ./share/classes/sun/misc/UCDecoder.java
> ./share/classes/sun/misc/ProxyGenerator.java
> ./share/classes/sun/misc/BASE64Decoder.java
> ./share/classes/sun/misc/UUDecoder.java
> ./share/classes/sun/misc/FloatingDecimal.java
> ./share/classes/sun/misc/HexDumpEncoder.java
> ./share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java
> ./share/classes/sun/util/calendar/ZoneInfoFile.java
> ./share/classes/sun/security/krb5/EncryptedData.java
> ./share/classes/sun/security/krb5/internal/ccache/CCacheOutputStream.java
> ./share/classes/sun/security/krb5/internal/crypto/crc32.java
> ./share/classes/sun/security/krb5/internal/crypto/Des.java
> ./share/classes/sun/security/krb5/internal/crypto/dk/ArcFourCrypto.java
> ./share/classes/sun/security/krb5/internal/crypto/dk/DkCrypto.java
> ./share/classes/sun/security/krb5/internal/crypto/dk/AesDkCrypto.java
> ./share/classes/sun/security/krb5/internal/crypto/Crc32CksumType.java
> ./share/classes/sun/security/krb5/internal/util/KrbDataOutputStream.java
> ./share/classes/sun/security/krb5/internal/util/KrbDataInputStream.java
> ./share/classes/sun/security/krb5/internal/NetClient.java
> ./share/classes/sun/security/krb5/internal/LocalSeqNumber.java
> ./share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java
> ./share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java
> ./share/classes/sun/security/pkcs11/SunPKCS11.java
> ./share/classes/sun/security/pkcs11/wrapper/CK_VERSION.java
> ./share/classes/sun/security/pkcs11/wrapper/Functions.java
> ./share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java
> ./share/classes/sun/security/pkcs11/P11Key.java
> ./share/classes/sun/security/pkcs11/P11Util.java
> ./share/classes/sun/security/x509/X509Key.java
> ./share/classes/sun/security/jgss/krb5/MessageToken_v2.java
> ./share/classes/sun/security/jgss/krb5/MessageToken.java
> ./share/classes/sun/security/jgss/wrapper/GSSNameElement.java
> ./share/classes/sun/security/jgss/GSSNameImpl.java
> ./share/classes/sun/security/jgss/GSSToken.java
> ./share/classes/sun/security/util/Debug.java
> ./share/classes/sun/security/util/ByteArrayLexOrder.java
> ./share/classes/sun/security/util/BitArray.java
> ./share/classes/sun/security/util/DerOutputStream.java
> ./share/classes/sun/security/util/Cache.java
> ./share/classes/sun/security/util/DerValue.java
> ./share/classes/sun/security/util/DerIndefLenConverter.java
> ./share/classes/sun/security/util/DerInputStream.java
> ./share/classes/sun/security/util/DerInputBuffer.java
> ./share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java
> ./share/classes/sun/security/ssl/OutputRecord.java
> ./share/classes/sun/security/ssl/ProtocolVersion.java
> ./share/classes/sun/security/ssl/CipherBox.java
> ./share/classes/sun/security/ssl/HelloExtensions.java
> ./share/classes/sun/security/ssl/InputRecord.java
> ./share/classes/sun/security/ssl/HandshakeMessage.java
> ./share/classes/sun/security/ssl/EngineInputRecord.java
> ./share/classes/sun/security/ssl/MAC.java
> ./share/classes/sun/security/ssl/AppInputStream.java
> ./share/classes/sun/security/ssl/CipherSuite.java
> ./share/classes/sun/security/rsa/RSAPadding.java
> ./share/classes/sun/security/ec/NamedCurve.java
> ./share/classes/sun/security/provider/MD2.java
> ./share/classes/sun/security/provider/MD5.java
> ./share/classes/sun/security/provider/DSA.java
> ./share/classes/sun/security/provider/ByteArrayAccess.java
> ./share/classes/sun/security/smartcardio/PCSC.java
> ./share/classes/sun/security/smartcardio/CardImpl.java
> ./share/classes/sun/security/smartcardio/ChannelImpl.java
> ./share/classes/sun/reflect/UTF8.java
> ./share/classes/sun/reflect/ClassFileAssembler.java
> ./share/classes/sun/reflect/annotation/AnnotationParser.java
> ./share/classes/sun/invoke/anon/ConstantPoolPatch.java
> ./share/classes/sun/invoke/anon/ConstantPoolParser.java
> ./share/classes/sun/invoke/anon/ConstantPoolVisitor.java
> ./share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java
>
> ./share/classes/sun/management/ManagementFactoryHelper.java
> ./share/classes/sun/awt/FontConfiguration.java
> ./share/classes/sun/awt/image/ImageRepresentation.java
> ./share/classes/sun/awt/image/PixelConverter.java
> ./share/classes/sun/awt/image/PNGImageDecoder.java
> ./share/classes/sun/awt/image/GifImageDecoder.java
> ./share/classes/sun/awt/image/BytePackedRaster.java
> ./share/classes/sun/awt/image/BufferedImageGraphicsConfig.java
> ./share/classes/sun/awt/image/JPEGImageDecoder.java
> ./share/classes/sun/awt/image/ByteInterleavedRaster.java
> ./share/classes/sun/awt/image/BufImgSurfaceData.java
> ./share/classes/sun/awt/image/OffScreenImageSource.java
> ./share/classes/sun/awt/datatransfer/DataTransferer.java
> ./share/classes/sun/awt/PlatformFont.java
> ./share/classes/sun/nio/cs/UnicodeEncoder.java
> ./share/classes/sun/nio/cs/ISO_8859_1.java
> ./share/classes/sun/nio/cs/UTF_8.java
> ./share/classes/sun/nio/cs/UTF_32Coder.java
> ./share/classes/sun/nio/cs/CharsetMapping.java
> ./share/classes/sun/nio/cs/ext/DoubleByte.java
> ./share/classes/sun/nio/cs/ext/SimpleEUCEncoder.java
> ./share/classes/sun/nio/cs/ext/ISO2022_JP.java
> ./share/classes/sun/nio/cs/ext/IBM33722.java
> ./share/classes/sun/nio/cs/ext/EUC_TW.java
> ./share/classes/sun/nio/cs/ext/ISO2022_CN.java
> ./share/classes/sun/nio/cs/ext/IBM943C.java
> ./share/classes/sun/nio/cs/ext/HKSCS.java
> ./share/classes/sun/nio/cs/ext/IBM949C.java
> ./share/classes/sun/nio/cs/ext/DoubleByteDecoder.java
> ./share/classes/sun/nio/cs/ext/JIS_X_0212_MS5022X_Encoder.java
> ./share/classes/sun/nio/cs/ext/DoubleByteEncoder.java
> ./share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java
> ./share/classes/sun/nio/cs/ext/SJIS.java
> ./share/classes/sun/nio/cs/ext/JISAutoDetect.java
> ./share/classes/sun/nio/cs/ext/EUC_JP.java
> ./share/classes/sun/nio/cs/ext/IBM964.java
> ./share/classes/sun/nio/cs/ext/GB18030.java
> ./share/classes/sun/nio/cs/ext/PCK.java
> ./share/classes/sun/nio/cs/ext/JIS_X_0201.java
> ./share/classes/sun/nio/cs/ext/EUC_JP_Open.java
> ./share/classes/sun/nio/cs/ext/SJIS_0213.java
> ./share/classes/sun/nio/cs/ext/Big5_Solaris.java
> ./share/classes/sun/nio/cs/ext/ISO2022.java
> ./share/classes/sun/nio/cs/SingleByte.java
> ./share/classes/sun/nio/cs/UnicodeDecoder.java
> ./share/classes/sun/nio/cs/CESU_8.java
> ./share/classes/sun/nio/ch/DatagramSocketAdaptor.java
> ./share/classes/sun/nio/ch/ChannelInputStream.java
> ./share/classes/sun/nio/ch/Net.java
> ./share/classes/sun/font/FileFontStrike.java
> ./share/classes/sun/font/ExtendedTextSourceLabel.java
> ./share/classes/sun/font/TrueTypeFont.java
> ./share/classes/sun/font/CompositeStrike.java
> ./share/classes/sun/font/TrueTypeGlyphMapper.java
> ./share/classes/sun/font/Type1Font.java
> ./share/classes/sun/font/GlyphList.java
> ./share/classes/sun/font/CMap.java
> ./share/classes/sun/font/PhysicalStrike.java
> ./share/classes/sun/font/Type1GlyphMapper.java
> ./share/classes/sun/font/FontDesignMetrics.java
> ./share/classes/sun/font/StandardGlyphVector.java
> ./share/classes/sun/font/CharToGlyphMapper.java
> ./share/classes/sun/font/CompositeGlyphMapper.java
> ./share/classes/sun/applet/AppletPanel.java
> ./share/classes/sun/launcher/LauncherHelper.java
> ./share/classes/sun/java2d/pisces/PiscesTileGenerator.java
> ./share/classes/sun/java2d/pipe/BufferedPaints.java
> ./share/classes/sun/java2d/pipe/AATileGenerator.java
> ./share/classes/sun/java2d/pipe/AAShapePipe.java
> ./share/classes/sun/java2d/pipe/BufferedTextPipe.java
> ./share/classes/sun/java2d/loops/MaskFill.java
> ./share/classes/sun/java2d/loops/MaskBlit.java
> ./share/classes/sun/java2d/loops/BlitBg.java
> ./share/classes/sun/java2d/SunGraphics2D.java
> ./share/classes/sun/java2d/cmm/CMSManager.java
> ./share/classes/sun/java2d/cmm/lcms/LCMSTransform.java
> ./share/classes/sun/tools/java/Constants.java
> ./share/classes/sun/tools/java/Scanner.java
> ./share/classes/sun/tools/java/BinaryConstantPool.java
> ./share/classes/sun/tools/jconsole/ConnectDialog.java
> ./share/classes/sun/tools/jconsole/JConsole.java
> ./share/classes/sun/tools/jconsole/AboutDialog.java
> ./share/classes/sun/tools/jconsole/HTMLPane.java
> ./share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java
> ./share/classes/javax/sound/midi/MidiMessage.java
> ./share/classes/javax/sound/midi/ShortMessage.java
> ./share/classes/javax/sound/midi/MetaMessage.java
> ./share/classes/javax/sound/midi/SysexMessage.java
> ./share/classes/javax/sound/sampled/AudioInputStream.java
> ./share/classes/javax/crypto/CipherInputStream.java
> ./share/classes/javax/crypto/spec/DESKeySpec.java
> ./share/classes/javax/swing/DebugGraphicsFilter.java
> ./share/classes/javax/swing/JComponent.java
> ./share/classes/javax/swing/text/html/parser/Parser.java
> ./share/classes/javax/swing/text/html/parser/Entity.java
> ./share/classes/javax/swing/plaf/metal/MetalUtils.java
> ./share/classes/javax/swing/plaf/metal/OceanTheme.java
> ./share/classes/javax/swing/plaf/metal/MetalTheme.java
> ./share/classes/javax/swing/plaf/ColorUIResource.java
> ./share/classes/javax/swing/plaf/nimbus/DropShadowEffect.java
> ./share/classes/javax/swing/plaf/nimbus/EffectUtils.java
> ./share/classes/javax/swing/plaf/nimbus/InnerShadowEffect.java
> ./share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
> ./share/classes/javax/swing/plaf/nimbus/NimbusStyle.java
> ./share/classes/javax/swing/plaf/nimbus/DerivedColor.java
> ./share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java
> ./share/classes/javax/swing/JColorChooser.java
> ./share/classes/javax/swing/colorchooser/ColorChooserPanel.java
> ./share/classes/javax/swing/colorchooser/ColorModel.java
> ./share/classes/javax/swing/GrayFilter.java
> ./share/classes/javax/management/remote/rmi/RMIConnectorServer.java
> ./share/classes/javax/imageio/stream/ImageOutputStreamImpl.java
> ./share/classes/javax/imageio/stream/ImageOutputStream.java
> ./share/classes/javax/imageio/stream/ImageInputStream.java
> ./share/classes/javax/imageio/stream/ImageInputStreamImpl.java
> ./share/classes/javax/imageio/stream/MemoryCache.java
> ./share/classes/javax/imageio/ImageTypeSpecifier.java
> ./share/classes/javax/imageio/metadata/IIOMetadataNode.java
> ./share/classes/javax/smartcardio/ResponseAPDU.java
> ./share/classes/javax/smartcardio/CommandAPDU.java
>



From joe.darcy at oracle.com Thu Jan 26 21:37:57 2012
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Thu, 26 Jan 2012 13:37:57 -0800
Subject: Using unsigned library work in the JDK
In-Reply-To: <4F2189D3.9080508@gmx.de>
References: <4F20D879.8010800@oracle.com> <4F217B24.3030405@oracle.com>
<4F2189D3.9080508@gmx.de>
Message-ID: <4F21C7B5.6020904@oracle.com>

Hello,

On 1/26/2012 9:13 AM, Ulf Zibis wrote:
> Am 26.01.2012 17:11, schrieb Roger Riggs:
>

[snip]

>
>> Its unfortunate that between the method name and need to qualify
>> with the class (or use static imports) that the code is longer and
>> not always clearer.
> +1
> - static import could become ambiguous using Byte.toUnsignedInt() +
> Short.toUnsignedInt() at same time.
> + The shortest I can think:
> Short.unsigned(byte)
> Integer.unsigned(short)
> Long.unsigned(int)
> BigInteger.unsigned(long)
> + Nothing would be ambiguous, using static import.

That style of design was considered for

4504839 Java libraries should provide support for unsigned integer
arithmetic

However, at least for now, we choose the other approach.

-Joe


From lance.andersen at oracle.com Thu Jan 26 21:46:43 2012
From: lance.andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 26 Jan 2012 16:46:43 -0500
Subject: Review needed for 7132879 to address the findbug errors in
CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl,
SerialOutputImpl
Message-ID: <F845866E-6E29-4DBA-A06A-DA1A8C8D95A9@oracle.com>

Hi,

Looking for a reviewer for http://cr.openjdk.java.net/~lancea/7133815/webrev.00/

this is a small change to address 2 findbug errors. The findbug issues being addressed:

May expose internal representation by returning reference to mutable object

and

Load of known null value


For CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl


Best,
Lance

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 forax at univ-mlv.fr Thu Jan 26 22:21:23 2012
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 26 Jan 2012 23:21:23 +0100
Subject: Review needed for 7132879 to address the findbug errors in
CachedRowSetImpl,
SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl
In-Reply-To: <F845866E-6E29-4DBA-A06A-DA1A8C8D95A9@oracle.com>
References: <F845866E-6E29-4DBA-A06A-DA1A8C8D95A9@oracle.com>
Message-ID: <4F21D1E3.3040706@univ-mlv.fr>

On 01/26/2012 10:46 PM, Lance Andersen - Oracle wrote:
> Hi,
>
> Looking for a reviewer for http://cr.openjdk.java.net/~lancea/7133815/webrev.00/
>
> this is a small change to address 2 findbug errors. The findbug issues being addressed:
>
> May expose internal representation by returning reference to mutable object
>
> and
>
> Load of known null value
>
>
> For CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl

Hi Lance,
I think it's better to use array.clone() or
Arrays.copyOf(array, array.length) which is a little faster.

so the code of CachedRowSetImpl should be:

int[]keyCols = this.keyCols;
return (keyCols == null)? null: Arrays.copyOf(keyCols, keyCols.length);

otherwise the code of SQLOutputImpl is ok for me.

cheers,
R?mi



From Lance.Andersen at oracle.com Thu Jan 26 23:12:07 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 26 Jan 2012 18:12:07 -0500
Subject: Review needed for 7132879 to address the findbug errors in
CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl,
SerialOutputImpl
In-Reply-To: <4F21D1E3.3040706@univ-mlv.fr>
References: <F845866E-6E29-4DBA-A06A-DA1A8C8D95A9@oracle.com>
<4F21D1E3.3040706@univ-mlv.fr>
Message-ID: <F456B05B-BA0B-483F-AAFD-1E163B9B63E2@oracle.com>

Hi Remi,

Thanks for the feedback, I made the suggested changes http://cr.openjdk.java.net/~lancea/7133815/webrev.01/ and re-ran the rowset tck .

Best
Lance
On Jan 26, 2012, at 5:21 PM, R?mi Forax wrote:

> On 01/26/2012 10:46 PM, Lance Andersen - Oracle wrote:
>> Hi,
>>
>> Looking for a reviewer for http://cr.openjdk.java.net/~lancea/7133815/webrev.00/
>>
>> this is a small change to address 2 findbug errors. The findbug issues being addressed:
>>
>> May expose internal representation by returning reference to mutable object
>>
>> and
>>
>> Load of known null value
>>
>>
>> For CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl
>
> Hi Lance,
> I think it's better to use array.clone() or
> Arrays.copyOf(array, array.length) which is a little faster.
>
> so the code of CachedRowSetImpl should be:
>
> int[]keyCols = this.keyCols;
> return (keyCols == null)? null: Arrays.copyOf(keyCols, keyCols.length);
>
> otherwise the code of SQLOutputImpl is ok for me.
>
> cheers,
> R?mi
>


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 forax at univ-mlv.fr Thu Jan 26 23:47:42 2012
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 27 Jan 2012 00:47:42 +0100
Subject: Review needed for 7132879 to address the findbug errors in
CachedRowSetImpl,
SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl
In-Reply-To: <F456B05B-BA0B-483F-AAFD-1E163B9B63E2@oracle.com>
References: <F845866E-6E29-4DBA-A06A-DA1A8C8D95A9@oracle.com>
<4F21D1E3.3040706@univ-mlv.fr>
<F456B05B-BA0B-483F-AAFD-1E163B9B63E2@oracle.com>
Message-ID: <4F21E61E.80809@univ-mlv.fr>

On 01/27/2012 12:12 AM, Lance Andersen - Oracle wrote:
> Hi Remi,
>
> Thanks for the feedback, I made the suggested changes http://cr.openjdk.java.net/~lancea/7133815/webrev.01/ and re-ran the rowset tck .
>
> Best
> Lance

Lance,
sorry to not have been crystal clear in my previous email,
I've forgotten to mention that because the field is stored in a local
variable
to do the nullcheck you can reuse the same local variable instead of
reloading the value from the field which is a good code practice.

So instead of

int[] keyColumns = this.keyCols;
return (keyColumns == null) ? null : Arrays.copyOf(keyCols, keyCols.length);

the code should be

int[] keyColumns = this.keyCols;
return (keyColumns == null) ? null : Arrays.copyOf(keyColumns,keyColumns.length);


Now, this is not strictly needed for the codes of the changeset because
the JIT
can easily prove in these codes that the field will not be changed between
the first load and the subsequent accesses as arguments of Arrays.copyOf.

Anyway, as i said, it's a good practice to avoid to do several getfields
if the value is not supposed to change in between.

R?mi

PS: as a bonus, using local variables reduces the size of the generated
bytecodes,
aload_1 takes one byte and getfield takes three bytes :)

> On Jan 26, 2012, at 5:21 PM, R?mi Forax wrote:
>
>> On 01/26/2012 10:46 PM, Lance Andersen - Oracle wrote:
>>> Hi,
>>>
>>> Looking for a reviewer for http://cr.openjdk.java.net/~lancea/7133815/webrev.00/
>>>
>>> this is a small change to address 2 findbug errors. The findbug issues being addressed:
>>>
>>> May expose internal representation by returning reference to mutable object
>>>
>>> and
>>>
>>> Load of known null value
>>>
>>>
>>> For CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl
>> Hi Lance,
>> I think it's better to use array.clone() or
>> Arrays.copyOf(array, array.length) which is a little faster.
>>
>> so the code of CachedRowSetImpl should be:
>>
>> int[]keyCols = this.keyCols;
>> return (keyCols == null)? null: Arrays.copyOf(keyCols, keyCols.length);
>>
>> otherwise the code of SQLOutputImpl is ok for me.
>>
>> cheers,
>> R?mi
>>
>
> 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 Fri Jan 27 00:03:37 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 26 Jan 2012 19:03:37 -0500
Subject: Review needed for 7132879 to address the findbug errors in
CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl,
SerialOutputImpl
In-Reply-To: <4F21E61E.80809@univ-mlv.fr>
References: <F845866E-6E29-4DBA-A06A-DA1A8C8D95A9@oracle.com>
<4F21D1E3.3040706@univ-mlv.fr>
<F456B05B-BA0B-483F-AAFD-1E163B9B63E2@oracle.com>
<4F21E61E.80809@univ-mlv.fr>
Message-ID: <16BD2690-E9EA-4604-B4B6-88F48A51E416@oracle.com>

Hi Remi,

thanks for the additional info. Made the extra changehttp://cr.openjdk.java.net/~lancea/7133815/webrev.02, so I hope we are good to go now.

Best
Lance
On Jan 26, 2012, at 6:47 PM, R?mi Forax wrote:

> On 01/27/2012 12:12 AM, Lance Andersen - Oracle wrote:
>> Hi Remi,
>>
>> Thanks for the feedback, I made the suggested changes http://cr.openjdk.java.net/~lancea/7133815/webrev.01/ and re-ran the rowset tck .
>>
>> Best
>> Lance
>
> Lance,
> sorry to not have been crystal clear in my previous email,
> I've forgotten to mention that because the field is stored in a local variable
> to do the nullcheck you can reuse the same local variable instead of
> reloading the value from the field which is a good code practice.
>
> So instead of
>
> int[] keyColumns = this.keyCols;
> return (keyColumns == null) ? null : Arrays.copyOf(keyCols, keyCols.length);
>
> the code should be
>
> int[] keyColumns = this.keyCols;
> return (keyColumns == null) ? null : Arrays.copyOf(keyColumns,keyColumns.length);
>
>
> Now, this is not strictly needed for the codes of the changeset because the JIT
> can easily prove in these codes that the field will not be changed between
> the first load and the subsequent accesses as arguments of Arrays.copyOf.
>
> Anyway, as i said, it's a good practice to avoid to do several getfields
> if the value is not supposed to change in between.
>
> R?mi
>
> PS: as a bonus, using local variables reduces the size of the generated bytecodes,
> aload_1 takes one byte and getfield takes three bytes :)
>
>> On Jan 26, 2012, at 5:21 PM, R?mi Forax wrote:
>>
>>> On 01/26/2012 10:46 PM, Lance Andersen - Oracle wrote:
>>>> Hi,
>>>>
>>>> Looking for a reviewer for http://cr.openjdk.java.net/~lancea/7133815/webrev.00/
>>>>
>>>> this is a small change to address 2 findbug errors. The findbug issues being addressed:
>>>>
>>>> May expose internal representation by returning reference to mutable object
>>>>
>>>> and
>>>>
>>>> Load of known null value
>>>>
>>>>
>>>> For CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl
>>> Hi Lance,
>>> I think it's better to use array.clone() or
>>> Arrays.copyOf(array, array.length) which is a little faster.
>>>
>>> so the code of CachedRowSetImpl should be:
>>>
>>> int[]keyCols = this.keyCols;
>>> return (keyCols == null)? null: Arrays.copyOf(keyCols, keyCols.length);
>>>
>>> otherwise the code of SQLOutputImpl is ok for me.
>>>
>>> cheers,
>>> R?mi
>>>
>>
>> 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 forax at univ-mlv.fr Fri Jan 27 00:33:43 2012
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 27 Jan 2012 01:33:43 +0100
Subject: Review needed for 7132879 to address the findbug errors in
CachedRowSetImpl,
SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl
In-Reply-To: <16BD2690-E9EA-4604-B4B6-88F48A51E416@oracle.com>
References: <F845866E-6E29-4DBA-A06A-DA1A8C8D95A9@oracle.com>
<4F21D1E3.3040706@univ-mlv.fr>
<F456B05B-BA0B-483F-AAFD-1E163B9B63E2@oracle.com>
<4F21E61E.80809@univ-mlv.fr>
<16BD2690-E9EA-4604-B4B6-88F48A51E416@oracle.com>
Message-ID: <4F21F0E7.8090403@univ-mlv.fr>

On 01/27/2012 01:03 AM, Lance Andersen - Oracle wrote:
> Hi Remi,
>
> thanks for the additional info. Made the extra changehttp://cr.openjdk.java.net/~lancea/7133815/webrev.02, so I hope we are good to go now.
>
> Best
> Lance

thumb up :)

R?mi

> On Jan 26, 2012, at 6:47 PM, R?mi Forax wrote:
>
>> On 01/27/2012 12:12 AM, Lance Andersen - Oracle wrote:
>>> Hi Remi,
>>>
>>> Thanks for the feedback, I made the suggested changes http://cr.openjdk.java.net/~lancea/7133815/webrev.01/ and re-ran the rowset tck .
>>>
>>> Best
>>> Lance
>> Lance,
>> sorry to not have been crystal clear in my previous email,
>> I've forgotten to mention that because the field is stored in a local variable
>> to do the nullcheck you can reuse the same local variable instead of
>> reloading the value from the field which is a good code practice.
>>
>> So instead of
>>
>> int[] keyColumns = this.keyCols;
>> return (keyColumns == null) ? null : Arrays.copyOf(keyCols, keyCols.length);
>>
>> the code should be
>>
>> int[] keyColumns = this.keyCols;
>> return (keyColumns == null) ? null : Arrays.copyOf(keyColumns,keyColumns.length);
>>
>>
>> Now, this is not strictly needed for the codes of the changeset because the JIT
>> can easily prove in these codes that the field will not be changed between
>> the first load and the subsequent accesses as arguments of Arrays.copyOf.
>>
>> Anyway, as i said, it's a good practice to avoid to do several getfields
>> if the value is not supposed to change in between.
>>
>> R?mi
>>
>> PS: as a bonus, using local variables reduces the size of the generated bytecodes,
>> aload_1 takes one byte and getfield takes three bytes :)
>>
>>> On Jan 26, 2012, at 5:21 PM, R?mi Forax wrote:
>>>
>>>> On 01/26/2012 10:46 PM, Lance Andersen - Oracle wrote:
>>>>> Hi,
>>>>>
>>>>> Looking for a reviewer for http://cr.openjdk.java.net/~lancea/7133815/webrev.00/
>>>>>
>>>>> this is a small change to address 2 findbug errors. The findbug issues being addressed:
>>>>>
>>>>> May expose internal representation by returning reference to mutable object
>>>>>
>>>>> and
>>>>>
>>>>> Load of known null value
>>>>>
>>>>>
>>>>> For CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl
>>>> Hi Lance,
>>>> I think it's better to use array.clone() or
>>>> Arrays.copyOf(array, array.length) which is a little faster.
>>>>
>>>> so the code of CachedRowSetImpl should be:
>>>>
>>>> int[]keyCols = this.keyCols;
>>>> return (keyCols == null)? null: Arrays.copyOf(keyCols, keyCols.length);
>>>>
>>>> otherwise the code of SQLOutputImpl is ok for me.
>>>>
>>>> cheers,
>>>> R?mi
>>>>
>>> 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 lance.andersen at oracle.com Fri Jan 27 00:42:05 2012
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Fri, 27 Jan 2012 00:42:05 +0000
Subject: hg: jdk8/tl/jdk: 7133815: address the findbug errors in
CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl,
SerialOutputImpl
Message-ID: <20120127004215.C6803471E7@hg.openjdk.java.net>

Changeset: b518b160607f
Author: lancea
Date: 2012-01-26 19:41 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b518b160607f

7133815: address the findbug errors in CachedRowSetImpl, SerialStruct, BaseRow, SerialInputImpl, SerialOutputImpl
Reviewed-by: forax

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/BaseRow.java
! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java
! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java
! src/share/classes/javax/sql/rowset/serial/SerialStruct.java



From bradford.wetmore at oracle.com Fri Jan 27 01:16:54 2012
From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com)
Date: Fri, 27 Jan 2012 01:16:54 +0000
Subject: hg: jdk8/tl/jdk: 7126889: Incorrect SSLEngine debug output
Message-ID: <20120127011704.23275471EA@hg.openjdk.java.net>

Changeset: 5ee30ab905db
Author: wetmore
Date: 2012-01-26 17:16 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ee30ab905db

7126889: Incorrect SSLEngine debug output
Reviewed-by: xuelei

! src/share/classes/sun/security/ssl/EngineArgs.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.java
+ test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh



From joe.darcy at oracle.com Fri Jan 27 01:33:51 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 26 Jan 2012 17:33:51 -0800
Subject: Using unsigned library work in the JDK
In-Reply-To: <4F2192C3.3080808@oracle.com>
References: <4F20D879.8010800@oracle.com> <4F2192C3.3080808@oracle.com>
Message-ID: <4F21FEFF.8040100@oracle.com>

Sherman, thanks for offering to investigate the performance impact, if
any, of this change.

-Joe

PS All the jar/zip regression tests pass with this change.

On 01/26/2012 09:52 AM, Xueming Shen wrote:
> Joe,
>
> The changes look fine. However I have the same performance concern in
> cases that the vm fails to inline the toUnsignedInt(), especially for
> those
> "simple" one line utility methods, such as the get16(), CH(), SH(), my
> guess is that it might have a performance impact. It might not be a big
> deal for operation like creating or extracting a jar/zip file but
> probably will
> slow down the loc/cen table reading only operation such as list a jar/zip
> file. I will try to get some performance data to see if the impact is
> "significant" enough to be a real concern.
>
> -Sherman
>
> On 01/25/2012 08:37 PM, Joe Darcy wrote:
>> Hello,
>>
>> As a follow-up to the recent push of unsigned library support in the
>> JDK [1], I grepped -i for "0xff" in the JDK code base to look for
>> candidate locations to use the new methods. I choose to first tackle
>> some jar/zip code.
>>
>> Sherman, can you review the changes below?
>>
>> diff -r 303b67074666
>> src/share/classes/java/util/jar/JarOutputStream.java
>> --- a/src/share/classes/java/util/jar/JarOutputStream.java Tue Jan
>> 24 15:13:27 2012 -0500
>> +++ b/src/share/classes/java/util/jar/JarOutputStream.java Wed Jan
>> 25 20:31:05 2012 -0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All
>> rights reserved.
>> + * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All
>> rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -135,7 +135,7 @@
>> * The bytes are assumed to be in Intel (little-endian) byte order.
>> */
>> private static int get16(byte[] b, int off) {
>> - return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8);
>> + return Byte.toUnsignedInt(b[off]) | (
>> Byte.toUnsignedInt(b[off+1]) << 8);
>> }
>>
>> /*
>> diff -r 303b67074666 src/share/classes/java/util/jar/Manifest.java
>> --- a/src/share/classes/java/util/jar/Manifest.java Tue Jan 24
>> 15:13:27 2012 -0500
>> +++ b/src/share/classes/java/util/jar/Manifest.java Wed Jan 25
>> 20:31:05 2012 -0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2006, Oracle and/or its affiliates. All
>> rights reserved.
>> + * Copyright (c) 1997, 2012, Oracle and/or its affiliates. All
>> rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -339,7 +339,7 @@
>> return -1;
>> }
>> }
>> - return buf[pos++] & 0xff;
>> + return Byte.toUnsignedInt(buf[pos++]);
>> }
>>
>> public int read(byte[] b, int off, int len) throws
>> IOException {
>> diff -r 303b67074666
>> src/share/classes/java/util/zip/InflaterInputStream.java
>> --- a/src/share/classes/java/util/zip/InflaterInputStream.java Tue
>> Jan 24 15:13:27 2012 -0500
>> +++ b/src/share/classes/java/util/zip/InflaterInputStream.java Wed
>> Jan 25 20:31:05 2012 -0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1996, 2006, Oracle and/or its affiliates. All
>> rights reserved.
>> + * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All
>> rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -119,7 +119,7 @@
>> */
>> public int read() throws IOException {
>> ensureOpen();
>> - return read(singleByteBuf, 0, 1) == -1 ? -1 :
>> singleByteBuf[0] & 0xff;
>> + return read(singleByteBuf, 0, 1) == -1 ? -1 :
>> Byte.toUnsignedInt(singleByteBuf[0]);
>> }
>>
>> /**
>> diff -r 303b67074666 src/share/classes/java/util/zip/ZipInputStream.java
>> --- a/src/share/classes/java/util/zip/ZipInputStream.java Tue Jan
>> 24 15:13:27 2012 -0500
>> +++ b/src/share/classes/java/util/zip/ZipInputStream.java Wed Jan
>> 25 20:31:05 2012 -0800
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1996, 2009, Oracle and/or its affiliates. All
>> rights reserved.
>> + * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All
>> rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -435,7 +435,7 @@
>> * The bytes are assumed to be in Intel (little-endian) byte order.
>> */
>> private static final int get16(byte b[], int off) {
>> - return (b[off] & 0xff) | ((b[off+1] & 0xff) << 8);
>> + return Byte.toUnsignedInt(b[off]) |
>> (Byte.toUnsignedInt(b[off+1]) << 8);
>> }
>>
>> /*
>> diff -r 303b67074666
>> src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
>> ---
>> a/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
>> Tue Jan 24 15:13:27 2012 -0500
>> +++
>> b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java
>> Wed Jan 25 20:31:05 2012 -0800
>> @@ -185,11 +185,11 @@
>> */
>> ///////////////////////////////////////////////////////
>> static final int CH(byte[] b, int n) {
>> - return b[n] & 0xff;
>> + return Byte.toUnsignedInt(b[n]);
>> }
>>
>> static final int SH(byte[] b, int n) {
>> - return (b[n] & 0xff) | ((b[n + 1] & 0xff) << 8);
>> + return Byte.toUnsignedInt(b[n]) | (Byte.toUnsignedInt(b[n +
>> 1]) << 8);
>> }
>>
>> static final long LG(byte[] b, int n) {
>>
>> If the changes look good, I'll file a bug for them, etc.
>>
>> In case other people want to look over candidates sites in different
>> areas, I've included the list of JDK files using "0xff" below.
>>
>> Thanks,
>>
>> -Joe
>>
>> [1] 4504839: Java libraries should provide support for unsigned
>> integer arithmetic
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-January/008926.html
>>
>>
>> .



From brandon.passanisi at oracle.com Fri Jan 27 01:50:22 2012
From: brandon.passanisi at oracle.com (Brandon Passanisi)
Date: Thu, 26 Jan 2012 17:50:22 -0800
Subject: Code review request for #6469160, #7088271: (fmt) format("%.1g",
0.0) throws ArrayOutOfBoundsException
In-Reply-To: <4F1FB632.4070802@oracle.com>
References: <4F19B04C.8040104@oracle.com> <4F1E4819.5080505@oracle.com>
<4F1FA929.4020303@oracle.com> <4F1FB632.4070802@oracle.com>
Message-ID: <4F2202DE.3060406@oracle.com>

Hi David. I have revised my fix for this CR. Here's a description of
the most recent changes:

1. The code fix has been moved slightly from it's original position
into a section within FormattedFloatingDecimal.java which handles
0.0* numbers.

2. The code fix no longer changes the precision value.

3. The code fix checks to see if the precision is 1 and the number
is a one-digit 0. If not, the normal code which adds the decimal
and remaining digits is run. If so, this block of code is not run.

In addition, I have re-run the Basic-X set of Formatter tests to make
sure there aren't any regressions.

Webrev: http://cr.openjdk.java.net/~bpassani/6469160/1/webrev/
<http://cr.openjdk.java.net/%7Ebpassani/6469160/1/webrev/>


Thanks.

On 1/24/2012 11:58 PM, David Holmes wrote:
> Hi Brandon,
>
> On 25/01/2012 5:03 PM, Brandon Passanisi wrote:
>> Hi David. Thank you for your review comments. My answers to your
>> questions are below:
>>
>> On 1/23/2012 9:56 PM, David Holmes wrote:
>>> More generally it is not clear to me that putting in this special case
>>> is the right way to fix this. Though I admit I don't really understand
>>> what the specification requires when you give a precision of 0 with a
>>> 'g' conversion:
>>>
>>> "If the conversion is 'g' or 'G', then the precision is the total
>>> number of digits in the resulting magnitude after rounding."
>>>
>>> So we asked for zero digits? What should that mean?
>>
>> The Formatter javadoc, within the "Float and Double" section, describes
>> the following regarding a value of 0 for precision and the 'g'/'G'
>> conversion [1]:
>>
>> "If the precision is 0, then it is taken to be 1"
>
> Ah! Thanks. I hadn't seen that (wish they wouldn't split up the spec
> for this across different sections!).
>
> Okay that explains the 0/1 situation.
>
> But that makes me question the "rightness" of the fix even more. We
> took steps to change a precision of 0 to 1, but then the fix changes
> it back to 0 because otherwise something else breaks. Seems to me that
> the "something else" that handles the precision of 1 incorrectly is
> the code that really needs to be fixed. Further it suggest that there
> may be assumptions in later code that precision is in fact never 0.
>
> David
> -----
>
>
>> The following code block within Formatter.java near line 3278 is run to
>> do this:
>>
>> if (precision == -1)
>> prec = 6;
>> else if (precision == 0)
>> prec = 1;
>>
>> And the precision value "prec" is given to FormattedFloatingDecimal.
>> Therefore, when this particular error condition is seen and the proposed
>> code fix is reached in FormattedFloatingDecimal.java, the precision will
>> be 1. So, the proposed code fix ends up supporting a precision value of
>> 0 and 1.
>>
>>
>> [1]: http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html
>>
>>
>> Thanks.
>>
>>>
>>> David
>>> -----
>>>
>>>> Since java has been throwing exceptions in these cases, I consulted
>>>> with
>>>> the output of C's printf to make sure that the outputted strings
>>>> are the
>>>> same. I updated the Formatter's Basic-X template of tests with a
>>>> little
>>>> over 20 test format strings that were causing exceptions without the
>>>> change and the output of each is compared with the output from C's
>>>> printf with the same format string. And, I ran all of the Basic-X
>>>> tests
>>>> to make sure there weren't any regressions in behavior.
>>>>
>>>> Thanks.
>>

--
Oracle <http://www.oracle.com>
Brandon Passanisi | Principle Member of Technical Staff


Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment


From masayoshi.okutsu at oracle.com Fri Jan 27 06:50:16 2012
From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com)
Date: Fri, 27 Jan 2012 06:50:16 +0000
Subject: hg: jdk8/tl/jdk: 7130335: Problem with timezone in a SimpleDateFormat
Message-ID: <20120127065039.955054721C@hg.openjdk.java.net>

Changeset: 7aa5ddfa3c9d
Author: okutsu
Date: 2012-01-27 14:58 +0900
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7aa5ddfa3c9d

7130335: Problem with timezone in a SimpleDateFormat
Reviewed-by: peytoia

! src/share/classes/java/text/SimpleDateFormat.java
+ test/java/text/Format/DateFormat/Bug7130335.java



From david.holmes at oracle.com Fri Jan 27 06:52:48 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Jan 2012 16:52:48 +1000
Subject: Code review request for #6469160, #7088271: (fmt) format("%.1g",
0.0) throws ArrayOutOfBoundsException
In-Reply-To: <4F2202DE.3060406@oracle.com>
References: <4F19B04C.8040104@oracle.com> <4F1E4819.5080505@oracle.com>
<4F1FA929.4020303@oracle.com> <4F1FB632.4070802@oracle.com>
<4F2202DE.3060406@oracle.com>
Message-ID: <4F2249C0.206@oracle.com>

Hi Brandon,

This point fix still bothered me so I dug a bit deeper into what the
code does (as complex and convoluted as it is). I wanted to compare the
cases of 0.0 and 1.0 to see why they differed and it seemed to me that
the difference was introduced way back when the FormattedFloatingDecimal
is created. If we detect a zero we initialize explicitly as:

decExponent = 0;
digits = zero;
nDigits = 1;

whereas with 1.0 we'd have a decExponent of 1. Later in the code (at the
site of your original change) we have:

} else {
form = Form.DECIMAL_FLOAT;
precision = precision - exp;
}

which will leave precision unchanged at 1 for 0.0 ( 1 minus 0) but will
drop it to 0 for 1.0 ( 1 minus 1). Your original fix hardwired changing
the precision to 0 if dealing with 0. It seemed to me that if we go back
to that constructor and instead set decExponent == 1 for the zero case,
then we will later get the desired precision==0 and avoid the
ArrayOutOfBoundsException. And we do, but not for that reason. By
setting decExponent to 1 we enter the "print digit.digits" branch rather
than the "print 0.0*" branch - and it works (though not exhaustively
tested).

Your updated patch tackles the "print 0.0* digits" path. We skip the
first if block as exp==0. We would then hit:

int t = Math.min(digits.length, precision + exp);
if (t > 0) {

Your original patch will cause t==0 so we skip the if block. Your new
patch guards the Math.min and the if block with an additional:

if (precision != 1 || digits[0] != '0' || digits.length != 1) {

so we again skip the t>0 if block.

I'm left wondering of any of these three "fixes" are actually 'the right
fix", or whether it really matters. Presuming a second reviewer is
needed anyway perhaps we should just wait to see what they have to offer.

Apologies that this has (again) become far more time consuming than
anticipated. I wish a domain expert would step in on this (assuming one
still exists).

Thanks,
David

On 27/01/2012 11:50 AM, Brandon Passanisi wrote:
> Hi David. I have revised my fix for this CR. Here's a description of the
> most recent changes:
>
> 1. The code fix has been moved slightly from it's original position
> into a section within FormattedFloatingDecimal.java which handles
> 0.0* numbers.
>
> 2. The code fix no longer changes the precision value.
>
> 3. The code fix checks to see if the precision is 1 and the number
> is a one-digit 0. If not, the normal code which adds the decimal
> and remaining digits is run. If so, this block of code is not run.
>
> In addition, I have re-run the Basic-X set of Formatter tests to make
> sure there aren't any regressions.
>
> Webrev: http://cr.openjdk.java.net/~bpassani/6469160/1/webrev/
> <http://cr.openjdk.java.net/%7Ebpassani/6469160/1/webrev/>
>
>
> Thanks.
>
> On 1/24/2012 11:58 PM, David Holmes wrote:
>> Hi Brandon,
>>
>> On 25/01/2012 5:03 PM, Brandon Passanisi wrote:
>>> Hi David. Thank you for your review comments. My answers to your
>>> questions are below:
>>>
>>> On 1/23/2012 9:56 PM, David Holmes wrote:
>>>> More generally it is not clear to me that putting in this special case
>>>> is the right way to fix this. Though I admit I don't really understand
>>>> what the specification requires when you give a precision of 0 with a
>>>> 'g' conversion:
>>>>
>>>> "If the conversion is 'g' or 'G', then the precision is the total
>>>> number of digits in the resulting magnitude after rounding."
>>>>
>>>> So we asked for zero digits? What should that mean?
>>>
>>> The Formatter javadoc, within the "Float and Double" section, describes
>>> the following regarding a value of 0 for precision and the 'g'/'G'
>>> conversion [1]:
>>>
>>> "If the precision is 0, then it is taken to be 1"
>>
>> Ah! Thanks. I hadn't seen that (wish they wouldn't split up the spec
>> for this across different sections!).
>>
>> Okay that explains the 0/1 situation.
>>
>> But that makes me question the "rightness" of the fix even more. We
>> took steps to change a precision of 0 to 1, but then the fix changes
>> it back to 0 because otherwise something else breaks. Seems to me that
>> the "something else" that handles the precision of 1 incorrectly is
>> the code that really needs to be fixed. Further it suggest that there
>> may be assumptions in later code that precision is in fact never 0.
>>
>> David
>> -----
>>
>>
>>> The following code block within Formatter.java near line 3278 is run to
>>> do this:
>>>
>>> if (precision == -1)
>>> prec = 6;
>>> else if (precision == 0)
>>> prec = 1;
>>>
>>> And the precision value "prec" is given to FormattedFloatingDecimal.
>>> Therefore, when this particular error condition is seen and the proposed
>>> code fix is reached in FormattedFloatingDecimal.java, the precision will
>>> be 1. So, the proposed code fix ends up supporting a precision value of
>>> 0 and 1.
>>>
>>>
>>> [1]: http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html
>>>
>>>
>>> Thanks.
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>>> Since java has been throwing exceptions in these cases, I consulted
>>>>> with
>>>>> the output of C's printf to make sure that the outputted strings
>>>>> are the
>>>>> same. I updated the Formatter's Basic-X template of tests with a
>>>>> little
>>>>> over 20 test format strings that were causing exceptions without the
>>>>> change and the output of each is compared with the output from C's
>>>>> printf with the same format string. And, I ran all of the Basic-X
>>>>> tests
>>>>> to make sure there weren't any regressions in behavior.
>>>>>
>>>>> Thanks.
>>>
>


From michael.x.mcmahon at oracle.com Fri Jan 27 11:41:08 2012
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Fri, 27 Jan 2012 11:41:08 +0000
Subject: RFR: 7134690: remove legacy jnilib support from ClassLoader and System
[macosx]
Message-ID: <4F228D54.8040801@oracle.com>

Can I get the following change reviewed please? The change is to remove
some mac specific code from:

src/share/classes/java/lang/System.java and
src/share/classes/java/lang/ClassLoader.java

which added support for non-standard native library suffixes on Mac OS
(ie. .jnilib as well as the standard .dylib).

We would like to remove this code, so there will be no changes to those
sources
when the Mac changes get pushed to jdk7u-dev

I have submitted a hotspot CR to track providing the same functionality
in Mac specific code in hotspot. Though we can probably live without it
in the short-term.

http://cr.openjdk.java.net/~michaelm/7134690/webrev.1/

Thanks
Michael


From Alan.Bateman at oracle.com Fri Jan 27 12:12:08 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 27 Jan 2012 12:12:08 +0000
Subject: RFR: 7134690: remove legacy jnilib support from ClassLoader and
System [macosx]
In-Reply-To: <4F228D54.8040801@oracle.com>
References: <4F228D54.8040801@oracle.com>
Message-ID: <4F229498.7030701@oracle.com>

On 27/01/2012 11:41, Michael McMahon wrote:
> Can I get the following change reviewed please? The change is to remove
> some mac specific code from:
>
> src/share/classes/java/lang/System.java and
> src/share/classes/java/lang/ClassLoader.java
>
> which added support for non-standard native library suffixes on Mac OS
> (ie. .jnilib as well as the standard .dylib).
>
> We would like to remove this code, so there will be no changes to
> those sources
> when the Mac changes get pushed to jdk7u-dev
>
> I have submitted a hotspot CR to track providing the same functionality
> in Mac specific code in hotspot. Though we can probably live without
> it in the short-term.
>
> http://cr.openjdk.java.net/~michaelm/7134690/webrev.1/
This looks fine to me as this wasn't the right place to support this. I
don't know how common .jnilib was to know if the VM changes will be
required in the short term.

-Alan


From kumar.x.srinivasan at oracle.COM Fri Jan 27 18:03:52 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Fri, 27 Jan 2012 10:03:52 -0800
Subject: Please review: 7127906: (launcher) convert the launcher regression
tests to java
Message-ID: <4F22E708.2070104@oracle.COM>

Hi Joe, Naoto, Sherman,

Here are the highlights of these changes:

1. The TestHelper.java is now extensible, this simplifies the usage of
static variables
and methods, added a couple of convenience methods and some minor
refactoring.

2. Eliminated some shell tests, (few more remaining, saved for a future
project).
a. UnicodeTest.sh, UnicodeCleanup.java merged into UnicodeTest.java
b. i18nTest.sh, deleteI18n.sh, CreatePlatformFile.java merged into
I18NTest.java
c. ChangeDataModel.sh converted to ChangeDataModel.java
d. unresolvedExceptions.sh converted and merged into
UnresolvedExceptions.java

3. Arrrghs.java when testing on Solaris with ja_JP.UTF-8 locale, some
of the tests fail
as the launcher messages in java are localized, therefore these
tests are skipped,
under such conditions.

Tests: Windows English/Japanese, Solaris C/ja_JP.UTF-8 + usual jprt
systems (undergoing).

webrev: http://cr.openjdk.java.net/~ksrini/7127906/webrev.0/

Thanks
Kumar




From joe.darcy at oracle.com Fri Jan 27 18:30:29 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 27 Jan 2012 10:30:29 -0800
Subject: Please review: 7127906: (launcher) convert the launcher regression
tests to java
In-Reply-To: <4F22E708.2070104@oracle.COM>
References: <4F22E708.2070104@oracle.COM>
Message-ID: <4F22ED45.7060406@oracle.com>

Hi Kumar,

Looks fine; good to see the shell code go away!

-Joe

On 01/27/2012 10:03 AM, Kumar Srinivasan wrote:
> Hi Joe, Naoto, Sherman,
>
> Here are the highlights of these changes:
>
> 1. The TestHelper.java is now extensible, this simplifies the usage of
> static variables
> and methods, added a couple of convenience methods and some minor
> refactoring.
>
> 2. Eliminated some shell tests, (few more remaining, saved for a
> future project).
> a. UnicodeTest.sh, UnicodeCleanup.java merged into UnicodeTest.java
> b. i18nTest.sh, deleteI18n.sh, CreatePlatformFile.java merged into
> I18NTest.java
> c. ChangeDataModel.sh converted to ChangeDataModel.java
> d. unresolvedExceptions.sh converted and merged into
> UnresolvedExceptions.java
>
> 3. Arrrghs.java when testing on Solaris with ja_JP.UTF-8 locale, some
> of the tests fail
> as the launcher messages in java are localized, therefore these
> tests are skipped,
> under such conditions.
>
> Tests: Windows English/Japanese, Solaris C/ja_JP.UTF-8 + usual jprt
> systems (undergoing).
>
> webrev: http://cr.openjdk.java.net/~ksrini/7127906/webrev.0/
>
> Thanks
> Kumar
>
>



From naoto.sato at oracle.com Fri Jan 27 19:05:26 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 27 Jan 2012 11:05:26 -0800
Subject: Please review: 7127906: (launcher) convert the launcher regression
tests to java
In-Reply-To: <4F22ED45.7060406@oracle.com>
References: <4F22E708.2070104@oracle.COM> <4F22ED45.7060406@oracle.com>
Message-ID: <4F22F576.5010203@oracle.com>

Hi Kumar,

I have a question/suggestion on TestHelper.isEnglishLocale field.

- Is there any chance that the test case changes the default locale by
Locale.setDefault() during the test execution? If that's the case,
static initialization of the field may not work.

- If the default locale does not change during the test execution, then
I'd suggest to initialize it with something like:

isEnglishLocale = Locale.getDefault().getLanguage().equals("en");

Otherwise it won't work with other English locales such as en_GB.

Other than that, it looks good to me.

Naoto

On 1/27/12 10:30 AM, Joe Darcy wrote:
> Hi Kumar,
>
> Looks fine; good to see the shell code go away!
>
> -Joe
>
> On 01/27/2012 10:03 AM, Kumar Srinivasan wrote:
>> Hi Joe, Naoto, Sherman,
>>
>> Here are the highlights of these changes:
>>
>> 1. The TestHelper.java is now extensible, this simplifies the usage of
>> static variables
>> and methods, added a couple of convenience methods and some minor
>> refactoring.
>>
>> 2. Eliminated some shell tests, (few more remaining, saved for a
>> future project).
>> a. UnicodeTest.sh, UnicodeCleanup.java merged into UnicodeTest.java
>> b. i18nTest.sh, deleteI18n.sh, CreatePlatformFile.java merged into
>> I18NTest.java
>> c. ChangeDataModel.sh converted to ChangeDataModel.java
>> d. unresolvedExceptions.sh converted and merged into
>> UnresolvedExceptions.java
>>
>> 3. Arrrghs.java when testing on Solaris with ja_JP.UTF-8 locale, some
>> of the tests fail
>> as the launcher messages in java are localized, therefore these tests
>> are skipped,
>> under such conditions.
>>
>> Tests: Windows English/Japanese, Solaris C/ja_JP.UTF-8 + usual jprt
>> systems (undergoing).
>>
>> webrev: http://cr.openjdk.java.net/~ksrini/7127906/webrev.0/
>>
>> Thanks
>> Kumar
>>
>>
>



From kumar.x.srinivasan at oracle.COM Fri Jan 27 19:36:16 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Fri, 27 Jan 2012 11:36:16 -0800
Subject: Please review: 7127906: (launcher) convert the launcher regression
tests to java
In-Reply-To: <4F22F576.5010203@oracle.com>
References: <4F22E708.2070104@oracle.COM> <4F22ED45.7060406@oracle.com>
<4F22F576.5010203@oracle.com>
Message-ID: <4F22FCB0.5070608@oracle.COM>

On 1/27/2012 11:05 AM, Naoto Sato wrote:
> Hi Kumar,
>
> I have a question/suggestion on TestHelper.isEnglishLocale field.
>
> - Is there any chance that the test case changes the default locale by
> Locale.setDefault() during the test execution? If that's the case,
> static initialization of the field may not work.

Yes, the tests that do change the default locale are UnicodeTest.java and
I18NJarTest.java, however they execute in their own child Process/VM.

I think I should also the save default to a static, such that we can
revert back the locale to the original default.

>
> - If the default locale does not change during the test execution,
> then I'd suggest to initialize it with something like:
>
> isEnglishLocale = Locale.getDefault().getLanguage().equals("en");

What do you suggest ?

Thanks
Kumar

>
> Otherwise it won't work with other English locales such as en_GB.
>
> Other than that, it looks good to me.
>
> Naoto
>
> On 1/27/12 10:30 AM, Joe Darcy wrote:
>> Hi Kumar,
>>
>> Looks fine; good to see the shell code go away!
>>
>> -Joe
>>
>> On 01/27/2012 10:03 AM, Kumar Srinivasan wrote:
>>> Hi Joe, Naoto, Sherman,
>>>
>>> Here are the highlights of these changes:
>>>
>>> 1. The TestHelper.java is now extensible, this simplifies the usage of
>>> static variables
>>> and methods, added a couple of convenience methods and some minor
>>> refactoring.
>>>
>>> 2. Eliminated some shell tests, (few more remaining, saved for a
>>> future project).
>>> a. UnicodeTest.sh, UnicodeCleanup.java merged into UnicodeTest.java
>>> b. i18nTest.sh, deleteI18n.sh, CreatePlatformFile.java merged into
>>> I18NTest.java
>>> c. ChangeDataModel.sh converted to ChangeDataModel.java
>>> d. unresolvedExceptions.sh converted and merged into
>>> UnresolvedExceptions.java
>>>
>>> 3. Arrrghs.java when testing on Solaris with ja_JP.UTF-8 locale, some
>>> of the tests fail
>>> as the launcher messages in java are localized, therefore these tests
>>> are skipped,
>>> under such conditions.
>>>
>>> Tests: Windows English/Japanese, Solaris C/ja_JP.UTF-8 + usual jprt
>>> systems (undergoing).
>>>
>>> webrev: http://cr.openjdk.java.net/~ksrini/7127906/webrev.0/
>>>
>>> Thanks
>>> Kumar
>>>
>>>
>>
>



From naoto.sato at oracle.com Fri Jan 27 19:49:09 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 27 Jan 2012 11:49:09 -0800
Subject: Please review: 7127906: (launcher) convert the launcher regression
tests to java
In-Reply-To: <4F22FCB0.5070608@oracle.COM>
References: <4F22E708.2070104@oracle.COM> <4F22ED45.7060406@oracle.com>
<4F22F576.5010203@oracle.com> <4F22FCB0.5070608@oracle.COM>
Message-ID: <4F22FFB5.4020007@oracle.com>

On 1/27/12 11:36 AM, Kumar Srinivasan wrote:
> On 1/27/2012 11:05 AM, Naoto Sato wrote:
>> Hi Kumar,
>>
>> I have a question/suggestion on TestHelper.isEnglishLocale field.
>>
>> - Is there any chance that the test case changes the default locale by
>> Locale.setDefault() during the test execution? If that's the case,
>> static initialization of the field may not work.
>
> Yes, the tests that do change the default locale are UnicodeTest.java and
> I18NJarTest.java, however they execute in their own child Process/VM.
>

Then I'd prefer to have isEnglishLocale as a simple static method,
rather than a field.

> I think I should also the save default to a static, such that we can
> revert back the locale to the original default.

Good point.

>
>>
>> - If the default locale does not change during the test execution,
>> then I'd suggest to initialize it with something like:
>>
>> isEnglishLocale = Locale.getDefault().getLanguage().equals("en");
>
> What do you suggest ?

To replace the current isEnglishLocale logic with the above, which
should work for all English language locales.

Naoto

>
> Thanks
> Kumar
>
>>
>> Otherwise it won't work with other English locales such as en_GB.
>>
>> Other than that, it looks good to me.
>>
>> Naoto
>>
>> On 1/27/12 10:30 AM, Joe Darcy wrote:
>>> Hi Kumar,
>>>
>>> Looks fine; good to see the shell code go away!
>>>
>>> -Joe
>>>
>>> On 01/27/2012 10:03 AM, Kumar Srinivasan wrote:
>>>> Hi Joe, Naoto, Sherman,
>>>>
>>>> Here are the highlights of these changes:
>>>>
>>>> 1. The TestHelper.java is now extensible, this simplifies the usage of
>>>> static variables
>>>> and methods, added a couple of convenience methods and some minor
>>>> refactoring.
>>>>
>>>> 2. Eliminated some shell tests, (few more remaining, saved for a
>>>> future project).
>>>> a. UnicodeTest.sh, UnicodeCleanup.java merged into UnicodeTest.java
>>>> b. i18nTest.sh, deleteI18n.sh, CreatePlatformFile.java merged into
>>>> I18NTest.java
>>>> c. ChangeDataModel.sh converted to ChangeDataModel.java
>>>> d. unresolvedExceptions.sh converted and merged into
>>>> UnresolvedExceptions.java
>>>>
>>>> 3. Arrrghs.java when testing on Solaris with ja_JP.UTF-8 locale, some
>>>> of the tests fail
>>>> as the launcher messages in java are localized, therefore these tests
>>>> are skipped,
>>>> under such conditions.
>>>>
>>>> Tests: Windows English/Japanese, Solaris C/ja_JP.UTF-8 + usual jprt
>>>> systems (undergoing).
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ksrini/7127906/webrev.0/
>>>>
>>>> Thanks
>>>> Kumar
>>>>
>>>>
>>>
>>
>



From tbuktu at hotmail.com Fri Jan 27 22:41:39 2012
From: tbuktu at hotmail.com (Tim Buktu)
Date: Fri, 27 Jan 2012 15:41:39 -0700
Subject: Updated unit test for BigInteger patch (#4837946)
In-Reply-To: <4F0DDC21.90504@oracle.com>
References: <BLU0-SMTP1834158AEF452F0E964F245C69A0@phx.gbl>
<BLU0-SMTP220B8AE166DE1CB2D348063C6990@phx.gbl>
<4F0DDC21.90504@oracle.com>
Message-ID: <BLU0-SMTP152615288E2D14C60D2B49DC68E0@phx.gbl>

On 01/11/2012 11:59 AM, Joe Darcy wrote:
> Thanks Tim. I'll add this to my review queue after Alan Eliasen's work
> (finally) gets in.

Is there a timeframe for this yet?


From huizhe.wang at oracle.com Fri Jan 27 23:05:57 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 27 Jan 2012 15:05:57 -0800
Subject: Review request for 7133220: Additional patches to JAXP 1.4.5 update
1 for 7u4
In-Reply-To: <4EF4F236.3080200@oracle.com>
References: <4EF4F236.3080200@oracle.com>
Message-ID: <4F232DD4.8050901@oracle.com>

Hi,

With this additional patch, I'm fixing a SpecJvm2008 failure against 7u4
b07 (7098746), along with a couple of other fixes and accumulated Xalan
update. The changes are listed below and at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133220.
The webrev is at: http://cr.openjdk.java.net/~joehw/7u4-7133220/webrev/


Additional patches to JAXP 1.4.5 update 1

Nr Category ID Synopsis/Description
1 JAXP/OTHER 7098746 SpecJvm2008 xml.transform subbenchmark fails
validation
2 JAXP/OTHER 7131589 NPE IN
PARSERCONFIGURATIONSETTINGS.ADDRECOGNIZEDFEATURES
3 JAXP/OTHER 7133058 FINDBUGS WARNINGS IN COM.SUN.XML.INTERNAL.*

Apache Xalan update

Nr Key Synopsis/Description
1 XALANJ-1243 java.lang.StackOverflowError in XString.equals()
2 XALANJ-1991 StackOverflowException comparing two strings
3 XALANJ-2001 normalize-space gives StackOverflowError
4 XALANJ-1434 org.apache.xpath.axes.AxesWalker getLastPos: duplicate
predicate testing (one line change)
5 XALANJ-1497 xsl:copy adds a newline to processing instructions
6 XALANJ-1706 DocumentFragment returned by extension element causes
multiple SAX endDocument() events
7 XALANJ-2218 XML/HTML serializers should have default m_escapeSetting =
true
8 XALANJ-2316 WriterToUTF8Buffered.write(String s) fail with big strings
9 XALANJ-2336 Xalan-J should stop using java.util.Vector in some cases
10 XALANJ-2218 major 11/Mar/06 XML/HTML serializers should have default
m_escapeSetting = true
11 XALANJ-2236 trivial 30/Oct/06 [PATCH] clean up static calls thru
instance references
12 XALANJ-2271 major08/Mar/06 XML 1.1 Serialization, char in attribute
value not escaped


Thanks,
Joe


From valerie.peng at oracle.com Fri Jan 27 23:26:40 2012
From: valerie.peng at oracle.com (valerie.peng at oracle.com)
Date: Fri, 27 Jan 2012 23:26:40 +0000
Subject: hg: jdk8/tl/jdk: 7136538: typo in test/Makefile under the
jdk_security3 target
Message-ID: <20120127232657.9BF1547241@hg.openjdk.java.net>

Changeset: ff24779c147f
Author: valeriep
Date: 2012-01-27 15:25 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff24779c147f

7136538: typo in test/Makefile under the jdk_security3 target
Summary: Fixed the typo of "secrity".
Reviewed-by: wetmore

! test/Makefile



From kumar.x.srinivasan at oracle.COM Fri Jan 27 23:31:10 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Fri, 27 Jan 2012 15:31:10 -0800
Subject: Please review: 7127906: (launcher) convert the launcher regression
tests to java
In-Reply-To: <4F22FFB5.4020007@oracle.com>
References: <4F22E708.2070104@oracle.COM> <4F22ED45.7060406@oracle.com>
<4F22F576.5010203@oracle.com> <4F22FCB0.5070608@oracle.COM>
<4F22FFB5.4020007@oracle.com>
Message-ID: <4F2333BE.2080103@oracle.COM>

Hi Naoto,

Here is the incremental webrev since last revision:
http://cr.openjdk.java.net/~ksrini/7127906/webrev.1/webrev.delta/index.html

Here is the full webrev for reference:
http://cr.openjdk.java.net/~ksrini/7127906/webrev.1/index.html


Thanks
Kumar

> On 1/27/12 11:36 AM, Kumar Srinivasan wrote:
>> On 1/27/2012 11:05 AM, Naoto Sato wrote:
>>> Hi Kumar,
>>>
>>> I have a question/suggestion on TestHelper.isEnglishLocale field.
>>>
>>> - Is there any chance that the test case changes the default locale by
>>> Locale.setDefault() during the test execution? If that's the case,
>>> static initialization of the field may not work.
>>
>> Yes, the tests that do change the default locale are UnicodeTest.java
>> and
>> I18NJarTest.java, however they execute in their own child Process/VM.
>>
>
> Then I'd prefer to have isEnglishLocale as a simple static method,
> rather than a field.
>
>> I think I should also the save default to a static, such that we can
>> revert back the locale to the original default.
>
> Good point.
>
>>
>>>
>>> - If the default locale does not change during the test execution,
>>> then I'd suggest to initialize it with something like:
>>>
>>> isEnglishLocale = Locale.getDefault().getLanguage().equals("en");
>>
>> What do you suggest ?
>
> To replace the current isEnglishLocale logic with the above, which
> should work for all English language locales.
>
> Naoto
>
>>
>> Thanks
>> Kumar
>>
>>>
>>> Otherwise it won't work with other English locales such as en_GB.
>>>
>>> Other than that, it looks good to me.
>>>
>>> Naoto
>>>
>>> On 1/27/12 10:30 AM, Joe Darcy wrote:
>>>> Hi Kumar,
>>>>
>>>> Looks fine; good to see the shell code go away!
>>>>
>>>> -Joe
>>>>
>>>> On 01/27/2012 10:03 AM, Kumar Srinivasan wrote:
>>>>> Hi Joe, Naoto, Sherman,
>>>>>
>>>>> Here are the highlights of these changes:
>>>>>
>>>>> 1. The TestHelper.java is now extensible, this simplifies the
>>>>> usage of
>>>>> static variables
>>>>> and methods, added a couple of convenience methods and some minor
>>>>> refactoring.
>>>>>
>>>>> 2. Eliminated some shell tests, (few more remaining, saved for a
>>>>> future project).
>>>>> a. UnicodeTest.sh, UnicodeCleanup.java merged into UnicodeTest.java
>>>>> b. i18nTest.sh, deleteI18n.sh, CreatePlatformFile.java merged into
>>>>> I18NTest.java
>>>>> c. ChangeDataModel.sh converted to ChangeDataModel.java
>>>>> d. unresolvedExceptions.sh converted and merged into
>>>>> UnresolvedExceptions.java
>>>>>
>>>>> 3. Arrrghs.java when testing on Solaris with ja_JP.UTF-8 locale, some
>>>>> of the tests fail
>>>>> as the launcher messages in java are localized, therefore these tests
>>>>> are skipped,
>>>>> under such conditions.
>>>>>
>>>>> Tests: Windows English/Japanese, Solaris C/ja_JP.UTF-8 + usual jprt
>>>>> systems (undergoing).
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~ksrini/7127906/webrev.0/
>>>>>
>>>>> Thanks
>>>>> Kumar
>>>>>
>>>>>
>>>>
>>>
>>
>



From naoto.sato at oracle.com Fri Jan 27 23:53:05 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 27 Jan 2012 15:53:05 -0800
Subject: Please review: 7127906: (launcher) convert the launcher regression
tests to java
In-Reply-To: <4F2333BE.2080103@oracle.COM>
References: <4F22E708.2070104@oracle.COM> <4F22ED45.7060406@oracle.com>
<4F22F576.5010203@oracle.com> <4F22FCB0.5070608@oracle.COM>
<4F22FFB5.4020007@oracle.com> <4F2333BE.2080103@oracle.COM>
Message-ID: <4F2338E1.6060606@oracle.com>

Looks good to me. Thanks.

Naoto

On 1/27/12 3:31 PM, Kumar Srinivasan wrote:
> Hi Naoto,
>
> Here is the incremental webrev since last revision:
> http://cr.openjdk.java.net/~ksrini/7127906/webrev.1/webrev.delta/index.html
>
> Here is the full webrev for reference:
> http://cr.openjdk.java.net/~ksrini/7127906/webrev.1/index.html
>
>
> Thanks
> Kumar
>
>> On 1/27/12 11:36 AM, Kumar Srinivasan wrote:
>>> On 1/27/2012 11:05 AM, Naoto Sato wrote:
>>>> Hi Kumar,
>>>>
>>>> I have a question/suggestion on TestHelper.isEnglishLocale field.
>>>>
>>>> - Is there any chance that the test case changes the default locale by
>>>> Locale.setDefault() during the test execution? If that's the case,
>>>> static initialization of the field may not work.
>>>
>>> Yes, the tests that do change the default locale are UnicodeTest.java
>>> and
>>> I18NJarTest.java, however they execute in their own child Process/VM.
>>>
>>
>> Then I'd prefer to have isEnglishLocale as a simple static method,
>> rather than a field.
>>
>>> I think I should also the save default to a static, such that we can
>>> revert back the locale to the original default.
>>
>> Good point.
>>
>>>
>>>>
>>>> - If the default locale does not change during the test execution,
>>>> then I'd suggest to initialize it with something like:
>>>>
>>>> isEnglishLocale = Locale.getDefault().getLanguage().equals("en");
>>>
>>> What do you suggest ?
>>
>> To replace the current isEnglishLocale logic with the above, which
>> should work for all English language locales.
>>
>> Naoto
>>
>>>
>>> Thanks
>>> Kumar
>>>
>>>>
>>>> Otherwise it won't work with other English locales such as en_GB.
>>>>
>>>> Other than that, it looks good to me.
>>>>
>>>> Naoto
>>>>
>>>> On 1/27/12 10:30 AM, Joe Darcy wrote:
>>>>> Hi Kumar,
>>>>>
>>>>> Looks fine; good to see the shell code go away!
>>>>>
>>>>> -Joe
>>>>>
>>>>> On 01/27/2012 10:03 AM, Kumar Srinivasan wrote:
>>>>>> Hi Joe, Naoto, Sherman,
>>>>>>
>>>>>> Here are the highlights of these changes:
>>>>>>
>>>>>> 1. The TestHelper.java is now extensible, this simplifies the
>>>>>> usage of
>>>>>> static variables
>>>>>> and methods, added a couple of convenience methods and some minor
>>>>>> refactoring.
>>>>>>
>>>>>> 2. Eliminated some shell tests, (few more remaining, saved for a
>>>>>> future project).
>>>>>> a. UnicodeTest.sh, UnicodeCleanup.java merged into UnicodeTest.java
>>>>>> b. i18nTest.sh, deleteI18n.sh, CreatePlatformFile.java merged into
>>>>>> I18NTest.java
>>>>>> c. ChangeDataModel.sh converted to ChangeDataModel.java
>>>>>> d. unresolvedExceptions.sh converted and merged into
>>>>>> UnresolvedExceptions.java
>>>>>>
>>>>>> 3. Arrrghs.java when testing on Solaris with ja_JP.UTF-8 locale, some
>>>>>> of the tests fail
>>>>>> as the launcher messages in java are localized, therefore these tests
>>>>>> are skipped,
>>>>>> under such conditions.
>>>>>>
>>>>>> Tests: Windows English/Japanese, Solaris C/ja_JP.UTF-8 + usual jprt
>>>>>> systems (undergoing).
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~ksrini/7127906/webrev.0/
>>>>>>
>>>>>> Thanks
>>>>>> Kumar
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From kumar.x.srinivasan at oracle.com Sat Jan 28 18:48:05 2012
From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com)
Date: Sat, 28 Jan 2012 18:48:05 +0000
Subject: hg: jdk8/tl/jdk: 7127906: (launcher) convert the launcher regression
tests to java
Message-ID: <20120128184824.5522D4724E@hg.openjdk.java.net>

Changeset: 7dbc129d8e5c
Author: ksrini
Date: 2012-01-28 10:46 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7dbc129d8e5c

7127906: (launcher) convert the launcher regression tests to java
Reviewed-by: darcy, naoto

! test/tools/launcher/Arrrghs.java
+ test/tools/launcher/ChangeDataModel.java
- test/tools/launcher/ChangeDataModel.sh
- test/tools/launcher/CreatePlatformFile.java
! test/tools/launcher/DefaultLocaleTestRun.java
! test/tools/launcher/ExecutionEnvironment.java
! test/tools/launcher/I18NJarTest.java
+ test/tools/launcher/I18NTest.java
! test/tools/launcher/MiscTests.java
! test/tools/launcher/Settings.java
- test/tools/launcher/SomeException.java
! test/tools/launcher/Test7029048.java
! test/tools/launcher/TestHelper.java
- test/tools/launcher/UnicodeCleanup.java
! test/tools/launcher/UnicodeTest.java
- test/tools/launcher/UnicodeTest.sh
! test/tools/launcher/UnresolvedExceptions.java
- test/tools/launcher/deleteI18n.sh
- test/tools/launcher/i18nTest.sh
- test/tools/launcher/unresolvedExceptions.sh



From lana.steuck at oracle.com Sun Jan 29 05:58:30 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 29 Jan 2012 05:58:30 +0000
Subject: hg: jdk8/tl: 3 new changesets
Message-ID: <20120129055830.D7EDA47257@hg.openjdk.java.net>

Changeset: 60d6f64a86b1
Author: katleman
Date: 2012-01-20 13:08 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/rev/60d6f64a86b1

Added tag jdk8-b22 for changeset 7ad075c80995

! .hgtags

Changeset: 1a5f1d6b98d6
Author: katleman
Date: 2012-01-26 18:23 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/rev/1a5f1d6b98d6

Added tag jdk8-b23 for changeset 60d6f64a86b1

! .hgtags

Changeset: bd3fcc98c5d2
Author: lana
Date: 2012-01-28 20:36 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/rev/bd3fcc98c5d2

Merge




From lana.steuck at oracle.com Sun Jan 29 05:58:30 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 29 Jan 2012 05:58:30 +0000
Subject: hg: jdk8/tl/jaxp: 2 new changesets
Message-ID: <20120129055830.D4B4347256@hg.openjdk.java.net>

Changeset: 95102fd33418
Author: katleman
Date: 2012-01-20 13:08 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/95102fd33418

Added tag jdk8-b22 for changeset cf9d6ec44f89

! .hgtags

Changeset: 7836655e2495
Author: katleman
Date: 2012-01-26 18:23 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7836655e2495

Added tag jdk8-b23 for changeset 95102fd33418

! .hgtags



From lana.steuck at oracle.com Sun Jan 29 05:58:30 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 29 Jan 2012 05:58:30 +0000
Subject: hg: jdk8/tl/jaxws: 2 new changesets
Message-ID: <20120129055830.D1F4847255@hg.openjdk.java.net>

Changeset: 25ce7a000487
Author: katleman
Date: 2012-01-20 13:08 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/25ce7a000487

Added tag jdk8-b22 for changeset 8d3df89b0f2d

! .hgtags

Changeset: e0d90803439b
Author: katleman
Date: 2012-01-26 18:23 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e0d90803439b

Added tag jdk8-b23 for changeset 25ce7a000487

! .hgtags



From lana.steuck at oracle.com Sun Jan 29 05:58:30 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 29 Jan 2012 05:58:30 +0000
Subject: hg: jdk8/tl/corba: 2 new changesets
Message-ID: <20120129055832.93E6047258@hg.openjdk.java.net>

Changeset: 5218eb256658
Author: katleman
Date: 2012-01-20 13:08 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5218eb256658

Added tag jdk8-b22 for changeset a11d0062c445

! .hgtags

Changeset: b98f0e6dddf9
Author: katleman
Date: 2012-01-26 18:23 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b98f0e6dddf9

Added tag jdk8-b23 for changeset 5218eb256658

! .hgtags



From lana.steuck at oracle.com Sun Jan 29 05:58:30 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 29 Jan 2012 05:58:30 +0000
Subject: hg: jdk8/tl/langtools: 4 new changesets
Message-ID: <20120129055841.74AD347259@hg.openjdk.java.net>

Changeset: f6191bad139a
Author: katleman
Date: 2012-01-20 13:08 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f6191bad139a

Added tag jdk8-b22 for changeset 390a7828ae18

! .hgtags

Changeset: 601ffcc6551d
Author: lana
Date: 2012-01-24 13:44 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/601ffcc6551d

Merge


Changeset: 6c9d21ca92c4
Author: katleman
Date: 2012-01-26 18:23 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6c9d21ca92c4

Added tag jdk8-b23 for changeset 601ffcc6551d

! .hgtags

Changeset: 7d412606d641
Author: lana
Date: 2012-01-28 20:42 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d412606d641

Merge




From lana.steuck at oracle.com Sun Jan 29 05:58:48 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 29 Jan 2012 05:58:48 +0000
Subject: hg: jdk8/tl/hotspot: 88 new changesets
Message-ID: <20120129060149.DB6E24725A@hg.openjdk.java.net>

Changeset: 0841c0ec2ed6
Author: amurillo
Date: 2011-12-23 15:29 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0841c0ec2ed6

7123810: new hotspot build - hs23-b10
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 3b2b58fb1425
Author: tonyp
Date: 2011-12-20 12:59 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b2b58fb1425

7123165: G1: output during parallel verification can get messed up
Summary: Serialize the worker threads that are generating output during parallel heap verification to make sure the output is consistent.
Reviewed-by: brutisso, johnc, jmasa

! src/share/vm/gc_implementation/g1/heapRegion.cpp

Changeset: d15b458c4225
Author: jmasa
Date: 2011-12-20 20:29 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d15b458c4225

Merge


Changeset: 67fdcb391461
Author: tonyp
Date: 2011-12-21 07:53 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/67fdcb391461

7119027: G1: use atomics to update RS length / predict time of inc CSet
Summary: Make sure that the updates to the RS length and inc CSet predicted time are updated in an MT-safe way.
Reviewed-by: brutisso, iveresov

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp

Changeset: 441e946dc1af
Author: jmasa
Date: 2011-12-14 13:34 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/441e946dc1af

7121618: Change type of number of GC workers to unsigned int.
Summary: Change variables representing the number of GC workers to uint from int and size_t. Change the parameter in work(int i) to work(uint worker_id).
Reviewed-by: brutisso, tonyp

! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! 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/g1RemSet.cpp
! src/share/vm/gc_implementation/g1/g1RemSet.hpp
! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp
! src/share/vm/gc_interface/collectedHeap.hpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/genCollectedHeap.hpp
! src/share/vm/memory/referenceProcessor.cpp
! src/share/vm/memory/referenceProcessor.hpp
! src/share/vm/memory/sharedHeap.cpp
! src/share/vm/memory/sharedHeap.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/utilities/workgroup.cpp
! src/share/vm/utilities/workgroup.hpp
! src/share/vm/utilities/yieldingWorkgroup.cpp
! src/share/vm/utilities/yieldingWorkgroup.hpp

Changeset: 1cbe7978b021
Author: brutisso
Date: 2011-12-21 22:13 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cbe7978b021

7113021: G1: automatically enable young gen size auto-tuning when -Xms==-Xmx
Summary: Use a percentage of -Xms as min and another percentage of -Xmx as max for the young gen size
Reviewed-by: tonyp, johnc

! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 7faca6dfa2ed
Author: jmasa
Date: 2011-12-27 12:38 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7faca6dfa2ed

Merge

! src/share/vm/runtime/globals.hpp

Changeset: 4ceaf61479fc
Author: dcubed
Date: 2011-12-22 12:50 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4ceaf61479fc

7122253: Instrumentation.retransformClasses() leaks class bytes
Summary: Change ClassFileParser::parseClassFile() to use the instanceKlass:_cached_class_file_bytes field to avoid leaking the cache.
Reviewed-by: coleenp, acorn, poonam

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/prims/jvmtiEnv.cpp
! src/share/vm/prims/jvmtiExport.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp

Changeset: 4ec93d767458
Author: vladidan
Date: 2011-12-26 20:36 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4ec93d767458

Merge


Changeset: 3db6ea5ce021
Author: vladidan
Date: 2011-12-29 20:09 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3db6ea5ce021

Merge


Changeset: 20bfb6d15a94
Author: iveresov
Date: 2011-12-27 16:43 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/20bfb6d15a94

7124829: NUMA: memory leak on Linux with large pages
Summary: In os::free_memory() use mmap with the same attributes as for the heap space
Reviewed-by: kvn
Contributed-by: Aleksey Ignatenko <aleksey.v.ignatenko at intel.com>

! src/os/bsd/vm/os_bsd.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp
! src/share/vm/gc_implementation/shared/mutableSpace.cpp
! src/share/vm/runtime/os.hpp

Changeset: 776173fc2df9
Author: stefank
Date: 2011-12-29 07:37 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/776173fc2df9

7125516: G1: ~ConcurrentMark() frees incorrectly
Summary: Replaced the code with a ShouldNotReachHere
Reviewed-by: tonyp, jmasa

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: 5ee33ff9b1c4
Author: jmasa
Date: 2012-01-03 10:22 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ee33ff9b1c4

Merge


Changeset: 75c0a73eee98
Author: coleenp
Date: 2011-11-17 12:53 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/75c0a73eee98

7102776: Pack instanceKlass boolean fields into single u1 field
Summary: Reduce class runtime memory usage by packing 4 instanceKlass boolean fields into single u1 field. Save 4-byte for each loaded class.
Reviewed-by: dholmes, bobv, phh, twisti, never, coleenp
Contributed-by: Jiangli Zhou <jiangli.zhou at oracle.com>

! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! src/share/vm/code/dependencies.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: da4dd142ea01
Author: bobv
Date: 2011-11-29 14:44 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da4dd142ea01

Merge

! src/share/vm/code/dependencies.cpp

Changeset: 52b5d32fbfaf
Author: coleenp
Date: 2011-12-06 18:28 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/52b5d32fbfaf

7117052: instanceKlass::_init_state can be u1 type
Summary: Change instanceKlass::_init_state field to u1 type.
Reviewed-by: bdelsart, coleenp, dholmes, phh, never
Contributed-by: Jiangli Zhou <jiangli.zhou at oracle.com>

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/ci/ciInstanceKlass.cpp
! src/share/vm/memory/dump.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: eccc4b1f8945
Author: vladidan
Date: 2011-12-07 16:47 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eccc4b1f8945

7050298: ARM: SIGSEGV in JNIHandleBlock::allocate_handle
Summary: missing release barrier in Monitor::IUnlock
Reviewed-by: dholmes, dice

! src/share/vm/runtime/mutex.cpp

Changeset: 2685ea97b89f
Author: jiangli
Date: 2011-12-09 11:29 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2685ea97b89f

Merge

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp

Changeset: 8fdf463085e1
Author: jiangli
Date: 2011-12-16 17:33 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8fdf463085e1

Merge


Changeset: dca455dea3a7
Author: bdelsart
Date: 2011-12-20 12:33 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dca455dea3a7

7116216: StackOverflow GC crash
Summary: GC crash for explicit stack overflow checks after a C2I transition.
Reviewed-by: coleenp, never
Contributed-by: yang02.wang at sap.com, bertrand.delsart at oracle.com

! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
+ test/compiler/7116216/LargeFrame.java
+ test/compiler/7116216/StackOverflow.java

Changeset: cd5d8cafcc84
Author: jiangli
Date: 2011-12-28 12:15 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd5d8cafcc84

7123315: instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count should be u2 type.
Summary: Change instanceKlass::_static_oop_field_count and instanceKlass::_java_fields_count to u2 type.
Reviewed-by: never, bdelsart, dholmes
Contributed-by: Jiangli Zhou <jiangli.zhou at oracle.com>

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 05de27e852c4
Author: jiangli
Date: 2012-01-04 12:36 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/05de27e852c4

Merge

! src/share/vm/classfile/classFileParser.cpp

Changeset: b6a04c79ccbc
Author: stefank
Date: 2012-01-02 10:01 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b6a04c79ccbc

7125503: Compiling collectedHeap.cpp fails with -Werror=int-to-pointer-cast with g++ 4.6.1
Summary: Used uintptr_t and void* for all the casts and checks in test_is_in.
Reviewed-by: tonyp, jmasa

! src/share/vm/gc_interface/collectedHeap.cpp

Changeset: 4753e3dda3c8
Author: jmasa
Date: 2012-01-04 07:56 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4753e3dda3c8

Merge


Changeset: 2ee4167627a3
Author: jmasa
Date: 2012-01-05 21:02 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ee4167627a3

Merge


Changeset: 7ab5f6318694
Author: phh
Date: 2012-01-01 11:17 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7ab5f6318694

7125934: Add a fast unordered timestamp capability to Hotspot on x86/x64
Summary: Add rdtsc detection and inline generation.
Reviewed-by: kamg, dholmes
Contributed-by: karen.kinnear at oracle.com

! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp
+ src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp
! src/os_cpu/linux_x86/vm/os_linux_x86.hpp
+ src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp
+ src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp
! src/os_cpu/solaris_x86/vm/solaris_x86_32.il
! src/os_cpu/solaris_x86/vm/solaris_x86_64.il
! src/os_cpu/windows_x86/vm/os_windows_x86.hpp
+ src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/os.hpp
+ src/share/vm/runtime/os_ext.hpp

Changeset: b16494a69d3d
Author: phh
Date: 2012-01-03 15:11 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b16494a69d3d

7126185: Clean up lasterror handling, add os::get_last_error()
Summary: Add os::get_last_error(), replace getLastErrorString() by os::lasterror() in os_windows.cpp.
Reviewed-by: kamg, dholmes
Contributed-by: erik.gahlin at oracle.com

! src/os/posix/vm/os_posix.cpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/runtime/os.hpp

Changeset: 5b58979183f9
Author: dcubed
Date: 2012-01-05 06:24 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b58979183f9

7127032: fix for 7122253 adds a JvmtiThreadState earlier than necessary
Summary: Use JavaThread::jvmti_thread_state() instead of JvmtiThreadState::state_for().
Reviewed-by: coleenp, poonam, acorn

! src/share/vm/classfile/classFileParser.cpp

Changeset: 8a63c6323842
Author: fparain
Date: 2012-01-05 07:26 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8a63c6323842

7125594: C-heap growth issue in ThreadService::find_deadlocks_at_safepoint
Reviewed-by: sspitsyn, dcubed, mchung, dholmes

! src/share/vm/services/threadService.cpp

Changeset: 2e0ef19fc891
Author: phh
Date: 2012-01-05 17:14 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2e0ef19fc891

7126480: Make JVM start time in milliseconds since the Java epoch available
Summary: Expose existing Management::_begin_vm_creation_time via new accessor Management::begin_vm_creation_time().
Reviewed-by: acorn, dcubed

! src/share/vm/services/management.hpp

Changeset: 66259eca2bf7
Author: phh
Date: 2012-01-05 17:16 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/66259eca2bf7

Merge


Changeset: 2b3acb34791f
Author: dcubed
Date: 2012-01-06 16:18 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b3acb34791f

Merge

! src/os/windows/vm/os_windows.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/runtime/os.hpp

Changeset: abcceac2f7cd
Author: iveresov
Date: 2011-12-12 12:44 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/abcceac2f7cd

7119730: Tiered: SIGSEGV in AdvancedThresholdPolicy::is_method_profiled(methodOop)
Summary: Added handles for references to methods in select_task()
Reviewed-by: twisti, kvn

! src/share/vm/runtime/advancedThresholdPolicy.cpp

Changeset: 7bca37d28f32
Author: roland
Date: 2011-12-13 10:54 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7bca37d28f32

7114106: C1: assert(goto_state->is_same(sux_state)) failed: states must match now
Summary: fix C1's CEE to take inlining into account when the stacks in states are compared.
Reviewed-by: iveresov, never

! src/share/vm/c1/c1_Optimizer.cpp

Changeset: d725f0affb1a
Author: iveresov
Date: 2011-12-13 17:10 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d725f0affb1a

7121111: -server -Xcomp -XX:+TieredCompilation does not invoke C2 compiler
Summary: Exercise C2 more in tiered mode with Xcomp
Reviewed-by: kvn, never

! src/share/vm/runtime/arguments.cpp

Changeset: 127b3692c168
Author: kvn
Date: 2011-12-14 14:54 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/127b3692c168

7116452: Add support for AVX instructions
Summary: Added support for AVX extension to the x86 instruction set.
Reviewed-by: never

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/assembler_x86.inline.hpp
! src/cpu/x86/vm/nativeInst_x86.cpp
! src/cpu/x86/vm/nativeInst_x86.hpp
! src/cpu/x86/vm/register_definitions_x86.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/runtime/globals.hpp

Changeset: 669f6a7d5b70
Author: never
Date: 2011-12-19 14:16 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/669f6a7d5b70

7121073: secondary_super_cache memory slice has incorrect bounds in flatten_alias_type
Reviewed-by: kvn

! src/share/vm/opto/compile.cpp

Changeset: 65149e74c706
Author: kvn
Date: 2011-12-20 00:55 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65149e74c706

7121648: Use 3-operands SIMD instructions on x86 with AVX
Summary: Use 3-operands SIMD instructions in C2 generated code for machines with AVX.
Reviewed-by: never

! make/bsd/makefiles/adlc.make
! make/linux/makefiles/adlc.make
! make/solaris/makefiles/adlc.make
! make/windows/makefiles/adlc.make
! 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/matcher.cpp

Changeset: 069ab3f976d3
Author: stefank
Date: 2011-12-07 11:35 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/069ab3f976d3

7118863: Move sizeof(klassOopDesc) into the *Klass::*_offset_in_bytes() functions
Summary: Moved sizeof(klassOopDesc), changed the return type to ByteSize and removed the _in_bytes suffix.
Reviewed-by: never, bdelsart, coleenp, jrose

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/cppInterpreter_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_CodeStubs_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/cppInterpreter_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/oops/arrayKlass.hpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/klassOop.hpp
! src/share/vm/oops/objArrayKlass.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/shark/sharkIntrinsics.cpp
! src/share/vm/shark/sharkTopLevelBlock.cpp

Changeset: 1dc233a8c7fe
Author: roland
Date: 2011-12-20 16:56 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1dc233a8c7fe

7121140: Allocation paths require explicit memory synchronization operations for RMO systems
Summary: adds store store barrier after initialization of header and body of objects.
Reviewed-by: never, kvn

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/node.hpp

Changeset: e5ac210043cd
Author: roland
Date: 2011-12-22 10:55 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e5ac210043cd

7123108: C1: assert(if_state != NULL) failed: states do not match up
Summary: In CEE, ensure if and common successor state are at the same inline level
Reviewed-by: never

! src/share/vm/c1/c1_Optimizer.cpp
+ test/compiler/7123108/Test7123108.java

Changeset: b642b49f9738
Author: roland
Date: 2011-12-23 09:36 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b642b49f9738

7123253: C1: in store check code, usage of registers may be incorrect
Summary: fix usage of input register in assembly code for store check.
Reviewed-by: never

! src/share/vm/c1/c1_LIR.cpp

Changeset: 40c2484c09e1
Author: kvn
Date: 2011-12-23 15:24 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40c2484c09e1

7110832: ctw/.../org_apache_avalon_composition_util_StringHelper crashes the VM
Summary: Distance is too large for one short branch in string_indexofC8().
Reviewed-by: iveresov

! src/cpu/x86/vm/assembler_x86.cpp
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp

Changeset: d12a66fa3820
Author: kvn
Date: 2011-12-27 15:08 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d12a66fa3820

7123954: Some CTW test crash with SIGSEGV
Summary: Correct Allocate expansion code to preserve i_o when only slow call is generated.
Reviewed-by: iveresov

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/macro.cpp

Changeset: 8940fd98d540
Author: kvn
Date: 2011-12-29 11:37 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8940fd98d540

Merge

! src/cpu/x86/vm/assembler_x86.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 9c87bcb3b4dd
Author: kvn
Date: 2011-12-30 11:43 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c87bcb3b4dd

7125879: assert(proj != NULL) failed: must be found
Summary: Leave i_o attached to slow allocation call when there are no i_o users after the call.
Reviewed-by: iveresov, twisti

! src/share/vm/opto/macro.cpp
+ test/compiler/7125879/Test7125879.java

Changeset: 1cb50d7a9d95
Author: iveresov
Date: 2012-01-05 17:25 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cb50d7a9d95

7119294: Two command line options cause JVM to crash
Summary: Setup thread register in MacroAssembler::incr_allocated_bytes() on x64
Reviewed-by: kvn

! src/cpu/x86/vm/assembler_x86.cpp

Changeset: 22cee0ee8927
Author: kvn
Date: 2012-01-06 20:09 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22cee0ee8927

Merge

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateInterpreter_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_Runtime1_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateInterpreter_x86_32.cpp
! src/cpu/x86/vm/templateInterpreter_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/parseHelper.cpp

Changeset: 8f8b94305aff
Author: dcubed
Date: 2012-01-11 19:54 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f8b94305aff

7129240: backout fix for 7102776 until 7128770 is resolved
Reviewed-by: phh, bobv, coleenp, dcubed
Contributed-by: Jiangli Zhou <jiangli.zhou at oracle.com>

! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! src/share/vm/code/dependencies.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/oops/instanceKlassKlass.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 4f25538b54c9
Author: fparain
Date: 2012-01-09 10:27 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f25538b54c9

7120511: Add diagnostic commands
Reviewed-by: acorn, phh, dcubed, sspitsyn

! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp
! src/share/vm/services/diagnosticFramework.cpp
! src/share/vm/services/diagnosticFramework.hpp
! src/share/vm/services/management.cpp

Changeset: 865e0817f32b
Author: kamg
Date: 2012-01-10 15:47 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/865e0817f32b

Merge

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp

Changeset: efdf6985a3a2
Author: kamg
Date: 2012-01-12 09:59 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/efdf6985a3a2

Merge


Changeset: 5da7201222d5
Author: kvn
Date: 2012-01-07 10:39 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5da7201222d5

7110824: ctw/jarfiles/GUI3rdParty_jar/ob_mask_DateField crashes VM
Summary: Change yank_if_dead() to recursive method to remove all dead inputs.
Reviewed-by: never

! src/cpu/sparc/vm/sparc.ad
! src/share/vm/opto/chaitin.hpp
! src/share/vm/opto/postaloc.cpp

Changeset: e9a5e0a812c8
Author: kvn
Date: 2012-01-07 13:26 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e9a5e0a812c8

7125896: Eliminate nested locks
Summary: Nested locks elimination done before lock nodes expansion by looking for outer locks of the same object.
Reviewed-by: never, twisti

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/ci/ciTypeFlow.hpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/callnode.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/locknode.cpp
! src/share/vm/opto/locknode.hpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/macro.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/deoptimization.cpp

Changeset: 35acf8f0a2e4
Author: kvn
Date: 2012-01-10 18:05 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35acf8f0a2e4

7128352: assert(obj_node == obj) failed
Summary: Compare uncasted object nodes.
Reviewed-by: never

! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/locknode.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/phaseX.hpp
! src/share/vm/opto/subnode.cpp
! test/compiler/7116216/StackOverflow.java

Changeset: c8d8e124380c
Author: kvn
Date: 2012-01-12 12:28 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c8d8e124380c

7064302: JDK7 build 147 crashed after testing my java 6-compiled web app
Summary: Don't split CMove node if it's control edge is different from split region.
Reviewed-by: never

! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/loopopts.cpp

Changeset: 31a5b9aad4bc
Author: jrose
Date: 2012-01-13 00:27 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31a5b9aad4bc

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: bacb651cf5bf
Author: tonyp
Date: 2012-01-05 05:54 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bacb651cf5bf

7113006: G1: excessive ergo output when an evac failure happens
Summary: Introduce a flag that is set when a heap expansion attempt during a GC fails so that we do not consantly attempt to expand the heap when it's going to fail anyway. This not only prevents the excessive ergo output (which is generated when a region allocation fails) but also avoids excessive and ultimately unsuccessful expansion attempts.
Reviewed-by: jmasa, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp

Changeset: 5fd354a959c5
Author: jmasa
Date: 2012-01-05 21:21 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5fd354a959c5

Merge


Changeset: 023652e49ac0
Author: johnc
Date: 2011-12-23 11:14 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/023652e49ac0

7121496: G1: do the per-region evacuation failure handling work in parallel
Summary: Parallelize the removal of self forwarding pointers etc. by wrapping in a HeapRegion closure, which is then wrapped inside an AbstractGangTask.
Reviewed-by: tonyp, iveresov

! 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/g1EvacFailure.hpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp

Changeset: 02838862dec8
Author: tonyp
Date: 2012-01-07 00:43 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/02838862dec8

7121623: G1: always be able to reliably calculate the length of a forwarded chunked array
Summary: Store the "next chunk start index" in the length field of the to-space object, instead of the from-space object, so that we can always reliably read the size of all from-space objects.
Reviewed-by: johnc, ysr, jmasa

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 97c00e21fecb
Author: tonyp
Date: 2012-01-09 23:50 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/97c00e21fecb

7125281: G1: heap expansion code is replicated
Reviewed-by: brutisso, johnc

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: 1d6185f732aa
Author: brutisso
Date: 2012-01-10 20:02 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1d6185f732aa

7128532: G1: Change default value of G1DefaultMaxNewGenPercent to 80
Reviewed-by: tonyp, jmasa

! src/share/vm/gc_implementation/g1/g1_globals.hpp

Changeset: 2ace1c4ee8da
Author: tonyp
Date: 2012-01-10 18:58 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ace1c4ee8da

6888336: G1: avoid explicitly marking and pushing objects in survivor spaces
Summary: This change simplifies the interaction between GC and concurrent marking. By disabling survivor spaces during the initial-mark pause we don't need to propagate marks of objects we copy during each GC (since we never need to copy an explicitly marked object).
Reviewed-by: johnc, brutisso

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.hpp
! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp
! 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/g1EvacFailure.hpp
! src/share/vm/gc_implementation/g1/g1OopClosures.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp
! src/share/vm/gc_implementation/g1/heapRegion.inline.hpp
! src/share/vm/gc_implementation/g1/ptrQueue.hpp
! src/share/vm/gc_implementation/g1/satbQueue.cpp
! src/share/vm/gc_implementation/g1/satbQueue.hpp

Changeset: 9d4f4a1825e4
Author: brutisso
Date: 2012-01-13 01:55 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d4f4a1825e4

Merge


Changeset: 5acd82522540
Author: brutisso
Date: 2012-01-13 06:18 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5acd82522540

Merge


Changeset: b0ff910edfc9
Author: kvn
Date: 2012-01-12 14:45 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b0ff910edfc9

7128355: assert(!nocreate) failed: Cannot build a phi for a block already parsed
Summary: Do not common BoxLock nodes and avoid creating phis of boxes.
Reviewed-by: never

! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/locknode.cpp
! src/share/vm/opto/locknode.hpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/parse1.cpp

Changeset: f4d8930a45b9
Author: jrose
Date: 2012-01-13 00:51 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f4d8930a45b9

Merge


Changeset: 89d0a5d40008
Author: kvn
Date: 2012-01-13 12:58 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/89d0a5d40008

7129618: assert(obj_node->eqv_uncast(obj),"");
Summary: Relax verification and locks elimination checks for new implementation (EliminateNestedLocks).
Reviewed-by: iveresov

! src/share/vm/opto/locknode.cpp
! src/share/vm/opto/macro.cpp

Changeset: e504fd26c073
Author: kvn
Date: 2012-01-13 14:21 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e504fd26c073

Merge


Changeset: 513351373923
Author: amurillo
Date: 2012-01-14 00:47 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/513351373923

Merge


Changeset: 24727fb37561
Author: amurillo
Date: 2012-01-14 00:47 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/24727fb37561

Added tag hs23-b10 for changeset 513351373923

! .hgtags

Changeset: 338d438ee229
Author: katleman
Date: 2012-01-20 13:08 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/338d438ee229

Added tag jdk8-b22 for changeset 24727fb37561

! .hgtags

Changeset: 4e80db53c323
Author: amurillo
Date: 2012-01-14 00:52 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4e80db53c323

7129512: new hotspot build - hs23-b11
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 94ec88ca68e2
Author: phh
Date: 2012-01-11 17:34 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/94ec88ca68e2

7115199: Add event tracing hooks and Java Flight Recorder infrastructure
Summary: Added a nop tracing infrastructure, JFR makefile changes and other infrastructure used only by JFR.
Reviewed-by: acorn, sspitsyn
Contributed-by: markus.gronlund at oracle.com

! make/Makefile
! make/bsd/makefiles/vm.make
! make/defs.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/vm.make
! make/windows/build.bat
! make/windows/create_obj_files.sh
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/vm.make
! src/share/vm/classfile/symbolTable.cpp
! src/share/vm/classfile/symbolTable.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp
! src/share/vm/oops/methodKlass.cpp
! src/share/vm/oops/methodOop.hpp
! src/share/vm/prims/jni.cpp
+ src/share/vm/prims/jniExport.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/runtime/mutexLocker.cpp
! src/share/vm/runtime/mutexLocker.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vm_operations.hpp
+ src/share/vm/trace/traceEventTypes.hpp
+ src/share/vm/trace/traceMacros.hpp
+ src/share/vm/trace/tracing.hpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: 4f3ce9284781
Author: phh
Date: 2012-01-11 17:58 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4f3ce9284781

Merge

! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klass.hpp

Changeset: f1cd52d6ce02
Author: kamg
Date: 2012-01-17 10:16 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1cd52d6ce02

Merge


Changeset: d7e3846464d0
Author: zgu
Date: 2012-01-17 13:08 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d7e3846464d0

7071311: Decoder enhancement
Summary: Made decoder thread-safe
Reviewed-by: coleenp, kamg

- src/os/bsd/vm/decoder_bsd.cpp
+ src/os/bsd/vm/decoder_machO.cpp
+ src/os/bsd/vm/decoder_machO.hpp
! src/os/linux/vm/decoder_linux.cpp
! src/os/linux/vm/os_linux.cpp
! src/os/solaris/vm/decoder_solaris.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/windows/vm/decoder_windows.cpp
+ src/os/windows/vm/decoder_windows.hpp
! src/os/windows/vm/os_windows.cpp
! src/share/vm/utilities/decoder.cpp
! src/share/vm/utilities/decoder.hpp
+ src/share/vm/utilities/decoder_elf.cpp
+ src/share/vm/utilities/decoder_elf.hpp
! src/share/vm/utilities/elfFile.cpp
! src/share/vm/utilities/elfFile.hpp
! src/share/vm/utilities/elfStringTable.cpp
! src/share/vm/utilities/elfStringTable.hpp
! src/share/vm/utilities/elfSymbolTable.cpp
! src/share/vm/utilities/elfSymbolTable.hpp
! src/share/vm/utilities/vmError.cpp

Changeset: 6520f9861937
Author: kamg
Date: 2012-01-17 21:25 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6520f9861937

Merge


Changeset: db18ca98d237
Author: zgu
Date: 2012-01-18 11:45 -0500
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db18ca98d237

7131050: fix for "7071311 Decoder enhancement" does not build on MacOS X
Summary: Decoder API changes did not reflect in os_bsd
Reviewed-by: kamg, dcubed

! src/os/bsd/vm/os_bsd.cpp

Changeset: eaa9557116a2
Author: bdelsart
Date: 2012-01-18 16:18 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eaa9557116a2

7120448: Fix FP values for compiled frames in frame::describe
Summary: fix for debug method frame::describe
Reviewed-by: never, kvn

! src/cpu/sparc/vm/frame_sparc.inline.hpp
! src/cpu/x86/vm/frame_x86.cpp
! src/cpu/x86/vm/frame_x86.hpp
! src/cpu/zero/vm/frame_zero.inline.hpp
! src/share/vm/runtime/frame.cpp
! src/share/vm/runtime/frame.hpp

Changeset: 15d394228cfa
Author: jrose
Date: 2012-01-19 13:00 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15d394228cfa

7111138: delete the obsolete flag -XX:+UseRicochetFrames
Reviewed-by: dholmes, bdelsart, kvn, twisti

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/zero/vm/methodHandles_zero.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 898522ae3c32
Author: iveresov
Date: 2012-01-19 10:56 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/898522ae3c32

7131288: COMPILE SKIPPED: deopt handler overflow (retry at different tier)
Summary: Fix exception handler stub size, enable guarantees to check for the correct deopt and exception stub sizes in the future
Reviewed-by: kvn, never, twisti

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp

Changeset: 469e0a46f2fe
Author: jrose
Date: 2012-01-19 17:20 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/469e0a46f2fe

Merge


Changeset: 50d9b7a0072c
Author: jrose
Date: 2012-01-19 18:35 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/50d9b7a0072c

Merge


Changeset: dcc292399a39
Author: amurillo
Date: 2012-01-20 16:56 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dcc292399a39

Merge

- src/os/bsd/vm/decoder_bsd.cpp

Changeset: e850d8e7ea54
Author: amurillo
Date: 2012-01-20 16:56 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e850d8e7ea54

Added tag hs23-b11 for changeset dcc292399a39

! .hgtags

Changeset: 6edfe6e42a68
Author: katleman
Date: 2012-01-26 18:23 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6edfe6e42a68

Added tag jdk8-b23 for changeset e850d8e7ea54

! .hgtags



From lana.steuck at oracle.com Sun Jan 29 05:59:07 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Sun, 29 Jan 2012 05:59:07 +0000
Subject: hg: jdk8/tl/jdk: 23 new changesets
Message-ID: <20120129060256.0A9F54725B@hg.openjdk.java.net>

Changeset: 76bfd08d8cc5
Author: katleman
Date: 2012-01-20 13:08 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76bfd08d8cc5

Added tag jdk8-b22 for changeset dda27c73d8db

! .hgtags

Changeset: 44bd765c22f4
Author: prr
Date: 2012-01-13 13:11 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44bd765c22f4

7127827: JRE8: javaws fails to launch on oracle linux due to XRender
Reviewed-by: bae, jgodinez

! src/solaris/classes/sun/java2d/xr/XRCompositeManager.java

Changeset: b566004bcb1a
Author: dbuck
Date: 2012-01-16 11:52 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b566004bcb1a

7083621: Add fontconfig file for OEL6 and rename RH/O EL 5 file so that it is picked up for all 5.x updates
Reviewed-by: bae, prr

! make/sun/awt/Makefile

Changeset: 397667460892
Author: lana
Date: 2012-01-18 11:27 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/397667460892

Merge

- test/tools/launcher/DefaultLocaleTest.sh

Changeset: e0f94b9c53a8
Author: alexsch
Date: 2012-01-10 15:46 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0f94b9c53a8

7110815: closed/javax/swing/JSplitPane/4885629/bug4885629.java unstable on MacOS
Reviewed-by: kizune

+ test/javax/swing/JSplitPane/4885629/bug4885629.java

Changeset: 79d14e328670
Author: alexsch
Date: 2012-01-10 17:11 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79d14e328670

6505523: NullPointerException in BasicTreeUI when a node is removed by expansion listener
Reviewed-by: rupashka

! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java
+ test/javax/swing/JTree/6505523/bug6505523.java

Changeset: ce32a4e1be1d
Author: alexsch
Date: 2012-01-13 12:39 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce32a4e1be1d

7121765: closed/javax/swing/JTextArea/4697612/bug4697612.java fails on MacOS on Aqua L&F
Reviewed-by: rupashka

+ test/javax/swing/JTextArea/4697612/bug4697612.java
+ test/javax/swing/JTextArea/4697612/bug4697612.txt

Changeset: 59b8875949e1
Author: malenkov
Date: 2012-01-16 18:28 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59b8875949e1

7122740: PropertyDescriptor Performance Slow
Reviewed-by: rupashka

! src/share/classes/com/sun/beans/TypeResolver.java

Changeset: 3e9d35e6ee4f
Author: denis
Date: 2012-01-17 19:09 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e9d35e6ee4f

7110590: DnDMerlinQLTestsuite_DnDJTextArea test fails with an java.awt.dnd.InvalidDnDOperationException
Reviewed-by: art

! src/share/classes/java/awt/AWTKeyStroke.java

Changeset: 89bc9d08fe82
Author: anthony
Date: 2012-01-18 19:09 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89bc9d08fe82

7130662: GTK file dialog crashes with a NPE
Summary: Guard adding a back slash to the directory name with an if (!= null) check
Reviewed-by: anthony, art
Contributed-by: Matt <melkor at orangepalantir.org>

! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java

Changeset: fe1278123fbb
Author: lana
Date: 2012-01-18 11:41 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe1278123fbb

Merge

- test/tools/launcher/DefaultLocaleTest.sh

Changeset: 4d8b49a45cff
Author: lana
Date: 2012-01-18 20:23 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d8b49a45cff

Merge


Changeset: e6614f361127
Author: lana
Date: 2012-01-18 20:24 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6614f361127

Merge

- test/java/io/File/BlockIsDirectory.java

Changeset: 227fcf5d0bec
Author: lana
Date: 2012-01-24 13:43 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/227fcf5d0bec

Merge

- test/java/io/File/BlockIsDirectory.java

Changeset: db189e2f3cdb
Author: jrose
Date: 2012-01-18 17:34 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db189e2f3cdb

7117167: Misc warnings in java.lang.invoke and sun.invoke.*
Reviewed-by: smarks

! src/share/classes/java/lang/invoke/AdapterMethodHandle.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleProxies.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/sun/invoke/util/ValueConversions.java
! src/share/classes/sun/invoke/util/Wrapper.java
! test/java/lang/invoke/CallSiteTest.java
! test/java/lang/invoke/ClassValueTest.java
! test/java/lang/invoke/InvokeGenericTest.java
! test/java/lang/invoke/JavaDocExamplesTest.java
! test/java/lang/invoke/MethodHandlesTest.java
! test/java/lang/invoke/MethodTypeTest.java
! test/java/lang/invoke/PermuteArgsTest.java
! test/java/lang/invoke/RicochetTest.java
! test/java/lang/invoke/ThrowExceptionsTest.java
! test/sun/invoke/util/ValueConversionsTest.java

Changeset: 01014596ada1
Author: jrose
Date: 2012-01-18 17:34 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01014596ada1

7077803: java.lang.InternalError in java.lang.invoke.MethodHandleNatives.init
Summary: Use correct access token for unreflecting MHs where setAccessible(true)
Reviewed-by: never, twisti

! src/share/classes/java/lang/invoke/MethodHandles.java

Changeset: 92d2cba30f08
Author: jrose
Date: 2012-01-18 17:34 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92d2cba30f08

7030453: JSR 292 ClassValue.get method is too slow
Summary: Implement ClassValue cooperatively with Class like ThreadLocal with Thread.
Reviewed-by: twisti, mduigou

! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/ClassValue.java
! test/java/lang/invoke/ClassValueTest.java

Changeset: 81a2629aa2a2
Author: amurillo
Date: 2012-01-20 14:31 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81a2629aa2a2

Merge


Changeset: 954a1c535730
Author: amurillo
Date: 2012-01-25 12:36 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/954a1c535730

Merge

- test/java/io/File/BlockIsDirectory.java

Changeset: d3b334e376d3
Author: mr
Date: 2012-01-23 12:39 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3b334e376d3

7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems
Reviewed-by: ohair

! make/javax/sound/jsoundalsa/Makefile

Changeset: 54202e0148ec
Author: katleman
Date: 2012-01-25 13:54 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54202e0148ec

Merge


Changeset: 34029a0c69bb
Author: katleman
Date: 2012-01-26 18:23 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34029a0c69bb

Added tag jdk8-b23 for changeset 54202e0148ec

! .hgtags

Changeset: 7a25b72b3644
Author: lana
Date: 2012-01-28 20:41 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a25b72b3644

Merge




From joe.darcy at oracle.com Mon Jan 30 03:58:01 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 29 Jan 2012 19:58:01 -0800
Subject: JDK 8 code review request for 7140820 Add covariant overrides to
Collections clone methods
Message-ID: <4F261549.5090308@oracle.com>

Hello,

As an indirect outgrowth of warnings cleanup day, various categories of
warnings can be eliminated by in the use of Cloneable types by
overriding the

Object clone()

method inherited from java.lang.Object with a covariant override such as

MyType clone()

Please review my changes for

7140820 Add covariant overrides to Collections clone methods
http://cr.openjdk.java.net/~darcy/7140820.0/

which add such covariant override clone methods to collections and a few
other classes in java.util. Doing a full JDK build with these changes,
I've also made alterations to other classes to remove now superfuous
casts (casts which are a javac lint warning!) and some unneeded
@SuppressWarnings annotations. I also cleaned up a few rawtypes
warnings while in editing files in java.util.

(Note that the old specListeners method in EventRequestSpecList.java was
much buggy; it cast an ArrayList from runtime.specListeners to a Vector.)

Thanks,

-Joe


From david.holmes at oracle.com Mon Jan 30 05:18:34 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Jan 2012 15:18:34 +1000
Subject: JDK 8 code review request for 7140820 Add covariant overrides
to Collections clone methods
In-Reply-To: <4F261549.5090308@oracle.com>
References: <4F261549.5090308@oracle.com>
Message-ID: <4F26282A.3080604@oracle.com>

Hi Joe,

This looks okay to me.

I guess we don't have any tests for that code in EventRequestSpecList!

Pity about the constant need for suppressing "unchecked" :(

Cheers,
David

On 30/01/2012 1:58 PM, Joe Darcy wrote:
> Hello,
>
> As an indirect outgrowth of warnings cleanup day, various categories of
> warnings can be eliminated by in the use of Cloneable types by
> overriding the
>
> Object clone()
>
> method inherited from java.lang.Object with a covariant override such as
>
> MyType clone()
>
> Please review my changes for
>
> 7140820 Add covariant overrides to Collections clone methods
> http://cr.openjdk.java.net/~darcy/7140820.0/
>
> which add such covariant override clone methods to collections and a few
> other classes in java.util. Doing a full JDK build with these changes,
> I've also made alterations to other classes to remove now superfuous
> casts (casts which are a javac lint warning!) and some unneeded
> @SuppressWarnings annotations. I also cleaned up a few rawtypes warnings
> while in editing files in java.util.
>
> (Note that the old specListeners method in EventRequestSpecList.java was
> much buggy; it cast an ArrayList from runtime.specListeners to a Vector.)
>
> Thanks,
>
> -Joe


From joe.darcy at oracle.com Mon Jan 30 05:44:25 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 29 Jan 2012 21:44:25 -0800
Subject: JDK 8 code review request for 7140820 Add covariant overrides
to Collections clone methods
In-Reply-To: <4F26282A.3080604@oracle.com>
References: <4F261549.5090308@oracle.com> <4F26282A.3080604@oracle.com>
Message-ID: <4F262E39.6040601@oracle.com>

Hi David,

On 01/29/2012 09:18 PM, David Holmes wrote:
> Hi Joe,
>
> This looks okay to me.
>
> I guess we don't have any tests for that code in EventRequestSpecList!

Guess not!

>
> Pity about the constant need for suppressing "unchecked" :(


At least better once per type in the libraries rather than than once at
every call-site.

The clone method would be a good use-case for self types, but adding
those to Java remains a research-class problem.

Thanks for the review,

-Joe

>
> Cheers,
> David
>
> On 30/01/2012 1:58 PM, Joe Darcy wrote:
>> Hello,
>>
>> As an indirect outgrowth of warnings cleanup day, various categories of
>> warnings can be eliminated by in the use of Cloneable types by
>> overriding the
>>
>> Object clone()
>>
>> method inherited from java.lang.Object with a covariant override such as
>>
>> MyType clone()
>>
>> Please review my changes for
>>
>> 7140820 Add covariant overrides to Collections clone methods
>> http://cr.openjdk.java.net/~darcy/7140820.0/
>>
>> which add such covariant override clone methods to collections and a few
>> other classes in java.util. Doing a full JDK build with these changes,
>> I've also made alterations to other classes to remove now superfuous
>> casts (casts which are a javac lint warning!) and some unneeded
>> @SuppressWarnings annotations. I also cleaned up a few rawtypes warnings
>> while in editing files in java.util.
>>
>> (Note that the old specListeners method in EventRequestSpecList.java was
>> much buggy; it cast an ArrayList from runtime.specListeners to a
>> Vector.)
>>
>> Thanks,
>>
>> -Joe



From forax at univ-mlv.fr Mon Jan 30 06:52:36 2012
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Mon, 30 Jan 2012 07:52:36 +0100
Subject: JDK 8 code review request for 7140820 Add covariant overrides
to Collections clone methods
In-Reply-To: <4F261549.5090308@oracle.com>
References: <4F261549.5090308@oracle.com>
Message-ID: <4F263E34.6040805@univ-mlv.fr>

On 01/30/2012 04:58 AM, Joe Darcy wrote:
> Hello,
>
> As an indirect outgrowth of warnings cleanup day, various categories
> of warnings can be eliminated by in the use of Cloneable types by
> overriding the
>
> Object clone()
>
> method inherited from java.lang.Object with a covariant override such as
>
> MyType clone()
>
> Please review my changes for
>
> 7140820 Add covariant overrides to Collections clone methods
> http://cr.openjdk.java.net/~darcy/7140820.0/
>
> which add such covariant override clone methods to collections and a
> few other classes in java.util. Doing a full JDK build with these
> changes, I've also made alterations to other classes to remove now
> superfuous casts (casts which are a javac lint warning!) and some
> unneeded @SuppressWarnings annotations. I also cleaned up a few
> rawtypes warnings while in editing files in java.util.
>
> (Note that the old specListeners method in EventRequestSpecList.java
> was much buggy; it cast an ArrayList from runtime.specListeners to a
> Vector.)
>
> Thanks,
>
> -Joe

WTF !

while it's maybe a binary compatible change, I haven't take a look to
all modified classes to be sure
it's not a source compatible change.

People had created class that inherits from ArrayList and override clone,
while it's not a good practice, there is a *lot* of code from pre-1.5
days that does exactly that,
this change will simply break all those codes.

R?mi




From tom.hawtin at oracle.com Mon Jan 30 12:19:00 2012
From: tom.hawtin at oracle.com (Tom Hawtin)
Date: Mon, 30 Jan 2012 12:19:00 +0000
Subject: JDK 8 code review request for 7140820 Add covariant overrides
to Collections clone methods
In-Reply-To: <4F261549.5090308@oracle.com>
References: <4F261549.5090308@oracle.com>
Message-ID: <4F268AB4.5030708@oracle.com>

On 30/01/2012 03:58, Joe Darcy wrote:

> Object clone()
>
> method inherited from java.lang.Object with a covariant override such as
>
> MyType clone()

This is, of course, going to break any existing overrides (that aren't
making use of covariant return types). This will be why the changes
weren't made way back in 1.5.

Other clone implementations are overridden for (mobile code) security
reasons. These methods may have the same thing done to them by trusted
code outside of the Java library.

A better solution to the unchecked casts from clone, is not to clone.
Using a constructor gets rid of the problem, and ensures you aren't
using some funky (potentially malicious) subclass.

- return (Hashtable<String, java.lang.Object>)_env.clone();
+ return new Hashtable<>(_env);

Tom


From Ulf.Zibis at gmx.de Mon Jan 30 13:16:40 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Mon, 30 Jan 2012 14:16:40 +0100
Subject: JDK 8 code review request for 7140820 Add covariant overrides
to Collections clone methods
In-Reply-To: <4F268AB4.5030708@oracle.com>
References: <4F261549.5090308@oracle.com> <4F268AB4.5030708@oracle.com>
Message-ID: <4F269838.6080606@gmx.de>

Am 30.01.2012 13:19, schrieb Tom Hawtin:
> A better solution to the unchecked casts from clone, is not to clone. Using a constructor gets rid
> of the problem, and ensures you aren't using some funky (potentially malicious) subclass.
>
> - return (Hashtable<String, java.lang.Object>)_env.clone();
> + return new Hashtable<>(_env);

Isn't cloning faster than normal instantiation?
I can imagine, that behind the scenes cloning mainly only needs to duplicate the binary footprint of
an object.

-Ulf



From tom.hawtin at oracle.com Mon Jan 30 13:28:07 2012
From: tom.hawtin at oracle.com (Tom Hawtin)
Date: Mon, 30 Jan 2012 13:28:07 +0000
Subject: JDK 8 code review request for 7140820 Add covariant overrides
to Collections clone methods
In-Reply-To: <4F269838.6080606@gmx.de>
References: <4F261549.5090308@oracle.com> <4F268AB4.5030708@oracle.com>
<4F269838.6080606@gmx.de>
Message-ID: <4F269AE7.1070207@oracle.com>

On 30/01/2012 13:16, Ulf Zibis wrote:
> Isn't cloning faster than normal instantiation?
> I can imagine, that behind the scenes cloning mainly only needs to
> duplicate the binary footprint of an object.

I don't see a good reason why it should be (equally, I've not tried
benchmarking).

For the immediate fields of an object, (partial) bitwise copying "by
hand" should be of comparable performance to a bitwise clone. For
copying the referenced objects, there is no benefit for the clone.

Implementation of HashMap.clone is:

HashMap<K,V> result = null;
try {
result = (HashMap<K,V>)super.clone();
} catch (CloneNotSupportedException e) {
// assert false;
}
result.table = new Entry[table.length];
result.entrySet = null;
result.modCount = 0;
result.size = 0;
result.init();
result.putAllForCreate(this);

return result;

The "copy constructor" is slightly different in that it uses the default
load factor (and minimum size) instead of copying.

this(Math.max((int) (m.size() / DEFAULT_LOAD_FACTOR) + 1,
DEFAULT_INITIAL_CAPACITY), DEFAULT_LOAD_FACTOR);
putAllForCreate(m);

Tom


From forax at univ-mlv.fr Mon Jan 30 13:31:52 2012
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Mon, 30 Jan 2012 14:31:52 +0100
Subject: JDK 8 code review request for 7140820 Add covariant overrides
to Collections clone methods
In-Reply-To: <4F268AB4.5030708@oracle.com>
References: <4F261549.5090308@oracle.com> <4F268AB4.5030708@oracle.com>
Message-ID: <4F269BC8.5080601@univ-mlv.fr>

On 01/30/2012 01:19 PM, Tom Hawtin wrote:
> On 30/01/2012 03:58, Joe Darcy wrote:
>
>> Object clone()
>>
>> method inherited from java.lang.Object with a covariant override such as
>>
>> MyType clone()
>
> This is, of course, going to break any existing overrides (that aren't
> making use of covariant return types). This will be why the changes
> weren't made way back in 1.5.
>
> Other clone implementations are overridden for (mobile code) security
> reasons. These methods may have the same thing done to them by trusted
> code outside of the Java library.
>
> A better solution to the unchecked casts from clone, is not to clone.
> Using a constructor gets rid of the problem, and ensures you aren't
> using some funky (potentially malicious) subclass.
>
> - return (Hashtable<String, java.lang.Object>)_env.clone();
> + return new Hashtable<>(_env);

don't forget that java.util.Property inherits from java.util.Hashtable.

Most of the time, the semantics wanted by the developer is the one of clone
and not the one of the copy constructor. You can safely use the copy
constructor only
if the class is final.

>
> Tom

R?mi



From chris.hegarty at oracle.com Mon Jan 30 14:07:39 2012
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Mon, 30 Jan 2012 14:07:39 +0000
Subject: hg: jdk8/tl/jdk: 7132378: Race in FutureTask if used with explicit
set ( not Runnable )
Message-ID: <20120130140758.691934728A@hg.openjdk.java.net>

Changeset: f9fb8c4b4550
Author: dl
Date: 2012-01-30 11:44 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f9fb8c4b4550

7132378: Race in FutureTask if used with explicit set ( not Runnable )
Reviewed-by: chegar, dholmes

! src/share/classes/java/util/concurrent/FutureTask.java
+ test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java
+ test/java/util/concurrent/FutureTask/ExplicitSet.java



From Alan.Bateman at oracle.com Mon Jan 30 15:08:51 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Jan 2012 15:08:51 +0000
Subject: 7140918: Remove dependency on apt and com.sun.mirror API
Message-ID: <4F26B283.8090103@oracle.com>


The following webrev is a patch from Miran Kos and Martin Grebac (cc'ed)
to remove the JAX-WS dependency on apt and the com.sun.mirror API:

http://cr.openjdk.java.net/~alanb/7140918/webrev/

This is needed before Joe Darcy can wield his machete.

Please cc'ed Miran and Martin on my review comments.

-Alan.


From joe.darcy at oracle.com Mon Jan 30 16:26:04 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 30 Jan 2012 08:26:04 -0800
Subject: 7140918: Remove dependency on apt and com.sun.mirror API
In-Reply-To: <4F26B283.8090103@oracle.com>
References: <4F26B283.8090103@oracle.com>
Message-ID: <4F26C49C.4050600@oracle.com>

On 01/30/2012 07:08 AM, Alan Bateman wrote:
>
> The following webrev is a patch from Miran Kos and Martin Grebac
> (cc'ed) to remove the JAX-WS dependency on apt and the com.sun.mirror
> API:
>
> http://cr.openjdk.java.net/~alanb/7140918/webrev/
>
> This is needed before Joe Darcy can wield his machete.
>
> Please cc'ed Miran and Martin on my review comments.
>
> -Alan.

Hi Alan,

In Release.gmk, there seems to be inconsistent indention on these two lines:

368 com/sun/tools/internal/jxc/ap \
369 com/sun/tools/internal/ws/wscompile/plugin/at_generated \

Likewise at Defs-jaxws.gmk:

58
META-INF/services/com.sun.tools.internal.ws.wscompile.Plugin \
59 META-INF/services/com.sun.tools.internal.xjc.Plugin \

Otherwise, the changes look okay.

Thanks,

-Joe


From joe.darcy at oracle.com Mon Jan 30 17:06:41 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 30 Jan 2012 09:06:41 -0800
Subject: Updated unit test for BigInteger patch (#4837946)
In-Reply-To: <BLU0-SMTP152615288E2D14C60D2B49DC68E0@phx.gbl>
References: <BLU0-SMTP1834158AEF452F0E964F245C69A0@phx.gbl>
<BLU0-SMTP220B8AE166DE1CB2D348063C6990@phx.gbl>
<4F0DDC21.90504@oracle.com>
<BLU0-SMTP152615288E2D14C60D2B49DC68E0@phx.gbl>
Message-ID: <4F26CE21.4060807@oracle.com>

On 01/27/2012 02:41 PM, Tim Buktu wrote:
> On 01/11/2012 11:59 AM, Joe Darcy wrote:
>> Thanks Tim. I'll add this to my review queue after Alan Eliasen's work
>> (finally) gets in.
> Is there a timeframe for this yet?

The timeframe is on the order of weeks to months.

Cheers,

-Joe


From joe.darcy at oracle.com Mon Jan 30 17:10:42 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 30 Jan 2012 09:10:42 -0800
Subject: JDK 8 code review request for 7140820 Add covariant overrides
to Collections clone methods
In-Reply-To: <4F263E34.6040805@univ-mlv.fr>
References: <4F261549.5090308@oracle.com> <4F263E34.6040805@univ-mlv.fr>
Message-ID: <4F26CF12.4090104@oracle.com>

On 01/29/2012 10:52 PM, R?mi Forax wrote:
> On 01/30/2012 04:58 AM, Joe Darcy wrote:
>> Hello,
>>
>> As an indirect outgrowth of warnings cleanup day, various categories
>> of warnings can be eliminated by in the use of Cloneable types by
>> overriding the
>>
>> Object clone()
>>
>> method inherited from java.lang.Object with a covariant override such as
>>
>> MyType clone()
>>
>> Please review my changes for
>>
>> 7140820 Add covariant overrides to Collections clone methods
>> http://cr.openjdk.java.net/~darcy/7140820.0/
>>
>> which add such covariant override clone methods to collections and a
>> few other classes in java.util. Doing a full JDK build with these
>> changes, I've also made alterations to other classes to remove now
>> superfuous casts (casts which are a javac lint warning!) and some
>> unneeded @SuppressWarnings annotations. I also cleaned up a few
>> rawtypes warnings while in editing files in java.util.
>>
>> (Note that the old specListeners method in EventRequestSpecList.java
>> was much buggy; it cast an ArrayList from runtime.specListeners to a
>> Vector.)
>>
>> Thanks,
>>
>> -Joe
>
> WTF !
>
> while it's maybe a binary compatible change, I haven't take a look to
> all modified classes to be sure
> it's not a source compatible change.

Adding the covariant override is a binary compatible change because
there would be a bridge method providing the original "Object clone()"
signature.

>
> People had created class that inherits from ArrayList and override clone,
> while it's not a good practice, there is a *lot* of code from pre-1.5
> days that does exactly that,
> this change will simply break all those codes.
>

*sigh*

Yes, I didn't fully consider the source compatibility implications given
that these types can be subclasses; I'll look this over some more.

(This was meant to be part of a larger effort to review of potentially
overridable clone methods in the JDK. I wrote an annotation processor
to look over the code base to find potential classes to upgrade; I can
refine the processor to look for classes that don't override clone and
are also final or effectively final, having no accessible constructors.)

Thanks Remi,

-Joe


From joe.darcy at oracle.com Mon Jan 30 17:35:17 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 30 Jan 2012 09:35:17 -0800
Subject: JDK 8 code review request for 7140820 Add covariant overrides
to Collections clone methods
In-Reply-To: <4F268AB4.5030708@oracle.com>
References: <4F261549.5090308@oracle.com> <4F268AB4.5030708@oracle.com>
Message-ID: <4F26D4D5.9030302@oracle.com>

On 01/30/2012 04:19 AM, Tom Hawtin wrote:
> On 30/01/2012 03:58, Joe Darcy wrote:
>
>> Object clone()
>>
>> method inherited from java.lang.Object with a covariant override such as
>>
>> MyType clone()
>
> This is, of course, going to break any existing overrides (that aren't
> making use of covariant return types). This will be why the changes
> weren't made way back in 1.5.

While this issue may have good technical grounding, there were also many
potential changes omitted from JDK 5 due to lack of time, etc.

>
> Other clone implementations are overridden for (mobile code) security
> reasons. These methods may have the same thing done to them by trusted
> code outside of the Java library.
>
> A better solution to the unchecked casts from clone, is not to clone.
> Using a constructor gets rid of the problem, and ensures you aren't
> using some funky (potentially malicious) subclass.
>
> - return (Hashtable<String, java.lang.Object>)_env.clone();
> + return new Hashtable<>(_env);
>
> Tom

I suppose this depends on what your threat model is. For better or
worse, the types in question are Cloneable and should have reasonable
clone methods.

-Joe


From Ulf.Zibis at gmx.de Mon Jan 30 21:07:07 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Mon, 30 Jan 2012 22:07:07 +0100
Subject: JDK 8 code review request for 7140820 Add covariant overrides
to Collections clone methods
In-Reply-To: <4F269AE7.1070207@oracle.com>
References: <4F261549.5090308@oracle.com> <4F268AB4.5030708@oracle.com>
<4F269838.6080606@gmx.de> <4F269AE7.1070207@oracle.com>
Message-ID: <4F27067B.8080206@gmx.de>

Am 30.01.2012 14:28, schrieb Tom Hawtin:
> On 30/01/2012 13:16, Ulf Zibis wrote:
>> Isn't cloning faster than normal instantiation?
>> I can imagine, that behind the scenes cloning mainly only needs to
>> duplicate the binary footprint of an object.
>
> I don't see a good reason why it should be (equally, I've not tried benchmarking).
>
> For the immediate fields of an object, (partial) bitwise copying "by hand" should be of comparable
> performance to a bitwise clone. For copying the referenced objects, there is no benefit for the
> clone.

Is there anybody, who knows this exactly, e.g. in reference to Hotspot runtime?

-Ulf



From vitalyd at gmail.com Mon Jan 30 21:17:15 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 30 Jan 2012 16:17:15 -0500
Subject: JDK 8 code review request for 7140820 Add covariant overrides to
Collections clone methods
In-Reply-To: <4F27067B.8080206@gmx.de>
References: <4F261549.5090308@oracle.com> <4F268AB4.5030708@oracle.com>
<4F269838.6080606@gmx.de> <4F269AE7.1070207@oracle.com>
<4F27067B.8080206@gmx.de>
Message-ID: <CAHjP37H5TPVMtfy1Tqx2vqj9T=uZgt5MvoFVqYGAM8YuORW11w@mail.gmail.com>

I would also expect clone to run a bit faster than copy constructor, if for
nothing else than clone not executing any constructor; this perf diff would
probably be more noticeable in interpreter as compiler may inline
constructor. In addition, I'd also think that clone can basically be
equivalent to memcpy which should be faster.

Sent from my phone
On Jan 30, 2012 4:08 PM, "Ulf Zibis" <Ulf.Zibis at gmx.de> wrote:

> Am 30.01.2012 14:28, schrieb Tom Hawtin:
>
>> On 30/01/2012 13:16, Ulf Zibis wrote:
>>
>>> Isn't cloning faster than normal instantiation?
>>> I can imagine, that behind the scenes cloning mainly only needs to
>>> duplicate the binary footprint of an object.
>>>
>>
>> I don't see a good reason why it should be (equally, I've not tried
>> benchmarking).
>>
>> For the immediate fields of an object, (partial) bitwise copying "by
>> hand" should be of comparable performance to a bitwise clone. For copying
>> the referenced objects, there is no benefit for the clone.
>>
>
> Is there anybody, who knows this exactly, e.g. in reference to Hotspot
> runtime?
>
> -Ulf
>
>


From forax at univ-mlv.fr Mon Jan 30 23:47:03 2012
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Tue, 31 Jan 2012 00:47:03 +0100
Subject: JDK 8 code review request for 7140820 Add covariant overrides
to Collections clone methods
In-Reply-To: <CAHjP37H5TPVMtfy1Tqx2vqj9T=uZgt5MvoFVqYGAM8YuORW11w@mail.gmail.com>
References: <4F261549.5090308@oracle.com> <4F268AB4.5030708@oracle.com>
<4F269838.6080606@gmx.de> <4F269AE7.1070207@oracle.com>
<4F27067B.8080206@gmx.de>
<CAHjP37H5TPVMtfy1Tqx2vqj9T=uZgt5MvoFVqYGAM8YuORW11w@mail.gmail.com>
Message-ID: <4F272BF7.9080100@univ-mlv.fr>

On 01/30/2012 10:17 PM, Vitaly Davidovich wrote:
> I would also expect clone to run a bit faster than copy constructor, if for
> nothing else than clone not executing any constructor; this perf diff would
> probably be more noticeable in interpreter as compiler may inline
> constructor. In addition, I'd also think that clone can basically be
> equivalent to memcpy which should be faster.

It depends if the class if final or not.
If the class is not final the VM will have to add a guard before calling
Object.clone().
Object.clone() is intrinsified (lookup for 'intrinsics' in the source code)
so it will do a memcopy. A far as I remember, memcopy is slower that copying
fields one by one if there is a few fields (otherwise it's faster).
Then you need a checkcast at the end and as far as I remember, the VM
doesn't remove it.

So as Tom said, if the class is final, using a copy constructor is
usually faster.

Anyway, this is too Hotspot specific and may change in the future,
moreover I've never seen a call clone() or to a copy constructor
being the performance bottleneck.
Stupid algorithms and bad choices of the data structures are far more
frequent.

R?mi

>
> Sent from my phone
> On Jan 30, 2012 4:08 PM, "Ulf Zibis"<Ulf.Zibis at gmx.de> wrote:
>
>> Am 30.01.2012 14:28, schrieb Tom Hawtin:
>>
>>> On 30/01/2012 13:16, Ulf Zibis wrote:
>>>
>>>> Isn't cloning faster than normal instantiation?
>>>> I can imagine, that behind the scenes cloning mainly only needs to
>>>> duplicate the binary footprint of an object.
>>>>
>>> I don't see a good reason why it should be (equally, I've not tried
>>> benchmarking).
>>>
>>> For the immediate fields of an object, (partial) bitwise copying "by
>>> hand" should be of comparable performance to a bitwise clone. For copying
>>> the referenced objects, there is no benefit for the clone.
>>>
>> Is there anybody, who knows this exactly, e.g. in reference to Hotspot
>> runtime?
>>
>> -Ulf
>>
>>



From vitalyd at gmail.com Tue Jan 31 00:29:55 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 30 Jan 2012 19:29:55 -0500
Subject: JDK 8 code review request for 7140820 Add covariant overrides to
Collections clone methods
In-Reply-To: <4F272BF7.9080100@univ-mlv.fr>
References: <4F261549.5090308@oracle.com> <4F268AB4.5030708@oracle.com>
<4F269838.6080606@gmx.de> <4F269AE7.1070207@oracle.com>
<4F27067B.8080206@gmx.de>
<CAHjP37H5TPVMtfy1Tqx2vqj9T=uZgt5MvoFVqYGAM8YuORW11w@mail.gmail.com>
<4F272BF7.9080100@univ-mlv.fr>
Message-ID: <CAHjP37F19-sBLAR-FPNzmejewngiv=3KeGOENzqvpVQcHHYW4w@mail.gmail.com>

I agree that performance of clone vs copy ctor should be irrelevant in the
grand scheme of things -- I think this question is purely academic at this
point. I think most call sites that call clone() will have just one (maybe
two) receiver types, so the guard should predict every time in most cases,
and I'd imagine is a cheap check (a type check, which I believe is just a
few instructions). As for memcpy, I think some compilers generate better
code for it than others by substituting their own version instead of using
the library call, including using different instructions depending on
amount of data to copy and the machine architecture. Anyway, that's a
whole other topic. I think the general point is that calling clone() makes
a clearer indication of intent to the JVM, so in theory it should have more
room for optimization.

Cheers


On Mon, Jan 30, 2012 at 6:47 PM, R?mi Forax <forax at univ-mlv.fr> wrote:

> On 01/30/2012 10:17 PM, Vitaly Davidovich wrote:
>
>> I would also expect clone to run a bit faster than copy constructor, if
>> for
>> nothing else than clone not executing any constructor; this perf diff
>> would
>> probably be more noticeable in interpreter as compiler may inline
>> constructor. In addition, I'd also think that clone can basically be
>> equivalent to memcpy which should be faster.
>>
>
> It depends if the class if final or not.
> If the class is not final the VM will have to add a guard before calling
> Object.clone().
> Object.clone() is intrinsified (lookup for 'intrinsics' in the source code)
> so it will do a memcopy. A far as I remember, memcopy is slower that
> copying
> fields one by one if there is a few fields (otherwise it's faster).
> Then you need a checkcast at the end and as far as I remember, the VM
> doesn't remove it.
>
> So as Tom said, if the class is final, using a copy constructor is usually
> faster.
>
> Anyway, this is too Hotspot specific and may change in the future,
> moreover I've never seen a call clone() or to a copy constructor
> being the performance bottleneck.
> Stupid algorithms and bad choices of the data structures are far more
> frequent.
>
> R?mi
>
>
>
>> Sent from my phone
>> On Jan 30, 2012 4:08 PM, "Ulf Zibis"<Ulf.Zibis at gmx.de> wrote:
>>
>> Am 30.01.2012 14:28, schrieb Tom Hawtin:
>>>
>>> On 30/01/2012 13:16, Ulf Zibis wrote:
>>>>
>>>> Isn't cloning faster than normal instantiation?
>>>>> I can imagine, that behind the scenes cloning mainly only needs to
>>>>> duplicate the binary footprint of an object.
>>>>>
>>>>> I don't see a good reason why it should be (equally, I've not tried
>>>> benchmarking).
>>>>
>>>> For the immediate fields of an object, (partial) bitwise copying "by
>>>> hand" should be of comparable performance to a bitwise clone. For
>>>> copying
>>>> the referenced objects, there is no benefit for the clone.
>>>>
>>>> Is there anybody, who knows this exactly, e.g. in reference to Hotspot
>>> runtime?
>>>
>>> -Ulf
>>>
>>>
>>>
>


--
Vitaly
617-548-7007 (mobile)


From david.holmes at oracle.com Tue Jan 31 00:50:27 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jan 2012 10:50:27 +1000
Subject: 7140918: Remove dependency on apt and com.sun.mirror API
In-Reply-To: <4F26B283.8090103@oracle.com>
References: <4F26B283.8090103@oracle.com>
Message-ID: <4F273AD3.5070207@oracle.com>

On 31/01/2012 1:08 AM, Alan Bateman wrote:
>
> The following webrev is a patch from Miran Kos and Martin Grebac (cc'ed)
> to remove the JAX-WS dependency on apt and the com.sun.mirror API:
>
> http://cr.openjdk.java.net/~alanb/7140918/webrev/
>
> This is needed before Joe Darcy can wield his machete.
>
> Please cc'ed Miran and Martin on my review comments.

One question: how does this change:

jaxws_src.bundle.name=jdk8-jaxws-2_2-SNAPSHOT-2012_01_11.zip

impact day to day builds? Do we need to have some internal locations
updated with this new zip file? JPRT?

Thanks,
David

> -Alan.


From joe.darcy at oracle.com Tue Jan 31 01:12:50 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 30 Jan 2012 17:12:50 -0800
Subject: 7140918: Remove dependency on apt and com.sun.mirror API
In-Reply-To: <4F273AD3.5070207@oracle.com>
References: <4F26B283.8090103@oracle.com> <4F273AD3.5070207@oracle.com>
Message-ID: <4F274012.7090904@oracle.com>

On 01/30/2012 04:50 PM, David Holmes wrote:
> On 31/01/2012 1:08 AM, Alan Bateman wrote:
>>
>> The following webrev is a patch from Miran Kos and Martin Grebac (cc'ed)
>> to remove the JAX-WS dependency on apt and the com.sun.mirror API:
>>
>> http://cr.openjdk.java.net/~alanb/7140918/webrev/
>>
>> This is needed before Joe Darcy can wield his machete.
>>
>> Please cc'ed Miran and Martin on my review comments.
>
> One question: how does this change:
>
> jaxws_src.bundle.name=jdk8-jaxws-2_2-SNAPSHOT-2012_01_11.zip
>
> impact day to day builds? Do we need to have some internal locations
> updated with this new zip file? JPRT?
>

Yes, there is an Oracle-internal directory location where the zip files
are stored and where the build looks for the files by default.
Otherwise, for a build outside of Oracle, you can run with
ALLOW_DOWNLOADS=true or download the file into a directory named by the
the DROPS_DIR variable (which is what I do for my builds).

-Joe


From david.holmes at oracle.com Tue Jan 31 01:17:58 2012
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jan 2012 11:17:58 +1000
Subject: 7140918: Remove dependency on apt and com.sun.mirror API
In-Reply-To: <4F274012.7090904@oracle.com>
References: <4F26B283.8090103@oracle.com> <4F273AD3.5070207@oracle.com>
<4F274012.7090904@oracle.com>
Message-ID: <4F274146.9050103@oracle.com>

On 31/01/2012 11:12 AM, Joe Darcy wrote:
> On 01/30/2012 04:50 PM, David Holmes wrote:
>> On 31/01/2012 1:08 AM, Alan Bateman wrote:
>>>
>>> The following webrev is a patch from Miran Kos and Martin Grebac (cc'ed)
>>> to remove the JAX-WS dependency on apt and the com.sun.mirror API:
>>>
>>> http://cr.openjdk.java.net/~alanb/7140918/webrev/
>>>
>>> This is needed before Joe Darcy can wield his machete.
>>>
>>> Please cc'ed Miran and Martin on my review comments.
>>
>> One question: how does this change:
>>
>> jaxws_src.bundle.name=jdk8-jaxws-2_2-SNAPSHOT-2012_01_11.zip
>>
>> impact day to day builds? Do we need to have some internal locations
>> updated with this new zip file? JPRT?
>>
>
> Yes, there is an Oracle-internal directory location where the zip files
> are stored and where the build looks for the files by default.

Okay. So as part of this will the new zip file be installed before the
change gets pushed?

Thanks,
David

> Otherwise, for a build outside of Oracle, you can run with
> ALLOW_DOWNLOADS=true or download the file into a directory named by the
> the DROPS_DIR variable (which is what I do for my builds).
>
> -Joe


From Alan.Bateman at oracle.com Tue Jan 31 08:08:26 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 31 Jan 2012 08:08:26 +0000
Subject: 7140918: Remove dependency on apt and com.sun.mirror API
In-Reply-To: <4F274146.9050103@oracle.com>
References: <4F26B283.8090103@oracle.com> <4F273AD3.5070207@oracle.com>
<4F274012.7090904@oracle.com> <4F274146.9050103@oracle.com>
Message-ID: <4F27A17A.1020809@oracle.com>

On 31/01/2012 01:17, David Holmes wrote:
> :
> Okay. So as part of this will the new zip file be installed before the
> change gets pushed?
Yes, that's right.

-Alan


From neil.richards at ngmr.net Tue Jan 31 09:51:24 2012
From: neil.richards at ngmr.net (neil.richards at ngmr.net)
Date: Tue, 31 Jan 2012 09:51:24 +0000
Subject: hg: jdk8/tl/jdk: 7123229: (coll) EnumMap.containsValue(null) returns
true
Message-ID: <20120131095153.AD178472A8@hg.openjdk.java.net>

Changeset: 863a20b0bf08
Author: ngmr
Date: 2012-01-10 00:07 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/863a20b0bf08

7123229: (coll) EnumMap.containsValue(null) returns true
Summary: java.util.EnumMap.NULL equals() must only be true for itself
Reviewed-by: alanb, mduigou
Contributed-by: Neil Richards <neil.richards at ngmr.net>

! src/share/classes/java/util/EnumMap.java
+ test/java/util/EnumMap/UniqueNullValue.java



From neil.richards at ngmr.net Tue Jan 31 10:22:36 2012
From: neil.richards at ngmr.net (Neil Richards)
Date: Tue, 31 Jan 2012 10:22:36 +0000
Subject: Request for review: 7123229: (coll)
EnumMap.containsValue(null) returns true
In-Reply-To: <4F1E84AA.6060308@oracle.com>
References: <1326157533.18727.31.camel@chalkhill> <4F1E84AA.6060308@oracle.com>
Message-ID: <1328005356.12119.27.camel@chalkhill>

On Tue, 2012-01-24 at 10:15 +0000, Alan Bateman wrote:
> Neil - are you still planning to push this to jdk8/tl? As it's
> regression, albeit small, it seems like a good candidate for jdk7u too.
>
> -Alan.

Hi Alan,
Thanks to you and Mike for reviewing this change.
I've now pushed this change up [1].

Apologies for the delay in getting this done.

I too think this a good candidate for jdk7u.
Will I need another bug id to push the change there (after getting
approval on the jdk7u-dev mailing list, ofc)?

Regards,
Neil

[1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/863a20b0bf08
[2] http://openjdk.java.net/projects/jdk7u/qanda.html

--
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 Alan.Bateman at oracle.com Tue Jan 31 10:38:02 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 31 Jan 2012 10:38:02 +0000
Subject: Request for review: 7123229: (coll) EnumMap.containsValue(null)
returns true
In-Reply-To: <1328005356.12119.27.camel@chalkhill>
References: <1326157533.18727.31.camel@chalkhill> <4F1E84AA.6060308@oracle.com>
<1328005356.12119.27.camel@chalkhill>
Message-ID: <4F27C48A.5090401@oracle.com>

On 31/01/2012 10:22, Neil Richards wrote:
> :
> Hi Alan,
> Thanks to you and Mike for reviewing this change.
> I've now pushed this change up [1].
>
> Apologies for the delay in getting this done.
>
> I too think this a good candidate for jdk7u.
> Will I need another bug id to push the change there (after getting
> approval on the jdk7u-dev mailing list, ofc)?
>
Thanks for getting this one fixed. One thing I notice is that your
change-set comment has you listed in the Contributed-by field and as the
author at the same time.

On jdk7u then you use the same bug ID. The jdk7 update project has its
own set of processes [1] but it's mostly straight-forward. If you are
quick then then you will get into 7u4.

-Alan.

[1] http://openjdk.java.net/projects/jdk7u/


From neil.richards at ngmr.net Tue Jan 31 10:40:14 2012
From: neil.richards at ngmr.net (Neil Richards)
Date: Tue, 31 Jan 2012 10:40:14 +0000
Subject: POSIX compatibility change for including wait.h in
UNIXProcess_md.c
In-Reply-To: <CAC-GWLca94Cnej-Ct0kPQ0ghCFg1YRtT+MMKC_KmorwMD8EPVA@mail.gmail.com>
References: <4F0EA969.5000600@linux.vnet.ibm.com>
<4F0EC525.4070507@oracle.com> <4F0FDF85.1060406@linux.vnet.ibm.com>
<4F204811.6070707@oracle.com>
<CAC-GWLca94Cnej-Ct0kPQ0ghCFg1YRtT+MMKC_KmorwMD8EPVA@mail.gmail.com>
Message-ID: <1328006414.12119.32.camel@chalkhill>

On Thu, 2012-01-26 at 17:45 +0800, Jonathan Lu wrote:
>
>
> I think we forgot to create a bug for this, I've created it
> now:
>
> 7133301: (process) UNIXProcess_md.c should include sys/wait.h
> rather than wait.h
>
> Thanks a lot, Alan!
>
>
> I don't mind pushing it for you but maybe this is something
> that Neil wants to do?
>
>
> Hi Neil, could you please help to push it?
>
>
> -Alan
>
> Cheers!
> - Jonathan
>

Hi Johnathan,
I've now pushed this change [1].

Thanks, Alan, for doing the review.

Regards,
Neil

[1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13978750cb87

--
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 neil.richards at ngmr.net Tue Jan 31 11:05:29 2012
From: neil.richards at ngmr.net (Neil Richards)
Date: Tue, 31 Jan 2012 11:05:29 +0000
Subject: Request for review: 7123229: (coll)
EnumMap.containsValue(null) returns true
In-Reply-To: <4F27C48A.5090401@oracle.com>
References: <1326157533.18727.31.camel@chalkhill>
<4F1E84AA.6060308@oracle.com> <1328005356.12119.27.camel@chalkhill>
<4F27C48A.5090401@oracle.com>
Message-ID: <1328007929.12119.45.camel@chalkhill>

On Tue, 2012-01-31 at 10:38 +0000, Alan Bateman wrote:
> Thanks for getting this one fixed. One thing I notice is that your
> change-set comment has you listed in the Contributed-by field and as the
> author at the same time.

Hi Alan,
I had thought that always having "Contributed-by" was the correct thing
to do.

As you called it out, I re-read the relevant bit in the OpenJDK
Developers Guide [1] ("Formatting a Changeset Comment"), and now see
that I was mistaken:

"It <the contributed-by line> should be included only when the
author or authors of the change do not have commit rights to the
target repository and thus would not otherwise receive
acknowledgement."

Thanks for the correction.

Regards,
Neil

[1] http://openjdk.java.net/guide/producingChangeset.html

--
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 neil.richards at ngmr.net Tue Jan 31 10:33:45 2012
From: neil.richards at ngmr.net (neil.richards at ngmr.net)
Date: Tue, 31 Jan 2012 10:33:45 +0000
Subject: hg: jdk8/tl/jdk: 7133301: (process) UNIXProcess_md.c should include
sys/wait.h rather than wait.h
Message-ID: <20120131103407.6E9E0472AC@hg.openjdk.java.net>

Changeset: 13978750cb87
Author: ngmr
Date: 2012-01-31 10:31 +0000
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13978750cb87

7133301: (process) UNIXProcess_md.c should include sys/wait.h rather than wait.h
Reviewed-by: alanb
Contributed-by: Jonathan Lu <luchsh at linux.vnet.ibm.com>

! src/solaris/native/java/lang/UNIXProcess_md.c



From Alan.Bateman at oracle.com Tue Jan 31 11:30:07 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 31 Jan 2012 11:30:07 +0000
Subject: Review request for 7133220: Additional patches to JAXP 1.4.5
update 1 for 7u4
In-Reply-To: <4F232DD4.8050901@oracle.com>
References: <4EF4F236.3080200@oracle.com> <4F232DD4.8050901@oracle.com>
Message-ID: <4F27D0BF.7060801@oracle.com>


Does anyone have cycles to do a review (or partial review) of Joe's
changes? Now that the jaxp code is in the jaxp repository (for jdk7u, I
assume jdk8 soon) it means that the changes will require a reviewer?

Joe - is the intention that you will continue to do batch updates? I ask
because it is usually easier to review specific fixes, big patches
usually require a bit of effort.

-Alan

On 27/01/2012 23:05, Joe Wang wrote:
> Hi,
>
> With this additional patch, I'm fixing a SpecJvm2008 failure against
> 7u4 b07 (7098746), along with a couple of other fixes and accumulated
> Xalan update. The changes are listed below and at
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133220.
> The webrev is at: http://cr.openjdk.java.net/~joehw/7u4-7133220/webrev/
>
>
> Additional patches to JAXP 1.4.5 update 1
>
> Nr Category ID Synopsis/Description
> 1 JAXP/OTHER 7098746 SpecJvm2008 xml.transform subbenchmark fails
> validation
> 2 JAXP/OTHER 7131589 NPE IN
> PARSERCONFIGURATIONSETTINGS.ADDRECOGNIZEDFEATURES
> 3 JAXP/OTHER 7133058 FINDBUGS WARNINGS IN COM.SUN.XML.INTERNAL.*
>
> Apache Xalan update
>
> Nr Key Synopsis/Description
> 1 XALANJ-1243 java.lang.StackOverflowError in XString.equals()
> 2 XALANJ-1991 StackOverflowException comparing two strings
> 3 XALANJ-2001 normalize-space gives StackOverflowError
> 4 XALANJ-1434 org.apache.xpath.axes.AxesWalker getLastPos: duplicate
> predicate testing (one line change)
> 5 XALANJ-1497 xsl:copy adds a newline to processing instructions
> 6 XALANJ-1706 DocumentFragment returned by extension element causes
> multiple SAX endDocument() events
> 7 XALANJ-2218 XML/HTML serializers should have default m_escapeSetting
> = true
> 8 XALANJ-2316 WriterToUTF8Buffered.write(String s) fail with big strings
> 9 XALANJ-2336 Xalan-J should stop using java.util.Vector in some cases
> 10 XALANJ-2218 major 11/Mar/06 XML/HTML serializers should have
> default m_escapeSetting = true
> 11 XALANJ-2236 trivial 30/Oct/06 [PATCH] clean up static calls thru
> instance references
> 12 XALANJ-2271 major08/Mar/06 XML 1.1 Serialization, char in attribute
> value not escaped
>
>
> Thanks,
> Joe



From Ulf.Zibis at gmx.de Tue Jan 31 13:02:20 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 31 Jan 2012 14:02:20 +0100
Subject: JDK 8 code review request for 7140820 Add covariant overrides
to Collections clone methods
In-Reply-To: <4F263E34.6040805@univ-mlv.fr>
References: <4F261549.5090308@oracle.com> <4F263E34.6040805@univ-mlv.fr>
Message-ID: <4F27E65C.30408@gmx.de>

Am 30.01.2012 07:52, schrieb R?mi Forax:
>
> WTF !
>
> while it's maybe a binary compatible change, I haven't take a look to all modified classes to be sure
> it's not a source compatible change.
>
> People had created class that inherits from ArrayList and override clone,
> while it's not a good practice, there is a *lot* of code from pre-1.5 days that does exactly that,
> this change will simply break all those codes.

I guess, as not source compatible for, you think about case A, but not case B? :
class SubClass extends JdkApiClass {
@Override // case A
Object clone() {...}
@Override // case B
SubClass clone() {...}
}

-Ulf



From Ulf.Zibis at gmx.de Tue Jan 31 17:43:14 2012
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 31 Jan 2012 18:43:14 +0100
Subject: JDK 8 code review request for 7140820 Add covariant overrides
to Collections clone methods
In-Reply-To: <CAHjP37F19-sBLAR-FPNzmejewngiv=3KeGOENzqvpVQcHHYW4w@mail.gmail.com>
References: <4F261549.5090308@oracle.com> <4F268AB4.5030708@oracle.com>
<4F269838.6080606@gmx.de> <4F269AE7.1070207@oracle.com>
<4F27067B.8080206@gmx.de>
<CAHjP37H5TPVMtfy1Tqx2vqj9T=uZgt5MvoFVqYGAM8YuORW11w@mail.gmail.com>
<4F272BF7.9080100@univ-mlv.fr>
<CAHjP37F19-sBLAR-FPNzmejewngiv=3KeGOENzqvpVQcHHYW4w@mail.gmail.com>
Message-ID: <4F282832.7030604@gmx.de>

_In theory (am I wrong?):_
- Copy constructor:
1.) allocate memory
2.) individually initialize fields with 0/null
3.) individually initialize fields from initializers
4.) individually initialize fields from super/this constructors (can be many)
5.) individually copy values from original
6.) _optionally_ do some additional work
- Cloning:
1.) allocate memory
2.) copy all values(=memcopy/intrinsic) from original
3.) _optionally_ do some additional work via overriding clone()

_In practice:_
- Thanks for all your detailed answers!

> I think most call sites that call clone() will have just one (maybe two) receiver types

I was thinking about use cases in factories.
Especially cloning an already prepared master-object seems faster to me, than instantiating and
post-processing a virgin object.

In a former case, I had to use a given API, Charset#newDecoder(), to retrieve new decoder objects,
which share a big mapping table object (one for each distinct charset), which was expensive to load.
So the Charset class should hold a virgin decoder object by SoftReference to temporarily prevent the
mapping table from GCing, even if no decoder object was in use(=referenced from user code). As the
decoder object could be of different class type, a concrete (copy)constructor was not accessible.

So I had to decide between _expensive_ (copy)constructor _invocation via reflection_ or, as I think,
_cheap cloning_.

-Ulf


Am 31.01.2012 01:29, schrieb Vitaly Davidovich:
> I agree that performance of clone vs copy ctor should be irrelevant in the
> grand scheme of things -- I think this question is purely academic at this
> point. I think most call sites that call clone() will have just one (maybe
> two) receiver types, so the guard should predict every time in most cases,
> and I'd imagine is a cheap check (a type check, which I believe is just a
> few instructions). As for memcpy, I think some compilers generate better
> code for it than others by substituting their own version instead of using
> the library call, including using different instructions depending on
> amount of data to copy and the machine architecture. Anyway, that's a
> whole other topic. I think the general point is that calling clone() makes
> a clearer indication of intent to the JVM, so in theory it should have more
> room for optimization.
>
> Cheers
>
>
> On Mon, Jan 30, 2012 at 6:47 PM, R?mi Forax<forax at univ-mlv.fr> wrote:
>
>> On 01/30/2012 10:17 PM, Vitaly Davidovich wrote:
>>
>>> I would also expect clone to run a bit faster than copy constructor, if
>>> for
>>> nothing else than clone not executing any constructor; this perf diff
>>> would
>>> probably be more noticeable in interpreter as compiler may inline
>>> constructor. In addition, I'd also think that clone can basically be
>>> equivalent to memcpy which should be faster.
>>>
>> It depends if the class if final or not.
>> If the class is not final the VM will have to add a guard before calling
>> Object.clone().
>> Object.clone() is intrinsified (lookup for 'intrinsics' in the source code)
>> so it will do a memcopy. A far as I remember, memcopy is slower that
>> copying
>> fields one by one if there is a few fields (otherwise it's faster).
>> Then you need a checkcast at the end and as far as I remember, the VM
>> doesn't remove it.
>>
>> So as Tom said, if the class is final, using a copy constructor is usually
>> faster.
>>
>> Anyway, this is too Hotspot specific and may change in the future,
>> moreover I've never seen a call clone() or to a copy constructor
>> being the performance bottleneck.
>> Stupid algorithms and bad choices of the data structures are far more
>> frequent.
>>
>> R?mi
>>
>>
>>
>>> Sent from my phone
>>> On Jan 30, 2012 4:08 PM, "Ulf Zibis"<Ulf.Zibis at gmx.de> wrote:
>>>
>>> Am 30.01.2012 14:28, schrieb Tom Hawtin:
>>>> On 30/01/2012 13:16, Ulf Zibis wrote:
>>>>> Isn't cloning faster than normal instantiation?
>>>>>> I can imagine, that behind the scenes cloning mainly only needs to
>>>>>> duplicate the binary footprint of an object.
>>>>>>
>>>>>> I don't see a good reason why it should be (equally, I've not tried
>>>>> benchmarking).
>>>>>
>>>>> For the immediate fields of an object, (partial) bitwise copying "by
>>>>> hand" should be of comparable performance to a bitwise clone. For
>>>>> copying
>>>>> the referenced objects, there is no benefit for the clone.
>>>>>
>>>>> Is there anybody, who knows this exactly, e.g. in reference to Hotspot
>>>> runtime?
>>>>
>>>> -Ulf
>>>>
>>>>
>>>>
>


From huizhe.wang at oracle.com Tue Jan 31 22:29:32 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 31 Jan 2012 14:29:32 -0800
Subject: Review request for 7133220: Additional patches to JAXP 1.4.5 update
1 for 7u4
Message-ID: <4F286B4C.6090806@oracle.com>

Now that jaxp sources are in the repo, it's possible to do specific fixes rather than batch update. However, the sources on jaxp.java.net need some work before patches can be directly applied to that in the jdk repo. I tried before and received lots of failures.
Besides that, it's a bit of convenience to do a all-test run before a batch update. I will probably have to use this process until jaxp is completely migrated, that is, being able to pull jaxp standalone out of the jdk repo.

-Joe


On 31/01/2012 03:30, Alan wrote:
>Does anyone have cycles to do a review (or partial review) of Joe's
>changes? Now that the jaxp code is in the jaxp repository (for jdk7u, I
>assume jdk8 soon) it means that the changes will require a reviewer?

>Joe - is the intention that you will continue to do batch updates? I ask
>because it is usually easier to review specific fixes, big patches
>usually require a bit of effort.

>-Alan

On 27/01/2012 23:05, Joe Wang wrote:
>/ Hi,
/>/
/>/ With this additional patch, I'm fixing a SpecJvm2008 failure against
/>/ 7u4 b07 (7098746), along with a couple of other fixes and accumulated
/>/ Xalan update. The changes are listed below and at
/>/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133220.
/>/ The webrev is at:http://cr.openjdk.java.net/~joehw/7u4-7133220/webrev/ <http://cr.openjdk.java.net/%7Ejoehw/7u4-7133220/webrev/>
/>/
/>/
/>/ Additional patches to JAXP 1.4.5 update 1
/>/
/>/ Nr Category ID Synopsis/Description
/>/ 1 JAXP/OTHER 7098746 SpecJvm2008 xml.transform subbenchmark fails
/>/ validation
/>/ 2 JAXP/OTHER 7131589 NPE IN
/>/ PARSERCONFIGURATIONSETTINGS.ADDRECOGNIZEDFEATURES
/>/ 3 JAXP/OTHER 7133058 FINDBUGS WARNINGS IN COM.SUN.XML.INTERNAL.*
/>/
/>/ Apache Xalan update
/>/
/>/ Nr Key Synopsis/Description
/>/ 1 XALANJ-1243 java.lang.StackOverflowError in XString.equals()
/>/ 2 XALANJ-1991 StackOverflowException comparing two strings
/>/ 3 XALANJ-2001 normalize-space gives StackOverflowError
/>/ 4 XALANJ-1434 org.apache.xpath.axes.AxesWalker getLastPos: duplicate
/>/ predicate testing (one line change)
/>/ 5 XALANJ-1497 xsl:copy adds a newline to processing instructions
/>/ 6 XALANJ-1706 DocumentFragment returned by extension element causes
/>/ multiple SAX endDocument() events
/>/ 7 XALANJ-2218 XML/HTML serializers should have default m_escapeSetting
/>/ = true
/>/ 8 XALANJ-2316 WriterToUTF8Buffered.write(String s) fail with big strings
/>/ 9 XALANJ-2336 Xalan-J should stop using java.util.Vector in some cases
/>/ 10 XALANJ-2218 major 11/Mar/06 XML/HTML serializers should have
/>/ default m_escapeSetting = true
/>/ 11 XALANJ-2236 trivial 30/Oct/06 [PATCH] clean up static calls thru
/>/ instance references
/>/ 12 XALANJ-2271 major08/Mar/06 XML 1.1 Serialization, char in attribute
/>/ value not escaped
/>/
/>/
/>/ Thanks,
/>/ Joe
/



From pugh at cs.umd.edu Thu Jan 5 06:02:22 2012
From: pugh at cs.umd.edu (Bill Pugh)
Date: Thu, 05 Jan 2012 06:02:22 -0000
Subject: 100218: BigInteger staticRandom field
In-Reply-To: <4F03A96E.1040101@cs.oswego.edu>
References: <4F03A96E.1040101@cs.oswego.edu>
Message-ID: <4EA545BF-252D-44CD-B459-0567CCA80D54@cs.umd.edu>

OK, I actually starting this bug report when developing a course project (Paul is a student in my class).
I got bit by this using Doug Lea's ParallelArray infrastructure. My code was checking which elements in an array of 300,000 long values were prime, by checking for divisibility by small primes and then constructing a BigInteger and calling isProbablePrime. But I found that using more than one thread only gave me slowdowns.

After about a half day of thinking I was using the ParallelArray code incorrectly, I eventually tracked it down to a bottleneck in the SecureRandom. At first, I figured it was just a problem with the shared SecureRandom being used in the private method passesMillerRabin when no Random object is provided. Since the method is private, I couldn't provide my own Random.

I wound up using reflection to bypass access control and call passesMillerRabin with a Random object stored in a thread local.

In replicating my benchmarks for this email, I noticed that I was using regular old Random objects rather than SecureRandom objects (using regular Random objects was good enough for my testing). I found that if I used a ThreadLocal<SecureRandom>, I was also getting a slow down when doing parallel primality testing.

I spent some time looking at the implementation of SecureRandom and of sun.security.provider.NativePRNG. The implementation of NativePRNG uses a static singleton to perform all of the work, so that looked like the concurrency bottleneck. But when I rewrote that class, it turns out that even removing all of the Java level concurrency bottlenecks, we still can't generate concurrent secure random numbers, because the NativePRNG reads /dev/urandom for each byte, and that is inherently sequential and is the bottleneck to the entire process of generating secure random numbers.

So I think the right thing to do is to abandon the original patch, and instead make the following changes:
add the following method to BigInteger public boolean isProbablePrime(int certainty, Random end) , which allows primality testing with arbitrary Random objects. In many cases, using a well seeded normal Random object will work just fine, and this will give users the ability to provide their own Random objects
Document SecureRandom to note that all instances of SecureRandom depend on a common shared source of randomness, and thus it can be a concurrency bottlenck.
Document that BigInteger.isProbablePrime(int certainty) is a concurrency bottleneck.
Add java.util.concurrent.MostlySecureRandom which uses /dev/random for seeding, and uses only the SHA1PRNG implementation provided by sun.security.provider.SecureRandom to generate subsequent randomness. Feel free to pick a name other than MostlySecureRandom. After the initial seeding, calls to generate randomness using a MostlySecureRandom should not use any shared values.

If this sounds reasonable, we can work out a strategy for who will do what to make this happen.

Bill


>
> -------- Original Message --------
> Subject: Re: 100218: BigInteger staticRandom field
> Date: Wed, 04 Jan 2012 10:15:10 +1000
> From:
> Organization: Oracle Corporation
> To: Paul Ciprich <paul.ciprich at gmail.com>
> CC: core-libs-dev at openjdk.java.net
>
> On 4/01/2012 10:08 AM, David Holmes wrote:
>> Hi Paul,
>>
>> For some reason this email, despite being dated Dec 14, only just
>> appeared in my inbox on Jan 3!
>
> Oops! I missed the fact a copy of this email also turned up on Dec 15
> and that I already replied to it.
>
> Comments still apply. Need to understand the context in which this
> becomes a bottleneck and the performance implications for non-concurrent
> use.
>
> David
>
>> On 14/12/2011 12:44 AM, Paul Ciprich wrote:
>>> All,
>>>
>>> I've created a bug report to address a scalability problem with
>>> BigInteger's staticRandom field. The problem is that the shared
>>> staticRandom field causes bottlenecks with parallel code. The proposed
>>> solution is to change the staticRandom field to a ThreadLocal and
>>> eliminate
>>> the bottleneck by giving each thread its own copy of the SecureRandom
>>> object. Bug 100218 contains a patch with the proposed change if it is
>>> deemed acceptable.
>>
>> As I mention in the bug report we have to ensure that we don't add
>> unacceptable overhead to the non-concurrent case. Also I'm wondering if
>> anyone might be relying on the existing SecureRandom instance being shared?
>>
>> Can you clarify the context for the proposed fix: what code is the
>> bottleneck (isProbablePrime?), under what conditions - is it a
>> microbenchmark or real code?
>>
>> Thanks,
>> David Holmes



From wasserman.louis at gmail.com Wed Jan 18 19:14:33 2012
From: wasserman.louis at gmail.com (Louis Wasserman)
Date: Wed, 18 Jan 2012 19:14:33 -0000
Subject: Float.parseFloat rounding patch
Message-ID: <CA+tXMXOv1gtORCAF=m8NQCnh73vVbp+g9sg9ds-Ap_nJQdtivQ@mail.gmail.com>

A while back I independently discovered Sun bug
6358355<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6358355> --
basically, under certain conditions, Float.parseFloat just uses a heuristic
to round from Double.parseDouble (it tries to round in the opposite
direction from parseDouble), which predictably enough for a hackish
approach to floating-point rounding, doesn't work correctly in all cases.
The relevant source is
here<https://bugs.openjdk.java.net/attachment.cgi?id=243&action=diff#a/src/share/classes/sun/misc/FloatingDecimal.java_sec5>;
the comment: "look at the class instance variable roundDir, which should
help us avoid double-rounding error. roundDir was set in hardValueOf if the
estimate was close enough, but not exact. It tells us which direction of
rounding is preferred."

I have a patch and a test at
https://bugs.openjdk.java.net/show_bug.cgi?id=100208, and I was advised to
contact this mailing list to get it reviewed. What do I need to do?

Louis Wasserman
wasserman.louis at gmail.com
http://profiles.google.com/wasserman.louis


From scott.kovatch at oracle.com Fri Jan 27 15:56:36 2012
From: scott.kovatch at oracle.com (Scott Kovatch)
Date: Fri, 27 Jan 2012 07:56:36 -0800
Subject: RFR: 7134690: remove legacy jnilib support from ClassLoader and
System [macosx]
In-Reply-To: <4F229498.7030701@oracle.com>
References: <4F228D54.8040801@oracle.com> <4F229498.7030701@oracle.com>
Message-ID: <C10493DF-CE1D-4A27-A977-6098FC07A399@oracle.com>

On Jan 27, 2012, at 4:12 AM, Alan Bateman wrote:

> On 27/01/2012 11:41, Michael McMahon wrote:
>> Can I get the following change reviewed please? The change is to remove
>> some mac specific code from:
>>
>> src/share/classes/java/lang/System.java and
>> src/share/classes/java/lang/ClassLoader.java
>>
>> which added support for non-standard native library suffixes on Mac OS
>> (ie. .jnilib as well as the standard .dylib).
>>
>> We would like to remove this code, so there will be no changes to those sources
>> when the Mac changes get pushed to jdk7u-dev
>>
>> I have submitted a hotspot CR to track providing the same functionality
>> in Mac specific code in hotspot. Though we can probably live without it in the short-term.
>>
>> http://cr.openjdk.java.net/~michaelm/7134690/webrev.1/
> This looks fine to me as this wasn't the right place to support this. I don't know how common .jnilib was to know if the VM changes will be required in the short term.

For 7u4 this is probably going to be okay, but we definitely need this functionality for 7u6 when the plugin is released. There are some popular web sites (Minecraft, for example) that use JOGL, which uses a .jnilib extension.

-- Scott K.

----------------------------------------
Scott Kovatch
scott.kovatch at oracle.com
Santa Clara/Pleasanton, CA




From igor.nekrestyanov at oracle.com Fri Jan 27 17:51:15 2012
From: igor.nekrestyanov at oracle.com (Igor Nekrestyanov)
Date: Fri, 27 Jan 2012 09:51:15 -0800
Subject: RFR: 7134690: remove legacy jnilib support from ClassLoader and
System [macosx]
In-Reply-To: <C10493DF-CE1D-4A27-A977-6098FC07A399@oracle.com>
References: <4F228D54.8040801@oracle.com> <4F229498.7030701@oracle.com>
<C10493DF-CE1D-4A27-A977-6098FC07A399@oracle.com>
Message-ID: <4F22E413.40808@oracle.com>

On 1/27/12 7:56 AM, Scott Kovatch wrote:
> On Jan 27, 2012, at 4:12 AM, Alan Bateman wrote:
>
>> On 27/01/2012 11:41, Michael McMahon wrote:
>>> Can I get the following change reviewed please? The change is to remove
>>> some mac specific code from:
>>>
>>> src/share/classes/java/lang/System.java and
>>> src/share/classes/java/lang/ClassLoader.java
>>>
>>> which added support for non-standard native library suffixes on Mac OS
>>> (ie. .jnilib as well as the standard .dylib).
>>>
>>> We would like to remove this code, so there will be no changes to those sources
>>> when the Mac changes get pushed to jdk7u-dev
>>>
>>> I have submitted a hotspot CR to track providing the same functionality
>>> in Mac specific code in hotspot. Though we can probably live without it in the short-term.
>>>
>>> http://cr.openjdk.java.net/~michaelm/7134690/webrev.1/
>> This looks fine to me as this wasn't the right place to support this. I don't know how common .jnilib was to know if the VM changes will be required in the short term.
> For 7u4 this is probably going to be okay, but we definitely need this functionality for 7u6 when the plugin is released. There are some popular web sites (Minecraft, for example) that use JOGL, which uses a .jnilib extension.
IMHO, this is enough to justify support for .jnilib in 7u4.
Otherwise beta plugin bundle will not work for most popular sites ...

-igor
>
> -- Scott K.
>
> ----------------------------------------
> Scott Kovatch
> scott.kovatch at oracle.com
> Santa Clara/Pleasanton, CA
>
>



From staffan.larsen at oracle.com Tue Jan 31 15:48:13 2012
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Tue, 31 Jan 2012 15:48:13 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20120131154836.61930472B5@hg.openjdk.java.net>

Changeset: 431bc327f34a
Author: sla
Date: 2012-01-31 10:46 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/431bc327f34a

7132199: sun/management/jmxremote/bootstrap/JvmstatCountersTest.java failing on all platforms
Summary: Make sure HotSpot and JDK looks for well-known files in the same location
Reviewed-by: dholmes, dsamersoff

! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java
! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java
! test/ProblemList.txt

Changeset: 663a6333105d
Author: sla
Date: 2012-01-31 04:57 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/663a6333105d

Merge




Set Home | Add to Favorites

All Rights Reserved Powered by Free Document Search and Download

Copyright © 2011
This site does not host pdf,doc,ppt,xls,rtf,txt files all document are the property of their respective owners. complaint#downhi.com
TOP