From iris.clark at oracle.com  Mon Oct  1 00:35:17 2012
From: iris.clark at oracle.com (Iris Clark)
Date: Sun, 30 Sep 2012 17:35:17 -0700 (PDT)
Subject: 8000269: Cleanup javadoc warnings
In-Reply-To: <50675F7C.7010502@oracle.com>
References: <50675F7C.7010502@oracle.com>
Message-ID: <f64b1cea-b191-403f-97c5-b14034e19183@default>

Hi, Alan.

Looks fantastic!

By fixing these javadoc warnings for @throws and @param, I'm assuming that we will be changing the generated javadoc.  Are any of these changes significant enough to warrant a ccc?  Most of the changes looked fairly innocuous but there are a couple here and there (e.g. java.lang.management.ThreadInfo, java.util.JapaneseImperialCalendar) that may warrant a closer look.

In java.util.Locale it looks like you determined that the '/' used for tag self-termination is unacceptable.  Does it need to stay there now that you've done the explicit termination?

(e.g. 
your new l86: <dt><a name="def_language"/><b>language</b></a></dt>
Proposed new: <dt><a name="def_language"><b>language</b></a></dt>
)

Thanks,
iris

-----Original Message-----
From: Alan Bateman 
Sent: Saturday, September 29, 2012 1:52 PM
To: core-libs-dev
Subject: 8000269: Cleanup javadoc warnings


A small number of javadoc warnings have sneaked into the jdk8 builds lately. They are easily fixed but it's a good opportunity to try out Jon's doccheck tool [1], built on the DocTree API, and get a better workout. I decided to mostly focus on -Xmsgs:reference, which covers references like @param and @throws. I fixed a small number of html issues along the way but that was not my focus. The webrev, which fixes up most of the reference issues in roughly the core area, is here:

http://cr.openjdk.java.net/~alanb/8000269/webrev/index.html

When I say "most" then I excluded j.u.c and java.lang.invoke.

The reason that so many files are changed is because doccheck looks at private and package-private classes and methods that wouldn't normally be in the javadoc. Also, no foray into the *Permission classes is possible without fixing up at least a few formatting issues. Note that there is one non-javadoc change in this webrev; in java.net.Inet4Address I have removed a private static field that has not been used for several releases.

The changes are trivial and easy to review. At it covers many areas then partial reviews are okay too.

Thanks,

Alan.

[1]
http://mail.openjdk.java.net/pipermail/compiler-dev/2012-September/004800.html


From david.holmes at oracle.com  Mon Oct  1 07:20:23 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 01 Oct 2012 17:20:23 +1000
Subject: 8000269: Cleanup javadoc warnings
In-Reply-To: <50675F7C.7010502@oracle.com>
References: <50675F7C.7010502@oracle.com>
Message-ID: <50694437.2060000@oracle.com>

Hi Alan,

This one caught my eye:

src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java

This entire class seems to re-declare inherited methods from 
DatagramSocketImpl for no obvious reason and mess up the javadoc in the 
process. In many/most cases there is no need to redeclare the methods 
AFAICS. If there is some subtle reason then inheritance of the existing 
javadoc should suffice in the majority of cases.

David
-----


On 30/09/2012 6:52 AM, Alan Bateman wrote:
>
> A small number of javadoc warnings have sneaked into the jdk8 builds
> lately. They are easily fixed but it's a good opportunity to try out
> Jon's doccheck tool [1], built on the DocTree API, and get a better
> workout. I decided to mostly focus on -Xmsgs:reference, which covers
> references like @param and @throws. I fixed a small number of html
> issues along the way but that was not my focus. The webrev, which fixes
> up most of the reference issues in roughly the core area, is here:
>
> http://cr.openjdk.java.net/~alanb/8000269/webrev/index.html
>
> When I say "most" then I excluded j.u.c and java.lang.invoke.
>
> The reason that so many files are changed is because doccheck looks at
> private and package-private classes and methods that wouldn't normally
> be in the javadoc. Also, no foray into the *Permission classes is
> possible without fixing up at least a few formatting issues. Note that
> there is one non-javadoc change in this webrev; in java.net.Inet4Address
> I have removed a private static field that has not been used for several
> releases.
>
> The changes are trivial and easy to review. At it covers many areas then
> partial reviews are okay too.
>
> Thanks,
>
> Alan.
>
> [1]
> http://mail.openjdk.java.net/pipermail/compiler-dev/2012-September/004800.html
>


From Alan.Bateman at oracle.com  Mon Oct  1 08:50:17 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 01 Oct 2012 09:50:17 +0100
Subject: 8000269: Cleanup javadoc warnings
In-Reply-To: <f64b1cea-b191-403f-97c5-b14034e19183@default>
References: <50675F7C.7010502@oracle.com>
	<f64b1cea-b191-403f-97c5-b14034e19183@default>
Message-ID: <50695949.70102@oracle.com>

On 01/10/2012 01:35, Iris Clark wrote:
> Hi, Alan.
>
> Looks fantastic!
>
> By fixing these javadoc warnings for @throws and @param, I'm assuming that we will be changing the generated javadoc.  Are any of these changes significant enough to warrant a ccc?  Most of the changes looked fairly innocuous but there are a couple here and there (e.g. java.lang.management.ThreadInfo, java.util.JapaneseImperialCalendar) that may warrant a closer look.
Thanks Irish. I don't believe there is anything significant. A lot of 
the changes are actually to private or package-private methods so they 
don't show up in the javadoc anyway (the changes to ThreadInfo and 
JapaneseImperialCalendar are for private methods and a private constructor).

>
> In java.util.Locale it looks like you determined that the '/' used for tag self-termination is unacceptable.  Does it need to stay there now that you've done the explicit termination?
>
> (e.g.
> your new l86:<dt><a name="def_language"/><b>language</b></a></dt>
> Proposed new:<dt><a name="def_language"><b>language</b></a></dt>
> )
>
You're right, I shouldn't have touched those (the only reason I was in 
Locale was because there's a typo in the @throws of the readObject method).

-Alan


From Alan.Bateman at oracle.com  Mon Oct  1 08:53:01 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 01 Oct 2012 09:53:01 +0100
Subject: 8000269: Cleanup javadoc warnings
In-Reply-To: <50694437.2060000@oracle.com>
References: <50675F7C.7010502@oracle.com> <50694437.2060000@oracle.com>
Message-ID: <506959ED.9010700@oracle.com>

On 01/10/2012 08:20, David Holmes wrote:
> Hi Alan,
>
> This one caught my eye:
>
> src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
>
> This entire class seems to re-declare inherited methods from 
> DatagramSocketImpl for no obvious reason and mess up the javadoc in 
> the process. In many/most cases there is no need to redeclare the 
> methods AFAICS. If there is some subtle reason then inheritance of the 
> existing javadoc should suffice in the majority of cases.
I agree. I talked to Chris about it as it's left over from the 
refactoring of the socket impls. As these are package-private classes 
and don't show up in the javadoc I decided to do the minimum and just 
fix up the @param tags. I create a separate issue to sort out the socket 
impl docs.

-Alan


From david.holmes at oracle.com  Mon Oct  1 11:30:40 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 01 Oct 2012 21:30:40 +1000
Subject: 8000269: Cleanup javadoc warnings
In-Reply-To: <506959ED.9010700@oracle.com>
References: <50675F7C.7010502@oracle.com> <50694437.2060000@oracle.com>
	<506959ED.9010700@oracle.com>
Message-ID: <50697EE0.3070700@oracle.com>

On 1/10/2012 6:53 PM, Alan Bateman wrote:
> On 01/10/2012 08:20, David Holmes wrote:
>> Hi Alan,
>>
>> This one caught my eye:
>>
>> src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
>>
>> This entire class seems to re-declare inherited methods from
>> DatagramSocketImpl for no obvious reason and mess up the javadoc in
>> the process. In many/most cases there is no need to redeclare the
>> methods AFAICS. If there is some subtle reason then inheritance of the
>> existing javadoc should suffice in the majority of cases.
> I agree. I talked to Chris about it as it's left over from the
> refactoring of the socket impls. As these are package-private classes
> and don't show up in the javadoc I decided to do the minimum and just
> fix up the @param tags. I create a separate issue to sort out the socket
> impl docs.

In that case you should fix:

102      * @param p to be sent.

->

  * @param p the packet to be sent.

David
-----

> -Alan


From Alan.Bateman at oracle.com  Mon Oct  1 11:37:37 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 01 Oct 2012 12:37:37 +0100
Subject: 8000269: Cleanup javadoc warnings
In-Reply-To: <50697EE0.3070700@oracle.com>
References: <50675F7C.7010502@oracle.com> <50694437.2060000@oracle.com>
	<506959ED.9010700@oracle.com> <50697EE0.3070700@oracle.com>
Message-ID: <50698081.6020404@oracle.com>

On 01/10/2012 12:30, David Holmes wrote:
>
> In that case you should fix:
>
> 102      * @param p to be sent.
>
> ->
>
>  * @param p the packet to be sent.
Okay, I'll fix up that while I'm there.

-Alan


From paul.sandoz at oracle.com  Mon Oct  1 13:14:07 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 1 Oct 2012 15:14:07 +0200
Subject: Reviewer and committer request for 7197642
Message-ID: <BC25F659-8ADC-46AC-AF8F-FEED253B3944@oracle.com>

Hi,

See here:

  http://cr.openjdk.java.net/~psandoz/tl/7197642/webrev/

Thanks,
Paul.

From paul.sandoz at oracle.com  Mon Oct  1 14:33:18 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 1 Oct 2012 16:33:18 +0200
Subject: ServiceLoader.load(Class, ClassLoader) bug
In-Reply-To: <5052E8EB.4010304@gmail.com>
References: <5051F823.7010803@gmail.com> <5052E8EB.4010304@gmail.com>
Message-ID: <5F450021-A977-4533-8A78-DECDE3D3285E@oracle.com>

Hi Peter,

Thanks for reporting this.

It would be helpful to know the original intent of the author, but i suspect this is a bug (even though null is commonly used to refer to the bootstrap CL).

FWIW i cannot find any explicit cases in the JDK that relies on this behaviour to explicitly limit the loading of service provider classes to those in rt.jar, which would be kind of a pointless use of SL :-)

I am inclined to think that fixing this is mostly harmless, since passing a null CL renders SL useless for anything but service provider classes in rt.jar, and there are so very few of those provider classes i.e. this issue is likely to have been mostly worked around by explicitly passing in a non-null CL, such as ClassLoader.getSystemClassLoader().

However, I say mostly harmless because fixing this will change behaviour to no longer produce an error that would otherwise be acted on. This may be the case for libraries that use SL and the user passed a CL to the library and the library on error uses, for example. the thread context CL. Who knows, CL code can be very strange.

Paul.

On Sep 14, 2012, at 10:20 AM, Peter Levart <peter.levart at gmail.com> wrote:

> I reported this as Bug ID: 7198496
> 
> Regards, Peter
> 
> On 09/13/2012 05:13 PM, Peter Levart wrote:
>> Hi,
>> 
>> The javadoc for java.util.ServiceLoader.load(Class service, ClassLoader loader) method says about it's parameters:
>> 
>>     * @param  service
>>     *         The interface or abstract class representing the service
>>     *
>>     * @param  loader
>>     *         The class loader to be used to load provider-configuration files
>>     *         and provider classes, or <tt>null</tt> if the system class
>>     *         loader (or, failing that, the bootstrap class loader) is to be
>>     *         used
>> 
>> So one might think that calling:
>> 
>>    ServiceLoader.load(service, null);
>> 
>> is equivalent to:
>> 
>>    ServiceLoader.load(service, ClassLoader.getSystemClassLoader());
>> 
>> 
>> But it is not. Either this is a bug in ServiceLoader or javadoc has to be changed.
>> 
>> If null is specified as ClassLoader then ServiceLoader locates META-INF/services/interface.name resources using system ClassLoader (using ClassLoader.getSystemResources), but loads implementation classes using bootstrap ClassLoader (using Class.forName(className, true, null)).
>> 
>> If this is not the expected behaviour then the fix is simple (in the private constructor of ServiceLoader[217]):
>> 
>> -    loader = cl;
>> +   loader = cl == null ? ClassLoader.getSystemClassLoader() : cl;
>> 
>> 
>> 
>> Regards, Peter
>> 
>> 
>> 
>> 
> 



From alan.bateman at oracle.com  Mon Oct  1 14:43:23 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Mon, 01 Oct 2012 14:43:23 +0000
Subject: hg: jdk8/tl/jdk: 8000269: Cleanup javadoc warnings
Message-ID: <20121001144346.24F384714B@hg.openjdk.java.net>

Changeset: 39cbe256c3d1
Author:    alanb
Date:      2012-10-01 15:36 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39cbe256c3d1

8000269: Cleanup javadoc warnings
Reviewed-by: lancea, darcy, ulfzibis, iris, naoto, dholmes

! src/share/classes/java/io/FilePermission.java
! src/share/classes/java/io/PrintWriter.java
! src/share/classes/java/io/Reader.java
! src/share/classes/java/lang/Class.java
! src/share/classes/java/lang/InheritableThreadLocal.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Package.java
! src/share/classes/java/lang/StrictMath.java
! src/share/classes/java/lang/String.java
! src/share/classes/java/lang/System.java
! src/share/classes/java/lang/ThreadGroup.java
! src/share/classes/java/lang/ThreadLocal.java
! src/share/classes/java/lang/management/ThreadInfo.java
! src/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
! src/share/classes/java/net/AbstractPlainSocketImpl.java
! src/share/classes/java/net/DatagramSocket.java
! src/share/classes/java/net/Inet4Address.java
! src/share/classes/java/net/SocketInputStream.java
! src/share/classes/java/net/SocketPermission.java
! src/share/classes/java/net/SocksSocketImpl.java
! src/share/classes/java/net/URLConnection.java
! src/share/classes/java/nio/channels/Channels.java
! src/share/classes/java/nio/file/FileSystem.java
! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java
! src/share/classes/java/nio/file/attribute/FileTime.java
! src/share/classes/java/security/AllPermission.java
! src/share/classes/java/security/BasicPermission.java
! src/share/classes/java/security/CodeSource.java
! src/share/classes/java/security/KeyStore.java
! src/share/classes/java/security/cert/PKIXRevocationChecker.java
! src/share/classes/java/sql/CallableStatement.java
! src/share/classes/java/text/CollationElementIterator.java
! src/share/classes/java/text/DigitList.java
! src/share/classes/java/text/Format.java
! src/share/classes/java/text/RBCollationTables.java
! src/share/classes/java/text/RBTableBuilder.java
! src/share/classes/java/text/SimpleDateFormat.java
! src/share/classes/java/util/Calendar.java
! src/share/classes/java/util/Currency.java
! src/share/classes/java/util/Formatter.java
! src/share/classes/java/util/JapaneseImperialCalendar.java
! src/share/classes/java/util/JumboEnumSet.java
! src/share/classes/java/util/Locale.java
! src/share/classes/java/util/PropertyPermission.java
! src/share/classes/java/util/RegularEnumSet.java
! src/share/classes/java/util/Scanner.java
! src/share/classes/java/util/TimeZone.java
! src/share/classes/java/util/logging/Logging.java
! src/share/classes/java/util/prefs/XmlSupport.java
! src/share/classes/javax/crypto/CryptoAllPermission.java
! src/share/classes/javax/crypto/CryptoPermission.java
! src/share/classes/javax/crypto/CryptoPolicyParser.java
! src/share/classes/javax/crypto/NullCipherSpi.java
! src/share/classes/javax/management/loading/MLet.java
! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java
! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java
! src/share/classes/javax/naming/spi/NamingManager.java
! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java
! src/share/classes/javax/security/auth/kerberos/ServicePermission.java
! src/share/classes/javax/sql/ConnectionPoolDataSource.java
! src/share/classes/javax/sql/PooledConnection.java
! src/share/classes/javax/sql/rowset/spi/SyncProvider.java



From peter.levart at gmail.com  Mon Oct  1 17:00:41 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 01 Oct 2012 19:00:41 +0200
Subject: ServiceLoader.load(Class, ClassLoader) bug
In-Reply-To: <5F450021-A977-4533-8A78-DECDE3D3285E@oracle.com>
References: <5051F823.7010803@gmail.com> <5052E8EB.4010304@gmail.com>
	<5F450021-A977-4533-8A78-DECDE3D3285E@oracle.com>
Message-ID: <5069CC39.5030604@gmail.com>

Hi Paul,

It would be very strange code indeed that acted on the 
ServiceConfigurationError in a way that you describe. After all, the 
java.lang.Error hierarchy of throwables is reserved for things that 
should be "acted upon" only by fixing the code, isn't it?

This is also explicitly noted in the javadoc of the ServiceLoader:

"Design Note: Throwing an error in these cases may seem extreme. The 
rationale for this behaviour is that a malformed provider-configuration 
file, like a malformed class file, indicates a serious problem with the 
way the Java virtual machine is configured or is being used. As such it 
is preferable to throw an error rather than try to recover or, even 
worse, fail silently."

FWIW, I stumbled on the bug by chance in an application using Jetty 
servlet engine as an embedded component. The service that was to be 
loaded was a component of the Spring web application framework which 
passed  the "Web Context" CL to the ServiceLoader to load a component 
and that "Web Context" CL returned by embedded Jetty was null (probably 
because of miss-configuration of Jetty).

If ServiceLoader used System CL to load the class instead, the 
miss-configuration of Jetty would go unnoticed.

But that's not the situation that you are concerned about. You are 
concerned that a (badly written app) might end up loading "different" 
service implementation even though that might be the one that should be 
loaded (by the book).


Regards, Peter

On 10/01/2012 04:33 PM, Paul Sandoz wrote:
> Hi Peter,
>
> Thanks for reporting this.
>
> It would be helpful to know the original intent of the author, but i suspect this is a bug (even though null is commonly used to refer to the bootstrap CL).
>
> FWIW i cannot find any explicit cases in the JDK that relies on this behaviour to explicitly limit the loading of service provider classes to those in rt.jar, which would be kind of a pointless use of SL :-)
>
> I am inclined to think that fixing this is mostly harmless, since passing a null CL renders SL useless for anything but service provider classes in rt.jar, and there are so very few of those provider classes i.e. this issue is likely to have been mostly worked around by explicitly passing in a non-null CL, such as ClassLoader.getSystemClassLoader().
>
> However, I say mostly harmless because fixing this will change behaviour to no longer produce an error that would otherwise be acted on. This may be the case for libraries that use SL and the user passed a CL to the library and the library on error uses, for example. the thread context CL. Who knows, CL code can be very strange.
>
> Paul.
>
> On Sep 14, 2012, at 10:20 AM, Peter Levart <peter.levart at gmail.com> wrote:
>
>> I reported this as Bug ID: 7198496
>>
>> Regards, Peter
>>
>> On 09/13/2012 05:13 PM, Peter Levart wrote:
>>> Hi,
>>>
>>> The javadoc for java.util.ServiceLoader.load(Class service, ClassLoader loader) method says about it's parameters:
>>>
>>>      * @param  service
>>>      *         The interface or abstract class representing the service
>>>      *
>>>      * @param  loader
>>>      *         The class loader to be used to load provider-configuration files
>>>      *         and provider classes, or <tt>null</tt> if the system class
>>>      *         loader (or, failing that, the bootstrap class loader) is to be
>>>      *         used
>>>
>>> So one might think that calling:
>>>
>>>     ServiceLoader.load(service, null);
>>>
>>> is equivalent to:
>>>
>>>     ServiceLoader.load(service, ClassLoader.getSystemClassLoader());
>>>
>>>
>>> But it is not. Either this is a bug in ServiceLoader or javadoc has to be changed.
>>>
>>> If null is specified as ClassLoader then ServiceLoader locates META-INF/services/interface.name resources using system ClassLoader (using ClassLoader.getSystemResources), but loads implementation classes using bootstrap ClassLoader (using Class.forName(className, true, null)).
>>>
>>> If this is not the expected behaviour then the fix is simple (in the private constructor of ServiceLoader[217]):
>>>
>>> -    loader = cl;
>>> +   loader = cl == null ? ClassLoader.getSystemClassLoader() : cl;
>>>
>>>
>>>
>>> Regards, Peter
>>>
>>>
>>>
>>>



From Alan.Bateman at oracle.com  Mon Oct  1 17:35:14 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 01 Oct 2012 18:35:14 +0100
Subject: Reviewer and committer request for 7197642
In-Reply-To: <BC25F659-8ADC-46AC-AF8F-FEED253B3944@oracle.com>
References: <BC25F659-8ADC-46AC-AF8F-FEED253B3944@oracle.com>
Message-ID: <5069D452.7080206@oracle.com>

On 01/10/2012 14:14, Paul Sandoz wrote:
> Hi,
>
> See here:
>
>    http://cr.openjdk.java.net/~psandoz/tl/7197642/webrev/
>
> Thanks,
> Paul.
If I have it right, this "moves" the NPE from the ServiceLoader's 
iterator methods to the load* methods where the check should have been. 
It's a subtle behavior change but I think it's okay for a major release.

The test looks good except that it's partying like it's 1999 :-)  I'm 
happy to sponsor this and I can fix up the copyright date before pushing 
the change. I'll leave it until tomorrow to give other a chance to jump 
in if they wish.

-Alan.


From jim.gish at oracle.com  Mon Oct  1 21:22:29 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Mon, 01 Oct 2012 17:22:29 -0400
Subject: RFR: 6206780 (str) Forwarding append methods in String{Buffer,
	Builder} are inconsistent
In-Reply-To: <50685F03.6040706@oracle.com>
References: <50622A25.4050605@oracle.com> <5062D4F8.9040201@oracle.com>
	<506339D1.6050909@oracle.com> <5065E7D4.6000705@oracle.com>
	<5068025A.5010303@oracle.com> <50685F03.6040706@oracle.com>
Message-ID: <506A0995.6030905@oracle.com>

Alan & Chris,

I agree with you that the new approach is less clear than the previous 
approach, but the original approach suffered from code duplication which 
was the motivation for the change.  However, let me propose something 
else.  How about /all /the methods in StringBuffer be synchronized?  
Although this is not strictly necessary, it works because reentrant 
synchronization is allowed. This eliminates the original problem with 
code duplication with the dispatch during the narrowing of types being 
done in both StringBuilder and StringBuffer, and also eliminates the 
confusion about where synchronization is being done and having to test 
for it.

I can still add a test to ensure that all methods of StringBuffer are 
synchronized, but that now becomes far easier - I simply can use 
reflection on each method and test for isSynchronized().  Having to do 
invocation tests to check for blocking or not seems much harder (unless 
you have a trick in your bag that I don't yet know).

Sound reasonable?

Thanks,
    Jim
On 09/30/2012 11:02 AM, Alan Bateman wrote:
> On 30/09/2012 09:27, Chris Hegarty wrote:
>> Jim,
>>
>> I can confirm that the changes in the updated webrev are as per my 
>> comments, and that behavior should be maintained.
>>
>> I have no problem with the changes in ABS and builder, but I'm not so 
>> sure about the changes in buffer. With delegation to the super class 
>> it is not clear where the synchronization is actually happening (at 
>> least not to me).
>>
>> The old direct delegation to other sync'ed methods in its own class 
>> is very understandable. I know, my last comment was to remove the 
>> explicit sycn blocks because they are unnecessary, but now I'm 
>> thinking that the old/original code here is actually more 
>> readable/understandable, with respect to where the synchronization is 
>> happening.
>>
>> Maybe others would have an opinion on this.
>>
>> -Chris.
> I looked through the proposed changes and don't see anything obviously 
> wrong.
>
> I agree with Chris's comment that removing the explicit 
> synchronization from the methods in StringBuffer makes it less clear 
> that the methods actually do synchronize as specified. How about 
> adding a comment to make it clear that the synchronization is achieved 
> by calling into other StringBuffer methods? There was such a comment 
> in insert and lastIndexOf but they have been removed for some reason.
>
> On the tests then it would be really nice if there was a test that 
> verified that each one of the StringBuilder does synchronize as 
> specified. That would give people confidence when doing clean-ups like 
> this one. Also can you check the coverage of the insert methods? Since 
> you changed them too then we need to be sure that they are well tested.
>
> I'm in too minds on the addition of @Override, some people like it, 
> some people don't. With the proposed changes then you've added it to a 
> subset of the methods that are overridden so it's a bit inconsistent.
>
> -Alan.
>
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From martinrb at google.com  Mon Oct  1 21:46:22 2012
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 1 Oct 2012 14:46:22 -0700
Subject: RFR: 6206780 (str) Forwarding append methods in String{Buffer,
	Builder} are inconsistent
In-Reply-To: <506A0995.6030905@oracle.com>
References: <50622A25.4050605@oracle.com> <5062D4F8.9040201@oracle.com>
	<506339D1.6050909@oracle.com> <5065E7D4.6000705@oracle.com>
	<5068025A.5010303@oracle.com> <50685F03.6040706@oracle.com>
	<506A0995.6030905@oracle.com>
Message-ID: <CA+kOe09VmYCPPY3DKhyMP6D_zLypf+qdceEg5BmjuLWGJFF6Sw@mail.gmail.com>

On Mon, Oct 1, 2012 at 2:22 PM, Jim Gish <jim.gish at oracle.com> wrote:

> Alan & Chris,
>
> However, let me propose something else.  How about /all /the methods in
> StringBuffer be synchronized?  Although this is not strictly necessary, it
> works because reentrant synchronization is allowed.


Reentrant lock acquisition is not free.  In core libraries like
StringBuffer we should prefer the lesser evil of code duplication to the
loss of performance.


From paul.sandoz at oracle.com  Tue Oct  2 07:34:12 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 2 Oct 2012 09:34:12 +0200
Subject: Reviewer and committer request for 7197642
In-Reply-To: <5069D452.7080206@oracle.com>
References: <BC25F659-8ADC-46AC-AF8F-FEED253B3944@oracle.com>
	<5069D452.7080206@oracle.com>
Message-ID: <1EA1C0D5-BE0F-4587-B437-67477A4DE5F3@oracle.com>


On Oct 1, 2012, at 7:35 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 01/10/2012 14:14, Paul Sandoz wrote:
>> Hi,
>> 
>> See here:
>> 
>>   http://cr.openjdk.java.net/~psandoz/tl/7197642/webrev/
>> 
>> Thanks,
>> Paul.
> If I have it right, this "moves" the NPE from the ServiceLoader's iterator methods to the load* methods where the check should have been.

Yes, more specifically the first call to Iterator.getNext(), and an somewhat obfuscated NPE would have been thrown.


> It's a subtle behavior change but I think it's okay for a major release.
> 
> The test looks good except that it's partying like it's 1999 :-)

:-)


>  I'm happy to sponsor this and I can fix up the copyright date before pushing the change. I'll leave it until tomorrow to give other a chance to jump in if they wish.
> 

Thanks,
Paul.

From paul.sandoz at oracle.com  Tue Oct  2 08:00:15 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 2 Oct 2012 10:00:15 +0200
Subject: ServiceLoader.load(Class, ClassLoader) bug
In-Reply-To: <5069CC39.5030604@gmail.com>
References: <5051F823.7010803@gmail.com> <5052E8EB.4010304@gmail.com>
	<5F450021-A977-4533-8A78-DECDE3D3285E@oracle.com>
	<5069CC39.5030604@gmail.com>
Message-ID: <671CD7F0-4B73-4E86-8E45-CAB9614739A9@oracle.com>

Hi Peter,

On Oct 1, 2012, at 7:00 PM, Peter Levart <peter.levart at gmail.com> wrote:

> Hi Paul,
> 
> It would be very strange code indeed that acted on the ServiceConfigurationError in a way that you describe. After all, the java.lang.Error hierarchy of throwables is reserved for things that should be "acted upon" only by fixing the code, isn't it?
> 
> This is also explicitly noted in the javadoc of the ServiceLoader:
> 
> "Design Note: Throwing an error in these cases may seem extreme. The rationale for this behaviour is that a malformed provider-configuration file, like a malformed class file, indicates a serious problem with the way the Java virtual machine is configured or is being used. As such it is preferable to throw an error rather than try to recover or, even worse, fail silently."
> 

In some cases one wants to keep on iterating when an SCE is thrown for hasNext/next e.g. perhaps log the error and move on.

In other cases if no service instances are found (in the face of errors or otherwise) there might be a fallback plan to some default behaviour.

Or when trying to convert code to use ServiceLoader that previously used some proprietary mechanism compatible META-INF/services fiies (e.g. like modifying JAXP or JAX-WS to use SL) while retaining the same behaviour.

So it's not always quite so clear cut.


> FWIW, I stumbled on the bug by chance in an application using Jetty servlet engine as an embedded component. The service that was to be loaded was a component of the Spring web application framework which passed  the "Web Context" CL to the ServiceLoader to load a component and that "Web Context" CL returned by embedded Jetty was null (probably because of miss-configuration of Jetty).
> 

Thanks, that's very useful to know.


> If ServiceLoader used System CL to load the class instead, the miss-configuration of Jetty would go unnoticed.
> 
> But that's not the situation that you are concerned about. You are concerned that a (badly written app) might end up loading "different" service implementation even though that might be the one that should be loaded (by the book).
> 

Badly written, weirdly written.

The JavaDoc for Thread. getContextClassLoader() states:

Returns:
the context ClassLoader for this Thread, or null indicating the system class loader (or, failing that, the bootstrap class loader)

Given the JavDoc on TCCL, what you say about Jetty and that JDK 8 is a major release I am inclined to think we can make such a change. I have convinced myself at least :-) i will send a webrev out.

Paul.

From chris.hegarty at oracle.com  Tue Oct  2 08:48:58 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 02 Oct 2012 09:48:58 +0100
Subject: RFR: 6206780 (str) Forwarding append methods in String{Buffer,
	Builder} are inconsistent
In-Reply-To: <CA+kOe09VmYCPPY3DKhyMP6D_zLypf+qdceEg5BmjuLWGJFF6Sw@mail.gmail.com>
References: <50622A25.4050605@oracle.com> <5062D4F8.9040201@oracle.com>
	<506339D1.6050909@oracle.com> <5065E7D4.6000705@oracle.com>
	<5068025A.5010303@oracle.com> <50685F03.6040706@oracle.com>
	<506A0995.6030905@oracle.com>
	<CA+kOe09VmYCPPY3DKhyMP6D_zLypf+qdceEg5BmjuLWGJFF6Sw@mail.gmail.com>
Message-ID: <506AAA7A.6070606@oracle.com>

On 01/10/12 22:46, Martin Buchholz wrote:
> On Mon, Oct 1, 2012 at 2:22 PM, Jim Gish <jim.gish at oracle.com> wrote:
>
>> Alan & Chris,
>>
>> However, let me propose something else.  How about /all /the methods in
>> StringBuffer be synchronized?  Although this is not strictly necessary, it
>> works because reentrant synchronization is allowed.
>
>
> Reentrant lock acquisition is not free.  In core libraries like
> StringBuffer we should prefer the lesser evil of code duplication to the
> loss of performance.

I have to agree with Martin here. There may still be some minor clean up 
that makes sense here, but I believe the existing synchronization and 
delegation is most appropriate.

-Chris.


From Alan.Bateman at oracle.com  Tue Oct  2 09:07:45 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 02 Oct 2012 10:07:45 +0100
Subject: RFR: 6206780 (str) Forwarding append methods in String{Buffer,
	Builder} are inconsistent
In-Reply-To: <506A0995.6030905@oracle.com>
References: <50622A25.4050605@oracle.com> <5062D4F8.9040201@oracle.com>
	<506339D1.6050909@oracle.com> <5065E7D4.6000705@oracle.com>
	<5068025A.5010303@oracle.com> <50685F03.6040706@oracle.com>
	<506A0995.6030905@oracle.com>
Message-ID: <506AAEE1.8080207@oracle.com>

On 01/10/2012 22:22, Jim Gish wrote:
> Alan & Chris,
>
> I agree with you that the new approach is less clear than the previous 
> approach, but the original approach suffered from code duplication 
> which was the motivation for the change.  However, let me propose 
> something else.  How about /all /the methods in StringBuffer be 
> synchronized?  Although this is not strictly necessary, it works 
> because reentrant synchronization is allowed.  This eliminates the 
> original problem with code duplication with the dispatch during the 
> narrowing of types being done in both StringBuilder and StringBuffer, 
> and also eliminates the confusion about where synchronization is being 
> done and having to test for it.
>
> I can still add a test to ensure that all methods of StringBuffer are 
> synchronized, but that now becomes far easier - I simply can use 
> reflection on each method and test for isSynchronized().  Having to do 
> invocation tests to check for blocking or not seems much harder 
> (unless you have a trick in your bag that I don't yet know).
>
> Sound reasonable?
As Martin said, it's not free.

I think a comment (along the lines of the comments that you removed) 
would be sufficient to make it clear where the synchronization is done. 
Alternatively we just close this issue as it's not worth spending a lot 
of time on it.

-Alan.




From alan.bateman at oracle.com  Tue Oct  2 09:14:41 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 02 Oct 2012 09:14:41 +0000
Subject: hg: jdk8/tl/jdk: 7050528: Improve performance of
	java.text.DecimalFormat.format() call stack
Message-ID: <20121002091518.BA1934715D@hg.openjdk.java.net>

Changeset: 75080f572f84
Author:    olagneau
Date:      2012-10-02 10:11 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75080f572f84

7050528: Improve performance of java.text.DecimalFormat.format() call stack
Reviewed-by: darcy

! src/share/classes/java/text/DecimalFormat.java
! src/share/classes/java/text/NumberFormat.java
+ test/java/text/Format/DecimalFormat/FormatMicroBenchmark.java
+ test/java/text/Format/DecimalFormat/GoldenDoubleValues.java
+ test/java/text/Format/DecimalFormat/GoldenFormattedValues.java
+ test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java



From alan.bateman at oracle.com  Tue Oct  2 09:37:28 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 02 Oct 2012 09:37:28 +0000
Subject: hg: jdk8/tl/jdk: 7197642: (sl) ServiceLoader.load(null) doesn't throw
	NPE
Message-ID: <20121002093922.444EE4715E@hg.openjdk.java.net>

Changeset: 041c687c4f40
Author:    psandoz
Date:      2012-10-02 10:36 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/041c687c4f40

7197642: (sl) ServiceLoader.load(null) doesn't throw NPE
Reviewed-by: alanb

! src/share/classes/java/util/ServiceLoader.java
+ test/java/util/ServiceLoader/NPE.java



From alan.bateman at oracle.com  Tue Oct  2 11:24:22 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 02 Oct 2012 11:24:22 +0000
Subject: hg: jdk8/tl/jdk: 8000268:
	sun/security/provider/X509Factory/BigCRL.java failing on Linux 32-bit
Message-ID: <20121002112435.42F3A47162@hg.openjdk.java.net>

Changeset: 6750ab947255
Author:    alanb
Date:      2012-10-02 12:23 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6750ab947255

8000268: sun/security/provider/X509Factory/BigCRL.java failing on Linux 32-bit
Reviewed-by: mullan

! test/sun/security/provider/X509Factory/BigCRL.java



From jim.gish at oracle.com  Tue Oct  2 13:33:48 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Tue, 02 Oct 2012 09:33:48 -0400
Subject: RFR: 6206780 (str) Forwarding append methods in String{Buffer,
	Builder} are inconsistent
In-Reply-To: <506AAEE1.8080207@oracle.com>
References: <50622A25.4050605@oracle.com> <5062D4F8.9040201@oracle.com>
	<506339D1.6050909@oracle.com> <5065E7D4.6000705@oracle.com>
	<5068025A.5010303@oracle.com> <50685F03.6040706@oracle.com>
	<506A0995.6030905@oracle.com> <506AAEE1.8080207@oracle.com>
Message-ID: <506AED3C.7080000@oracle.com>

Ok -- I have some comments prepared, so I'll wrap it up with that. 
However, I am curious about suggested approaches for tests to ensure 
that methods are synchronizing properly ( as I mentioned in my message 
below ).

Thanks,
    Jim

On 10/02/2012 05:07 AM, Alan Bateman wrote:
> On 01/10/2012 22:22, Jim Gish wrote:
>> Alan & Chris,
>>
>> I agree with you that the new approach is less clear than the 
>> previous approach, but the original approach suffered from code 
>> duplication which was the motivation for the change.  However, let me 
>> propose something else.  How about /all /the methods in StringBuffer 
>> be synchronized?  Although this is not strictly necessary, it works 
>> because reentrant synchronization is allowed.  This eliminates the 
>> original problem with code duplication with the dispatch during the 
>> narrowing of types being done in both StringBuilder and StringBuffer, 
>> and also eliminates the confusion about where synchronization is 
>> being done and having to test for it.
>>
>> I can still add a test to ensure that all methods of StringBuffer are 
>> synchronized, but that now becomes far easier - I simply can use 
>> reflection on each method and test for isSynchronized().  Having to 
>> do invocation tests to check for blocking or not seems much harder 
>> (unless you have a trick in your bag that I don't yet know).
>>
>> Sound reasonable?
> As Martin said, it's not free.
>
> I think a comment (along the lines of the comments that you removed) 
> would be sufficient to make it clear where the synchronization is 
> done. Alternatively we just close this issue as it's not worth 
> spending a lot of time on it.
>
> -Alan.
>
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From vitalyd at gmail.com  Tue Oct  2 17:20:38 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 2 Oct 2012 13:20:38 -0400
Subject: RFR: 6206780 (str) Forwarding append methods in String{Buffer,
	Builder} are inconsistent
In-Reply-To: <506AED3C.7080000@oracle.com>
References: <50622A25.4050605@oracle.com> <5062D4F8.9040201@oracle.com>
	<506339D1.6050909@oracle.com> <5065E7D4.6000705@oracle.com>
	<5068025A.5010303@oracle.com> <50685F03.6040706@oracle.com>
	<506A0995.6030905@oracle.com> <506AAEE1.8080207@oracle.com>
	<506AED3C.7080000@oracle.com>
Message-ID: <CAHjP37Ekhyo1dQa92ZYvG_e7zjTATCKGmHKh=fv6ES_rcXvd7g@mail.gmail.com>

Jim, how about an assert with Thread.holdsLock() work for tests?

Sent from my phone
On Oct 2, 2012 9:34 AM, "Jim Gish" <jim.gish at oracle.com> wrote:

> Ok -- I have some comments prepared, so I'll wrap it up with that.
> However, I am curious about suggested approaches for tests to ensure that
> methods are synchronizing properly ( as I mentioned in my message below ).
>
> Thanks,
>    Jim
>
> On 10/02/2012 05:07 AM, Alan Bateman wrote:
>
>> On 01/10/2012 22:22, Jim Gish wrote:
>>
>>> Alan & Chris,
>>>
>>> I agree with you that the new approach is less clear than the previous
>>> approach, but the original approach suffered from code duplication which
>>> was the motivation for the change.  However, let me propose something else.
>>>  How about /all /the methods in StringBuffer be synchronized?  Although
>>> this is not strictly necessary, it works because reentrant synchronization
>>> is allowed.  This eliminates the original problem with code duplication
>>> with the dispatch during the narrowing of types being done in both
>>> StringBuilder and StringBuffer, and also eliminates the confusion about
>>> where synchronization is being done and having to test for it.
>>>
>>> I can still add a test to ensure that all methods of StringBuffer are
>>> synchronized, but that now becomes far easier - I simply can use reflection
>>> on each method and test for isSynchronized().  Having to do invocation
>>> tests to check for blocking or not seems much harder (unless you have a
>>> trick in your bag that I don't yet know).
>>>
>>> Sound reasonable?
>>>
>> As Martin said, it's not free.
>>
>> I think a comment (along the lines of the comments that you removed)
>> would be sufficient to make it clear where the synchronization is done.
>> Alternatively we just close this issue as it's not worth spending a lot of
>> time on it.
>>
>> -Alan.
>>
>>
>>
> --
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.gish at oracle.com
>
>


From Alan.Bateman at oracle.com  Tue Oct  2 17:45:03 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 02 Oct 2012 18:45:03 +0100
Subject: RFR: 6206780 (str) Forwarding append methods in String{Buffer,
	Builder} are inconsistent
In-Reply-To: <CAHjP37Ekhyo1dQa92ZYvG_e7zjTATCKGmHKh=fv6ES_rcXvd7g@mail.gmail.com>
References: <50622A25.4050605@oracle.com> <5062D4F8.9040201@oracle.com>
	<506339D1.6050909@oracle.com> <5065E7D4.6000705@oracle.com>
	<5068025A.5010303@oracle.com> <50685F03.6040706@oracle.com>
	<506A0995.6030905@oracle.com> <506AAEE1.8080207@oracle.com>
	<506AED3C.7080000@oracle.com>
	<CAHjP37Ekhyo1dQa92ZYvG_e7zjTATCKGmHKh=fv6ES_rcXvd7g@mail.gmail.com>
Message-ID: <506B281F.1090005@oracle.com>

On 02/10/2012 18:20, Vitaly Davidovich wrote:
>
> Jim, how about an assert with Thread.holdsLock() work for tests?
>
A concern is that this could disrupt the inlining. In any case, I think 
Jim has figured out how to test this with a blackbox test. If nothing 
else, at least this exercise should expand the tests in the jdk repository.

-Alan.



From dan.xu at oracle.com  Tue Oct  2 22:42:37 2012
From: dan.xu at oracle.com (Dan Xu)
Date: Tue, 02 Oct 2012 15:42:37 -0700
Subject: Review Request for 8000333 - Typo in :
	java.io.ObjectOutputStream.reset() "refered"
Message-ID: <506B6DDD.4070707@oracle.com>

Hi,

This is a simple fix to correct a typo in the java doc.

Please review the change at 
http://cr.openjdk.java.net/~dxu/8000333/webrev/. Thanks!

-Dan


From yuka.kamiya at oracle.com  Wed Oct  3 06:13:12 2012
From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com)
Date: Wed, 03 Oct 2012 06:13:12 +0000
Subject: hg: jdk8/tl/jdk: 7104012: AIOOBE from
	RuleBasedBreakIterator.lookupState for some suppl. chars
Message-ID: <20121003061355.63DA747171@hg.openjdk.java.net>

Changeset: 4744dc70e5d1
Author:    peytoia
Date:      2012-10-03 15:11 +0900
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4744dc70e5d1

7104012: AIOOBE from RuleBasedBreakIterator.lookupState for some suppl. chars
Reviewed-by: okutsu

! src/share/classes/sun/text/SupplementaryCharacterData.java
+ test/java/text/BreakIterator/Bug7104012.java



From david.holmes at oracle.com  Wed Oct  3 07:32:34 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 03 Oct 2012 17:32:34 +1000
Subject: Review Request for 8000333 - Typo in :
	java.io.ObjectOutputStream.reset() "refered"
In-Reply-To: <506B6DDD.4070707@oracle.com>
References: <506B6DDD.4070707@oracle.com>
Message-ID: <506BEA12.6030802@oracle.com>

Looks good.

David

On 3/10/2012 8:42 AM, Dan Xu wrote:
> Hi,
>
> This is a simple fix to correct a typo in the java doc.
>
> Please review the change at
> http://cr.openjdk.java.net/~dxu/8000333/webrev/. Thanks!
>
> -Dan


From Alan.Bateman at oracle.com  Wed Oct  3 07:46:09 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 03 Oct 2012 08:46:09 +0100
Subject: Review Request for 8000333 - Typo in :
	java.io.ObjectOutputStream.reset() "refered"
In-Reply-To: <506B6DDD.4070707@oracle.com>
References: <506B6DDD.4070707@oracle.com>
Message-ID: <506BED41.1000505@oracle.com>

On 02/10/2012 23:42, Dan Xu wrote:
> Hi,
>
> This is a simple fix to correct a typo in the java doc.
>
> Please review the change at 
> http://cr.openjdk.java.net/~dxu/8000333/webrev/. Thanks!
>
> -Dan
This looks good but note that the bug number is 6910472.

-Alan


From alan.bateman at oracle.com  Wed Oct  3 08:03:55 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 03 Oct 2012 08:03:55 +0000
Subject: hg: jdk8/tl/jdk: 6910472: Typo in :
	java.io.ObjectOutputStream.reset() "refered"
Message-ID: <20121003080418.3979A47174@hg.openjdk.java.net>

Changeset: 7fe88d457d85
Author:    dxu
Date:      2012-10-03 09:03 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fe88d457d85

6910472: Typo in : java.io.ObjectOutputStream.reset() "refered"
Reviewed-by: dholmes, alanb

! src/share/classes/java/io/ObjectOutputStream.java



From paul.sandoz at oracle.com  Wed Oct  3 11:03:21 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 3 Oct 2012 13:03:21 +0200
Subject: Reviewer and committer request for 7198496
Message-ID: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>

Hi,

See here:

  http://cr.openjdk.java.net/~psandoz/tl/7198496/webrev/

Thanks,
Paul.


From peter.levart at gmail.com  Wed Oct  3 12:41:44 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 03 Oct 2012 14:41:44 +0200
Subject: Reviewer and committer request for 7198496
In-Reply-To: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
Message-ID: <506C3288.6040907@gmail.com>

I think that in the LazyIterator.hasNext() you still have to check for 
null loader:

  337                     if (loader == null)
  338                         configs = ClassLoader.getSystemResources(fullName);
  339                     else
  340                         configs = loader.getResources(fullName);


Because the ClassLoader.getSystemClassLoader() can return null. In that 
case, ClassLoader.getSystemResources() delegates just to 
.getBootstrapResources() which is in sync with later:


  359                 S p = service.cast(Class.forName(cn, true, loader)
  360                                    .newInstance());


when loader is null - i.e. it loads just bootstrap classes.


Regards, Peter

  On 10/03/2012 01:03 PM, Paul Sandoz wrote:
> Hi,
>
> See here:
>
>    http://cr.openjdk.java.net/~psandoz/tl/7198496/webrev/
>
> Thanks,
> Paul.



From paul.sandoz at oracle.com  Wed Oct  3 12:50:54 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 3 Oct 2012 14:50:54 +0200
Subject: Reviewer and committer request for 7198496
In-Reply-To: <506C3288.6040907@gmail.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
Message-ID: <F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>


On Oct 3, 2012, at 2:41 PM, Peter Levart <peter.levart at gmail.com> wrote:

> I think that in the LazyIterator.hasNext() you still have to check for null loader:
> 
> 337                     if (loader == null)
> 338                         configs = ClassLoader.getSystemResources(fullName);
> 339                     else
> 340                         configs = loader.getResources(fullName);
> 
> 
> Because the ClassLoader.getSystemClassLoader() can return null. In that case, ClassLoader.getSystemResources() delegates just to .getBootstrapResources() which is in sync with later:
> 
> 
> 359                 S p = service.cast(Class.forName(cn, true, loader)
> 360                                    .newInstance());
> 
> 
> when loader is null - i.e. it loads just bootstrap classes.
> 

Yes, thanks, i just caught that silly mistake just before i received your email :-) , the webrev is updated.

--

For the benefit of others; for some context see this recent thread:

http://markmail.org/search/?q=openjdk#query:openjdk%20list%3Anet.java.openjdk.core-libs-dev%20order%3Adate-backward+page:2+mid:inod424lqbey5fms+state:results

Basically ServiceLoader is treating a null CL parameter as the system CL for loading the META-INF/services resources file and as the bootstrap CL for loading the classes of class names declared in those resource files.

Which also means that calls to:

  ServiceLoader.load(serviceInterface)
  ServiceLoader.load(serviceInterface, Thread.currentThread().getContextClassLoader());

Will behave oddly if the TCCL is null, from the JavaDoc of Thread.getContextClassLoader():

  http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#getContextClassLoader()
  Returns:
  the context ClassLoader for this Thread, or null indicating the system class loader (or, failing that, the bootstrap class loader)

Paul.

From david.holmes at oracle.com  Wed Oct  3 13:17:40 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 03 Oct 2012 23:17:40 +1000
Subject: Reviewer and committer request for 7198496
In-Reply-To: <F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
Message-ID: <506C3AF4.2010007@oracle.com>

Paul,

On 3/10/2012 10:50 PM, Paul Sandoz wrote:
> For the benefit of others; for some context see this recent thread:
>
> http://markmail.org/search/?q=openjdk#query:openjdk%20list%3Anet.java.openjdk.core-libs-dev%20order%3Adate-backward+page:2+mid:inod424lqbey5fms+state:results
>
> Basically ServiceLoader is treating a null CL parameter as the system CL for loading the META-INF/services resources file and as the bootstrap CL for loading the classes of class names declared in those resource files.
>
> Which also means that calls to:
>
>    ServiceLoader.load(serviceInterface)
>    ServiceLoader.load(serviceInterface, Thread.currentThread().getContextClassLoader());
>
> Will behave oddly if the TCCL is null, from the JavaDoc of Thread.getContextClassLoader():
>
>    http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#getContextClassLoader()
>    Returns:
>    the context ClassLoader for this Thread, or null indicating the system class loader (or, failing that, the bootstrap class loader)

The @return doc for getContextClassLoader is wrong, or at best 
mis-leading. A null return does NOT indicate the system class loader 
(which is never null) - it simply means there is no CCL for that thread. 
If anything null would represent the bootstrap loader.

David
-----

> Paul.


From paul.sandoz at oracle.com  Wed Oct  3 13:37:23 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 3 Oct 2012 15:37:23 +0200
Subject: Reviewer and committer request for 7198496
In-Reply-To: <506C3AF4.2010007@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
Message-ID: <37A14496-560E-4D60-938C-C30974293660@oracle.com>


On Oct 3, 2012, at 3:17 PM, David Holmes <david.holmes at oracle.com> wrote:

> Paul,
> 
> On 3/10/2012 10:50 PM, Paul Sandoz wrote:
>> For the benefit of others; for some context see this recent thread:
>> 
>> http://markmail.org/search/?q=openjdk#query:openjdk%20list%3Anet.java.openjdk.core-libs-dev%20order%3Adate-backward+page:2+mid:inod424lqbey5fms+state:results
>> 
>> Basically ServiceLoader is treating a null CL parameter as the system CL for loading the META-INF/services resources file and as the bootstrap CL for loading the classes of class names declared in those resource files.
>> 
>> Which also means that calls to:
>> 
>>   ServiceLoader.load(serviceInterface)
>>   ServiceLoader.load(serviceInterface, Thread.currentThread().getContextClassLoader());
>> 
>> Will behave oddly if the TCCL is null, from the JavaDoc of Thread.getContextClassLoader():
>> 
>>   http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#getContextClassLoader()
>>   Returns:
>>   the context ClassLoader for this Thread, or null indicating the system class loader (or, failing that, the bootstrap class loader)
> 
> The @return doc for getContextClassLoader is wrong, or at best mis-leading. A null return does NOT indicate the system class loader (which is never null) - it simply means there is no CCL for that thread. If anything null would represent the bootstrap loader.

> 

In the JDK i see code such as:

                Class c = Class.forName(className, true,Thread.currentThread().
                                        getContextClassLoader());

and:

        ClassLoader contextClassLoader =
            Thread.currentThread().getContextClassLoader();
        if (contextClassLoader == null) {
            contextClassLoader = ClassLoader.getSystemClassLoader();
        }

The only way i can interpret that TCCL JavaDoc sanely is to assume "null" is overloaded to mean the caller should try to use system or bootstrap CL if possible, otherwise failing that the bootstrap CL.

Paul.

From martinrb at google.com  Wed Oct  3 14:40:31 2012
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 3 Oct 2012 07:40:31 -0700
Subject: Reviewer and committer request for 7198496
In-Reply-To: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
Message-ID: <CA+kOe096S3hYmVWqC_Lwex5hQakf+0rroc8RjSmoM86URyGB0Q@mail.gmail.com>

On Wed, Oct 3, 2012 at 4:03 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> See here:
>
>   http://cr.openjdk.java.net/~psandoz/tl/7198496/webrev/


It's hard to tell from your message what you're trying to change or why.
There is a link to the bug in your webrev, but it points to monaco.sfbay,
which your reviewers might not be able to access.

Martin


From Ulf.Zibis at CoSoCo.de  Wed Oct  3 15:18:29 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Wed, 03 Oct 2012 17:18:29 +0200
Subject: Reviewer and committer request for 7198496
In-Reply-To: <CA+kOe096S3hYmVWqC_Lwex5hQakf+0rroc8RjSmoM86URyGB0Q@mail.gmail.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<CA+kOe096S3hYmVWqC_Lwex5hQakf+0rroc8RjSmoM86URyGB0Q@mail.gmail.com>
Message-ID: <506C5745.2070300@CoSoCo.de>

Am 03.10.2012 16:40, schrieb Martin Buchholz:
> On Wed, Oct 3, 2012 at 4:03 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>> Hi,
>>
>> See here:
>>
>>    http://cr.openjdk.java.net/~psandoz/tl/7198496/webrev/
>
> It's hard to tell from your message what you're trying to change or why.
> There is a link to the bug in your webrev, but it points to monaco.sfbay,
> which your reviewers might not be able to access.
>
> Martin

Additionally please add the summary of the bug to the subject line.
Otherwise, how could people have overview in the mailing-list?
Instead "Reviewer and committer request for" you could just write "RFR".

My 2 cents,

-Ulf


OT: Personnel greetings to Martin.




From Alan.Bateman at oracle.com  Wed Oct  3 16:29:32 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 03 Oct 2012 17:29:32 +0100
Subject: Reviewer and committer request for 7198496
In-Reply-To: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
Message-ID: <506C67EC.2030407@oracle.com>

On 03/10/2012 12:03, Paul Sandoz wrote:
> Hi,
>
> See here:
>
>    http://cr.openjdk.java.net/~psandoz/tl/7198496/webrev/
>
> Thanks,
> Paul.
I searched through the JDK sources and I don't see anywhere obvious that 
uses null. In JDI there are two cases where the loader is specified to 
be the defining loader of the service type and those cases would end up 
using null if used with exploded classes on the file system (dev 
environment without images so no tools.jar where JDI normally lives). So 
I'm inclined to thing this is mostly harmless.

-Alan


From rob.mckenna at oracle.com  Wed Oct  3 21:44:35 2012
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 3 Oct 2012 14:44:35 -0700 (PDT)
Subject: RFR: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing
	intermittently [sol]
Message-ID: <506CB1C3.5050009@oracle.com>

Hi folks,

The only way I can see this test failing in this manner[*] is if we 
destroy the process before we begin the read. That being the case I've 
jacked up the sleep (giving the reader thread a little more time to get 
cracking) and added a check to see if the threads stack has entered a 
read call.

http://cr.openjdk.java.net/~robm/7152183/webrev.01/ 
<http://cr.openjdk.java.net/%7Erobm/7152183/webrev.01/>

Feedback greatly appreciated.

     -Rob


[*] le trace:

java.io.IOException: Stream Closed
at java.io.FileInputStream.read(Native Method)
at java.lang.UNIXProcess$DeferredCloseInputStream.read(UNIXProcess.java:253)
at Basic$64.run(Basic.java:1908)
java.lang.AssertionError: Some tests failed
at Basic.main(Basic.java:2248)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:474)
at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
at java.lang.Thread.run(Thread.java:722)

for 
http://hg.openjdk.java.net/jdk8/tl/jdk/file/d45bc4307996/test/java/lang/ProcessBuilder/Basic.java

(current version differs in line number)


From david.holmes at oracle.com  Wed Oct  3 22:33:06 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 04 Oct 2012 08:33:06 +1000
Subject: Reviewer and committer request for 7198496
In-Reply-To: <37A14496-560E-4D60-938C-C30974293660@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
Message-ID: <506CBD22.7090107@oracle.com>

On 3/10/2012 11:37 PM, Paul Sandoz wrote:
> On Oct 3, 2012, at 3:17 PM, David Holmes<david.holmes at oracle.com>  wrote:
>> On 3/10/2012 10:50 PM, Paul Sandoz wrote:
>>> For the benefit of others; for some context see this recent thread:
>>>
>>> http://markmail.org/search/?q=openjdk#query:openjdk%20list%3Anet.java.openjdk.core-libs-dev%20order%3Adate-backward+page:2+mid:inod424lqbey5fms+state:results
>>>
>>> Basically ServiceLoader is treating a null CL parameter as the system CL for loading the META-INF/services resources file and as the bootstrap CL for loading the classes of class names declared in those resource files.
>>>
>>> Which also means that calls to:
>>>
>>>    ServiceLoader.load(serviceInterface)
>>>    ServiceLoader.load(serviceInterface, Thread.currentThread().getContextClassLoader());
>>>
>>> Will behave oddly if the TCCL is null, from the JavaDoc of Thread.getContextClassLoader():
>>>
>>>    http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#getContextClassLoader()
>>>    Returns:
>>>    the context ClassLoader for this Thread, or null indicating the system class loader (or, failing that, the bootstrap class loader)
>>
>> The @return doc for getContextClassLoader is wrong, or at best mis-leading. A null return does NOT indicate the system class loader (which is never null) - it simply means there is no CCL for that thread. If anything null would represent the bootstrap loader.
>
>>
>
> In the JDK i see code such as:
>
>                  Class c = Class.forName(className, true,Thread.currentThread().
>                                          getContextClassLoader());
>
> and:
>
>          ClassLoader contextClassLoader =
>              Thread.currentThread().getContextClassLoader();
>          if (contextClassLoader == null) {
>              contextClassLoader = ClassLoader.getSystemClassLoader();
>          }
>
> The only way i can interpret that TCCL JavaDoc sanely is to assume "null" is overloaded to mean the caller should try to use system or bootstrap CL if possible, otherwise failing that the bootstrap CL.

The TCCL doc for @return is simply confusing. The method will return the 
TCCL or it will return null. If it returns null it means the Thread has 
no CCL set. So what does a caller then do? They have a few choices:
a) use their own ClassLoader
b) use the system ClassLoader
c) use the the bootstrap loader

Your first example chooses (c) because the null arg to forName will 
indicate to use the bootstrap loader. Your second example chooses (b). 
This is not an arbitrary choice as it depends on the API - the three arg 
version of forName treats null as the bootstrap loader, but if you 
simply did getContextClassLoader().loadClass(...) then you would get NPE.

The point is that returning null in itself has no direct significance. 
The issue here is how ServiceLoader should attempt to load something if 
there is no CCL set for the thread.

David

> Paul.


From yuka.kamiya at oracle.com  Thu Oct  4 02:38:08 2012
From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com)
Date: Thu, 04 Oct 2012 02:38:08 +0000
Subject: hg: jdk8/tl/jdk: 7196316: Wrong rounding mode in DecimalFormat after
	deserialization
Message-ID: <20121004023839.5A4B147194@hg.openjdk.java.net>

Changeset: 123db1c28d92
Author:    peytoia
Date:      2012-10-04 11:36 +0900
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/123db1c28d92

7196316: Wrong rounding mode in DecimalFormat after deserialization
Reviewed-by: okutsu

! src/share/classes/java/text/DecimalFormat.java
+ test/java/text/Format/DecimalFormat/Bug7196316.java



From Alan.Bateman at oracle.com  Thu Oct  4 07:39:00 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 04 Oct 2012 08:39:00 +0100
Subject: RFR: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java
	failing intermittently [sol]
In-Reply-To: <506CB1C3.5050009@oracle.com>
References: <506CB1C3.5050009@oracle.com>
Message-ID: <506D3D14.4070304@oracle.com>

On 03/10/2012 22:44, Rob McKenna wrote:
> Hi folks,
>
> The only way I can see this test failing in this manner[*] is if we 
> destroy the process before we begin the read. That being the case I've 
> jacked up the sleep (giving the reader thread a little more time to 
> get cracking) and added a check to see if the threads stack has 
> entered a read call.
>
> http://cr.openjdk.java.net/~robm/7152183/webrev.01/ 
> <http://cr.openjdk.java.net/%7Erobm/7152183/webrev.01/>
>
> Feedback greatly appreciated.
>
>     -Rob
>
>
> [*] le trace:
>
So stack traces are masculine, I didn't know that.

I think your analysis is right, it's just that the sleep(10) is not 
sufficient to ensure that the thread gets to the read method. Increasing 
the sleep is probably sufficient. The hack to look at the stack trace 
makes it more robust for really extreme cases, at the cost of potential 
further maintenance in the event that the implementation changes. In any 
case it's good to resolve this intermittent test failure.

-Alan


From paul.sandoz at oracle.com  Thu Oct  4 07:43:30 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 4 Oct 2012 09:43:30 +0200
Subject: Reviewer and committer request for 7198496
In-Reply-To: <506CBD22.7090107@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
Message-ID: <639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>


On Oct 4, 2012, at 12:33 AM, David Holmes <david.holmes at oracle.com> wrote:

> On 3/10/2012 11:37 PM, Paul Sandoz wrote:
>> On Oct 3, 2012, at 3:17 PM, David Holmes<david.holmes at oracle.com>  wrote:
>>> On 3/10/2012 10:50 PM, Paul Sandoz wrote:
>>>> For the benefit of others; for some context see this recent thread:
>>>> 
>>>> http://markmail.org/search/?q=openjdk#query:openjdk%20list%3Anet.java.openjdk.core-libs-dev%20order%3Adate-backward+page:2+mid:inod424lqbey5fms+state:results
>>>> 
>>>> Basically ServiceLoader is treating a null CL parameter as the system CL for loading the META-INF/services resources file and as the bootstrap CL for loading the classes of class names declared in those resource files.
>>>> 
>>>> Which also means that calls to:
>>>> 
>>>>   ServiceLoader.load(serviceInterface)
>>>>   ServiceLoader.load(serviceInterface, Thread.currentThread().getContextClassLoader());
>>>> 
>>>> Will behave oddly if the TCCL is null, from the JavaDoc of Thread.getContextClassLoader():
>>>> 
>>>>   http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#getContextClassLoader()
>>>>   Returns:
>>>>   the context ClassLoader for this Thread, or null indicating the system class loader (or, failing that, the bootstrap class loader)
>>> 
>>> The @return doc for getContextClassLoader is wrong, or at best mis-leading. A null return does NOT indicate the system class loader (which is never null) - it simply means there is no CCL for that thread. If anything null would represent the bootstrap loader.
>> 
>>> 
>> 
>> In the JDK i see code such as:
>> 
>>                 Class c = Class.forName(className, true,Thread.currentThread().
>>                                         getContextClassLoader());
>> 
>> and:
>> 
>>         ClassLoader contextClassLoader =
>>             Thread.currentThread().getContextClassLoader();
>>         if (contextClassLoader == null) {
>>             contextClassLoader = ClassLoader.getSystemClassLoader();
>>         }
>> 
>> The only way i can interpret that TCCL JavaDoc sanely is to assume "null" is overloaded to mean the caller should try to use system or bootstrap CL if possible, otherwise failing that the bootstrap CL.
> 
> The TCCL doc for @return is simply confusing.

> The method will return the TCCL or it will return null. If it returns null it means the Thread has no CCL set. So what does a caller then do? They have a few choices:
> a) use their own ClassLoader
> b) use the system ClassLoader
> c) use the the bootstrap loader
> 
> Your first example chooses (c) because the null arg to forName will indicate to use the bootstrap loader. Your second example chooses (b). This is not an arbitrary choice as it depends on the API - the three arg version of forName treats null as the bootstrap loader, but if you simply did getContextClassLoader().loadClass(...) then you would get NPE.
> 

> The point is that returning null in itself has no direct significance.

I am not sure i agree. The TCCL can be set to null and that has significance as per the JavaDoc:

     * @param  cl
     *         the context ClassLoader for this Thread, or null  indicating the
     *         system class loader (or, failing that, the bootstrap class loader)
     *
     * @throws  SecurityException
     *          if the current thread cannot set the context ClassLoader
     *
     * @since 1.2
     */
    public void setContextClassLoader(ClassLoader cl) {

Paul.

> The issue here is how ServiceLoader should attempt to load something if there is no CCL set for the thread.
> 


From paul.sandoz at oracle.com  Thu Oct  4 07:44:51 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 4 Oct 2012 09:44:51 +0200
Subject: Reviewer and committer request for 7198496
In-Reply-To: <506C67EC.2030407@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C67EC.2030407@oracle.com>
Message-ID: <3E5B63FC-566C-44EC-9703-9236C25A1D87@oracle.com>


On Oct 3, 2012, at 6:29 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 03/10/2012 12:03, Paul Sandoz wrote:
>> Hi,
>> 
>> See here:
>> 
>>   http://cr.openjdk.java.net/~psandoz/tl/7198496/webrev/
>> 
>> Thanks,
>> Paul.
> I searched through the JDK sources and I don't see anywhere obvious that uses null.

Same here. I also kicked off JPRT run and there were no failures.

Paul.

> In JDI there are two cases where the loader is specified to be the defining loader of the service type and those cases would end up using null if used with exploded classes on the file system (dev environment without images so no tools.jar where JDI normally lives). So I'm inclined to thing this is mostly harmless.
> 
> -Alan



From david.holmes at oracle.com  Thu Oct  4 08:14:54 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 04 Oct 2012 18:14:54 +1000
Subject: Reviewer and committer request for 7198496
In-Reply-To: <639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
Message-ID: <506D457E.8030309@oracle.com>

On 4/10/2012 5:43 PM, Paul Sandoz wrote:
>
> On Oct 4, 2012, at 12:33 AM, David Holmes<david.holmes at oracle.com>  wrote:
>
>> On 3/10/2012 11:37 PM, Paul Sandoz wrote:
>>> On Oct 3, 2012, at 3:17 PM, David Holmes<david.holmes at oracle.com>   wrote:
>>>> On 3/10/2012 10:50 PM, Paul Sandoz wrote:
>>>>> For the benefit of others; for some context see this recent thread:
>>>>>
>>>>> http://markmail.org/search/?q=openjdk#query:openjdk%20list%3Anet.java.openjdk.core-libs-dev%20order%3Adate-backward+page:2+mid:inod424lqbey5fms+state:results
>>>>>
>>>>> Basically ServiceLoader is treating a null CL parameter as the system CL for loading the META-INF/services resources file and as the bootstrap CL for loading the classes of class names declared in those resource files.
>>>>>
>>>>> Which also means that calls to:
>>>>>
>>>>>    ServiceLoader.load(serviceInterface)
>>>>>    ServiceLoader.load(serviceInterface, Thread.currentThread().getContextClassLoader());
>>>>>
>>>>> Will behave oddly if the TCCL is null, from the JavaDoc of Thread.getContextClassLoader():
>>>>>
>>>>>    http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#getContextClassLoader()
>>>>>    Returns:
>>>>>    the context ClassLoader for this Thread, or null indicating the system class loader (or, failing that, the bootstrap class loader)
>>>>
>>>> The @return doc for getContextClassLoader is wrong, or at best mis-leading. A null return does NOT indicate the system class loader (which is never null) - it simply means there is no CCL for that thread. If anything null would represent the bootstrap loader.
>>>
>>>>
>>>
>>> In the JDK i see code such as:
>>>
>>>                  Class c = Class.forName(className, true,Thread.currentThread().
>>>                                          getContextClassLoader());
>>>
>>> and:
>>>
>>>          ClassLoader contextClassLoader =
>>>              Thread.currentThread().getContextClassLoader();
>>>          if (contextClassLoader == null) {
>>>              contextClassLoader = ClassLoader.getSystemClassLoader();
>>>          }
>>>
>>> The only way i can interpret that TCCL JavaDoc sanely is to assume "null" is overloaded to mean the caller should try to use system or bootstrap CL if possible, otherwise failing that the bootstrap CL.
>>
>> The TCCL doc for @return is simply confusing.
>
>> The method will return the TCCL or it will return null. If it returns null it means the Thread has no CCL set. So what does a caller then do? They have a few choices:
>> a) use their own ClassLoader
>> b) use the system ClassLoader
>> c) use the the bootstrap loader
>>
>> Your first example chooses (c) because the null arg to forName will indicate to use the bootstrap loader. Your second example chooses (b). This is not an arbitrary choice as it depends on the API - the three arg version of forName treats null as the bootstrap loader, but if you simply did getContextClassLoader().loadClass(...) then you would get NPE.
>>
>
>> The point is that returning null in itself has no direct significance.
>
> I am not sure i agree. The TCCL can be set to null and that has significance as per the JavaDoc:
>
>       * @param  cl
>       *         the context ClassLoader for this Thread, or null  indicating the
>       *         system class loader (or, failing that, the bootstrap class loader)
>       *
>       * @throws  SecurityException
>       *          if the current thread cannot set the context ClassLoader
>       *
>       * @since 1.2
>       */
>      public void setContextClassLoader(ClassLoader cl) {

Sorry but that is just the dual incorrect statement of what is in 
getContextClassLoader. It is not a meaningful description, in fact it is 
incorrect because null only ever means the bootstrap loader, never the 
system class loader - and the null can't mean two different things. And 
what is "or failing that" supposed to mean?

These parts of the javadoc for get/setContextClassLoader are simply wrong.

David
-----

> Paul.
>
>> The issue here is how ServiceLoader should attempt to load something if there is no CCL set for the thread.
>>


From chris.hegarty at oracle.com  Thu Oct  4 08:44:54 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 04 Oct 2012 09:44:54 +0100
Subject: Reviewer and committer request for 7198496
In-Reply-To: <506D457E.8030309@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com>
Message-ID: <506D4C86.8020503@oracle.com>

On 04/10/12 09:14, David Holmes wrote:
> ...
>>> The point is that returning null in itself has no direct significance.
>>
>> I am not sure i agree. The TCCL can be set to null and that has
>> significance as per the JavaDoc:
>>
>>       * @param  cl
>>       *         the context ClassLoader for this Thread, or null
>> indicating the
>>       *         system class loader (or, failing that, the bootstrap
>> class loader)
>>       *
>>       * @throws  SecurityException
>>       *          if the current thread cannot set the context ClassLoader
>>       *
>>       * @since 1.2
>>       */
>>      public void setContextClassLoader(ClassLoader cl) {
>
> Sorry but that is just the dual incorrect statement of what is in
> getContextClassLoader. It is not a meaningful description, in fact it is
> incorrect because null only ever means the bootstrap loader, never the
> system class loader - and the null can't mean two different things. And
> what is "or failing that" supposed to mean?
>
> These parts of the javadoc for get/setContextClassLoader are simply wrong.

They should be non-normative statements in the method description to 
give general guidance as to the interpretation of null.

I can file a new bug for this.

-Chris.

>
> David
> -----
>
>> Paul.
>>
>>> The issue here is how ServiceLoader should attempt to load something
>>> if there is no CCL set for the thread.
>>>


From paul.sandoz at oracle.com  Thu Oct  4 08:52:52 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 4 Oct 2012 10:52:52 +0200
Subject: Reviewer and committer request for 7198496
In-Reply-To: <506D457E.8030309@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com>
Message-ID: <3AC99BDE-5EC9-4F18-B1E6-64FF5C6093FB@oracle.com>

On Oct 4, 2012, at 10:14 AM, David Holmes <david.holmes at oracle.com> wrote:
>> I am not sure i agree. The TCCL can be set to null and that has significance as per the JavaDoc:
>> 
>>      * @param  cl
>>      *         the context ClassLoader for this Thread, or null  indicating the
>>      *         system class loader (or, failing that, the bootstrap class loader)
>>      *
>>      * @throws  SecurityException
>>      *          if the current thread cannot set the context ClassLoader
>>      *
>>      * @since 1.2
>>      */
>>     public void setContextClassLoader(ClassLoader cl) {
> 
> Sorry but that is just the dual incorrect statement of what is in getContextClassLoader. It is not a meaningful description, in fact it is incorrect because null only ever means the bootstrap loader, never the system class loader - and the null can't mean two different things.

> And what is "or failing that" supposed to mean?
> 

I presume it means if the system CL is null.

I would interpret the JavaDoc as follows: if I set the TCCL to null on a thread i would expect any consumer of the TCCL for that thread to first use the system CL. Which matches the behaviour of how SL is documented.


> These parts of the javadoc for get/setContextClassLoader are simply wrong.
> 

Wrong or not because of such JavaDoc developers have been coding using TCCL with certain expectations of "null" different to that of just meaning the bootstrap CL.

How would you propose to fix it?

Did i tell you i really dislike TCCL :-)

Paul.
 

From yuka.kamiya at oracle.com  Thu Oct  4 09:07:35 2012
From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com)
Date: Thu, 04 Oct 2012 09:07:35 +0000
Subject: hg: jdk8/tl/jdk: 7201151: Fix Contribution : Java cannot get
	Windows's IME name correctly
Message-ID: <20121004090757.E256947199@hg.openjdk.java.net>

Changeset: 8692e14b8ea8
Author:    peytoia
Date:      2012-10-04 18:05 +0900
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8692e14b8ea8

7201151: Fix Contribution : Java cannot get Windows's IME name correctly
Reviewed-by: okutsu

! src/windows/native/sun/windows/awt_InputMethod.cpp



From paul.sandoz at oracle.com  Thu Oct  4 09:19:35 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 4 Oct 2012 11:19:35 +0200
Subject: Reviewer and committer request for 7198496
In-Reply-To: <506D4C86.8020503@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com> <506D4C86.8020503@oracle.com>
Message-ID: <3ED43C1E-38D5-4D92-AEFA-ACBE78FFFD58@oracle.com>

On Oct 4, 2012, at 10:44 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> Sorry but that is just the dual incorrect statement of what is in
>> getContextClassLoader. It is not a meaningful description, in fact it is
>> incorrect because null only ever means the bootstrap loader, never the
>> system class loader - and the null can't mean two different things. And
>> what is "or failing that" supposed to mean?
>> 
>> These parts of the javadoc for get/setContextClassLoader are simply wrong.
> 
> They should be non-normative statements in the method description to give general guidance as to the interpretation of null.
> 

If i had 10 service providers, for service interface MyIterface, in jars added on my class path and i had application code that did the following:

  public static void main(String... args) throws Exception {
    Thread.currentThread().setContextClassLoader(null);
    int i = 0;
    for (MyIterface mi : ServiceLoader.load(MyIterface.class)) {
      i++;
    }
    System.out.println(i);
  }
  
What do you think should be the result of executing the above?

Paul.

From david.holmes at oracle.com  Thu Oct  4 09:34:55 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 04 Oct 2012 19:34:55 +1000
Subject: Reviewer and committer request for 7198496
In-Reply-To: <3AC99BDE-5EC9-4F18-B1E6-64FF5C6093FB@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com>
	<3AC99BDE-5EC9-4F18-B1E6-64FF5C6093FB@oracle.com>
Message-ID: <506D583F.2010808@oracle.com>

On 4/10/2012 6:52 PM, Paul Sandoz wrote:
> On Oct 4, 2012, at 10:14 AM, David Holmes<david.holmes at oracle.com>  wrote:
>>> I am not sure i agree. The TCCL can be set to null and that has significance as per the JavaDoc:
>>>
>>>       * @param  cl
>>>       *         the context ClassLoader for this Thread, or null  indicating the
>>>       *         system class loader (or, failing that, the bootstrap class loader)
>>>       *
>>>       * @throws  SecurityException
>>>       *          if the current thread cannot set the context ClassLoader
>>>       *
>>>       * @since 1.2
>>>       */
>>>      public void setContextClassLoader(ClassLoader cl) {
>>
>> Sorry but that is just the dual incorrect statement of what is in getContextClassLoader. It is not a meaningful description, in fact it is incorrect because null only ever means the bootstrap loader, never the system class loader - and the null can't mean two different things.
>
>> And what is "or failing that" supposed to mean?
>>
>
> I presume it means if the system CL is null.
>
> I would interpret the JavaDoc as follows: if I set the TCCL to null on a thread i would expect any consumer of the TCCL for that thread to first use the system CL. Which matches the behaviour of how SL is documented.
>
>
>> These parts of the javadoc for get/setContextClassLoader are simply wrong.
>>
>
> Wrong or not because of such JavaDoc developers have been coding using TCCL with certain expectations of "null" different to that of just meaning the bootstrap CL.
>
> How would you propose to fix it?

I don't see anything that actually needs fixing (apart from the 
javadoc). Anyone using getCCL has to expect null as a possibility and 
they are then free to proceed however they like. The obvious ways to 
proceed are as I outlined earlier:
- use current classloader
- use system loader
- use bootstrap loader

which is appropriate depends on the code that was using getCCL. Often 
the current loader will be either the system or bootloader so that 
narrows the options.

> Did i tell you i really dislike TCCL :-)

:) It was a necessary evil to handle dynamic loading from extensions.

Cheers,
David

> Paul.
>


From david.holmes at oracle.com  Thu Oct  4 09:44:11 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 04 Oct 2012 19:44:11 +1000
Subject: Reviewer and committer request for 7198496
In-Reply-To: <3ED43C1E-38D5-4D92-AEFA-ACBE78FFFD58@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com> <506D4C86.8020503@oracle.com>
	<3ED43C1E-38D5-4D92-AEFA-ACBE78FFFD58@oracle.com>
Message-ID: <506D5A6B.1070901@oracle.com>

On 4/10/2012 7:19 PM, Paul Sandoz wrote:
> On Oct 4, 2012, at 10:44 AM, Chris Hegarty<chris.hegarty at oracle.com>  wrote:
>>>
>>> Sorry but that is just the dual incorrect statement of what is in
>>> getContextClassLoader. It is not a meaningful description, in fact it is
>>> incorrect because null only ever means the bootstrap loader, never the
>>> system class loader - and the null can't mean two different things. And
>>> what is "or failing that" supposed to mean?
>>>
>>> These parts of the javadoc for get/setContextClassLoader are simply wrong.
>>
>> They should be non-normative statements in the method description to give general guidance as to the interpretation of null.
>>
>
> If i had 10 service providers, for service interface MyIterface, in jars added on my class path and i had application code that did the following:
>
>    public static void main(String... args) throws Exception {
>      Thread.currentThread().setContextClassLoader(null);
>      int i = 0;
>      for (MyIterface mi : ServiceLoader.load(MyIterface.class)) {
>        i++;
>      }
>      System.out.println(i);
>    }
>
> What do you think should be the result of executing the above?

Is this just a thought experiment? I would expect whatever 
ServiceLoader.load said would happen. Now if I were inventing 
ServiceLoader.load then I might specify it to do the following:
a) use the Thread CCL; or if that is null then;
b) use the caller classloader

With correctly delegating loaders this could implicitly cover the system 
loader and bootstrap loader. If I were somewhat conservative I might 
explicitly use the system loader if (a) and/or (b) fail, but then you 
are trying to second-guess an unknown classloading strategy so it may 
not be worth trying too many variations here.

So in my implementation all those interfaces would be loaded from their 
jars on the classpath.

David
-----


From paul.sandoz at oracle.com  Thu Oct  4 09:53:17 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 4 Oct 2012 11:53:17 +0200
Subject: Reviewer and committer request for 7198496
In-Reply-To: <506D583F.2010808@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com>
	<3AC99BDE-5EC9-4F18-B1E6-64FF5C6093FB@oracle.com>
	<506D583F.2010808@oracle.com>
Message-ID: <6C8D595A-765D-4555-BD63-C244D1B043E8@oracle.com>

On Oct 4, 2012, at 11:34 AM, David Holmes <david.holmes at oracle.com> wrote:
>> 
>>> These parts of the javadoc for get/setContextClassLoader are simply wrong.
>>> 
>> 
>> Wrong or not because of such JavaDoc developers have been coding using TCCL with certain expectations of "null" different to that of just meaning the bootstrap CL.
>> 
>> How would you propose to fix it?
> 
> I don't see anything that actually needs fixing (apart from the javadoc). Anyone using getCCL has to expect null as a possibility and they are then free to proceed however they like. The obvious ways to proceed are as I outlined earlier:
> - use current classloader
> - use system loader
> - use bootstrap loader
> 

So you are proposing to widen the scope? since i interpret the current JavaDoc to correspond to only the latter two options.

Paul.

From david.holmes at oracle.com  Thu Oct  4 10:37:19 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 04 Oct 2012 20:37:19 +1000
Subject: Reviewer and committer request for 7198496
In-Reply-To: <6C8D595A-765D-4555-BD63-C244D1B043E8@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com>
	<3AC99BDE-5EC9-4F18-B1E6-64FF5C6093FB@oracle.com>
	<506D583F.2010808@oracle.com>
	<6C8D595A-765D-4555-BD63-C244D1B043E8@oracle.com>
Message-ID: <506D66DF.9050505@oracle.com>

Paul,

On 4/10/2012 7:53 PM, Paul Sandoz wrote:
> On Oct 4, 2012, at 11:34 AM, David Holmes<david.holmes at oracle.com>  wrote:
>>>
>>>> These parts of the javadoc for get/setContextClassLoader are simply wrong.
>>>>
>>>
>>> Wrong or not because of such JavaDoc developers have been coding using TCCL with certain expectations of "null" different to that of just meaning the bootstrap CL.
>>>
>>> How would you propose to fix it?
>>
>> I don't see anything that actually needs fixing (apart from the javadoc). Anyone using getCCL has to expect null as a possibility and they are then free to proceed however they like. The obvious ways to proceed are as I outlined earlier:
>> - use current classloader
>> - use system loader
>> - use bootstrap loader
>>
>
> So you are proposing to widen the scope? since i interpret the current JavaDoc to correspond to only the latter two options.

I think you are missing the point. If getCCL returns null it returns 
null - end of story. What the caller of getCCL does after that is their 
business, it has nothing to do with the spec for getCCL. As Chris said 
getCCL can suggest that if null is returned then the caller might use 
the system or bootloader but that is all it is - a suggestion.

The issue here is what ServiceLoader says. First load(Class, 
ClassLoader) states:

* @param  loader
*         The class loader to be used to load provider-configuration files
*         and provider classes, or <tt>null</tt> if the system class
*         loader (or, failing that, the bootstrap class loader) is to be
*         used

which has the same language as used for the CCL. However here it is 
mostly well defined: if the passed in loader is null then use the system 
loader. The "or failing that, the bootstrap class loader" seems 
redundant - as the system loader (unless overridden I suppose) will 
delegate to the bootstrap loader first, there would be no point in then 
trying the bootstrap loader directly. But conservatively, if the system 
loader had been overridden you might also try the bootloader just in 
case. (But the implementation does not do that.)

Then load(Class) says:

/**
  * Creates a new service loader for the given service type, using the
  * current thread's {@linkplain java.lang.Thread#getContextClassLoader
  * context class loader}.

This is fine. If the CCL is null then the semantics for 
load(service,null) come into play.

So now we come to code in question:

private ServiceLoader(Class<S> svc, ClassLoader cl) {
     service = Objects.requireNonNull(svc, "Service interface cannot be 
null");
    loader = cl;
    reload();
}

No problem so far - loader can be null. The question is then how it is 
used later ...

    if (loader == null)
       configs = ClassLoader.getSystemResources(fullName);
    else
        configs = loader.getResources(fullName);

So the question now is what does ClassLoader.getSystemResources do? It says:

"Finds all resources of the specified name from the search path used to 
load classes. "

That sounds to me like it uses the system classloader, which in turn 
would first delegate to the bootstrap loader. All good. But we also have:

  try {
     S p = service.cast(Class.forName(cn, true, loader)
                 .newInstance());

and there is the bug because if you pass null to forName it will use the 
bootstrap loader, not the system loader. So it seems to me that a fix 
here is to just change the above to:

    Class.forName(cn, true, loader != null ? loader : 
Classloader.getSystemClassLoader())

Instead you have opted to deal with a null loader at construction time:

   loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;

which has the same semantic effect, but leaves some "dead" code 
internally as now loader can not be null.

David




> Paul.


From vincent.x.ryan at oracle.com  Thu Oct  4 10:58:02 2012
From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com)
Date: Thu, 04 Oct 2012 10:58:02 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20121004105931.35A3A4719A@hg.openjdk.java.net>

Changeset: 344f0acff085
Author:    vinnie
Date:      2012-02-14 11:18 +0000
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/344f0acff085

7133495: [macosx] KeyChain KeyStore implementation retrieves only one private key entry
Reviewed-by: weijun

! src/macosx/native/apple/security/KeystoreImpl.m
+ test/sun/security/tools/keytool/ListKeychainStore.sh

Changeset: 77af5b4ae4f0
Author:    vinnie
Date:      2012-10-04 11:54 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77af5b4ae4f0

Merge




From paul.sandoz at oracle.com  Thu Oct  4 11:56:59 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 4 Oct 2012 13:56:59 +0200
Subject: Reviewer and committer request for 7198496
In-Reply-To: <506D66DF.9050505@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com>
	<3AC99BDE-5EC9-4F18-B1E6-64FF5C6093FB@oracle.com>
	<506D583F.2010808@oracle.com>
	<6C8D595A-765D-4555-BD63-C244D1B043E8@oracle.com>
	<506D66DF.9050505@oracle.com>
Message-ID: <A2809AFE-1C5F-4DA3-8A92-C41E89F12720@oracle.com>


On Oct 4, 2012, at 12:37 PM, David Holmes <david.holmes at oracle.com> wrote:

> Paul,
> 
> On 4/10/2012 7:53 PM, Paul Sandoz wrote:
>> On Oct 4, 2012, at 11:34 AM, David Holmes<david.holmes at oracle.com>  wrote:
>>>> 
>>>>> These parts of the javadoc for get/setContextClassLoader are simply wrong.
>>>>> 
>>>> 
>>>> Wrong or not because of such JavaDoc developers have been coding using TCCL with certain expectations of "null" different to that of just meaning the bootstrap CL.
>>>> 
>>>> How would you propose to fix it?
>>> 
>>> I don't see anything that actually needs fixing (apart from the javadoc). Anyone using getCCL has to expect null as a possibility and they are then free to proceed however they like. The obvious ways to proceed are as I outlined earlier:
>>> - use current classloader
>>> - use system loader
>>> - use bootstrap loader
>>> 
>> 
>> So you are proposing to widen the scope? since i interpret the current JavaDoc to correspond to only the latter two options.
> 
> I think you are missing the point. If getCCL returns null it returns null - end of story.

> What the caller of getCCL does after that is their business, it has nothing to do with the spec for getCCL.

I think we may be misunderstanding and/or talking over each other. IIUC you are saying what behaviour you would like and i am saying how i interpret the current behaviour.

I interpret the current JavaDoc as normatively stating what the caller of getCCL *must* do if null a value is returned.

A little tweak to the doc might help:

From:

"@return  the context ClassLoader for this Thread, or {@code null} indicating the system class loader (or, failing that, the bootstrap class loader)"

To:

"@return  the context ClassLoader for this Thread, or {@code null} indicating the caller shall use the system class loader (or, failing that, the bootstrap class loader) in place of what would otherwise be the non-null context ClassLoader."

Because TCCL has the annoying property of decoupling behaviour (or "action at a distance") i think i can see why it was documented in such a way.


So from my perspective you are proposing a change in the specified behaviour, perhaps to something like:

@return  the context ClassLoader for this Thread, or {@code null} indicating the context ClassLoader is undefined. It is recommended that ...

Which might be fine, from a backwards compatibility perspective, i am not sure, but i have been on the receiving end of some very tricky bugs due to TCCL, hence a conservative position.


<snip>
>  loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
> 
> which has the same semantic effect, but leaves some "dead" code internally as now loader can not be null.
> 

It can if the system CL is null.

Paul.

From maurizio.cimadamore at oracle.com  Thu Oct  4 12:27:29 2012
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Thu, 04 Oct 2012 12:27:29 +0000
Subject: hg: jdk8/tl/langtools: 7177387: Add target-typing support in method
	context
Message-ID: <20121004122734.6397E4719D@hg.openjdk.java.net>

Changeset: 1408af4cd8b0
Author:    mcimadamore
Date:      2012-10-04 13:04 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1408af4cd8b0

7177387: Add target-typing support in method context
Summary: Add support for deferred types and speculative attribution
Reviewed-by: jjg, dlsmith

! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/TypeTags.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/AttrContext.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
+ src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/List.java
! src/share/classes/com/sun/tools/javac/util/Log.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! test/tools/javac/conditional/Conditional.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/IncompatibleTypesInConditional.java
+ test/tools/javac/diags/examples/TypeConditional.java



From david.holmes at oracle.com  Thu Oct  4 13:37:41 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 04 Oct 2012 23:37:41 +1000
Subject: Reviewer and committer request for 7198496
In-Reply-To: <A2809AFE-1C5F-4DA3-8A92-C41E89F12720@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com>
	<3AC99BDE-5EC9-4F18-B1E6-64FF5C6093FB@oracle.com>
	<506D583F.2010808@oracle.com>
	<6C8D595A-765D-4555-BD63-C244D1B043E8@oracle.com>
	<506D66DF.9050505@oracle.com>
	<A2809AFE-1C5F-4DA3-8A92-C41E89F12720@oracle.com>
Message-ID: <506D9125.7020103@oracle.com>

On 4/10/2012 9:56 PM, Paul Sandoz wrote:
>
> On Oct 4, 2012, at 12:37 PM, David Holmes<david.holmes at oracle.com>  wrote:
>
>> Paul,
>>
>> On 4/10/2012 7:53 PM, Paul Sandoz wrote:
>>> On Oct 4, 2012, at 11:34 AM, David Holmes<david.holmes at oracle.com>   wrote:
>>>>>
>>>>>> These parts of the javadoc for get/setContextClassLoader are simply wrong.
>>>>>>
>>>>>
>>>>> Wrong or not because of such JavaDoc developers have been coding using TCCL with certain expectations of "null" different to that of just meaning the bootstrap CL.
>>>>>
>>>>> How would you propose to fix it?
>>>>
>>>> I don't see anything that actually needs fixing (apart from the javadoc). Anyone using getCCL has to expect null as a possibility and they are then free to proceed however they like. The obvious ways to proceed are as I outlined earlier:
>>>> - use current classloader
>>>> - use system loader
>>>> - use bootstrap loader
>>>>
>>>
>>> So you are proposing to widen the scope? since i interpret the current JavaDoc to correspond to only the latter two options.
>>
>> I think you are missing the point. If getCCL returns null it returns null - end of story.
>
>> What the caller of getCCL does after that is their business, it has nothing to do with the spec for getCCL.
>
> I think we may be misunderstanding and/or talking over each other. IIUC you are saying what behaviour you would like and i am saying how i interpret the current behaviour.
>
> I interpret the current JavaDoc as normatively stating what the caller of getCCL *must* do if null a value is returned.

And that is the problem. A spec for a method can not normatively say 
what the caller of the method must do with the result.

> A little tweak to the doc might help:
>
> From:
>
> "@return  the context ClassLoader for this Thread, or {@code null} indicating the system class loader (or, failing that, the bootstrap class loader)"
>
> To:
>
> "@return  the context ClassLoader for this Thread, or {@code null} indicating the caller shall use the system class loader (or, failing that, the bootstrap class loader) in place of what would otherwise be the non-null context ClassLoader."
>
> Because TCCL has the annoying property of decoupling behaviour (or "action at a distance") i think i can see why it was documented in such a way.
>
>
> So from my perspective you are proposing a change in the specified behaviour, perhaps to something like:

No I'm not because you can not specify how your caller must behave.

> @return  the context ClassLoader for this Thread, or {@code null} indicating the context ClassLoader is undefined. It is recommended that ...
>
> Which might be fine, from a backwards compatibility perspective, i am not sure, but i have been on the receiving end of some very tricky bugs due to TCCL, hence a conservative position.
>
>
> <snip>
>>   loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
>>
>> which has the same semantic effect, but leaves some "dead" code internally as now loader can not be null.
>>
>
> It can if the system CL is null.

The system CL can never be null.

David
-----

> Paul.


From peter.levart at gmail.com  Thu Oct  4 14:11:15 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 04 Oct 2012 16:11:15 +0200
Subject: Reviewer and committer request for 7198496
In-Reply-To: <506D9125.7020103@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com>
	<3AC99BDE-5EC9-4F18-B1E6-64FF5C6093FB@oracle.com>
	<506D583F.2010808@oracle.com>
	<6C8D595A-765D-4555-BD63-C244D1B043E8@oracle.com>
	<506D66DF.9050505@oracle.com>
	<A2809AFE-1C5F-4DA3-8A92-C41E89F12720@oracle.com>
	<506D9125.7020103@oracle.com>
Message-ID: <506D9903.7090700@gmail.com>

On 10/04/2012 03:37 PM, David Holmes wrote:
> On 4/10/2012 9:56 PM, Paul Sandoz wrote:
>>
>> On Oct 4, 2012, at 12:37 PM, David Holmes<david.holmes at oracle.com>  
>> wrote:
>>
>>> Paul,
>>>
>>> On 4/10/2012 7:53 PM, Paul Sandoz wrote:
>>>> On Oct 4, 2012, at 11:34 AM, David 
>>>> Holmes<david.holmes at oracle.com>   wrote:
>>>>>>
>>>>>>> These parts of the javadoc for get/setContextClassLoader are 
>>>>>>> simply wrong.
>>>>>>>
>>>>>>
>>>>>> Wrong or not because of such JavaDoc developers have been coding 
>>>>>> using TCCL with certain expectations of "null" different to that 
>>>>>> of just meaning the bootstrap CL.
>>>>>>
>>>>>> How would you propose to fix it?
>>>>>
>>>>> I don't see anything that actually needs fixing (apart from the 
>>>>> javadoc). Anyone using getCCL has to expect null as a possibility 
>>>>> and they are then free to proceed however they like. The obvious 
>>>>> ways to proceed are as I outlined earlier:
>>>>> - use current classloader
>>>>> - use system loader
>>>>> - use bootstrap loader
>>>>>
>>>>
>>>> So you are proposing to widen the scope? since i interpret the 
>>>> current JavaDoc to correspond to only the latter two options.
>>>
>>> I think you are missing the point. If getCCL returns null it returns 
>>> null - end of story.
>>
>>> What the caller of getCCL does after that is their business, it has 
>>> nothing to do with the spec for getCCL.
>>
>> I think we may be misunderstanding and/or talking over each other. 
>> IIUC you are saying what behaviour you would like and i am saying how 
>> i interpret the current behaviour.
>>
>> I interpret the current JavaDoc as normatively stating what the 
>> caller of getCCL *must* do if null a value is returned.
>
> And that is the problem. A spec for a method can not normatively say 
> what the caller of the method must do with the result.
>
>> A little tweak to the doc might help:
>>
>> From:
>>
>> "@return  the context ClassLoader for this Thread, or {@code null} 
>> indicating the system class loader (or, failing that, the bootstrap 
>> class loader)"
>>
>> To:
>>
>> "@return  the context ClassLoader for this Thread, or {@code null} 
>> indicating the caller shall use the system class loader (or, failing 
>> that, the bootstrap class loader) in place of what would otherwise be 
>> the non-null context ClassLoader."
>>
>> Because TCCL has the annoying property of decoupling behaviour (or 
>> "action at a distance") i think i can see why it was documented in 
>> such a way.
>>
>>
>> So from my perspective you are proposing a change in the specified 
>> behaviour, perhaps to something like:
>
> No I'm not because you can not specify how your caller must behave.
>
>> @return  the context ClassLoader for this Thread, or {@code null} 
>> indicating the context ClassLoader is undefined. It is recommended 
>> that ...
>>
>> Which might be fine, from a backwards compatibility perspective, i am 
>> not sure, but i have been on the receiving end of some very tricky 
>> bugs due to TCCL, hence a conservative position.
>>
>>
>> <snip>
>>>   loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
>>>
>>> which has the same semantic effect, but leaves some "dead" code 
>>> internally as now loader can not be null.
>>>
>>
>> It can if the system CL is null.
>
> The system CL can never be null.
>
> David
> -----

Then there is some dead code in ClassLoader.getSystemClassLoader() method:

     public static ClassLoader getSystemClassLoader() {
         initSystemClassLoader();
         if (scl == null) {
             return null;
         }

And also the javadoc for the method is wrong since it is implying that 
the method may return null...

Or it might be that API is designed to allow null as a return value but 
the OpenJDK implementation never returns one.

If the later is true and ServiceLoader is to be re-used in other Java 
platform implementations, then it must be coded by the API contract and 
not by the implementation details and so should check for null...

Regards, Peter

>
>> Paul.



From paul.sandoz at oracle.com  Thu Oct  4 14:39:13 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 4 Oct 2012 16:39:13 +0200
Subject: Reviewer and committer request for 7198496
In-Reply-To: <506D9125.7020103@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com>
	<3AC99BDE-5EC9-4F18-B1E6-64FF5C6093FB@oracle.com>
	<506D583F.2010808@oracle.com>
	<6C8D595A-765D-4555-BD63-C244D1B043E8@oracle.com>
	<506D66DF.9050505@oracle.com>
	<A2809AFE-1C5F-4DA3-8A92-C41E89F12720@oracle.com>
	<506D9125.7020103@oracle.com>
Message-ID: <0B9A0CA9-2104-4F88-9D31-9C6FB1DF689C@oracle.com>

On Oct 4, 2012, at 3:37 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>> So you are proposing to widen the scope? since i interpret the current JavaDoc to correspond to only the latter two options.
>>> 
>>> I think you are missing the point. If getCCL returns null it returns null - end of story.
>> 
>>> What the caller of getCCL does after that is their business, it has nothing to do with the spec for getCCL.
>> 
>> I think we may be misunderstanding and/or talking over each other. IIUC you are saying what behaviour you would like and i am saying how i interpret the current behaviour.
>> 
>> I interpret the current JavaDoc as normatively stating what the caller of getCCL *must* do if null a value is returned.
> 
> And that is the problem. A spec for a method can not normatively say what the caller of the method must do with the result.
> 

Ah! i understand where you are coming from now, thanks for patience. 

It can say it but cannot enforce it. It's something developers can use to point fingers at each other :-)

In this case I would categorise it as a SHOULD (or RECOMMENDED) rather than a MUST in RFC parlance:

"@return  the context ClassLoader for this Thread, or {@code null} indicating the caller SHOULD use the system class loader (or, failing that, the bootstrap class loader) in place of what would otherwise be the non-null context ClassLoader."

AFAIK i don't think there is any spec in the JDK/JCP on key words to indicate requirement levels.
 

>> A little tweak to the doc might help:
>> 
>> From:
>> 
>> "@return  the context ClassLoader for this Thread, or {@code null} indicating the system class loader (or, failing that, the bootstrap class loader)"
>> 
>> To:
>> 
>> "@return  the context ClassLoader for this Thread, or {@code null} indicating the caller shall use the system class loader (or, failing that, the bootstrap class loader) in place of what would otherwise be the non-null context ClassLoader."
>> 
>> Because TCCL has the annoying property of decoupling behaviour (or "action at a distance") i think i can see why it was documented in such a way.
>> 
>> 
>> So from my perspective you are proposing a change in the specified behaviour, perhaps to something like:
> 
> No I'm not because you can not specify how your caller must behave.
> 
>> @return  the context ClassLoader for this Thread, or {@code null} indicating the context ClassLoader is undefined. It is recommended that ...
>> 
>> Which might be fine, from a backwards compatibility perspective, i am not sure, but i have been on the receiving end of some very tricky bugs due to TCCL, hence a conservative position.
>> 
>> 
>> <snip>
>>>  loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
>>> 
>>> which has the same semantic effect, but leaves some "dead" code internally as now loader can not be null.
>>> 
>> 
>> It can if the system CL is null.
> 
> The system CL can never be null.
> 

I thought that was the case too, my first webrev had the if/else removed but then i updated it after i read the JavaDoc of ClassLoader.getSystemClassLoader():

  Returns: The system ClassLoader for delegation, or null if none

Paul.

From naoto.sato at oracle.com  Thu Oct  4 17:06:07 2012
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 04 Oct 2012 17:06:07 +0000
Subject: hg: jdk8/tl/jdk: 7196799: CLDR adapter can not be invoked when region
	code is specified in Locale; ...
Message-ID: <20121004170630.E257C471A8@hg.openjdk.java.net>

Changeset: c6a0b13e6efa
Author:    naoto
Date:      2012-10-04 10:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6a0b13e6efa

7196799: CLDR adapter can not be invoked when region code is specified in Locale
7197573: java/util/Locale/LocaleProviders.sh failed.
Reviewed-by: okutsu

! make/java/java/FILES_java.gmk
! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java
+ src/share/classes/sun/util/locale/provider/FallbackLocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh



From martinrb at google.com  Thu Oct  4 17:24:05 2012
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 4 Oct 2012 10:24:05 -0700
Subject: RFR: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java
	failing intermittently [sol]
In-Reply-To: <506D3D14.4070304@oracle.com>
References: <506CB1C3.5050009@oracle.com>
	<506D3D14.4070304@oracle.com>
Message-ID: <CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>

Hi all,

Yeah, this particular test is rather racy - sorry about that.
We need to call p.destroy when the other thread is in the middle of a
read() system call, and there's no way to know for sure - seeing java
"read" in the stacktrace is not enough, since it may not have gotten to the
system call yet.

suggestions:
pull the computation of the inputstream before the latch to narrow the
window a bit:

final InputStream s;
switch (action & 0x1) {
case 0: s = p.getInputStream(); break;
case 1: s = p.getErrorStream(); break;
default: throw
}
latch.countdown();
switch (action & 0x2) {
case 0: r = s.read(); break;
case 1: r = s.read(bytes); break;
}

Examining the stack trace to look for "read" is clever but does not
actually eliminate the race.

Looking in UNIXProcess.java.solaris I see the use
of DeferredCloseInputStream.  We can eliminate the race on solaris (i.e. if
the inputstream.getclass isDeferredCloseInputStream)  by looping until the
useCount field of the DeferredCloseInputStream is > 0, using ugly but
effective reflective code.  This should allow us to avoid the horrible
sleep for 200ms.

You should use yield instead of sleep between loop iterations while waiting
for the useCount to be bumped.

On other platforms this is not an issue, I think.

Martin

On Thu, Oct 4, 2012 at 12:39 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

> On 03/10/2012 22:44, Rob McKenna wrote:
>
>> Hi folks,
>>
>> The only way I can see this test failing in this manner[*] is if we
>> destroy the process before we begin the read. That being the case I've
>> jacked up the sleep (giving the reader thread a little more time to get
>> cracking) and added a check to see if the threads stack has entered a read
>> call.
>>
>> http://cr.openjdk.java.net/~**robm/7152183/webrev.01/<http://cr.openjdk.java.net/~robm/7152183/webrev.01/><
>> http://cr.openjdk.java.net/%**7Erobm/7152183/webrev.01/<http://cr.openjdk.java.net/%7Erobm/7152183/webrev.01/>
>> >
>>
>> Feedback greatly appreciated.
>>
>>     -Rob
>>
>>
>> [*] le trace:
>>
>>  So stack traces are masculine, I didn't know that.
>
> I think your analysis is right, it's just that the sleep(10) is not
> sufficient to ensure that the thread gets to the read method. Increasing
> the sleep is probably sufficient. The hack to look at the stack trace makes
> it more robust for really extreme cases, at the cost of potential further
> maintenance in the event that the implementation changes. In any case it's
> good to resolve this intermittent test failure.
>
> -Alan
>


From rob.mckenna at oracle.com  Thu Oct  4 18:50:24 2012
From: rob.mckenna at oracle.com (rob.mckenna at oracle.com)
Date: Thu, 04 Oct 2012 18:50:24 +0000
Subject: hg: jdk8/tl/jdk: 7184932: Remove the temporary Selector usage in the
	NIO socket adapters
Message-ID: <20121004185045.DA1DF471A9@hg.openjdk.java.net>

Changeset: bba370caafad
Author:    robm
Date:      2012-10-04 19:53 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bba370caafad

7184932: Remove the temporary Selector usage in the NIO socket adapters
Reviewed-by: alanb

! make/java/nio/mapfile-bsd
! make/java/nio/mapfile-linux
! make/java/nio/mapfile-solaris
! src/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java
! src/share/classes/sun/nio/ch/Net.java
! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java
! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/share/classes/sun/nio/ch/SocketAdaptor.java
! src/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/share/classes/sun/nio/ch/Util.java
! src/solaris/native/sun/nio/ch/Net.c
! src/windows/native/sun/nio/ch/Net.c
+ test/java/nio/channels/etc/AdaptorCloseAndInterrupt.java



From Alan.Bateman at oracle.com  Thu Oct  4 20:56:35 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 04 Oct 2012 21:56:35 +0100
Subject: Reviewer and committer request for 7198496
In-Reply-To: <0B9A0CA9-2104-4F88-9D31-9C6FB1DF689C@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com>
	<3AC99BDE-5EC9-4F18-B1E6-64FF5C6093FB@oracle.com>
	<506D583F.2010808@oracle.com>
	<6C8D595A-765D-4555-BD63-C244D1B043E8@oracle.com>
	<506D66DF.9050505@oracle.com>
	<A2809AFE-1C5F-4DA3-8A92-C41E89F12720@oracle.com>
	<506D9125.7020103@oracle.com>
	<0B9A0CA9-2104-4F88-9D31-9C6FB1DF689C@oracle.com>
Message-ID: <506DF803.2050101@oracle.com>

On 04/10/2012 15:39, Paul Sandoz wrote:
> :
> I thought that was the case too, my first webrev had the if/else removed but then i updated it after i read the JavaDoc of ClassLoader.getSystemClassLoader():
>
>    Returns: The system ClassLoader for delegation, or null if none
>
> Paul.
Yes, the spec allows there to be no system class loader.

So my take on ServiceLoader is that the changes in your updated webrev 
are okay. Code that wants to allow for service providers to be be 
installed on the class path or located via the TCCL should use the load 
methods. Code that wants to restrict things to only service providers 
that in the extensions directory or the boot class path needs to use 
loadInstalled instead. It's hard to know how common the 
TCCL=null+load(S) or load(S,null) cases are but the spec seems clear and 
with the changes then I don't think there should be any issue.

As regards the Thread set/getTCCL methods then I think the null case is 
a bit of a corner case. The methods specify the intended usage but can't 
of course enforce it. My guess is that for regular applications is not 
an issue,the primordial thread starts out with it set to to the system 
class loader and other threads inherit it. I also suspect this is a 
non-issue for the EE apps too as I gather it's always set there because 
there are multiple contexts running in the same container. There can be 
security or GC reasons to reset it to null but that should be rare, at 
least outside of the JDK.

-Alan




From david.holmes at oracle.com  Thu Oct  4 23:37:51 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Oct 2012 09:37:51 +1000
Subject: Reviewer and committer request for 7198496
In-Reply-To: <506DF803.2050101@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com>
	<3AC99BDE-5EC9-4F18-B1E6-64FF5C6093FB@oracle.com>
	<506D583F.2010808@oracle.com>
	<6C8D595A-765D-4555-BD63-C244D1B043E8@oracle.com>
	<506D66DF.9050505@oracle.com>
	<A2809AFE-1C5F-4DA3-8A92-C41E89F12720@oracle.com>
	<506D9125.7020103@oracle.com>
	<0B9A0CA9-2104-4F88-9D31-9C6FB1DF689C@oracle.com>
	<506DF803.2050101@oracle.com>
Message-ID: <506E1DCF.3070904@oracle.com>

Not wanting to beat a dead-horse but ...

On 5/10/2012 6:56 AM, Alan Bateman wrote:
> On 04/10/2012 15:39, Paul Sandoz wrote:
>> :
>> I thought that was the case too, my first webrev had the if/else
>> removed but then i updated it after i read the JavaDoc of
>> ClassLoader.getSystemClassLoader():
>>
>> Returns: The system ClassLoader for delegation, or null if none
>>
>> Paul.
> Yes, the spec allows there to be no system class loader.

The @return claims it can be null, but if you read the rest of the spec 
that appears to be impossible - either the system loader has been 
created, in which case it is returned, else it is created. The creation 
is either successful or throws an exception. I don't see anywhere a null 
can possibly be returned - either in the spec or implementation.

Cheers,
David
---------

> So my take on ServiceLoader is that the changes in your updated webrev
> are okay. Code that wants to allow for service providers to be be
> installed on the class path or located via the TCCL should use the load
> methods. Code that wants to restrict things to only service providers
> that in the extensions directory or the boot class path needs to use
> loadInstalled instead. It's hard to know how common the
> TCCL=null+load(S) or load(S,null) cases are but the spec seems clear and
> with the changes then I don't think there should be any issue.
>
> As regards the Thread set/getTCCL methods then I think the null case is
> a bit of a corner case. The methods specify the intended usage but can't
> of course enforce it. My guess is that for regular applications is not
> an issue,the primordial thread starts out with it set to to the system
> class loader and other threads inherit it. I also suspect this is a
> non-issue for the EE apps too as I gather it's always set there because
> there are multiple contexts running in the same container. There can be
> security or GC reasons to reset it to null but that should be rare, at
> least outside of the JDK.
>
> -Alan
>
>


From naoto.sato at oracle.com  Fri Oct  5 04:05:39 2012
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 05 Oct 2012 04:05:39 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20121005040612.79C33471BE@hg.openjdk.java.net>

Changeset: cd4f181eb666
Author:    naoto
Date:      2012-10-04 21:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd4f181eb666

7200119: Collator.getAvailableLocales() doesn't return Locale.US
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
+ test/java/text/Collator/Bug7200119.java

Changeset: 647424d6cf65
Author:    naoto
Date:      2012-10-04 21:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/647424d6cf65

Merge




From Alan.Bateman at oracle.com  Fri Oct  5 09:56:46 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 05 Oct 2012 10:56:46 +0100
Subject: Fwd: AutoCloseable blocking or not
In-Reply-To: <CAPs61500ThVAQ3Ze-2MqU7hkhBvNsh+j5Q29DUSd=-W=f9XCjw@mail.gmail.com>
References: <CAPs61500ThVAQ3Ze-2MqU7hkhBvNsh+j5Q29DUSd=-W=f9XCjw@mail.gmail.com>
Message-ID: <506EAEDE.8060008@oracle.com>


Forwarding Kasper's mail to the right list.

-------- Original Message --------
Subject: 	AutoCloseable blocking or not
Date: 	Fri, 5 Oct 2012 11:42:35 +0200
From: 	Kasper Nielsen <kasperni at gmail.com>
To: 	nio-discuss at openjdk.java.net



Hi,

I have a question about the AutoCloseable interface. Since I cannot
find any mention about how asynchronously closeable resources should
be handled.

Say I wanted juc.ThreadPoolExecutorService to implement AutoCloseable.
When close() returned should the executor be in the shutdown phase or
in the terminated phase?

In other words should I implement close() like this (which I believe)

public void close() {
  executor.shutdown();
  executor.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS); //ignore
any interrupted exceptions
}

or like this

public void close() {
  executor.shutdown();
}

- Kasper



From aleksey.shipilev at oracle.com  Fri Oct  5 10:57:34 2012
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 05 Oct 2012 14:57:34 +0400
Subject: Fwd: AutoCloseable blocking or not
In-Reply-To: <506EAEDE.8060008@oracle.com>
References: <CAPs61500ThVAQ3Ze-2MqU7hkhBvNsh+j5Q29DUSd=-W=f9XCjw@mail.gmail.com>
	<506EAEDE.8060008@oracle.com>
Message-ID: <506EBD1E.5040702@oracle.com>

I would say that spec does not tell you anything about the blocking
contract for try-with-resources, so as far as you are OK with the
semantics outlined in JLS 14.20.3, you are good to go either way.
Another example of blocking close() would be releasing the object in
question to synchronized cache, which is potentially blocking.

BTW, while awaiting shutdown looks cleaner, there are some nasty
complications if the workers in thread pool are ignoring interrupts, in
which case you can block indefinitely. Not waiting for termination may
silently leave some of threads running (I find it enlightening to find
stale threads burning the CPU for days on production systems, while
application thinks they are stopped.) Hence, either way of implementing
TPE.close() as the standard method has its drawbacks, the users have to
choose either one that fits their use case.

-Aleksey.

On 10/05/2012 01:56 PM, Alan Bateman wrote:
> 
> Forwarding Kasper's mail to the right list.
> 
> -------- Original Message --------
> Subject:     AutoCloseable blocking or not
> Date:     Fri, 5 Oct 2012 11:42:35 +0200
> From:     Kasper Nielsen <kasperni at gmail.com>
> To:     nio-discuss at openjdk.java.net
> 
> 
> 
> Hi,
> 
> I have a question about the AutoCloseable interface. Since I cannot
> find any mention about how asynchronously closeable resources should
> be handled.
> 
> Say I wanted juc.ThreadPoolExecutorService to implement AutoCloseable.
> When close() returned should the executor be in the shutdown phase or
> in the terminated phase?
> 
> In other words should I implement close() like this (which I believe)
> 
> public void close() {
>  executor.shutdown();
>  executor.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS); //ignore
> any interrupted exceptions
> }
> 
> or like this
> 
> public void close() {
>  executor.shutdown();
> }
> 
> - Kasper
> 



From david.holmes at oracle.com  Fri Oct  5 11:10:53 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Oct 2012 21:10:53 +1000
Subject: Fwd: AutoCloseable blocking or not
In-Reply-To: <506EAEDE.8060008@oracle.com>
References: <CAPs61500ThVAQ3Ze-2MqU7hkhBvNsh+j5Q29DUSd=-W=f9XCjw@mail.gmail.com>
	<506EAEDE.8060008@oracle.com>
Message-ID: <506EC03D.9060507@oracle.com>

On 5/10/2012 7:56 PM, Alan Bateman wrote:
>
> Forwarding Kasper's mail to the right list.
>
> From: Kasper Nielsen <kasperni at gmail.com>
> To: nio-discuss at openjdk.java.net
>
> I have a question about the AutoCloseable interface. Since I cannot
> find any mention about how asynchronously closeable resources should
> be handled.
>
> Say I wanted juc.ThreadPoolExecutorService to implement AutoCloseable.
> When close() returned should the executor be in the shutdown phase or
> in the terminated phase?
>
> In other words should I implement close() like this (which I believe)
>
> public void close() {
> executor.shutdown();
> executor.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS); //ignore
> any interrupted exceptions
> }
>
> or like this
>
> public void close() {
> executor.shutdown();
> }

That's really an arbitrary choice. What semantics do you want the 
close() to have?

Personally I don't think AutoCloseable is a good fit for an executor 
service as the lifetime of an autocloseable is tied to a block of code 
and that would be a rare usage for an executor service.

David Holmes

> - Kasper
>


From kasperni at gmail.com  Fri Oct  5 13:14:50 2012
From: kasperni at gmail.com (Kasper Nielsen)
Date: Fri, 5 Oct 2012 15:14:50 +0200
Subject: Fwd: AutoCloseable blocking or not
In-Reply-To: <506EC03D.9060507@oracle.com>
References: <CAPs61500ThVAQ3Ze-2MqU7hkhBvNsh+j5Q29DUSd=-W=f9XCjw@mail.gmail.com>
	<506EAEDE.8060008@oracle.com> <506EC03D.9060507@oracle.com>
Message-ID: <CAPs6151Hi8zCoD60P4HaZD+=RAZ5m+8+BA7ynrtNy0O90Kb0Ow@mail.gmail.com>

On Fri, Oct 5, 2012 at 1:10 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 5/10/2012 7:56 PM, Alan Bateman wrote:
>>
>>
>> Forwarding Kasper's mail to the right list.
>>
>> From: Kasper Nielsen <kasperni at gmail.com>
>> To: nio-discuss at openjdk.java.net
>>
>> I have a question about the AutoCloseable interface. Since I cannot
>> find any mention about how asynchronously closeable resources should
>> be handled.
>>
>> Say I wanted juc.ThreadPoolExecutorService to implement AutoCloseable.
>> When close() returned should the executor be in the shutdown phase or
>> in the terminated phase?
>>
>> In other words should I implement close() like this (which I believe)
>>
>> public void close() {
>> executor.shutdown();
>> executor.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS); //ignore
>> any interrupted exceptions
>> }
>>
>> or like this
>>
>> public void close() {
>> executor.shutdown();
>> }
>
>
> That's really an arbitrary choice. What semantics do you want the close() to
> have?

The least surprising from a user perspective.

If a given auto closable resource can be in 3 states: running ->
closing -> closed.
And I have a resource where the closing phase can take multiple seconds.
Would the user assume that when close() returned, the resource was in
the closed state.
Or could I just spawn a thread that did the actual close and
immediately return control to the caller with the resource in the
closing state.

Given that any class I could find in the JDK that implements
AutoCloseable blocks until the socket/filesystem/rowset/... is fully
closed.
I thought maybe using AutoCloseable was a bit of a stretch to use for
closing a resource asynchronously.

- Kasper

>
> Personally I don't think AutoCloseable is a good fit for an executor service
> as the lifetime of an autocloseable is tied to a block of code and that
> would be a rare usage for an executor service.

I agree, I was just using the executor service as a rather poor example.

Kasper


From vitalyd at gmail.com  Fri Oct  5 13:22:51 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 5 Oct 2012 09:22:51 -0400
Subject: Fwd: AutoCloseable blocking or not
In-Reply-To: <CAPs6151Hi8zCoD60P4HaZD+=RAZ5m+8+BA7ynrtNy0O90Kb0Ow@mail.gmail.com>
References: <CAPs61500ThVAQ3Ze-2MqU7hkhBvNsh+j5Q29DUSd=-W=f9XCjw@mail.gmail.com>
	<506EAEDE.8060008@oracle.com> <506EC03D.9060507@oracle.com>
	<CAPs6151Hi8zCoD60P4HaZD+=RAZ5m+8+BA7ynrtNy0O90Kb0Ow@mail.gmail.com>
Message-ID: <CAHjP37Emd1bPs0u2Rn7gu1OAs75HMWix7wBrmOmV0snrVN1aXw@mail.gmail.com>

Personally, if an API just had close() I'd expect that when it returns the
semantics of close are done.  If the resource may take a while to close
(whatever "a while" means in the context) I'd expect to have a closeAsync()
(or something akin to that) that returns a future or takes a callback to
execute when it's finished.

Sent from my phone
On Oct 5, 2012 9:15 AM, "Kasper Nielsen" <kasperni at gmail.com> wrote:

> On Fri, Oct 5, 2012 at 1:10 PM, David Holmes <david.holmes at oracle.com>
> wrote:
> > On 5/10/2012 7:56 PM, Alan Bateman wrote:
> >>
> >>
> >> Forwarding Kasper's mail to the right list.
> >>
> >> From: Kasper Nielsen <kasperni at gmail.com>
> >> To: nio-discuss at openjdk.java.net
> >>
> >> I have a question about the AutoCloseable interface. Since I cannot
> >> find any mention about how asynchronously closeable resources should
> >> be handled.
> >>
> >> Say I wanted juc.ThreadPoolExecutorService to implement AutoCloseable.
> >> When close() returned should the executor be in the shutdown phase or
> >> in the terminated phase?
> >>
> >> In other words should I implement close() like this (which I believe)
> >>
> >> public void close() {
> >> executor.shutdown();
> >> executor.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS); //ignore
> >> any interrupted exceptions
> >> }
> >>
> >> or like this
> >>
> >> public void close() {
> >> executor.shutdown();
> >> }
> >
> >
> > That's really an arbitrary choice. What semantics do you want the
> close() to
> > have?
>
> The least surprising from a user perspective.
>
> If a given auto closable resource can be in 3 states: running ->
> closing -> closed.
> And I have a resource where the closing phase can take multiple seconds.
> Would the user assume that when close() returned, the resource was in
> the closed state.
> Or could I just spawn a thread that did the actual close and
> immediately return control to the caller with the resource in the
> closing state.
>
> Given that any class I could find in the JDK that implements
> AutoCloseable blocks until the socket/filesystem/rowset/... is fully
> closed.
> I thought maybe using AutoCloseable was a bit of a stretch to use for
> closing a resource asynchronously.
>
> - Kasper
>
> >
> > Personally I don't think AutoCloseable is a good fit for an executor
> service
> > as the lifetime of an autocloseable is tied to a block of code and that
> > would be a rare usage for an executor service.
>
> I agree, I was just using the executor service as a rather poor example.
>
> Kasper
>


From Alan.Bateman at oracle.com  Fri Oct  5 13:23:19 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 05 Oct 2012 14:23:19 +0100
Subject: Fwd: AutoCloseable blocking or not
In-Reply-To: <CAPs6151Hi8zCoD60P4HaZD+=RAZ5m+8+BA7ynrtNy0O90Kb0Ow@mail.gmail.com>
References: <CAPs61500ThVAQ3Ze-2MqU7hkhBvNsh+j5Q29DUSd=-W=f9XCjw@mail.gmail.com>
	<506EAEDE.8060008@oracle.com> <506EC03D.9060507@oracle.com>
	<CAPs6151Hi8zCoD60P4HaZD+=RAZ5m+8+BA7ynrtNy0O90Kb0Ow@mail.gmail.com>
Message-ID: <506EDF47.9030006@oracle.com>

On 05/10/2012 14:14, Kasper Nielsen wrote:
> :
>
> Given that any class I could find in the JDK that implements
> AutoCloseable blocks until the socket/filesystem/rowset/... is fully
> closed.
>
Not always, or at least not with steam oriented sockets as the default 
is not to linger when there is unsent data.

-Alan.


From Alan.Bateman at oracle.com  Fri Oct  5 13:41:14 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 05 Oct 2012 14:41:14 +0100
Subject: 8000354: (props) Properties.storeToXML/loadFromXML need to allow
	for alternative implementations
Message-ID: <506EE37A.1060507@oracle.com>


Properties defines the loadFromXML and storeToXML methods for 
loading/storing properties in XML format. These methods are problematic 
for our efforts to modularize the JDK because of the dependency on XML. 
They are also problematic for the Compact Profiles proposal [1] as it is 
unlikely that JAXP will be present in the smallest profile.

As the XML parsing needs of Properties is relatively simple we are 
thinking about including a small footprint parser that is sufficient for 
its needs. Joe Wang is looking this. In preparation for this we need to 
decouple Properties from the parser API that it uses and this is what 
the proposal here is about.

The webrev with the proposed changes is here:

http://cr.openjdk.java.net/~alanb/8000354/webrev/

Basically it introduces a JDK internal provider interface to which the 
loadFromXML and storeToXML methods delegate. The existing code that uses 
JAXP is moved into a provider implementation and will be used when 
present. When not present then the intention is that it will fallback to 
a default implementation that is the small footprint provider that Joe 
will add later. This approach ensures that we maintain compatibility (it 
remains to be seen whether we will have to deal with a few subtle issues 
when using the tiny parser). For test purposes there is a system 
property for overriding the provider, this is also why the system class 
loader is used as the initiating loader.

I should explain that when I say  "JDK internal provider interface" then 
the service type is in sun.util.spi for now. Maybe in the future it may 
be necessary to define a standard provider interface but it is not 
needed at this time (in addition it would require getting the security 
right to do that).

Thanks,

Alan.

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


From maurizio.cimadamore at oracle.com  Fri Oct  5 13:50:10 2012
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Fri, 05 Oct 2012 13:50:10 +0000
Subject: hg: jdk8/tl/langtools: 7177385: Add attribution support for lambda
	expressions
Message-ID: <20121005135014.E3F20471C9@hg.openjdk.java.net>

Changeset: 573ceb23beeb
Author:    mcimadamore
Date:      2012-10-05 14:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/573ceb23beeb

7177385: Add attribution support for lambda expressions
Summary: Add support for function descriptor lookup, functional interface inference and lambda expression type-checking
Reviewed-by: jjg, dlsmith

! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! test/tools/javac/6402516/TestLocalElements.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/CantAccessArgTypeInFunctionalDesc.java
+ test/tools/javac/diags/examples/CantAccessReturnTypeInFunctionalDesc.java
+ test/tools/javac/diags/examples/CantAccessThrownTypesInFunctionalDesc.java
! test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java
! test/tools/javac/diags/examples/CatchWithoutTry.java
+ test/tools/javac/diags/examples/CyclicInference.java
+ test/tools/javac/diags/examples/IncompatibleAbstracts.java
+ test/tools/javac/diags/examples/IncompatibleArgTypesInLambda.java
+ test/tools/javac/diags/examples/IncompatibleDescsInFunctionalIntf.java
+ test/tools/javac/diags/examples/IncompatibleRetTypeInLambda.java
+ test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java
+ test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java
+ test/tools/javac/diags/examples/MissingReturnValueFragment.java
+ test/tools/javac/diags/examples/NoAbstracts.java
+ test/tools/javac/diags/examples/NoSuitableFunctionalIntfInst.java
+ test/tools/javac/diags/examples/NotAFunctionalIntf.java
+ test/tools/javac/diags/examples/PotentialLambdaFound.java
- test/tools/javac/diags/examples/TypeConditional.java
+ test/tools/javac/diags/examples/UnexpectedLambda.java
! test/tools/javac/failover/CheckAttributedTree.java
! test/tools/javac/typeAnnotations/newlocations/BasicTest.out



From alan.bateman at oracle.com  Fri Oct  5 14:08:04 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 05 Oct 2012 14:08:04 +0000
Subject: hg: jdk8/tl/corba: 7195779:
	javax/management/remote/mandatory/threads/ExecutorTest.java
	fails intermittently, NPE in tie class
Message-ID: <20121005140804.E6F84471CA@hg.openjdk.java.net>

Changeset: 27d87f0031bf
Author:    alanb
Date:      2012-10-05 15:08 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/27d87f0031bf

7195779: javax/management/remote/mandatory/threads/ExecutorTest.java fails intermittently, NPE in tie class
Reviewed-by: alanb, coffeys
Contributed-by: jaroslav.bachorik at oracle.com

! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java



From naoto.sato at oracle.com  Fri Oct  5 17:00:31 2012
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 05 Oct 2012 17:00:31 +0000
Subject: hg: jdk8/tl/jdk: 7198834: HOST Adapter: one extra empty space in the
	end of the pattern string
Message-ID: <20121005170052.C74A1471D1@hg.openjdk.java.net>

Changeset: 88a726a5b2dc
Author:    naoto
Date:      2012-10-05 09:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88a726a5b2dc

7198834: HOST Adapter: one extra empty space in the end of the pattern string
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/windows/native/sun/util/locale/provider/HostLocaleProviderAdapter_md.c
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh



From mandy.chung at oracle.com  Fri Oct  5 18:22:57 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 05 Oct 2012 11:22:57 -0700
Subject: 8000354: (props) Properties.storeToXML/loadFromXML need to allow
	for alternative implementations
In-Reply-To: <506EE37A.1060507@oracle.com>
References: <506EE37A.1060507@oracle.com>
Message-ID: <506F2581.70409@oracle.com>

Alan,

Nice work and this sets a step toward the future to allow Properties to 
use a different XML parser implementation.  When there is a small 
footprint parser that Joe is working on, Properties no longer requires 
JAXP to be present.

> http://cr.openjdk.java.net/~alanb/8000354/webrev/ 
Properties.java L1157 - since loadProviderFromProperty method is called 
within a doPrivileged block, it doesn't seem to be necessary to catch 
SecurityException.

It uses the system class loader to load the service provider.  It's fine 
as it currently only supports the one provided by the platform (JAXP) as 
the SPI is internal; otherwise, it may be appropriate to use 
ServiceLoader.loadInstall.  What you have is fine.

test/java/util/Properties/LoadAndStoreXML.java
    It's good to test the cases with and without security manager.
    Could the test run both cases in the same VM (or even in the same 
test) if you explicitly save the SecurityManager before the test runs 
and restores it after the test finishes?  It's minor and I just thought 
that we might want to avoid othervm tests if possible.

Looks good otherwise.
Mandy

On 10/5/2012 6:41 AM, Alan Bateman wrote:
>
> Properties defines the loadFromXML and storeToXML methods for 
> loading/storing properties in XML format. These methods are 
> problematic for our efforts to modularize the JDK because of the 
> dependency on XML. They are also problematic for the Compact Profiles 
> proposal [1] as it is unlikely that JAXP will be present in the 
> smallest profile.
>
> As the XML parsing needs of Properties is relatively simple we are 
> thinking about including a small footprint parser that is sufficient 
> for its needs. Joe Wang is looking this. In preparation for this we 
> need to decouple Properties from the parser API that it uses and this 
> is what the proposal here is about.
>
> The webrev with the proposed changes is here:
>
> http://cr.openjdk.java.net/~alanb/8000354/webrev/
>
> Basically it introduces a JDK internal provider interface to which the 
> loadFromXML and storeToXML methods delegate. The existing code that 
> uses JAXP is moved into a provider implementation and will be used 
> when present. When not present then the intention is that it will 
> fallback to a default implementation that is the small footprint 
> provider that Joe will add later. This approach ensures that we 
> maintain compatibility (it remains to be seen whether we will have to 
> deal with a few subtle issues when using the tiny parser). For test 
> purposes there is a system property for overriding the provider, this 
> is also why the system class loader is used as the initiating loader.
>
> I should explain that when I say  "JDK internal provider interface" 
> then the service type is in sun.util.spi for now. Maybe in the future 
> it may be necessary to define a standard provider interface but it is 
> not needed at this time (in addition it would require getting the 
> security right to do that).
>
> Thanks,
>
> Alan.
>
> [1] http://openjdk.java.net/jeps/161


From bhavesh.x.patel at oracle.com  Fri Oct  5 21:22:00 2012
From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com)
Date: Fri, 05 Oct 2012 21:22:00 +0000
Subject: hg: jdk8/tl/langtools: 3 new changesets
Message-ID: <20121005212208.3DF32471D7@hg.openjdk.java.net>

Changeset: d604fd09480b
Author:    bpatel
Date:      2012-10-05 14:13 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d604fd09480b

7132631: The help-doc.html generates an invalid link to constant-values.html
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties
+ test/com/sun/javadoc/testHelpFile/TestHelpFile.java

Changeset: ef88ae455c88
Author:    bpatel
Date:      2012-10-05 14:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ef88ae455c88

7068595: html files in class-use dir do not get loaded correctly when Frames link is clicked
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! test/com/sun/javadoc/testUseOption/TestUseOption.java

Changeset: f4e45397722a
Author:    bpatel
Date:      2012-10-05 14:21 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f4e45397722a

4696488: javadoc doesn't handle UNC paths for destination directory
Reviewed-by: jjg

! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
+ test/tools/javadoc/T4696488.java



From forax at univ-mlv.fr  Fri Oct  5 21:31:25 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 05 Oct 2012 23:31:25 +0200
Subject: 8000354: (props) Properties.storeToXML/loadFromXML need to allow
	for alternative implementations
In-Reply-To: <506EE37A.1060507@oracle.com>
References: <506EE37A.1060507@oracle.com>
Message-ID: <506F51AD.6000009@univ-mlv.fr>

Hi Alan,
just some minor nits,
in Properties.XmlSupport, 'provider' should be PROVIDER because it's a 
constant and
instead of using loadProvider(), you should initialize PROVIDER in a 
static block.

line 1172, you declare a provider and line 1174, you initialize it,
I think line 1174 should do the declaration and the initialization on 
the same line.

cheers,
R?mi

On 10/05/2012 03:41 PM, Alan Bateman wrote:
>
> Properties defines the loadFromXML and storeToXML methods for 
> loading/storing properties in XML format. These methods are 
> problematic for our efforts to modularize the JDK because of the 
> dependency on XML. They are also problematic for the Compact Profiles 
> proposal [1] as it is unlikely that JAXP will be present in the 
> smallest profile.
>
> As the XML parsing needs of Properties is relatively simple we are 
> thinking about including a small footprint parser that is sufficient 
> for its needs. Joe Wang is looking this. In preparation for this we 
> need to decouple Properties from the parser API that it uses and this 
> is what the proposal here is about.
>
> The webrev with the proposed changes is here:
>
> http://cr.openjdk.java.net/~alanb/8000354/webrev/
>
> Basically it introduces a JDK internal provider interface to which the 
> loadFromXML and storeToXML methods delegate. The existing code that 
> uses JAXP is moved into a provider implementation and will be used 
> when present. When not present then the intention is that it will 
> fallback to a default implementation that is the small footprint 
> provider that Joe will add later. This approach ensures that we 
> maintain compatibility (it remains to be seen whether we will have to 
> deal with a few subtle issues when using the tiny parser). For test 
> purposes there is a system property for overriding the provider, this 
> is also why the system class loader is used as the initiating loader.
>
> I should explain that when I say  "JDK internal provider interface" 
> then the service type is in sun.util.spi for now. Maybe in the future 
> it may be necessary to define a standard provider interface but it is 
> not needed at this time (in addition it would require getting the 
> security right to do that).
>
> Thanks,
>
> Alan.
>
> [1] http://openjdk.java.net/jeps/161



From Alan.Bateman at oracle.com  Fri Oct  5 21:48:06 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 05 Oct 2012 22:48:06 +0100
Subject: 8000354: (props) Properties.storeToXML/loadFromXML need to allow
	for alternative implementations
In-Reply-To: <506F2581.70409@oracle.com>
References: <506EE37A.1060507@oracle.com> <506F2581.70409@oracle.com>
Message-ID: <506F5596.8080406@oracle.com>

On 05/10/2012 19:22, Mandy Chung wrote:
> Properties.java L1157 - since loadProviderFromProperty method is 
> called within a doPrivileged block, it doesn't seem to be necessary to 
> catch SecurityException.
Thanks for the quick review. You're right on catching the 
SecurityException, this isn't necessary.

>
> It uses the system class loader to load the service provider.  It's 
> fine as it currently only supports the one provided by the platform 
> (JAXP) as the SPI is internal; otherwise, it may be appropriate to use 
> ServiceLoader.loadInstall.  What you have is fine.
For the intended usage then loadInstalled would be fine but for testing 
it may be useful to try out providers on the class path too.

>
> test/java/util/Properties/LoadAndStoreXML.java
>    It's good to test the cases with and without security manager.
>    Could the test run both cases in the same VM (or even in the same 
> test) if you explicitly save the SecurityManager before the test runs 
> and restores it after the test finishes?  It's minor and I just 
> thought that we might want to avoid othervm tests if possible.
There aren't tests for these methods so I added this basic sanity test 
so that there is at least something in the jdk repository. You are right 
that it's more efficient if we can avoid needing to run in othervm mode. 
I've removed the @run tags and the same now exercises the methods both 
with and without a security manager.

The updated webrev is here: 
http://cr.openjdk.java.net/~alanb/8000354/webrev.02/

-Alan.


From mandy.chung at oracle.com  Fri Oct  5 21:58:45 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 05 Oct 2012 14:58:45 -0700
Subject: 8000354: (props) Properties.storeToXML/loadFromXML need to allow
	for alternative implementations
In-Reply-To: <506F5596.8080406@oracle.com>
References: <506EE37A.1060507@oracle.com> <506F2581.70409@oracle.com>
	<506F5596.8080406@oracle.com>
Message-ID: <506F5815.3090409@oracle.com>

On 10/5/2012 2:48 PM, Alan Bateman wrote:
> The updated webrev is here: 
> http://cr.openjdk.java.net/~alanb/8000354/webrev.02/

Looks good.  As for the test, I hope that the jdk_util tests do the 
proper cleanup; meaning that no samevm test sets security manager 
without resetting it before it exits.  I recalled running to some test 
failure due to some samevm test didn't do the proper cleanup.

Mandy


From jim.gish at oracle.com  Sat Oct  6 00:52:00 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Fri, 05 Oct 2012 20:52:00 -0400
Subject: RFR: 6206780 (str) Forwarding append methods in String{Buffer,
	Builder} are inconsistent
In-Reply-To: <506B281F.1090005@oracle.com>
References: <50622A25.4050605@oracle.com> <5062D4F8.9040201@oracle.com>
	<506339D1.6050909@oracle.com> <5065E7D4.6000705@oracle.com>
	<5068025A.5010303@oracle.com> <50685F03.6040706@oracle.com>
	<506A0995.6030905@oracle.com> <506AAEE1.8080207@oracle.com>
	<506AED3C.7080000@oracle.com>
	<CAHjP37Ekhyo1dQa92ZYvG_e7zjTATCKGmHKh=fv6ES_rcXvd7g@mail.gmail.com>
	<506B281F.1090005@oracle.com>
Message-ID: <506F80B0.4040105@oracle.com>

I've revamped the previous proposed change.  Please review the update at 
http://cr.openjdk.java.net/~jgish/Bug6206780-sb-append-forward/ 
<http://cr.openjdk.java.net/%7Ejgish/Bug6206780-sb-append-forward/>

This revision contains the following additions/changes:
1. consistent usage of @Overrides
2. comments on unsynchronized methods depending on other synchronized 
methods
3. overall more code coverage of insert, append, indexOf, lastIndexOf, 
etc. for both StringBuffer and StringBuilder
4. testing of StringBuffer to ensure that all public un-synchronized 
methods are actually synchronized along their call chain.  the 
StringBuffer/TestSynchronization class uses reflection to decide which 
methods to test and could be (with a bit of work on method parameter 
setup), be used to test any class for these synchronization properties.  
The motivation for this test is to provide some degree of assurance that 
modifications to StringBuffer, particularly addition of new methods, do 
not break the synchronization contract. The code also includes a 
self-test to guard against breaking the test program itself.

Thanks,
    Jim

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From maurizio.cimadamore at oracle.com  Sat Oct  6 09:51:30 2012
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Sat, 06 Oct 2012 09:51:30 +0000
Subject: hg: jdk8/tl/langtools: 7177386: Add attribution support for method
	references
Message-ID: <20121006095137.CD840471E8@hg.openjdk.java.net>

Changeset: d4b3cb1ece84
Author:    mcimadamore
Date:      2012-10-06 10:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d4b3cb1ece84

7177386: Add attribution support for method references
Summary: Add type-checking/lookup routines for method references
Reviewed-by: jjg, dlsmith

! src/share/classes/com/sun/tools/javac/code/Kinds.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/parser/Tokens.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! test/tools/javac/6758789/T6758789a.out
! test/tools/javac/6840059/T6840059.out
! test/tools/javac/7132880/T7132880.out
! test/tools/javac/Diagnostics/6722234/T6722234a_1.out
! test/tools/javac/Diagnostics/6722234/T6722234a_2.out
! test/tools/javac/Diagnostics/6722234/T6722234b_1.out
! test/tools/javac/Diagnostics/6722234/T6722234b_2.out
! test/tools/javac/Diagnostics/6722234/T6722234c.out
! test/tools/javac/Diagnostics/6862608/T6862608a.out
! test/tools/javac/Diagnostics/6862608/T6862608b.out
! test/tools/javac/T6326754.out
! test/tools/javac/diags/CheckResourceKeys.java
! test/tools/javac/diags/examples.not-yet.txt
+ test/tools/javac/diags/examples/CantAccessInnerClsConstr.java
+ test/tools/javac/diags/examples/CantApplySymbolFragment.java
+ test/tools/javac/diags/examples/CantApplySymbolsFragment.java
+ test/tools/javac/diags/examples/CantResolveLocationArgsFragment.java
+ test/tools/javac/diags/examples/CantResolveLocationArgsParamsFragment.java
! test/tools/javac/diags/examples/CyclicInference.java
! test/tools/javac/diags/examples/ExplicitParamsDoNotConformToBounds.java
! test/tools/javac/diags/examples/InaccessibleVarargsType/InaccessibleVarargsType.java
! test/tools/javac/diags/examples/IncompatibleEqUpperBounds.java
+ test/tools/javac/diags/examples/IncompatibleRetTypeInMref.java
+ test/tools/javac/diags/examples/IncompatibleThrownTypesInMref.java
! test/tools/javac/diags/examples/InferArgsLengthMismatch.java
! test/tools/javac/diags/examples/InferNoConformingAssignment.java
! test/tools/javac/diags/examples/InferVarargsArgumentMismatch.java
! test/tools/javac/diags/examples/InferredDoNotConformToEq.java
! test/tools/javac/diags/examples/InferredDoNotConformToUpper.java
! test/tools/javac/diags/examples/KindnameConstructor.java
! test/tools/javac/diags/examples/MethodReferencesNotSupported.java
! test/tools/javac/diags/examples/NoArgs.java
+ test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java
! test/tools/javac/diags/examples/NotApplicableMethodFound.java
+ test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessFragment.java
+ test/tools/javac/diags/examples/RefAmbiguousFragment.java
+ test/tools/javac/diags/examples/UnexpectedMref.java
! test/tools/javac/diags/examples/VarargsArgumentMismatch.java
! test/tools/javac/diags/examples/VerboseResolveMulti1.java
! test/tools/javac/diags/examples/WhereCaptured.java
! test/tools/javac/diags/examples/WhereCaptured1.java
! test/tools/javac/diags/examples/WhereTypeVar.java
! test/tools/javac/generics/7034511/T7034511a.out
! test/tools/javac/generics/7034511/T7034511b.out
! test/tools/javac/generics/inference/6611449/T6611449.out
! test/tools/javac/generics/inference/6638712/T6638712a.out
! test/tools/javac/generics/inference/6638712/T6638712c.out
! test/tools/javac/generics/inference/6638712/T6638712d.out
! test/tools/javac/generics/inference/6838943/T6838943.out
! test/tools/javac/generics/inference/7086586/T7086586.out
! test/tools/javac/generics/inference/7177306/T7177306b.out
! test/tools/javac/lambda/MethodReferenceParserTest.java
! test/tools/javac/quid/T6999438.out
! test/tools/javac/varargs/6313164/T6313164.out



From Alan.Bateman at oracle.com  Sat Oct  6 11:30:31 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 06 Oct 2012 12:30:31 +0100
Subject: 8000354: (props) Properties.storeToXML/loadFromXML need to allow
	for alternative implementations
In-Reply-To: <506F51AD.6000009@univ-mlv.fr>
References: <506EE37A.1060507@oracle.com> <506F51AD.6000009@univ-mlv.fr>
Message-ID: <50701657.7070701@oracle.com>

On 05/10/2012 22:31, Remi Forax wrote:
> Hi Alan,
> just some minor nits,
> in Properties.XmlSupport, 'provider' should be PROVIDER because it's a 
> constant and
> instead of using loadProvider(), you should initialize PROVIDER in a 
> static block.
>
> line 1172, you declare a provider and line 1174, you initialize it,
> I think line 1174 should do the declaration and the initialization on 
> the same line.
Thanks R?mi. You're right, it probably should be PROVIDER rather than 
"provider", I'll change that before I push this. I think I'll leave the 
initialization in the 3 methods rather than a jolly giant static 
initializer, just to keep it readable. I can move the declaration of 
provider to L1174, that is a bit nicer.

-Alan.


From forax at univ-mlv.fr  Sat Oct  6 12:42:41 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 06 Oct 2012 14:42:41 +0200
Subject: 8000354: (props) Properties.storeToXML/loadFromXML need to allow
	for alternative implementations
In-Reply-To: <50701657.7070701@oracle.com>
References: <506EE37A.1060507@oracle.com> <506F51AD.6000009@univ-mlv.fr>
	<50701657.7070701@oracle.com>
Message-ID: <50702741.8090901@univ-mlv.fr>

On 10/06/2012 01:30 PM, Alan Bateman wrote:
> On 05/10/2012 22:31, Remi Forax wrote:
>> Hi Alan,
>> just some minor nits,
>> in Properties.XmlSupport, 'provider' should be PROVIDER because it's 
>> a constant and
>> instead of using loadProvider(), you should initialize PROVIDER in a 
>> static block.
>>
>> line 1172, you declare a provider and line 1174, you initialize it,
>> I think line 1174 should do the declaration and the initialization on 
>> the same line.
> Thanks R?mi. You're right, it probably should be PROVIDER rather than 
> "provider", I'll change that before I push this. I think I'll leave 
> the initialization in the 3 methods rather than a jolly giant static 
> initializer, just to keep it readable. I can move the declaration of 
> provider to L1174, that is a bit nicer.

Thanks Alan,
I'm fine with methods loadProviderAsService and 
loadProviderFromProperty, but I think you can remove loadProvider
because PROVIDER can be initialized in a static block.

private static final XmlPropertiesProvider PROVIDER;
static {
    PROVIDER = AccessController.doPrivileged(
        new PrivilegedAction<XmlPropertiesProvider>() {
         ...
        }});
}

>
> -Alan.

cheers,
R?mi



From Alan.Bateman at oracle.com  Sat Oct  6 13:05:53 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 06 Oct 2012 14:05:53 +0100
Subject: 8000354: (props) Properties.storeToXML/loadFromXML need to allow
	for alternative implementations
In-Reply-To: <50702741.8090901@univ-mlv.fr>
References: <506EE37A.1060507@oracle.com> <506F51AD.6000009@univ-mlv.fr>
	<50701657.7070701@oracle.com> <50702741.8090901@univ-mlv.fr>
Message-ID: <50702CB1.1090809@oracle.com>

On 06/10/2012 13:42, Remi Forax wrote:
>
> Thanks Alan,
> I'm fine with methods loadProviderAsService and 
> loadProviderFromProperty, but I think you can remove loadProvider
> because PROVIDER can be initialized in a static block.
>
> private static final XmlPropertiesProvider PROVIDER;
> static {
>    PROVIDER = AccessController.doPrivileged(
>        new PrivilegedAction<XmlPropertiesProvider>() {
>         ...
>        }});
> }
Yes, it could be done this way too but I actually prefer the way it is 
now (I realize this is somewhat subjective).

-Alan.


From alan.bateman at oracle.com  Sat Oct  6 13:08:47 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 06 Oct 2012 13:08:47 +0000
Subject: hg: jdk8/tl/jdk: 8000354: (props) Properties.storeToXML/loadFromXML
	need to allow for alternative implementations
Message-ID: <20121006130910.CB0FF471EB@hg.openjdk.java.net>

Changeset: f65871e75fde
Author:    alanb
Date:      2012-10-06 13:56 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f65871e75fde

8000354: (props) Properties.storeToXML/loadFromXML need to allow for alternative implementations
Reviewed-by: mchung, forax

! make/java/java/FILES_java.gmk
! make/sun/util/Makefile
! src/share/classes/java/util/Properties.java
+ src/share/classes/sun/util/spi/XmlPropertiesProvider.java
+ src/share/classes/sun/util/xml/META-INF/services/sun.util.spi.XmlPropertiesProvider
+ src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java
- src/share/classes/sun/util/xml/XMLUtils.java
+ test/java/util/Properties/CustomProvider.java
+ test/java/util/Properties/LoadAndStoreXML.java
+ test/java/util/Properties/MyXmlPropertiesProvider.java



From forax at univ-mlv.fr  Sat Oct  6 13:34:47 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 06 Oct 2012 15:34:47 +0200
Subject: 8000354: (props) Properties.storeToXML/loadFromXML need to allow
	for alternative implementations
In-Reply-To: <50702CB1.1090809@oracle.com>
References: <506EE37A.1060507@oracle.com> <506F51AD.6000009@univ-mlv.fr>
	<50701657.7070701@oracle.com> <50702741.8090901@univ-mlv.fr>
	<50702CB1.1090809@oracle.com>
Message-ID: <50703377.2070103@univ-mlv.fr>

On 10/06/2012 03:05 PM, Alan Bateman wrote:
> On 06/10/2012 13:42, Remi Forax wrote:
>>
>> Thanks Alan,
>> I'm fine with methods loadProviderAsService and 
>> loadProviderFromProperty, but I think you can remove loadProvider
>> because PROVIDER can be initialized in a static block.
>>
>> private static final XmlPropertiesProvider PROVIDER;
>> static {
>>    PROVIDER = AccessController.doPrivileged(
>>        new PrivilegedAction<XmlPropertiesProvider>() {
>>         ...
>>        }});
>> }
> Yes, it could be done this way too but I actually prefer the way it is 
> now (I realize this is somewhat subjective).
>
> -Alan.

No problem, I'm fine with that.

R?mi



From jim.gish at oracle.com  Sat Oct  6 13:58:58 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Sat, 06 Oct 2012 09:58:58 -0400
Subject: 8000354: (props) Properties.storeToXML/loadFromXML need to allow
	for alternative implementations
In-Reply-To: <506EE37A.1060507@oracle.com>
References: <506EE37A.1060507@oracle.com>
Message-ID: <50703922.2020708@oracle.com>

Looks good, Alan.

A minor typo:
  For the javadoc of private static class XmlSupport (line 1128 of 
java/util/Properties.java), probably should say "fully qualifed name" 
rather than "full-qualified name"

Jim

On 10/05/2012 09:41 AM, Alan Bateman wrote:
>
> Properties defines the loadFromXML and storeToXML methods for 
> loading/storing properties in XML format. These methods are 
> problematic for our efforts to modularize the JDK because of the 
> dependency on XML. They are also problematic for the Compact Profiles 
> proposal [1] as it is unlikely that JAXP will be present in the 
> smallest profile.
>
> As the XML parsing needs of Properties is relatively simple we are 
> thinking about including a small footprint parser that is sufficient 
> for its needs. Joe Wang is looking this. In preparation for this we 
> need to decouple Properties from the parser API that it uses and this 
> is what the proposal here is about.
>
> The webrev with the proposed changes is here:
>
> http://cr.openjdk.java.net/~alanb/8000354/webrev/
>
> Basically it introduces a JDK internal provider interface to which the 
> loadFromXML and storeToXML methods delegate. The existing code that 
> uses JAXP is moved into a provider implementation and will be used 
> when present. When not present then the intention is that it will 
> fallback to a default implementation that is the small footprint 
> provider that Joe will add later. This approach ensures that we 
> maintain compatibility (it remains to be seen whether we will have to 
> deal with a few subtle issues when using the tiny parser). For test 
> purposes there is a system property for overriding the provider, this 
> is also why the system class loader is used as the initiating loader.
>
> I should explain that when I say  "JDK internal provider interface" 
> then the service type is in sun.util.spi for now. Maybe in the future 
> it may be necessary to define a standard provider interface but it is 
> not needed at this time (in addition it would require getting the 
> security right to do that).
>
> Thanks,
>
> Alan.
>
> [1] http://openjdk.java.net/jeps/161

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From rednaxelafx at gmail.com  Sat Oct  6 14:58:40 2012
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Sat, 6 Oct 2012 22:58:40 +0800
Subject: StackTraceElement question
In-Reply-To: <20121005190447.2365997124@rebar.astron.com>
References: <20121005190447.2365997124@rebar.astron.com>
Message-ID: <CA+cQ+tTDfCrU7h5uDRs=dWO=Y1Cs3agSqv9wOeCsrUJb0w3epQ@mail.gmail.com>

Hi,

I believe this discussion belongs to core-libs-dev list better. cc'd.

- Kris

On Sat, Oct 6, 2012 at 3:04 AM, Christos Zoulas <christos at zoulas.com> wrote:

> Hi,
>
> I don't know if this belongs to this list, but if it does not,
> please point me to where it does. I think that it would be nice if
> StackTraceElement which currently contains:
>
>     boolean     equals(Object obj)
>     String      getClassName()
>     String      getFileName()
>     int         getLineNumber()
>     String      getMethodName()
>     int         hashCode()
>     boolean     isNativeMethod()
>     String      toString()
>
> It would be more useful for it to also contain:
>
>     Class<?>    getClass()
>
> The reason I am asking, is because I have an application where I
> would like to find the enclosing class from where the exception is
> thrown not the superclass, but I cannot deduce that from the class
> name. If STE contained the above method, I could do:
>
>         Class<?> c = ste.getClass();
>         while (c.getEnclosingClass() != null) {
>              c = c.getEnclosingClass();
>         }
>         return c.getName();
>
> to find the class I want, and getClassName() could be just a wrapper:
>
>         String getClassName() {
>             return getClass().getName();
>         }
>
> Is there any reason to store the name instead of the Class<?>? Is it
> possible to fix this in a future version of the jdk?
>
> thanks
>
> christos
>


From Alan.Bateman at oracle.com  Sun Oct  7 14:24:34 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 07 Oct 2012 15:24:34 +0100
Subject: StackTraceElement question
In-Reply-To: <CA+cQ+tTDfCrU7h5uDRs=dWO=Y1Cs3agSqv9wOeCsrUJb0w3epQ@mail.gmail.com>
References: <20121005190447.2365997124@rebar.astron.com>
	<CA+cQ+tTDfCrU7h5uDRs=dWO=Y1Cs3agSqv9wOeCsrUJb0w3epQ@mail.gmail.com>
Message-ID: <507190A2.7070106@oracle.com>

On 06/10/2012 15:58, Krystal Mok wrote:
> :
> Is there any reason to store the name instead of the Class<?>? Is it
> possible to fix this in a future version of the jdk?
>
> thanks
>
> christos
I think this would require a bit of analysis as to the issues that might 
turn up. For example, would it allow access to class objects that code 
would not normally have access to? Serialization also comes to mind. 
There may be other concerns too.

-Alan


From Alan.Bateman at oracle.com  Sun Oct  7 18:42:24 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 07 Oct 2012 19:42:24 +0100
Subject: RFR: 6206780 (str) Forwarding append methods in String{Buffer,
	Builder} are inconsistent
In-Reply-To: <506F80B0.4040105@oracle.com>
References: <50622A25.4050605@oracle.com> <5062D4F8.9040201@oracle.com>
	<506339D1.6050909@oracle.com> <5065E7D4.6000705@oracle.com>
	<5068025A.5010303@oracle.com> <50685F03.6040706@oracle.com>
	<506A0995.6030905@oracle.com> <506AAEE1.8080207@oracle.com>
	<506AED3C.7080000@oracle.com>
	<CAHjP37Ekhyo1dQa92ZYvG_e7zjTATCKGmHKh=fv6ES_rcXvd7g@mail.gmail.com>
	<506B281F.1090005@oracle.com> <506F80B0.4040105@oracle.com>
Message-ID: <5071CD10.5050109@oracle.com>

On 06/10/2012 01:52, Jim Gish wrote:
> I've revamped the previous proposed change.  Please review the update 
> at http://cr.openjdk.java.net/~jgish/Bug6206780-sb-append-forward/ 
> <http://cr.openjdk.java.net/%7Ejgish/Bug6206780-sb-append-forward/>
>
> This revision contains the following additions/changes:
> 1. consistent usage of @Overrides
> 2. comments on unsynchronized methods depending on other synchronized 
> methods
> 3. overall more code coverage of insert, append, indexOf, lastIndexOf, 
> etc. for both StringBuffer and StringBuilder
> 4. testing of StringBuffer to ensure that all public un-synchronized 
> methods are actually synchronized along their call chain.  the 
> StringBuffer/TestSynchronization class uses reflection to decide which 
> methods to test and could be (with a bit of work on method parameter 
> setup), be used to test any class for these synchronization 
> properties.  The motivation for this test is to provide some degree of 
> assurance that modifications to StringBuffer, particularly addition of 
> new methods, do not break the synchronization contract. The code also 
> includes a self-test to guard against breaking the test program itself.
>
I'm skimmed over this and StringBuffer looks a lot better, thanks for 
reverting back and adding the comments.

I don't have time to review the tests just now but it looks like you've 
added a test of useful tests. I did look at 
TestSynchronization.testSynchronized and the approach looks right. The 
timeout is short so there will periodically be false positives but 
that's okay as increasing the timeout will slow down the test (the main 
thing I was looking for was the potential for false negatives).

-Alan


From Alan.Bateman at oracle.com  Sun Oct  7 19:35:17 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 07 Oct 2012 20:35:17 +0100
Subject: 7173494: some jdk tests are not run in test/Makefile
Message-ID: <5071D975.7080904@oracle.com>


This one is a small clean-up of the test targets defined in 
jdk/test/Makefile. The union of the tests executed by each of the make 
targets should be the entire test suite but this isn't so, there are 
small number of tests that aren't run.

I've renamed jdk_misc to jdk_other (the original name is confusing 
because of sun.misc) and expanded it to run additional areas that have a 
small number of tests. If more tests are added to these areas over time 
then it may make sense to add new targets in the future.

"make jdk_jmx" now runs the JMX tests as it was confusing to have those 
tests split between management1 and management2. I've also renamed 
jdk_tools1 to jdk_jdi to make it clear that this is the JDI tests rather 
than tools. When Kelly originally set this up he split the NIO tests 
into 3 batches, I don't think this is necessary any longer (the really 
slow tests have been long been dialed down or changed to run much faster).

The webrev with the proposed changes is here:
http://cr.openjdk.java.net/~alanb/7173494/webrev/

-Alan.


From rob.mckenna at oracle.com  Sun Oct  7 19:48:16 2012
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Sun, 07 Oct 2012 20:48:16 +0100
Subject: RFR: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java
	failing intermittently [sol]
In-Reply-To: <CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
References: <506CB1C3.5050009@oracle.com> <506D3D14.4070304@oracle.com>
	<CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
Message-ID: <5071DC80.3080507@oracle.com>

Thanks Martin,

I've uploaded a new webrev to:

http://cr.openjdk.java.net/~robm/7152183/webrev.02/ 
<http://cr.openjdk.java.net/%7Erobm/7152183/webrev.02/>

Let me know if this does the job.

     -Rob

On 04/10/12 18:24, Martin Buchholz wrote:
> Hi all,
>
> Yeah, this particular test is rather racy - sorry about that.
> We need to call p.destroy when the other thread is in the middle of a 
> read() system call, and there's no way to know for sure - seeing java 
> "read" in the stacktrace is not enough, since it may not have gotten 
> to the system call yet.
>
> suggestions:
> pull the computation of the inputstream before the latch to narrow the 
> window a bit:
>
> final InputStream s;
> switch (action & 0x1) {
> case 0: s = p.getInputStream(); break;
> case 1: s = p.getErrorStream(); break;
> default: throw
> }
> latch.countdown();
> switch (action & 0x2) {
> case 0: r = s.read(); break;
> case 1: r = s.read(bytes); break;
> }
>
> Examining the stack trace to look for "read" is clever but does not 
> actually eliminate the race.
>
> Looking in UNIXProcess.java.solaris I see the use 
> of DeferredCloseInputStream.  We can eliminate the race on solaris 
> (i.e. if the inputstream.getclass isDeferredCloseInputStream)  by 
> looping until the useCount field of the DeferredCloseInputStream is > 
> 0, using ugly but effective reflective code.  This should allow us to 
> avoid the horrible sleep for 200ms.
>
> You should use yield instead of sleep between loop iterations while 
> waiting for the useCount to be bumped.
>
> On other platforms this is not an issue, I think.
>
> Martin
>
> On Thu, Oct 4, 2012 at 12:39 AM, Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>     On 03/10/2012 22:44, Rob McKenna wrote:
>
>         Hi folks,
>
>         The only way I can see this test failing in this manner[*] is
>         if we destroy the process before we begin the read. That being
>         the case I've jacked up the sleep (giving the reader thread a
>         little more time to get cracking) and added a check to see if
>         the threads stack has entered a read call.
>
>         http://cr.openjdk.java.net/~robm/7152183/webrev.01/
>         <http://cr.openjdk.java.net/%7Erobm/7152183/webrev.01/>
>         <http://cr.openjdk.java.net/%7Erobm/7152183/webrev.01/>
>
>         Feedback greatly appreciated.
>
>             -Rob
>
>
>         [*] le trace:
>
>     So stack traces are masculine, I didn't know that.
>
>     I think your analysis is right, it's just that the sleep(10) is
>     not sufficient to ensure that the thread gets to the read method.
>     Increasing the sleep is probably sufficient. The hack to look at
>     the stack trace makes it more robust for really extreme cases, at
>     the cost of potential further maintenance in the event that the
>     implementation changes. In any case it's good to resolve this
>     intermittent test failure.
>
>     -Alan
>
>



From peter.levart at gmail.com  Sun Oct  7 22:17:12 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 08 Oct 2012 00:17:12 +0200
Subject: RFR: 6206780 (str) Forwarding append methods in String{Buffer,
	Builder} are inconsistent
In-Reply-To: <5071CD10.5050109@oracle.com>
References: <50622A25.4050605@oracle.com> <5062D4F8.9040201@oracle.com>
	<506339D1.6050909@oracle.com> <5065E7D4.6000705@oracle.com>
	<5068025A.5010303@oracle.com> <50685F03.6040706@oracle.com>
	<506A0995.6030905@oracle.com> <506AAEE1.8080207@oracle.com>
	<506AED3C.7080000@oracle.com>
	<CAHjP37Ekhyo1dQa92ZYvG_e7zjTATCKGmHKh=fv6ES_rcXvd7g@mail.gmail.com>
	<506B281F.1090005@oracle.com> <506F80B0.4040105@oracle.com>
	<5071CD10.5050109@oracle.com>
Message-ID: <5071FF68.8030804@gmail.com>

On 10/07/2012 08:42 PM, Alan Bateman wrote:
> On 06/10/2012 01:52, Jim Gish wrote:
>> I've revamped the previous proposed change.  Please review the update 
>> at http://cr.openjdk.java.net/~jgish/Bug6206780-sb-append-forward/ 
>> <http://cr.openjdk.java.net/%7Ejgish/Bug6206780-sb-append-forward/>
>>
>> This revision contains the following additions/changes:
>> 1. consistent usage of @Overrides
>> 2. comments on unsynchronized methods depending on other synchronized 
>> methods
>> 3. overall more code coverage of insert, append, indexOf, 
>> lastIndexOf, etc. for both StringBuffer and StringBuilder
>> 4. testing of StringBuffer to ensure that all public un-synchronized 
>> methods are actually synchronized along their call chain.  the 
>> StringBuffer/TestSynchronization class uses reflection to decide 
>> which methods to test and could be (with a bit of work on method 
>> parameter setup), be used to test any class for these synchronization 
>> properties.  The motivation for this test is to provide some degree 
>> of assurance that modifications to StringBuffer, particularly 
>> addition of new methods, do not break the synchronization contract. 
>> The code also includes a self-test to guard against breaking the test 
>> program itself.
>>
> I'm skimmed over this and StringBuffer looks a lot better, thanks for 
> reverting back and adding the comments.
>
> I don't have time to review the tests just now but it looks like 
> you've added a test of useful tests. I did look at 
> TestSynchronization.testSynchronized and the approach looks right. The 
> timeout is short so there will periodically be false positives but 
> that's okay as increasing the timeout will slow down the test (the 
> main thing I was looking for was the potential for false negatives).
>
> -Alan

Hi Jim,

Here's a way to test for synchronization deterministically. And it takes 
as much time as the testing methods runs (no timeouts):


public class SyncTest
{
     public static class MyClass
     {
         public synchronized void synchronized_method() throws 
InterruptedException
         {
             Thread.sleep(1000);
         }

         public void not_synchronized_method() throws InterruptedException
         {
             Thread.sleep(1000);
         }

         public void indirectly_synchronized_method() throws 
InterruptedException
         {
             Thread.sleep(100);
             synchronized_method();
         }
     }

     private static boolean isSynchronized(Method m, Object target)
     {
         Thread t = new Thread(new InvokeTask(m, target));

         Boolean isSynchronized = null;

         synchronized (target)
         {
             t.start();

             while (isSynchronized == null)
             {
                 switch (t.getState())
                 {
                     case NEW:
                     case RUNNABLE:
                     case WAITING:
                     case TIMED_WAITING:
                         Thread.yield();
                         break;
                     case BLOCKED:
                         isSynchronized = true;
                         break;
                     case TERMINATED:
                         isSynchronized = false;
                         break;
                 }
             }
         }

         try
         {
             t.join();
         }
         catch (InterruptedException ex)
         {
             ex.printStackTrace();
         }

         return isSynchronized;
     }

     public static void main(String[] args)
     {
         Method[] methods = MyClass.class.getDeclaredMethods();
         Object target = new MyClass();

         for (Method m : methods)
         {
             System.out.println(m + " - isSynchronized: " + 
isSynchronized(m, target));;
         }
     }

     static class InvokeTask implements Runnable
     {
         private final Method m;
         private final Object target;
         private final Object[] args;

         InvokeTask(Method m, Object target, Object...args)
         {
             this.m = m;
             this.target = target;
             this.args = args;
         }

         @Override
         public void run()
         {
             try
             {
                 m.invoke(target, args);
             }
             catch (Exception e)
             {
                 e.printStackTrace();
             }
         }
     }
}



Regards, Peter



From david.holmes at oracle.com  Sun Oct  7 23:27:27 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 08 Oct 2012 09:27:27 +1000
Subject: StackTraceElement question
In-Reply-To: <CA+cQ+tTDfCrU7h5uDRs=dWO=Y1Cs3agSqv9wOeCsrUJb0w3epQ@mail.gmail.com>
References: <20121005190447.2365997124@rebar.astron.com>
	<CA+cQ+tTDfCrU7h5uDRs=dWO=Y1Cs3agSqv9wOeCsrUJb0w3epQ@mail.gmail.com>
Message-ID: <50720FDF.3070709@oracle.com>

> On Sat, Oct 6, 2012 at 3:04 AM, Christos Zoulas<christos at zoulas.com>  wrote:
>
>> Hi,
>>
>> I don't know if this belongs to this list, but if it does not,
>> please point me to where it does. I think that it would be nice if
>> StackTraceElement which currently contains:
>>
>>      boolean     equals(Object obj)
>>      String      getClassName()
>>      String      getFileName()
>>      int         getLineNumber()
>>      String      getMethodName()
>>      int         hashCode()
>>      boolean     isNativeMethod()
>>      String      toString()
>>
>> It would be more useful for it to also contain:
>>
>>      Class<?>     getClass()
>>
>> The reason I am asking, is because I have an application where I
>> would like to find the enclosing class from where the exception is
>> thrown not the superclass, but I cannot deduce that from the class
>> name. If STE contained the above method, I could do:
>>
>>          Class<?>  c = ste.getClass();
>>          while (c.getEnclosingClass() != null) {
>>               c = c.getEnclosingClass();
>>          }
>>          return c.getName();

Can't you just do Class.forName(getClassName()) and then find the 
enclosing class?

David
-----

>> to find the class I want, and getClassName() could be just a wrapper:
>>
>>          String getClassName() {
>>              return getClass().getName();
>>          }
>>
>> Is there any reason to store the name instead of the Class<?>? Is it
>> possible to fix this in a future version of the jdk?
>>
>> thanks
>>
>> christos
>>


From weijun.wang at oracle.com  Mon Oct  8 02:43:54 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Mon, 08 Oct 2012 02:43:54 +0000
Subject: hg: jdk8/tl/jdk: 7201053: Krb5LoginModule shows NPE when both
	useTicketCache and storeKey are set to true
Message-ID: <20121008024417.12A4D471FE@hg.openjdk.java.net>

Changeset: 92f3a96f3c78
Author:    weijun
Date:      2012-10-08 10:42 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92f3a96f3c78

7201053: Krb5LoginModule shows NPE when both useTicketCache and storeKey are set to true
Reviewed-by: mullan

! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java
+ test/sun/security/krb5/auto/UseCacheAndStoreKey.java



From rednaxelafx at gmail.com  Mon Oct  8 11:33:38 2012
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Mon, 8 Oct 2012 19:33:38 +0800
Subject: StackTraceElement question
In-Reply-To: <50720FDF.3070709@oracle.com>
References: <20121005190447.2365997124@rebar.astron.com>
	<CA+cQ+tTDfCrU7h5uDRs=dWO=Y1Cs3agSqv9wOeCsrUJb0w3epQ@mail.gmail.com>
	<50720FDF.3070709@oracle.com>
Message-ID: <CA+cQ+tTOYv8qP=v6zqEa4eR02zx+dA+=Dfq423ROZgyA6x7Fvw@mail.gmail.com>

On Mon, Oct 8, 2012 at 7:27 AM, David Holmes <david.holmes at oracle.com>wrote:

> On Sat, Oct 6, 2012 at 3:04 AM, Christos Zoulas<christos at zoulas.com>
>>  wrote:
>>
>>  Hi,
>>>
>>> I don't know if this belongs to this list, but if it does not,
>>> please point me to where it does. I think that it would be nice if
>>> StackTraceElement which currently contains:
>>>
>>>      boolean     equals(Object obj)
>>>      String      getClassName()
>>>      String      getFileName()
>>>      int         getLineNumber()
>>>      String      getMethodName()
>>>      int         hashCode()
>>>      boolean     isNativeMethod()
>>>      String      toString()
>>>
>>> It would be more useful for it to also contain:
>>>
>>>      Class<?>     getClass()
>>>
>>> The reason I am asking, is because I have an application where I
>>> would like to find the enclosing class from where the exception is
>>> thrown not the superclass, but I cannot deduce that from the class
>>> name. If STE contained the above method, I could do:
>>>
>>>          Class<?>  c = ste.getClass();
>>>          while (c.getEnclosingClass() != null) {
>>>               c = c.getEnclosingClass();
>>>          }
>>>          return c.getName();
>>>
>>
> Can't you just do Class.forName(getClassName()) and then find the
> enclosing class?
>
> There could be potential class loader issues to
use Class.forName(getClassName()) in this case (most probably caused by
reflective calls).
But then again, giving the user a reference to instead of the name of a
class really gives the user more information then what's been given now
(e.g. class loader info). Which is not necessarily a good thing. I'd second
Alan on having to do more analysis.

- Kris


> David
> -----
>
>
>  to find the class I want, and getClassName() could be just a wrapper:
>>>
>>>          String getClassName() {
>>>              return getClass().getName();
>>>          }
>>>
>>> Is there any reason to store the name instead of the Class<?>? Is it
>>> possible to fix this in a future version of the jdk?
>>>
>>> thanks
>>>
>>> christos
>>>
>>>


From christos at zoulas.com  Mon Oct  8 11:48:42 2012
From: christos at zoulas.com (Christos Zoulas)
Date: Mon, 8 Oct 2012 07:48:42 -0400
Subject: StackTraceElement question
In-Reply-To: <CA+cQ+tTOYv8qP=v6zqEa4eR02zx+dA+=Dfq423ROZgyA6x7Fvw@mail.gmail.com>
	from Krystal Mok (Oct  8,  7:33pm)
Message-ID: <20121008114842.87C7F97124@rebar.astron.com>

On Oct 8,  7:33pm, rednaxelafx at gmail.com (Krystal Mok) wrote:
-- Subject: Re: StackTraceElement question

| > Can't you just do Class.forName(getClassName()) and then find the
| > enclosing class?
| >
| > There could be potential class loader issues to
| use Class.forName(getClassName()) in this case (most probably caused by
| reflective calls).
| But then again, giving the user a reference to instead of the name of a
| class really gives the user more information then what's been given now
| (e.g. class loader info). Which is not necessarily a good thing. I'd second
| Alan on having to do more analysis.

There is also the problem of having a class hierarchy like:

class A extends class I
class B extends class I

and then trying to figure out if it is A or B when you just have I from
that StackTraceElement.

Alan is right, there could be security issues providing the class, and
it is annoying and expensive to have to deal with them in the code
that fills in StackTraceElement, and there could be also serialization
issues. I think it is still a useful change though...

christos


From david.holmes at oracle.com  Mon Oct  8 13:07:46 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 08 Oct 2012 23:07:46 +1000
Subject: StackTraceElement question
In-Reply-To: <20121008114842.87C7F97124@rebar.astron.com>
References: <20121008114842.87C7F97124@rebar.astron.com>
Message-ID: <5072D022.8060002@oracle.com>

On 8/10/2012 9:48 PM, christos at zoulas.com wrote:
> On Oct 8,  7:33pm, rednaxelafx at gmail.com (Krystal Mok) wrote:
> -- Subject: Re: StackTraceElement question
>
> |>  Can't you just do Class.forName(getClassName()) and then find the
> |>  enclosing class?
> |>
> |>  There could be potential class loader issues to
> | use Class.forName(getClassName()) in this case (most probably caused by
> | reflective calls).
> | But then again, giving the user a reference to instead of the name of a
> | class really gives the user more information then what's been given now
> | (e.g. class loader info). Which is not necessarily a good thing. I'd second
> | Alan on having to do more analysis.
>
> There is also the problem of having a class hierarchy like:
>
> class A extends class I
> class B extends class I
>
> and then trying to figure out if it is A or B when you just have I from
> that StackTraceElement.

Can't say I have ever studied stacktraces in depth but I would expect to 
see A or B not I as the name.

The loader issue is real, you'd have to know where to locate the class. 
But another reason to not store the Class reference is that it may 
prevent the class from being unloaded. For every use-case there's a 
counter-use-case.

David

> Alan is right, there could be security issues providing the class, and
> it is annoying and expensive to have to deal with them in the code
> that fills in StackTraceElement, and there could be also serialization
> issues. I think it is still a useful change though...
>
> christos


From david.holmes at oracle.com  Mon Oct  8 13:14:07 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 08 Oct 2012 23:14:07 +1000
Subject: StackTraceElement question
In-Reply-To: <5072D022.8060002@oracle.com>
References: <20121008114842.87C7F97124@rebar.astron.com>
	<5072D022.8060002@oracle.com>
Message-ID: <5072D19F.3090205@oracle.com>

On 8/10/2012 11:07 PM, David Holmes wrote:
> On 8/10/2012 9:48 PM, christos at zoulas.com wrote:
>> On Oct 8, 7:33pm, rednaxelafx at gmail.com (Krystal Mok) wrote:
>> -- Subject: Re: StackTraceElement question
>>
>> |> Can't you just do Class.forName(getClassName()) and then find the
>> |> enclosing class?
>> |>
>> |> There could be potential class loader issues to
>> | use Class.forName(getClassName()) in this case (most probably caused by
>> | reflective calls).
>> | But then again, giving the user a reference to instead of the name of a
>> | class really gives the user more information then what's been given now
>> | (e.g. class loader info). Which is not necessarily a good thing. I'd
>> second
>> | Alan on having to do more analysis.
>>
>> There is also the problem of having a class hierarchy like:
>>
>> class A extends class I
>> class B extends class I
>>
>> and then trying to figure out if it is A or B when you just have I from
>> that StackTraceElement.
>
> Can't say I have ever studied stacktraces in depth but I would expect to
> see A or B not I as the name.

No I take that back. The class would be that defining the method, not 
the class of the object the method is invoked upon.

But then it doesn't matter if you store the class or the class name, you 
are going to get I not A or B.

David
-----

> The loader issue is real, you'd have to know where to locate the class.
> But another reason to not store the Class reference is that it may
> prevent the class from being unloaded. For every use-case there's a
> counter-use-case.
>
> David
>
>> Alan is right, there could be security issues providing the class, and
>> it is annoying and expensive to have to deal with them in the code
>> that fills in StackTraceElement, and there could be also serialization
>> issues. I think it is still a useful change though...
>>
>> christos


From christos at zoulas.com  Mon Oct  8 14:25:18 2012
From: christos at zoulas.com (Christos Zoulas)
Date: Mon, 8 Oct 2012 10:25:18 -0400
Subject: StackTraceElement question
In-Reply-To: <5072D022.8060002@oracle.com> from David Holmes (Oct  8, 11:07pm)
Message-ID: <20121008142518.E2EFB97124@rebar.astron.com>

On Oct 8, 11:07pm, david.holmes at oracle.com (David Holmes) wrote:
-- Subject: Re: StackTraceElement question

| > There is also the problem of having a class hierarchy like:
| >
| > class A extends class I
| > class B extends class I
| >
| > and then trying to figure out if it is A or B when you just have I from
| > that StackTraceElement.
| 
| Can't say I have ever studied stacktraces in depth but I would expect to 
| see A or B not I as the name.

I was expecting the same, but this is not the case:

$ cat StackTrace.java
class I {
    public void run()
        throws Exception
    {
        throw new Exception();
    }
}

class A
   extends I
{
}

public class StackTrace {
    public static void main(String[] args) {
        try {
            A a = new A();
            a.run();
        } catch (Exception e) {
            StackTraceElement[] ste = e.getStackTrace();
            for (int i = 0; i < ste.length; i++)
                System.out.println(ste[i].getClassName());
        }
    }
}
$ javac Stacktrace.java
$ java -cp . StackTrace
I
StackTrace

| The loader issue is real, you'd have to know where to locate the class. 
| But another reason to not store the Class reference is that it may 
| prevent the class from being unloaded. For every use-case there's a 
| counter-use-case.

Yes, the class loader issue is real. I am not sure about the Class
reference preventing the class to be unloaded; after all, the
StackTraceElements are typically transient (when the exception goes
out of context, they can be GC'ed); if not, then the reference can
be held until the StackTraceElement is not reachable. I don't think
that keeping the reference is such a big issue to even consider
making this Weak. I am really worried about the security implications.
As far as serialization goes, it could be made transient for
compatibility.  Anyway, I would be more than happy the StackTraceElement
contained the outermost enclosing class instead of the immediately
enclosing one.  Returning the Class<?> instance is still the most
versatile, but the one that needs most consideration because of its
implications.

christos

christos


From forax at univ-mlv.fr  Mon Oct  8 14:32:04 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 08 Oct 2012 16:32:04 +0200
Subject: StackTraceElement question
In-Reply-To: <5072D022.8060002@oracle.com>
References: <20121008114842.87C7F97124@rebar.astron.com>
	<5072D022.8060002@oracle.com>
Message-ID: <5072E3E4.1050709@univ-mlv.fr>

StackTraceElement are Serializable and because they don't store any class,
you can send an exception from the server back to the client without 
requiring
that the client knows the classes loaded by the server.

So at least, if the class is provided, this should be done optionally 
because
the class should not be serialized.

cheers,
R?mi

On 10/08/2012 03:07 PM, David Holmes wrote:
> On 8/10/2012 9:48 PM, christos at zoulas.com wrote:
>> On Oct 8,  7:33pm, rednaxelafx at gmail.com (Krystal Mok) wrote:
>> -- Subject: Re: StackTraceElement question
>>
>> |>  Can't you just do Class.forName(getClassName()) and then find the
>> |>  enclosing class?
>> |>
>> |>  There could be potential class loader issues to
>> | use Class.forName(getClassName()) in this case (most probably 
>> caused by
>> | reflective calls).
>> | But then again, giving the user a reference to instead of the name 
>> of a
>> | class really gives the user more information then what's been given 
>> now
>> | (e.g. class loader info). Which is not necessarily a good thing. 
>> I'd second
>> | Alan on having to do more analysis.
>>
>> There is also the problem of having a class hierarchy like:
>>
>> class A extends class I
>> class B extends class I
>>
>> and then trying to figure out if it is A or B when you just have I from
>> that StackTraceElement.
>
> Can't say I have ever studied stacktraces in depth but I would expect 
> to see A or B not I as the name.
>
> The loader issue is real, you'd have to know where to locate the 
> class. But another reason to not store the Class reference is that it 
> may prevent the class from being unloaded. For every use-case there's 
> a counter-use-case.
>
> David
>
>> Alan is right, there could be security issues providing the class, and
>> it is annoying and expensive to have to deal with them in the code
>> that fills in StackTraceElement, and there could be also serialization
>> issues. I think it is still a useful change though...
>>
>> christos



From rednaxelafx at gmail.com  Mon Oct  8 14:35:09 2012
From: rednaxelafx at gmail.com (Krystal Mok)
Date: Mon, 8 Oct 2012 22:35:09 +0800
Subject: StackTraceElement question
In-Reply-To: <20121008142518.E2EFB97124@rebar.astron.com>
References: <5072D022.8060002@oracle.com>
	<20121008142518.E2EFB97124@rebar.astron.com>
Message-ID: <CA+cQ+tTxROYnVAJx6gw+wjqVDn9KVWgxdcA=USXnKhchzSfuaQ@mail.gmail.com>

On Mon, Oct 8, 2012 at 10:25 PM, Christos Zoulas <christos at zoulas.com>wrote:

> On Oct 8, 11:07pm, david.holmes at oracle.com (David Holmes) wrote:
> -- Subject: Re: StackTraceElement question
>
> | > There is also the problem of having a class hierarchy like:
> | >
> | > class A extends class I
> | > class B extends class I
> | >
> | > and then trying to figure out if it is A or B when you just have I from
> | > that StackTraceElement.
> |
> | Can't say I have ever studied stacktraces in depth but I would expect to
> | see A or B not I as the name.
>
> I was expecting the same, but this is not the case:
>
> $ cat StackTrace.java
> class I {
>     public void run()
>         throws Exception
>     {
>         throw new Exception();
>     }
> }
>
> class A
>    extends I
> {
> }
>
> public class StackTrace {
>     public static void main(String[] args) {
>         try {
>             A a = new A();
>             a.run();
>         } catch (Exception e) {
>             StackTraceElement[] ste = e.getStackTrace();
>             for (int i = 0; i < ste.length; i++)
>                 System.out.println(ste[i].getClassName());
>         }
>     }
> }
> $ javac Stacktrace.java
> $ java -cp . StackTrace
> I
> StackTrace
>
> Printing "I" here is expected. After all, that's the class where you're
getting run()'s implementation from.
It's not designed to tell people the actual type of the receiver of a
certain method invocation. And that's what you're really after, right?

- Kris



> | The loader issue is real, you'd have to know where to locate the class.
> | But another reason to not store the Class reference is that it may
> | prevent the class from being unloaded. For every use-case there's a
> | counter-use-case.
>
> Yes, the class loader issue is real. I am not sure about the Class
> reference preventing the class to be unloaded; after all, the
> StackTraceElements are typically transient (when the exception goes
> out of context, they can be GC'ed); if not, then the reference can
> be held until the StackTraceElement is not reachable. I don't think
> that keeping the reference is such a big issue to even consider
> making this Weak. I am really worried about the security implications.
> As far as serialization goes, it could be made transient for
> compatibility.  Anyway, I would be more than happy the StackTraceElement
> contained the outermost enclosing class instead of the immediately
> enclosing one.  Returning the Class<?> instance is still the most
> versatile, but the one that needs most consideration because of its
> implications.
>
> christos
>
> christos
>


From vitalyd at gmail.com  Mon Oct  8 14:45:18 2012
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 8 Oct 2012 10:45:18 -0400
Subject: StackTraceElement question
In-Reply-To: <CA+cQ+tTxROYnVAJx6gw+wjqVDn9KVWgxdcA=USXnKhchzSfuaQ@mail.gmail.com>
References: <5072D022.8060002@oracle.com>
	<20121008142518.E2EFB97124@rebar.astron.com>
	<CA+cQ+tTxROYnVAJx6gw+wjqVDn9KVWgxdcA=USXnKhchzSfuaQ@mail.gmail.com>
Message-ID: <CAHjP37E52+uxaEwvW-1yd6dWx5WbFfca_CG5fjx62WjVDg0hPw@mail.gmail.com>

FWIW, .Net's equivalent to this doesn't return the class but exposes the
MethodBase (java.lang.reflect.Method analogous) that owns the frame and one
can get the defining class from that.

Sent from my phone
On Oct 8, 2012 10:35 AM, "Krystal Mok" <rednaxelafx at gmail.com> wrote:

> On Mon, Oct 8, 2012 at 10:25 PM, Christos Zoulas <christos at zoulas.com
> >wrote:
>
> > On Oct 8, 11:07pm, david.holmes at oracle.com (David Holmes) wrote:
> > -- Subject: Re: StackTraceElement question
> >
> > | > There is also the problem of having a class hierarchy like:
> > | >
> > | > class A extends class I
> > | > class B extends class I
> > | >
> > | > and then trying to figure out if it is A or B when you just have I
> from
> > | > that StackTraceElement.
> > |
> > | Can't say I have ever studied stacktraces in depth but I would expect
> to
> > | see A or B not I as the name.
> >
> > I was expecting the same, but this is not the case:
> >
> > $ cat StackTrace.java
> > class I {
> >     public void run()
> >         throws Exception
> >     {
> >         throw new Exception();
> >     }
> > }
> >
> > class A
> >    extends I
> > {
> > }
> >
> > public class StackTrace {
> >     public static void main(String[] args) {
> >         try {
> >             A a = new A();
> >             a.run();
> >         } catch (Exception e) {
> >             StackTraceElement[] ste = e.getStackTrace();
> >             for (int i = 0; i < ste.length; i++)
> >                 System.out.println(ste[i].getClassName());
> >         }
> >     }
> > }
> > $ javac Stacktrace.java
> > $ java -cp . StackTrace
> > I
> > StackTrace
> >
> > Printing "I" here is expected. After all, that's the class where you're
> getting run()'s implementation from.
> It's not designed to tell people the actual type of the receiver of a
> certain method invocation. And that's what you're really after, right?
>
> - Kris
>
>
>
> > | The loader issue is real, you'd have to know where to locate the class.
> > | But another reason to not store the Class reference is that it may
> > | prevent the class from being unloaded. For every use-case there's a
> > | counter-use-case.
> >
> > Yes, the class loader issue is real. I am not sure about the Class
> > reference preventing the class to be unloaded; after all, the
> > StackTraceElements are typically transient (when the exception goes
> > out of context, they can be GC'ed); if not, then the reference can
> > be held until the StackTraceElement is not reachable. I don't think
> > that keeping the reference is such a big issue to even consider
> > making this Weak. I am really worried about the security implications.
> > As far as serialization goes, it could be made transient for
> > compatibility.  Anyway, I would be more than happy the StackTraceElement
> > contained the outermost enclosing class instead of the immediately
> > enclosing one.  Returning the Class<?> instance is still the most
> > versatile, but the one that needs most consideration because of its
> > implications.
> >
> > christos
> >
> > christos
> >
>


From chris.hegarty at oracle.com  Mon Oct  8 17:08:55 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 08 Oct 2012 18:08:55 +0100
Subject: 7173494: some jdk tests are not run in test/Makefile
In-Reply-To: <5071D975.7080904@oracle.com>
References: <5071D975.7080904@oracle.com>
Message-ID: <507308A7.8040406@oracle.com>

This update looks ok to me.

At some point ( not asking you to do it now ) we will need to update 
7u-dev, to avoid confusion around what tests are being run in what batches.

-Chris.

On 07/10/2012 20:35, Alan Bateman wrote:
>
> This one is a small clean-up of the test targets defined in
> jdk/test/Makefile. The union of the tests executed by each of the make
> targets should be the entire test suite but this isn't so, there are
> small number of tests that aren't run.
>
> I've renamed jdk_misc to jdk_other (the original name is confusing
> because of sun.misc) and expanded it to run additional areas that have a
> small number of tests. If more tests are added to these areas over time
> then it may make sense to add new targets in the future.
>
> "make jdk_jmx" now runs the JMX tests as it was confusing to have those
> tests split between management1 and management2. I've also renamed
> jdk_tools1 to jdk_jdi to make it clear that this is the JDI tests rather
> than tools. When Kelly originally set this up he split the NIO tests
> into 3 batches, I don't think this is necessary any longer (the really
> slow tests have been long been dialed down or changed to run much faster).
>
> The webrev with the proposed changes is here:
> http://cr.openjdk.java.net/~alanb/7173494/webrev/
>
> -Alan.


From mandy.chung at oracle.com  Mon Oct  8 17:44:51 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 08 Oct 2012 10:44:51 -0700
Subject: 7173494: some jdk tests are not run in test/Makefile
In-Reply-To: <5071D975.7080904@oracle.com>
References: <5071D975.7080904@oracle.com>
Message-ID: <50731113.9070400@oracle.com>

It's good to clean this up and the change looks fine in general.    A 
couple of minor comments:

jdk_management - Might be good to include java/lang/management tests in 
this target in case someone only runs one target to verify that area.  
On the other hands, they are currently covered by jdk_lang target and 
might be better to take them out from jdk_lang (maybe in the future).

jdk_rmi target - you change "javax/rmi" to "javax/rmi/ssl".  There is no 
test in the test/javax/rmi directory currently but if a new test (or new 
subdirectory) is added under test/javax/rmi, you would have to change 
the jdk_rmi target.  Would it be better to keep "javax/rmi" as it is?

test/sun/misc seems to belong to jdk_lang.  Do you know why they are in 
jdk_other?

Mandy

On 10/7/2012 12:35 PM, Alan Bateman wrote:
>
> This one is a small clean-up of the test targets defined in 
> jdk/test/Makefile. The union of the tests executed by each of the make 
> targets should be the entire test suite but this isn't so, there are 
> small number of tests that aren't run.
>
> I've renamed jdk_misc to jdk_other (the original name is confusing 
> because of sun.misc) and expanded it to run additional areas that have 
> a small number of tests. If more tests are added to these areas over 
> time then it may make sense to add new targets in the future.
>
> "make jdk_jmx" now runs the JMX tests as it was confusing to have 
> those tests split between management1 and management2. I've also 
> renamed jdk_tools1 to jdk_jdi to make it clear that this is the JDI 
> tests rather than tools. When Kelly originally set this up he split 
> the NIO tests into 3 batches, I don't think this is necessary any 
> longer (the really slow tests have been long been dialed down or 
> changed to run much faster).
>
> The webrev with the proposed changes is here:
> http://cr.openjdk.java.net/~alanb/7173494/webrev/
>
> -Alan.


From martinrb at google.com  Mon Oct  8 17:52:58 2012
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 8 Oct 2012 10:52:58 -0700
Subject: RFR: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java
	failing intermittently [sol]
In-Reply-To: <5071DC80.3080507@oracle.com>
References: <506CB1C3.5050009@oracle.com> <506D3D14.4070304@oracle.com>
	<CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
	<5071DC80.3080507@oracle.com>
Message-ID: <CA+kOe08mRoVVXAR6K7j3PgDuNmiv+V=AkwxUoxAWcyTG+AXGqA@mail.gmail.com>

Thanks for the changes - this approach looks good.  But:

1954                                 case 0: r = s.read(bytes); break;
1955                                 case 2: r = s.read(bytes); break;

The two cases are the same code; you want

case 0: r = s.read(); break;

1964                 String os = System.getProperty("os.name");
1965                 if (os.equalsIgnoreCase("Solaris") ||
1966                     os.equalsIgnoreCase("SunOS"))

I wouldn't bother with testing for Solaris explicitly, and just rely on
reflective code testing the implementation of s.
Loop for useCount to go non-negative If and only if we find it reflectively.

1970                     if (s.toString().startsWith(
1971
"java.lang.UNIXProcess$DeferredCloseInputStream"))

It's bad style to depend on the output of toString() - better is something
like

Class<?> c = s.getClass();
if (c.getName().equals(...)) {

Oh, now I see the difficulty - the DeferredCloseInputStream may or may not
be wrapped in a BufferedInputStream.
Which makes the reflective code much more annoying.

1976                         useCount = (Integer)useCountField.get(s);

I think you want to use getInt (not get) on a field of type int.

1987                     while (useCount.intValue() <= 0) {
1988                         useCount = (Integer)useCountField.get(s);
1989                         Thread.currentThread().yield();
1990                     }

I was imagining a loop that looks more like this:

if (useCountField != null) {
while (useCountField.getInt(s) <= 0) {
  Thread.currentThread().yield();
}
}

I'm surprised you're not seeing IAE when calling useCountField.get(s) when
wrapped in a BIS.  Shouldn't that be a call to useCountField.get(deferred)
instead?  Can we fix this in the wrapped case by assigning "s = deferred"?

Thanks,

Martin

On Sun, Oct 7, 2012 at 12:48 PM, Rob McKenna <rob.mckenna at oracle.com> wrote:

>  Thanks Martin,
>
> I've uploaded a new webrev to:
>
> http://cr.openjdk.java.net/~robm/7152183/webrev.02/
>
> Let me know if this does the job.
>
>
>     -Rob
>
> On 04/10/12 18:24, Martin Buchholz wrote:
>
> Hi all,
>
>  Yeah, this particular test is rather racy - sorry about that.
> We need to call p.destroy when the other thread is in the middle of a
> read() system call, and there's no way to know for sure - seeing java
> "read" in the stacktrace is not enough, since it may not have gotten to the
> system call yet.
>
>  suggestions:
> pull the computation of the inputstream before the latch to narrow the
> window a bit:
>
>  final InputStream s;
> switch (action & 0x1) {
>  case 0: s = p.getInputStream(); break;
> case 1: s = p.getErrorStream(); break;
> default: throw
> }
> latch.countdown();
> switch (action & 0x2) {
> case 0: r = s.read(); break;
> case 1: r = s.read(bytes); break;
> }
>
> Examining the stack trace to look for "read" is clever but does not
> actually eliminate the race.
>
>  Looking in UNIXProcess.java.solaris I see the use
> of DeferredCloseInputStream.  We can eliminate the race on solaris (i.e. if
> the inputstream.getclass isDeferredCloseInputStream)  by looping until the
> useCount field of the DeferredCloseInputStream is > 0, using ugly but
> effective reflective code.  This should allow us to avoid the horrible
> sleep for 200ms.
>
>  You should use yield instead of sleep between loop iterations while
> waiting for the useCount to be bumped.
>
>  On other platforms this is not an issue, I think.
>
>  Martin
>
> On Thu, Oct 4, 2012 at 12:39 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:
>
>> On 03/10/2012 22:44, Rob McKenna wrote:
>>
>>> Hi folks,
>>>
>>> The only way I can see this test failing in this manner[*] is if we
>>> destroy the process before we begin the read. That being the case I've
>>> jacked up the sleep (giving the reader thread a little more time to get
>>> cracking) and added a check to see if the threads stack has entered a read
>>> call.
>>>
>>> http://cr.openjdk.java.net/~robm/7152183/webrev.01/ <
>>> http://cr.openjdk.java.net/%7Erobm/7152183/webrev.01/>
>>>
>>> Feedback greatly appreciated.
>>>
>>>     -Rob
>>>
>>>
>>> [*] le trace:
>>>
>>>  So stack traces are masculine, I didn't know that.
>>
>> I think your analysis is right, it's just that the sleep(10) is not
>> sufficient to ensure that the thread gets to the read method. Increasing
>> the sleep is probably sufficient. The hack to look at the stack trace makes
>> it more robust for really extreme cases, at the cost of potential further
>> maintenance in the event that the implementation changes. In any case it's
>> good to resolve this intermittent test failure.
>>
>> -Alan
>>
>
>
>


From Alan.Bateman at oracle.com  Mon Oct  8 18:12:33 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 08 Oct 2012 19:12:33 +0100
Subject: 7173494: some jdk tests are not run in test/Makefile
In-Reply-To: <50731113.9070400@oracle.com>
References: <5071D975.7080904@oracle.com> <50731113.9070400@oracle.com>
Message-ID: <50731791.4020806@oracle.com>

On 08/10/2012 18:44, Mandy Chung wrote:
> It's good to clean this up and the change looks fine in general.    A 
> couple of minor comments:
>
> jdk_management - Might be good to include java/lang/management tests 
> in this target in case someone only runs one target to verify that 
> area.  On the other hands, they are currently covered by jdk_lang 
> target and might be better to take them out from jdk_lang (maybe in 
> the future).
The jdk_management target could run the java/lang/management tests too 
but it would mean these tests would run twice. I have experimented with 
moving these tests to test/java/lang_management (same thing for 
java/lang/instrument to java/lang_instrument) but decided not to include 
those changes here as it's a disruptive change. With compact profiles 
[1] and future modularization then we may need to look at this again as 
it would be really nice to be able to specify the test directories to 
jtreg that correspond to the modules or profiles (I think it's just a 
bit early to know how the tests will run).
>
> jdk_rmi target - you change "javax/rmi" to "javax/rmi/ssl".  There is 
> no test in the test/javax/rmi directory currently but if a new test 
> (or new subdirectory) is added under test/javax/rmi, you would have to 
> change the jdk_rmi target.  Would it be better to keep "javax/rmi" as 
> it is?
javax.rmi.CORBA has the classes for RMI-IIOP and I would expect tests 
for this area to be run by a different make target, say jdk_corba. As it 
happens we don't have any tests for this area in the jdk repository so 
it doesn't make any difference at this time So somewhat of a drive-by 
fix (again profiles and modules motivated so that "make jdk_rmi" would 
run the RMI tests only).

>
> test/sun/misc seems to belong to jdk_lang.  Do you know why they are 
> in jdk_other?
The tests in test/sun/misc provide very sparse coverage and are somewhat 
of a mixed bag so I decided to leave them where they are. I wouldn't 
object to moving them to the jdk_lang target, do you have a strong 
opinion on this?

-Alan

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


From mandy.chung at oracle.com  Mon Oct  8 18:38:14 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 08 Oct 2012 11:38:14 -0700
Subject: 7173494: some jdk tests are not run in test/Makefile
In-Reply-To: <50731791.4020806@oracle.com>
References: <5071D975.7080904@oracle.com> <50731113.9070400@oracle.com>
	<50731791.4020806@oracle.com>
Message-ID: <50731D96.3040809@oracle.com>



On 10/8/2012 11:12 AM, Alan Bateman wrote:
> On 08/10/2012 18:44, Mandy Chung wrote:
>> It's good to clean this up and the change looks fine in general.    A 
>> couple of minor comments:
>>
>> jdk_management - Might be good to include java/lang/management tests 
>> in this target in case someone only runs one target to verify that 
>> area.  On the other hands, they are currently covered by jdk_lang 
>> target and might be better to take them out from jdk_lang (maybe in 
>> the future).
> The jdk_management target could run the java/lang/management tests too 
> but it would mean these tests would run twice. I have experimented 
> with moving these tests to test/java/lang_management (same thing for 
> java/lang/instrument to java/lang_instrument) but decided not to 
> include those changes here as it's a disruptive change. With compact 
> profiles [1] and future modularization then we may need to look at 
> this again as it would be really nice to be able to specify the test 
> directories to jtreg that correspond to the modules or profiles (I 
> think it's just a bit early to know how the tests will run).

Agree and it's fine to leave it as it is.

>>
>> jdk_rmi target - you change "javax/rmi" to "javax/rmi/ssl".  There is 
>> no test in the test/javax/rmi directory currently but if a new test 
>> (or new subdirectory) is added under test/javax/rmi, you would have 
>> to change the jdk_rmi target.  Would it be better to keep "javax/rmi" 
>> as it is?
> javax.rmi.CORBA has the classes for RMI-IIOP and I would expect tests 
> for this area to be run by a different make target, say jdk_corba. As 
> it happens we don't have any tests for this area in the jdk repository 
> so it doesn't make any difference at this time So somewhat of a 
> drive-by fix (again profiles and modules motivated so that "make 
> jdk_rmi" would run the RMI tests only).
>

That's right - I missed javax.rmi.CORBA package.

>>
>> test/sun/misc seems to belong to jdk_lang.  Do you know why they are 
>> in jdk_other?
> The tests in test/sun/misc provide very sparse coverage and are 
> somewhat of a mixed bag so I decided to leave them where they are. I 
> wouldn't object to moving them to the jdk_lang target, do you have a 
> strong opinion on this?

Just looking at the list of tests in test/sun/misc, it seems reasonable 
to move them to jdk_lang so that the default jprt target will include 
them.   This will require some work to verify.   It's fine if we do it 
in a future cleanup.

Thanks
Mandy

Mandy


From mike.duigou at oracle.com  Mon Oct  8 18:40:20 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 8 Oct 2012 11:40:20 -0700
Subject: 7173494: some jdk tests are not run in test/Makefile
In-Reply-To: <5071D975.7080904@oracle.com>
References: <5071D975.7080904@oracle.com>
Message-ID: <F39D7C96-8B10-4B1C-B80E-7A825FC2C9DE@oracle.com>

This looks like all good changes to me.

Mike

On Oct 7 2012, at 12:35 , Alan Bateman wrote:

> 
> This one is a small clean-up of the test targets defined in jdk/test/Makefile. The union of the tests executed by each of the make targets should be the entire test suite but this isn't so, there are small number of tests that aren't run.
> 
> I've renamed jdk_misc to jdk_other (the original name is confusing because of sun.misc) and expanded it to run additional areas that have a small number of tests. If more tests are added to these areas over time then it may make sense to add new targets in the future.
> 
> "make jdk_jmx" now runs the JMX tests as it was confusing to have those tests split between management1 and management2. I've also renamed jdk_tools1 to jdk_jdi to make it clear that this is the JDI tests rather than tools. When Kelly originally set this up he split the NIO tests into 3 batches, I don't think this is necessary any longer (the really slow tests have been long been dialed down or changed to run much faster).
> 
> The webrev with the proposed changes is here:
> http://cr.openjdk.java.net/~alanb/7173494/webrev/
> 
> -Alan.



From iris.clark at oracle.com  Mon Oct  8 18:51:04 2012
From: iris.clark at oracle.com (Iris Clark)
Date: Mon, 8 Oct 2012 11:51:04 -0700 (PDT)
Subject: 7173494: some jdk tests are not run in test/Makefile
In-Reply-To: <5071D975.7080904@oracle.com>
References: <5071D975.7080904@oracle.com>
Message-ID: <5fdd9c7a-c76f-4011-9834-4d12e33cb6a3@default>

> The webrev with the proposed changes is here:
> http://cr.openjdk.java.net/~alanb/7173494/webrev/

Looks like a good clean-up.

iris


From Alan.Bateman at oracle.com  Mon Oct  8 20:58:23 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 08 Oct 2012 21:58:23 +0100
Subject: 7173494: some jdk tests are not run in test/Makefile
In-Reply-To: <507308A7.8040406@oracle.com>
References: <5071D975.7080904@oracle.com> <507308A7.8040406@oracle.com>
Message-ID: <50733E6F.307@oracle.com>

On 08/10/2012 18:08, Chris Hegarty wrote:
> This update looks ok to me.
>
> At some point ( not asking you to do it now ) we will need to update 
> 7u-dev, to avoid confusion around what tests are being run in what 
> batches.
Yes, I think this should go into jdk7u-dev too.

-Alan


From rob.mckenna at oracle.com  Mon Oct  8 21:24:40 2012
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 08 Oct 2012 22:24:40 +0100
Subject: RFR: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java
	failing intermittently [sol]
In-Reply-To: <CA+kOe08mRoVVXAR6K7j3PgDuNmiv+V=AkwxUoxAWcyTG+AXGqA@mail.gmail.com>
References: <506CB1C3.5050009@oracle.com> <506D3D14.4070304@oracle.com>
	<CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
	<5071DC80.3080507@oracle.com>
	<CA+kOe08mRoVVXAR6K7j3PgDuNmiv+V=AkwxUoxAWcyTG+AXGqA@mail.gmail.com>
Message-ID: <50734498.40100@oracle.com>

Thanks Martin,

Updated webrev at:

http://cr.openjdk.java.net/~robm/7152183/webrev.03/ 
<http://cr.openjdk.java.net/%7Erobm/7152183/webrev.03/>

and a few comments inline:

On 08/10/12 18:52, Martin Buchholz wrote:
> Thanks for the changes - this approach looks good.  But:
>
> 1954                                 case 0: r = s.read(bytes); break;
> 1955                                 case 2: r = s.read(bytes); break;
>
> The two cases are the same code; you want
>
> case 0: r = s.read(); break;
Eesh, typo, sorry.
>
> 1964                 String os = System.getProperty("os.name 
> <http://os.name>");
> 1965                 if (os.equalsIgnoreCase("Solaris") ||
> 1966                     os.equalsIgnoreCase("SunOS"))
>
> I wouldn't bother with testing for Solaris explicitly, and just rely 
> on reflective code testing the implementation of s.
> Loop for useCount to go non-negative If and only if we find it 
> reflectively.
>
> 1970                     if (s.toString().startsWith(
> 1971 "java.lang.UNIXProcess$DeferredCloseInputStream"))
>
> It's bad style to depend on the output of toString() - better is 
> something like
>
> Class<?> c = s.getClass();
> if (c.getName().equals(...)) {
>
> Oh, now I see the difficulty - the DeferredCloseInputStream may or may 
> not be wrapped in a BufferedInputStream.
> Which makes the reflective code much more annoying.
Yes, that being the case I'm going to leave in the OS check, is that ok? 
Also yes, c.getName() makes far more sense, thanks.
>
> 1976                         useCount = (Integer)useCountField.get(s);
>
> I think you want to use getInt (not get) on a field of type int.
Yes I do.
>
> 1987                     while (useCount.intValue() <= 0) {
> 1988                         useCount = (Integer)useCountField.get(s);
> 1989 Thread.currentThread().yield();
> 1990                     }
>
> I was imagining a loop that looks more like this:
>
> if (useCountField != null) {
> while (useCountField.getInt(s) <= 0) {
>   Thread.currentThread().yield();
> }
> }
Thats much nicer. I was thinking I'd leave the null check out as if 
useCountField is null at this point, the test should probably fail. Let 
me know if thats ok.
>
> I'm surprised you're not seeing IAE when calling useCountField.get(s) 
> when wrapped in a BIS.  Shouldn't that be a call 
> to useCountField.get(deferred) instead?  Can we fix this in the 
> wrapped case by assigning "s = deferred"?
>
Sorry, that was a mistake. Rectified now. I hadn't actually exercised 
that code due to my while loop implementation and the fact that the 
problem wasn't reproducing. Thanks for spotting that.

     -Rob
> Thanks,
>
> Martin
>
> On Sun, Oct 7, 2012 at 12:48 PM, Rob McKenna <rob.mckenna at oracle.com 
> <mailto:rob.mckenna at oracle.com>> wrote:
>
>     Thanks Martin,
>
>     I've uploaded a new webrev to:
>
>     http://cr.openjdk.java.net/~robm/7152183/webrev.02/
>     <http://cr.openjdk.java.net/%7Erobm/7152183/webrev.02/>
>
>     Let me know if this does the job.
>
>
>         -Rob
>
>     On 04/10/12 18:24, Martin Buchholz wrote:
>>     Hi all,
>>
>>     Yeah, this particular test is rather racy - sorry about that.
>>     We need to call p.destroy when the other thread is in the middle
>>     of a read() system call, and there's no way to know for sure -
>>     seeing java "read" in the stacktrace is not enough, since it may
>>     not have gotten to the system call yet.
>>
>>     suggestions:
>>     pull the computation of the inputstream before the latch to
>>     narrow the window a bit:
>>
>>     final InputStream s;
>>     switch (action & 0x1) {
>>     case 0: s = p.getInputStream(); break;
>>     case 1: s = p.getErrorStream(); break;
>>     default: throw
>>     }
>>     latch.countdown();
>>     switch (action & 0x2) {
>>     case 0: r = s.read(); break;
>>     case 1: r = s.read(bytes); break;
>>     }
>>
>>     Examining the stack trace to look for "read" is clever but does
>>     not actually eliminate the race.
>>
>>     Looking in UNIXProcess.java.solaris I see the use
>>     of DeferredCloseInputStream.  We can eliminate the race on
>>     solaris (i.e. if the inputstream.getclass
>>     isDeferredCloseInputStream)  by looping until the useCount field
>>     of the DeferredCloseInputStream is > 0, using ugly but effective
>>     reflective code.  This should allow us to avoid the horrible
>>     sleep for 200ms.
>>
>>     You should use yield instead of sleep between loop iterations
>>     while waiting for the useCount to be bumped.
>>
>>     On other platforms this is not an issue, I think.
>>
>>     Martin
>>
>>     On Thu, Oct 4, 2012 at 12:39 AM, Alan Bateman
>>     <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>>         On 03/10/2012 22:44, Rob McKenna wrote:
>>
>>             Hi folks,
>>
>>             The only way I can see this test failing in this
>>             manner[*] is if we destroy the process before we begin
>>             the read. That being the case I've jacked up the sleep
>>             (giving the reader thread a little more time to get
>>             cracking) and added a check to see if the threads stack
>>             has entered a read call.
>>
>>             http://cr.openjdk.java.net/~robm/7152183/webrev.01/
>>             <http://cr.openjdk.java.net/%7Erobm/7152183/webrev.01/>
>>             <http://cr.openjdk.java.net/%7Erobm/7152183/webrev.01/>
>>
>>             Feedback greatly appreciated.
>>
>>                 -Rob
>>
>>
>>             [*] le trace:
>>
>>         So stack traces are masculine, I didn't know that.
>>
>>         I think your analysis is right, it's just that the sleep(10)
>>         is not sufficient to ensure that the thread gets to the read
>>         method. Increasing the sleep is probably sufficient. The hack
>>         to look at the stack trace makes it more robust for really
>>         extreme cases, at the cost of potential further maintenance
>>         in the event that the implementation changes. In any case
>>         it's good to resolve this intermittent test failure.
>>
>>         -Alan
>>
>>
>
>



From huizhe.wang at oracle.com  Tue Oct  9 04:31:45 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 08 Oct 2012 21:31:45 -0700
Subject: JAXP RFR: 8000172 : 2 SAX features does not work properly
Message-ID: <5073A8B1.7070908@oracle.com>

This is an issue found while I was working with SQE to expand test 
coverage. For a non-validating parser, when load-external-dtd is false, 
entity references are skipped. However, the skippedEntity() event was 
not reported.

The problem was due to missing infoset augmentations when document 
handler's startGeneralEntity/endGeneralEntity were called.  The fix 
therefore is simply add the arguments.

webrev: http://cr.openjdk.java.net/~joehw/jdk8/8000172/webrev/

Please review.

Thanks,
Joe


From sean.coffey at oracle.com  Tue Oct  9 11:47:42 2012
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Tue, 09 Oct 2012 11:47:42 +0000
Subject: hg: jdk8/tl/jdk: 7196533: TimeZone.getDefault() slow due to
	synchronization bottleneck
Message-ID: <20121009114834.DBD304723C@hg.openjdk.java.net>

Changeset: fecba6a8b78e
Author:    coffeys
Date:      2012-10-09 12:50 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fecba6a8b78e

7196533: TimeZone.getDefault() slow due to synchronization bottleneck
Reviewed-by: okutsu

! src/share/classes/java/util/TimeZone.java



From alan.bateman at oracle.com  Tue Oct  9 12:25:59 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 09 Oct 2012 12:25:59 +0000
Subject: hg: jdk8/tl: 7173494: some jdk tests are not run in test/Makefile
Message-ID: <20121009122559.9D6B747240@hg.openjdk.java.net>

Changeset: 4bde5640fb36
Author:    alanb
Date:      2012-10-09 13:25 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/4bde5640fb36

7173494: some jdk tests are not run in test/Makefile
Reviewed-by: chegar, mchung, mduigou, iris

! make/jprt.properties
! test/Makefile



From alan.bateman at oracle.com  Tue Oct  9 12:28:29 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Tue, 09 Oct 2012 12:28:29 +0000
Subject: hg: jdk8/tl/jdk: 7173494: some jdk tests are not run in test/Makefile
Message-ID: <20121009122913.280C647241@hg.openjdk.java.net>

Changeset: 3b79177ebfef
Author:    alanb
Date:      2012-10-09 13:28 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b79177ebfef

7173494: some jdk tests are not run in test/Makefile
Reviewed-by: chegar, mchung, mduigou, iris

! make/jprt.properties
! test/Makefile
! test/ProblemList.txt



From lance.andersen at oracle.com  Tue Oct  9 12:58:59 2012
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Tue, 09 Oct 2012 12:58:59 +0000
Subject: hg: jdk8/tl/jdk: 7197395: Add @Deprecated to all deprecated methods
	to eliminate compiler warnings in JDBC
Message-ID: <20121009125922.A5D8F47243@hg.openjdk.java.net>

Changeset: 036c55976cef
Author:    lancea
Date:      2012-10-09 08:58 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/036c55976cef

7197395: Add @Deprecated to all deprecated methods to eliminate compiler warnings in JDBC
Reviewed-by: alanb, smarks

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java
! src/share/classes/com/sun/rowset/JoinRowSetImpl.java
! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java
! src/share/classes/java/sql/CallableStatement.java
! src/share/classes/java/sql/Date.java
! src/share/classes/java/sql/DriverManager.java
! src/share/classes/java/sql/PreparedStatement.java
! src/share/classes/java/sql/ResultSet.java
! src/share/classes/javax/sql/rowset/BaseRowSet.java



From Lance.Andersen at oracle.com  Tue Oct  9 14:55:35 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 9 Oct 2012 10:55:35 -0400
Subject: JAXP RFR: 8000172 : 2 SAX features does not work properly
In-Reply-To: <5073A8B1.7070908@oracle.com>
References: <5073A8B1.7070908@oracle.com>
Message-ID: <2513C1FF-C964-4675-97DB-0334831036CB@oracle.com>

Look OK Joe


On Oct 9, 2012, at 12:31 AM, Joe Wang wrote:

> This is an issue found while I was working with SQE to expand test coverage. For a non-validating parser, when load-external-dtd is false, entity references are skipped. However, the skippedEntity() event was not reported.
> 
> The problem was due to missing infoset augmentations when document handler's startGeneralEntity/endGeneralEntity were called.  The fix therefore is simply add the arguments.
> 
> webrev: http://cr.openjdk.java.net/~joehw/jdk8/8000172/webrev/
> 
> Please review.
> 
> Thanks,
> Joe


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From huizhe.wang at oracle.com  Tue Oct  9 15:45:52 2012
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 09 Oct 2012 08:45:52 -0700
Subject: JAXP RFR: 8000172 : 2 SAX features does not work properly
In-Reply-To: <2513C1FF-C964-4675-97DB-0334831036CB@oracle.com>
References: <5073A8B1.7070908@oracle.com>
	<2513C1FF-C964-4675-97DB-0334831036CB@oracle.com>
Message-ID: <507446B0.9010105@oracle.com>

Thanks Lance!

On 10/9/2012 7:55 AM, Lance Andersen - Oracle wrote:
> Look OK Joe
>
>
> On Oct 9, 2012, at 12:31 AM, Joe Wang wrote:
>
>> This is an issue found while I was working with SQE to expand test 
>> coverage. For a non-validating parser, when load-external-dtd is 
>> false, entity references are skipped. However, the skippedEntity() 
>> event was not reported.
>>
>> The problem was due to missing infoset augmentations when document 
>> handler's startGeneralEntity/endGeneralEntity were called.  The fix 
>> therefore is simply add the arguments.
>>
>> webrev: http://cr.openjdk.java.net/~joehw/jdk8/8000172/webrev/ 
>> <http://cr.openjdk.java.net/%7Ejoehw/jdk8/8000172/webrev/>
>>
>> Please review.
>>
>> Thanks,
>> Joe
>
> <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 naoto.sato at oracle.com  Tue Oct  9 17:00:26 2012
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 09 Oct 2012 17:00:26 +0000
Subject: hg: jdk8/tl/jdk: 7200341: DateFormatSymbols.hashCode() throws
	ArrayIndexOutOfBoundsException in some circumstances
Message-ID: <20121009170052.2CF4E4724F@hg.openjdk.java.net>

Changeset: c725ce4bbf12
Author:    naoto
Date:      2012-10-09 09:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c725ce4bbf12

7200341: DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some circumstances
Reviewed-by: okutsu

! src/share/classes/java/text/DateFormatSymbols.java
! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java
! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh
! test/java/util/PluggableLocale/fooprovider.jar
! test/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java



From dan.xu at oracle.com  Tue Oct  9 17:46:27 2012
From: dan.xu at oracle.com (Dan Xu)
Date: Tue, 09 Oct 2012 10:46:27 -0700
Subject: Review Request: 7186817 - Remove Windows 95/98/ME Support
Message-ID: <507462F3.7040205@oracle.com>

Hi folks,

Please help review the code change for CR7186817 to remove Windows 
95/98/ME support. The webrev has been uploaded to 
http://cr.openjdk.java.net/~dxu/7186817/webrev/ 
<http://cr.openjdk.java.net/%7Edxu/7186817/webrev/>

The main focus of this clean-up is in IO area. And I also cleaned 
java/lang/ProcessImpl_md.c and java/util/TimeZone_md.c in this transaction.

Thanks,

-Dan


From sean.coffey at oracle.com  Tue Oct  9 18:38:31 2012
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Tue, 09 Oct 2012 19:38:31 +0100
Subject: RFR : 7196086 : update copyright years for files in corba repository
	(JDK 8)
Message-ID: <50746F27.5@oracle.com>

steve.sides at oracle.com has contributed the following patch which I'd 
like to push to jdk8 TL. It's the correction of copyright years in corba 
repo.
Need a reviewer.

webrev :
http://cr.openjdk.java.net/~coffeys/webrev.7196086.jdk8/ 
<http://cr.openjdk.java.net/%7Ecoffeys/webrev.7196086.jdk8/>

regards,
Sean.



From sean.coffey at oracle.com  Tue Oct  9 18:42:20 2012
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Tue, 09 Oct 2012 18:42:20 +0000
Subject: hg: jdk8/tl/jdk: 7181793: Socket getOutputStream create streams that
	cannot be GC'ed until Socket is closed
Message-ID: <20121009184322.5A95047253@hg.openjdk.java.net>

Changeset: 71de5e31d497
Author:    coffeys
Date:      2012-10-09 19:45 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71de5e31d497

7181793: Socket getOutputStream create streams that cannot be GC'ed until Socket is closed
Reviewed-by: alanb, chegar

! src/share/classes/java/net/AbstractPlainSocketImpl.java
+ test/java/net/Socket/SocketGrowth.java



From Lance.Andersen at oracle.com  Tue Oct  9 18:55:38 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 9 Oct 2012 14:55:38 -0400
Subject: RFR : 7196086 : update copyright years for files in corba
	repository (JDK 8)
In-Reply-To: <50746F27.5@oracle.com>
References: <50746F27.5@oracle.com>
Message-ID: <A6CC9467-6D7A-4B84-8706-B2AC12A84A6C@oracle.com>

looks fine Sean

Best
Lance
On Oct 9, 2012, at 2:38 PM, Se?n Coffey wrote:

> steve.sides at oracle.com has contributed the following patch which I'd like to push to jdk8 TL. It's the correction of copyright years in corba repo.
> Need a reviewer.
> 
> webrev :
> http://cr.openjdk.java.net/~coffeys/webrev.7196086.jdk8/ <http://cr.openjdk.java.net/%7Ecoffeys/webrev.7196086.jdk8/>
> 
> regards,
> Sean.
> 


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From sean.coffey at oracle.com  Tue Oct  9 19:16:07 2012
From: sean.coffey at oracle.com (sean.coffey at oracle.com)
Date: Tue, 09 Oct 2012 19:16:07 +0000
Subject: hg: jdk8/tl/corba: 7196086: update copyright years for files in corba
	repository (JDK 8)
Message-ID: <20121009191609.7C1CC47254@hg.openjdk.java.net>

Changeset: 679e8ad9874f
Author:    coffeys
Date:      2012-10-09 20:14 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/679e8ad9874f

7196086: update copyright years for files in corba repository (JDK 8)
Reviewed-by: lancea

! make/common/Defs-bsd.gmk
! make/common/internal/Resources.gmk
! make/common/shared/Defs-bsd.gmk
! make/common/shared/Defs-utils.gmk
! make/tools/src/build/tools/stripproperties/StripPropertiesCorba.java
! make/tools/strip_properties/Makefile



From martinrb at google.com  Tue Oct  9 19:27:57 2012
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 9 Oct 2012 12:27:57 -0700
Subject: RFR: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java
	failing intermittently [sol]
In-Reply-To: <50734498.40100@oracle.com>
References: <506CB1C3.5050009@oracle.com> <506D3D14.4070304@oracle.com>
	<CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
	<5071DC80.3080507@oracle.com>
	<CA+kOe08mRoVVXAR6K7j3PgDuNmiv+V=AkwxUoxAWcyTG+AXGqA@mail.gmail.com>
	<50734498.40100@oracle.com>
Message-ID: <CA+kOe09RmETEA3xJJ7751hF5nCQ6L3oyONy10+syGYHzzzN0Tw@mail.gmail.com>

On Mon, Oct 8, 2012 at 2:24 PM, Rob McKenna <rob.mckenna at oracle.com> wrote:

>  Thanks Martin,
>
> Updated webrev at:
>
> http://cr.openjdk.java.net/~robm/7152183/webrev.03/
>


The latest webrev looks correct to me - thanks!
I'd also make a couple of pedantic cosmetic changes:

1969                     Object deferred = null;

A good place to use a "blank final"

final Object deferred;

+                    Field useCountField;

Merge the declaration down to the initialization.


From Alan.Bateman at oracle.com  Tue Oct  9 19:30:45 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 09 Oct 2012 20:30:45 +0100
Subject: Review Request: 7186817 - Remove Windows 95/98/ME Support
In-Reply-To: <507462F3.7040205@oracle.com>
References: <507462F3.7040205@oracle.com>
Message-ID: <50747B65.20303@oracle.com>

On 09/10/2012 18:46, Dan Xu wrote:
> Hi folks,
>
> Please help review the code change for CR7186817 to remove Windows 
> 95/98/ME support. The webrev has been uploaded to 
> http://cr.openjdk.java.net/~dxu/7186817/webrev/ 
> <http://cr.openjdk.java.net/%7Edxu/7186817/webrev/>
>
> The main focus of this clean-up is in IO area. And I also cleaned 
> java/lang/ProcessImpl_md.c and java/util/TimeZone_md.c in this 
> transaction.
>
> Thanks,
>
> -Dan
This is great clean-up. I haven't gone through it all yet but one 
question - are there any changes to the code that moved from 
Win32FileSystem to WinNTFileSystem? I'm just wondering whether there is 
anything that needs a closer look.

-Alan


From Ulf.Zibis at CoSoCo.de  Tue Oct  9 19:31:18 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 09 Oct 2012 21:31:18 +0200
Subject: Review Request: 7186817 - Remove Windows 95/98/ME Support
In-Reply-To: <507462F3.7040205@oracle.com>
References: <507462F3.7040205@oracle.com>
Message-ID: <50747B86.3020401@CoSoCo.de>

Hi,

I did not look into the details, but the hint about performance on String.toLower in 
WindowsNTFileSystem catched my attention. Here is a very fast converter, which may be enough for 
calculating the hash:

     // Private ASCII-only optimized version
     public static final String toUpper(final String s) {
         boolean allUpper = true;
         char[] ca = null;
         for (int i=0; i<s.length(); i++) {
             int c = s.charAt(i);
             if (c >= 'a' && c <= 'z') {
                 if (allUpper) {
                     ca = s.toCharArray();
                     allUpper = false;
                 }
                 ca[i] -= '\u0020';
             }
         }
         return allUpper ? s : new String(ca);
     }

It also avoids instantiation of new objects, if there is nothing to change.
Note: the equivalent toLower algorithm statistically would be little slower on latin characters, but 
maybe faster on wide spreaded Unicode characters.

-Ulf


Am 09.10.2012 19:46, schrieb Dan Xu:
> Hi folks,
>
> Please help review the code change for CR7186817 to remove Windows 95/98/ME support. The webrev 
> has been uploaded to http://cr.openjdk.java.net/~dxu/7186817/webrev/ 
> <http://cr.openjdk.java.net/%7Edxu/7186817/webrev/>
>
> The main focus of this clean-up is in IO area. And I also cleaned java/lang/ProcessImpl_md.c and 
> java/util/TimeZone_md.c in this transaction.
>
> Thanks,
>
> -Dan
>



From dan.xu at oracle.com  Tue Oct  9 20:02:44 2012
From: dan.xu at oracle.com (Dan Xu)
Date: Tue, 09 Oct 2012 13:02:44 -0700
Subject: Review Request: 7186817 - Remove Windows 95/98/ME Support
In-Reply-To: <50747B65.20303@oracle.com>
References: <507462F3.7040205@oracle.com> <50747B65.20303@oracle.com>
Message-ID: <507482E4.7060607@oracle.com>


On 10/09/2012 12:30 PM, Alan Bateman wrote:
> On 09/10/2012 18:46, Dan Xu wrote:
>> Hi folks,
>>
>> Please help review the code change for CR7186817 to remove Windows 
>> 95/98/ME support. The webrev has been uploaded to 
>> http://cr.openjdk.java.net/~dxu/7186817/webrev/ 
>> <http://cr.openjdk.java.net/%7Edxu/7186817/webrev/>
>>
>> The main focus of this clean-up is in IO area. And I also cleaned 
>> java/lang/ProcessImpl_md.c and java/util/TimeZone_md.c in this 
>> transaction.
>>
>> Thanks,
>>
>> -Dan
> This is great clean-up. I haven't gone through it all yet but one 
> question - are there any changes to the code that moved from 
> Win32FileSystem to WinNTFileSystem? I'm just wondering whether there 
> is anything that needs a closer look.
>
> -Alan

Thanks, Alan.

There are no code changes when moving them from Win32FileSystem to 
WinNTFileSystem.

-Dan


From dan.xu at oracle.com  Tue Oct  9 20:52:07 2012
From: dan.xu at oracle.com (Dan Xu)
Date: Tue, 09 Oct 2012 13:52:07 -0700
Subject: Review Request: 7186817 - Remove Windows 95/98/ME Support
In-Reply-To: <50747B86.3020401@CoSoCo.de>
References: <507462F3.7040205@oracle.com> <50747B86.3020401@CoSoCo.de>
Message-ID: <50748E77.404@oracle.com>

Hi Ulf,

I think it is better to focus on the clean-up for my current 
transaction. The performance improvement of toUpper() method can be 
another topic for String class.

Thanks,

-Dan


On 10/09/2012 12:31 PM, Ulf Zibis wrote:
> Hi,
>
> I did not look into the details, but the hint about performance on 
> String.toLower in WindowsNTFileSystem catched my attention. Here is a 
> very fast converter, which may be enough for calculating the hash:
>
>     // Private ASCII-only optimized version
>     public static final String toUpper(final String s) {
>         boolean allUpper = true;
>         char[] ca = null;
>         for (int i=0; i<s.length(); i++) {
>             int c = s.charAt(i);
>             if (c >= 'a' && c <= 'z') {
>                 if (allUpper) {
>                     ca = s.toCharArray();
>                     allUpper = false;
>                 }
>                 ca[i] -= '\u0020';
>             }
>         }
>         return allUpper ? s : new String(ca);
>     }
>
> It also avoids instantiation of new objects, if there is nothing to 
> change.
> Note: the equivalent toLower algorithm statistically would be little 
> slower on latin characters, but maybe faster on wide spreaded Unicode 
> characters.
>
> -Ulf
>
>
> Am 09.10.2012 19:46, schrieb Dan Xu:
>> Hi folks,
>>
>> Please help review the code change for CR7186817 to remove Windows 
>> 95/98/ME support. The webrev has been uploaded to 
>> http://cr.openjdk.java.net/~dxu/7186817/webrev/ 
>> <http://cr.openjdk.java.net/%7Edxu/7186817/webrev/>
>>
>> The main focus of this clean-up is in IO area. And I also cleaned 
>> java/lang/ProcessImpl_md.c and java/util/TimeZone_md.c in this 
>> transaction.
>>
>> Thanks,
>>
>> -Dan
>>
>



From huizhe.wang at oracle.com  Tue Oct  9 21:17:05 2012
From: huizhe.wang at oracle.com (huizhe.wang at oracle.com)
Date: Tue, 09 Oct 2012 21:17:05 +0000
Subject: hg: jdk8/tl/jaxp: 8000172: 2 SAX features does not work properly
Message-ID: <20121009211710.B3FEB47258@hg.openjdk.java.net>

Changeset: 53a2a4893c8f
Author:    joehw
Date:      2012-10-09 14:19 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/53a2a4893c8f

8000172: 2 SAX features does not work properly
Summary: When external dtd is not loaded, skippedEntity event should be reported for entity references.
Reviewed-by: lancea

! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java



From Ulf.Zibis at CoSoCo.de  Tue Oct  9 23:41:20 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Wed, 10 Oct 2012 01:41:20 +0200
Subject: Review Request: 7186817 - Remove Windows 95/98/ME Support
In-Reply-To: <CACuKZqHYiu43gGCRXJ5H064ncLqOW_GLMag7dfmrKkiNVviwBQ@mail.gmail.com>
References: <507462F3.7040205@oracle.com> <50747B86.3020401@CoSoCo.de>
	<CACuKZqHYiu43gGCRXJ5H064ncLqOW_GLMag7dfmrKkiNVviwBQ@mail.gmail.com>
Message-ID: <5074B620.5020805@CoSoCo.de>

Thanks Zhong, you are correct.
So we additionally can save again 1 variable and 2 lines.

-Ulf

Am 09.10.2012 23:08, schrieb Zhong Yu:
> Ulf, since
>
>      allUpper  <==>  ca==null
>
> we don't need allUpper...
>
> On Tue, Oct 9, 2012 at 2:31 PM, Ulf Zibis <Ulf.Zibis at cosoco.de> wrote:
>> Hi,
>>
>> I did not look into the details, but the hint about performance on
>> String.toLower in WindowsNTFileSystem catched my attention. Here is a very
>> fast converter, which may be enough for calculating the hash:
>>
>>      // Private ASCII-only optimized version
>>      public static final String toUpper(final String s) {
>>          boolean allUpper = true;
>>          char[] ca = null;
>>          for (int i=0; i<s.length(); i++) {
>>              int c = s.charAt(i);
>>              if (c >= 'a' && c <= 'z') {
>>                  if (allUpper) {
>>                      ca = s.toCharArray();
>>                      allUpper = false;
>>                  }
>>                  ca[i] -= '\u0020';
>>              }
>>          }
>>          return allUpper ? s : new String(ca);
>>      }
>>
>> It also avoids instantiation of new objects, if there is nothing to change.
>> Note: the equivalent toLower algorithm statistically would be little slower
>> on latin characters, but maybe faster on wide spreaded Unicode characters.
>>
>> -Ulf
>>
>>
>> Am 09.10.2012 19:46, schrieb Dan Xu:
>>> Hi folks,
>>>
>>> Please help review the code change for CR7186817 to remove Windows
>>> 95/98/ME support. The webrev has been uploaded to
>>> http://cr.openjdk.java.net/~dxu/7186817/webrev/
>>> <http://cr.openjdk.java.net/%7Edxu/7186817/webrev/>
>>>
>>> The main focus of this clean-up is in IO area. And I also cleaned
>>> java/lang/ProcessImpl_md.c and java/util/TimeZone_md.c in this transaction.
>>>
>>> Thanks,
>>>
>>> -Dan
>>>



From jonathan.gibbons at oracle.com  Wed Oct 10 02:12:07 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 10 Oct 2012 02:12:07 +0000
Subject: hg: jdk8/tl/langtools: 8000663: clean up langtools imports
Message-ID: <20121010021212.4397447267@hg.openjdk.java.net>

Changeset: c75be5bc5283
Author:    jjg
Date:      2012-10-09 19:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c75be5bc5283

8000663: clean up langtools imports
Reviewed-by: darcy

! src/share/classes/com/sun/source/tree/CompilationUnitTree.java
! src/share/classes/com/sun/source/tree/Scope.java
! src/share/classes/com/sun/source/util/TaskEvent.java
! src/share/classes/com/sun/source/util/TreePath.java
! src/share/classes/com/sun/tools/classfile/ClassTranslator.java
! src/share/classes/com/sun/tools/classfile/Dependencies.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java
! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java
! src/share/classes/com/sun/tools/javac/api/JavacTrees.java
! src/share/classes/com/sun/tools/javac/api/WrappingJavaFileManager.java
! src/share/classes/com/sun/tools/javac/code/Annotations.java
! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java
! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Kinds.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/Scope.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/TargetType.java
! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java
! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java
! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java
! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java
! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java
! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java
! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/DocImpl.java
! src/share/classes/com/sun/tools/javadoc/DocLocale.java
! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java
! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java
! src/share/classes/com/sun/tools/javadoc/Messager.java
! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java
! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java
! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java
! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java
! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java
! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java
! src/share/classes/com/sun/tools/javadoc/SerializedForm.java
! src/share/classes/com/sun/tools/javadoc/Start.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java
! src/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java
! src/share/classes/javax/annotation/processing/Completions.java
! src/share/classes/javax/annotation/processing/FilerException.java
! src/share/classes/javax/annotation/processing/ProcessingEnvironment.java
! src/share/classes/javax/lang/model/element/AnnotationValue.java
! src/share/classes/javax/lang/model/element/Element.java
! src/share/classes/javax/lang/model/element/ExecutableElement.java
! src/share/classes/javax/lang/model/element/VariableElement.java
! src/share/classes/javax/lang/model/type/MirroredTypeException.java
! src/share/classes/javax/lang/model/type/MirroredTypesException.java
! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java
! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java
! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java
! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java
! src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java
! src/share/classes/javax/lang/model/util/AbstractElementVisitor8.java
! src/share/classes/javax/lang/model/util/ElementFilter.java
! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java
! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java
! src/share/classes/javax/lang/model/util/ElementScanner6.java
! src/share/classes/javax/lang/model/util/ElementScanner7.java
! src/share/classes/javax/lang/model/util/ElementScanner8.java
! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java
! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java
! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java
! src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java
! src/share/classes/javax/lang/model/util/SimpleElementVisitor8.java
! src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java
! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java
! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java
! src/share/classes/javax/lang/model/util/TypeKindVisitor8.java
! src/share/classes/javax/tools/ForwardingJavaFileManager.java
! src/share/classes/javax/tools/JavaFileObject.java



From jonathan.gibbons at oracle.com  Wed Oct 10 02:32:44 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 10 Oct 2012 02:32:44 +0000
Subject: hg: jdk8/tl/langtools: 8000208: fix langtools javadoc comment issues
Message-ID: <20121010023249.D14FF47268@hg.openjdk.java.net>

Changeset: fc123bdeddb8
Author:    jjg
Date:      2012-10-09 19:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fc123bdeddb8

8000208: fix langtools javadoc comment issues
Reviewed-by: bpatel, mcimadamore

! src/share/classes/com/sun/javadoc/Tag.java
! src/share/classes/com/sun/tools/classfile/BootstrapMethods_attribute.java
! src/share/classes/com/sun/tools/classfile/Dependencies.java
! src/share/classes/com/sun/tools/classfile/Instruction.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java
! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/api/JavacTool.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/TypeTags.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/file/Locations.java
! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/nio/PathFileManager.java
! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! src/share/classes/com/sun/tools/javac/parser/Scanner.java
! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java
! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java
! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/AbstractLog.java
! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/Context.java
! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java
! src/share/classes/com/sun/tools/javac/util/Position.java
! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/DocImpl.java
! src/share/classes/com/sun/tools/javadoc/JavadocTool.java
! src/share/classes/com/sun/tools/javadoc/ModifierFilter.java
! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java
! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java
! src/share/classes/com/sun/tools/javah/NativeHeaderTool.java
! src/share/classes/com/sun/tools/javap/DisassemblerTool.java



From Alan.Bateman at oracle.com  Wed Oct 10 10:58:26 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 10 Oct 2012 11:58:26 +0100
Subject: Review Request: 7186817 - Remove Windows 95/98/ME Support
In-Reply-To: <507482E4.7060607@oracle.com>
References: <507462F3.7040205@oracle.com> <50747B65.20303@oracle.com>
	<507482E4.7060607@oracle.com>
Message-ID: <507554D2.5000203@oracle.com>

On 09/10/2012 21:02, Dan Xu wrote:
> :
>
> There are no code changes when moving them from Win32FileSystem to 
> WinNTFileSystem.

Thanks for confirming, that makes it a lot easier to review.

I've looked through the changes and it looks that you've done a very 
thorough job, thank you! The only thing I notice is that a couple of the 
methods that are moved don't need protected access anymore, examples are 
rename0, delete0, getDriveDirectory, canonicalizeWithPrefix and probably 
a few others.

I see Ulf's suggestion to change the hashCode implementation while you 
are there but I agree that this should be looked at separately as the 
focus with this patch is removing code that isn't used anymore.

-Alan





From Alan.Bateman at oracle.com  Wed Oct 10 11:19:03 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 10 Oct 2012 12:19:03 +0100
Subject: 7192274: Deprecate LogManager addPropertyChangeListener and
	removePropertyChangeListe
Message-ID: <507559A7.6050103@oracle.com>


JEP 162 [1] captures a number of things that we can do in preparation 
for future modularization of the platform. One of these items is 
deprecating the Java SE APIs that are problematic for our modularization 
efforts. Thankfully the list is very short as this is deprecation is in 
anticipation of really removing the APIs when a module system comes along.

The patch proposed here is the first installation to deprecate the 
LogManager addPropertyChangeListener and removePropertyChangeListener 
methods. These methods are problematic because of the API dependency on 
java.beans.PropertyChangeListener (java.beans is toxic because of types 
in that package that are tied to Applet, AWT, and Swing). When we 
eventually get to remove these methods then we expect the impact will 
not be too significant. Mandy Chung has done a static analysis over 
20,000 projects to locate usages of these methods and found only 3 so we 
have some useful evidence to demonstrate that they aren't used very 
often. For now we are just proposing to deprecate the methods and the 
proposed patch is here:

http://cr.openjdk.java.net/~alanb/7192274/webrev/jdk.patch

Thanks,
Alan.

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


From Lance.Andersen at oracle.com  Wed Oct 10 11:56:16 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Wed, 10 Oct 2012 07:56:16 -0400
Subject: 7192274: Deprecate LogManager addPropertyChangeListener and
	removePropertyChangeListe
In-Reply-To: <507559A7.6050103@oracle.com>
References: <507559A7.6050103@oracle.com>
Message-ID: <5D42DCC2-D4F6-47CA-8BBE-9B5C0196730F@oracle.com>

looks fine Alan and in line with the other work we have done

Best
Lance
On Oct 10, 2012, at 7:19 AM, Alan Bateman wrote:

> 
> JEP 162 [1] captures a number of things that we can do in preparation for future modularization of the platform. One of these items is deprecating the Java SE APIs that are problematic for our modularization efforts. Thankfully the list is very short as this is deprecation is in anticipation of really removing the APIs when a module system comes along.
> 
> The patch proposed here is the first installation to deprecate the LogManager addPropertyChangeListener and removePropertyChangeListener methods. These methods are problematic because of the API dependency on java.beans.PropertyChangeListener (java.beans is toxic because of types in that package that are tied to Applet, AWT, and Swing). When we eventually get to remove these methods then we expect the impact will not be too significant. Mandy Chung has done a static analysis over 20,000 projects to locate usages of these methods and found only 3 so we have some useful evidence to demonstrate that they aren't used very often. For now we are just proposing to deprecate the methods and the proposed patch is here:
> 
> http://cr.openjdk.java.net/~alanb/7192274/webrev/jdk.patch
> 
> Thanks,
> Alan.
> 
> [1] http://openjdk.java.net/jeps/162


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 Roger.Riggs at oracle.com  Wed Oct 10 14:22:15 2012
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Wed, 10 Oct 2012 10:22:15 -0400
Subject: Reviewer needed: 6282196 There should be Math.mod(number, modulo)
	methods
Message-ID: <50758497.104@oracle.com>

A reviewer is needed for:

6282196 There should be Math.mod(number, modulo) methods

The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/

Thanks, Roger


From scolebourne at joda.org  Wed Oct 10 14:30:12 2012
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 10 Oct 2012 15:30:12 +0100
Subject: Reviewer needed: 6282196 There should be Math.mod(number,
	modulo) methods
In-Reply-To: <50758497.104@oracle.com>
References: <50758497.104@oracle.com>
Message-ID: <CACzrW9DLhOb_aJ0t5z9k7ouGtZOveJ1XARczD4rhpOpff8OciQ@mail.gmail.com>

On 10 October 2012 15:22, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> A reviewer is needed for:
>
> 6282196 There should be Math.mod(number, modulo) methods
>
> The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/

Just to note that floorMod(long, int) is not present. This is often
useful as the mod side generally fits in 32 bits, which means the
result can fit in 32 bits. This often saves the need to call
toIntExact() on the result.

Stephen


From lance.andersen at oracle.com  Wed Oct 10 15:08:42 2012
From: lance.andersen at oracle.com (Lance Andersen - Oracle)
Date: Wed, 10 Oct 2012 11:08:42 -0400
Subject: Review needed for 8000687
Message-ID: <13522A60-B7A9-41FA-9822-F255AE394B47@oracle.com>

Need a reviewer for a simple typo in the DriverManager javadoc

new-host-2:sql lanceandersen$ hg diff
diff -r 036c55976cef src/share/classes/java/sql/DriverManager.java
--- a/src/share/classes/java/sql/DriverManager.java	Tue Oct 09 08:58:27 2012 -0400
+++ b/src/share/classes/java/sql/DriverManager.java	Wed Oct 10 10:59:00 2012 -0400
@@ -412,7 +412,7 @@
      * method throws a <code>java.lang.SecurityException</code>.
      *
      * @param out the new logging/tracing PrintStream; to disable, set to <code>null</code>
-     * @deprecated Use {@code setLogWriter)
+     * @deprecated Use {@code setLogWriter}
      * @throws SecurityException if a security manager exists and its
      *    <code>checkPermission</code> method denies setting the log stream
      *
@@ -439,7 +439,7 @@
      * and all drivers.
      *
      * @return the logging/tracing PrintStream; if disabled, is <code>null</code>
-     * @deprecated  Use {@code getLogWriter)
+     * @deprecated  Use {@code getLogWriter}
      * @see #setLogStream
      */
     @Deprecated
new-host-2:sql lanceandersen$ 


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 Alan.Bateman at oracle.com  Wed Oct 10 15:11:54 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 10 Oct 2012 16:11:54 +0100
Subject: Review needed for 8000687
In-Reply-To: <13522A60-B7A9-41FA-9822-F255AE394B47@oracle.com>
References: <13522A60-B7A9-41FA-9822-F255AE394B47@oracle.com>
Message-ID: <5075903A.9060707@oracle.com>

On 10/10/2012 16:08, Lance Andersen - Oracle wrote:
> Need a reviewer for a simple typo in the DriverManager javadoc
>
> new-host-2:sql lanceandersen$ hg diff
> diff -r 036c55976cef src/share/classes/java/sql/DriverManager.java
> --- a/src/share/classes/java/sql/DriverManager.java	Tue Oct 09 08:58:27 2012 -0400
> +++ b/src/share/classes/java/sql/DriverManager.java	Wed Oct 10 10:59:00 2012 -0400
> @@ -412,7 +412,7 @@
>        * method throws a<code>java.lang.SecurityException</code>.
>        *
>        * @param out the new logging/tracing PrintStream; to disable, set to<code>null</code>
> -     * @deprecated Use {@code setLogWriter)
> +     * @deprecated Use {@code setLogWriter}
>        * @throws SecurityException if a security manager exists and its
>        *<code>checkPermission</code>  method denies setting the log stream
>        *
> @@ -439,7 +439,7 @@
>        * and all drivers.
>        *
>        * @return the logging/tracing PrintStream; if disabled, is<code>null</code>
> -     * @deprecated  Use {@code getLogWriter)
> +     * @deprecated  Use {@code getLogWriter}
>        * @see #setLogStream
>        */
>       @Deprecated
> new-host-2:sql lanceandersen$
>
Thanks Lance, looks good to me. Also the javadoc build was warning free 
a few days ago and it's nice to get back to that state.

-Alan


From lance.andersen at oracle.com  Wed Oct 10 15:15:48 2012
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Wed, 10 Oct 2012 15:15:48 +0000
Subject: hg: jdk8/tl/jdk: 8000687: Correct javadoc typo for getLogWriter and
	setLogWriter
Message-ID: <20121010151624.EDA6447284@hg.openjdk.java.net>

Changeset: 3c4be36de073
Author:    lancea
Date:      2012-10-10 11:15 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c4be36de073

8000687: Correct javadoc typo for getLogWriter and setLogWriter
Reviewed-by: alanb

! src/share/classes/java/sql/DriverManager.java



From eamonn at mcmanus.net  Wed Oct 10 16:12:28 2012
From: eamonn at mcmanus.net (Eamonn McManus)
Date: Wed, 10 Oct 2012 09:12:28 -0700
Subject: Reviewer needed: 6282196 There should be Math.mod(number,
	modulo) methods
In-Reply-To: <50758497.104@oracle.com>
References: <50758497.104@oracle.com>
Message-ID: <CACBEn46xV9ewQ4efwooWaX=wwa+24gtGtGCj24Wiwx_OTahwuQ@mail.gmail.com>

One edge case: the spec for floorDiv implies that
floorDiv(Integer.MIN_VALUE, -1) should be Integer.MAX_VALUE but I
believe the code produces Integer.MIN_VALUE. EIther the spec or the
code should be fixed.

?amonn


2012/10/10 Roger Riggs <Roger.Riggs at oracle.com>:
> A reviewer is needed for:
>
> 6282196 There should be Math.mod(number, modulo) methods
>
> The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/
>
> Thanks, Roger


From mandy.chung at oracle.com  Wed Oct 10 17:11:19 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 10 Oct 2012 10:11:19 -0700
Subject: 7192274: Deprecate LogManager addPropertyChangeListener and
	removePropertyChangeListe
In-Reply-To: <507559A7.6050103@oracle.com>
References: <507559A7.6050103@oracle.com>
Message-ID: <5075AC37.1010801@oracle.com>

The change looks good.
Mandy

On 10/10/2012 4:19 AM, Alan Bateman wrote:
>
> JEP 162 [1] captures a number of things that we can do in preparation 
> for future modularization of the platform. One of these items is 
> deprecating the Java SE APIs that are problematic for our 
> modularization efforts. Thankfully the list is very short as this is 
> deprecation is in anticipation of really removing the APIs when a 
> module system comes along.
>
> The patch proposed here is the first installation to deprecate the 
> LogManager addPropertyChangeListener and removePropertyChangeListener 
> methods. These methods are problematic because of the API dependency 
> on java.beans.PropertyChangeListener (java.beans is toxic because of 
> types in that package that are tied to Applet, AWT, and Swing). When 
> we eventually get to remove these methods then we expect the impact 
> will not be too significant. Mandy Chung has done a static analysis 
> over 20,000 projects to locate usages of these methods and found only 
> 3 so we have some useful evidence to demonstrate that they aren't used 
> very often. For now we are just proposing to deprecate the methods and 
> the proposed patch is here:
>
> http://cr.openjdk.java.net/~alanb/7192274/webrev/jdk.patch
>
> Thanks,
> Alan.
>
> [1] http://openjdk.java.net/jeps/162


From xueming.shen at oracle.com  Wed Oct 10 17:54:37 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 10 Oct 2012 10:54:37 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
Message-ID: <5075B65D.1020709@oracle.com>


A standard/public API for Base64 encoding and decoding has been long
overdue. JDK8  has a JEP [1] for this particular request.

Here is the draft proposal to add a public Base64 utility class for JDK8.

http://cr.openjdk.java.net/~sherman/4235519/webrev

This class basically provides 4 variants of Base64 encoding scheme,

(1) the default RFC 4648, which uses standard mapping, no line breaks,
(2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace 
"+" and
     "/" for the mapping
(3) the default MIME style, as in RFC 2045 (and its earlier versions), 
which uses
     "standard" base64 mapping, a 76 characters per line limit and uses 
crlf pair
      \r\n for line break.
(4) an extend-able MIME base64, with the char-per-line and the line 
separator(s)
      specified by developer.

The encoder/decoder now provides encoding and decoding for byte[], String,
ByteBuffer and a pair of "EncoderInputStream" and "DecoderOutputStrream",
which we believe/hope should satisfy most of the common use cases. 
Additional
method(s) can be added if strongly desired.

We tried couple slightly different styles of design for such this 
"simple" utility
class [2].  We kinda concluded that the version proposed probably provides
the best balance among readability, usability and extensibility.

Please help review and comment on the API and implementation.

Thanks!
-Sherman

[1] http://openjdk.java.net/jeps/135
[2] http://cr.openjdk.java.net/~sherman/base64/


From chris.hegarty at oracle.com  Wed Oct 10 18:55:35 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 10 Oct 2012 19:55:35 +0100
Subject: 7192274: Deprecate LogManager addPropertyChangeListener and
	removePropertyChangeListe
In-Reply-To: <5075AC37.1010801@oracle.com>
References: <507559A7.6050103@oracle.com> <5075AC37.1010801@oracle.com>
Message-ID: <58A0DBAE-0B5F-45D2-95E6-4D04A32E3321@oracle.com>


On 10 Oct 2012, at 18:11, Mandy Chung <mandy.chung at oracle.com> wrote:

> The change looks good.

+1

-Chris

> Mandy
> 
> On 10/10/2012 4:19 AM, Alan Bateman wrote:
>> 
>> JEP 162 [1] captures a number of things that we can do in preparation for future modularization of the platform. One of these items is deprecating the Java SE APIs that are problematic for our modularization efforts. Thankfully the list is very short as this is deprecation is in anticipation of really removing the APIs when a module system comes along.
>> 
>> The patch proposed here is the first installation to deprecate the LogManager addPropertyChangeListener and removePropertyChangeListener methods. These methods are problematic because of the API dependency on java.beans.PropertyChangeListener (java.beans is toxic because of types in that package that are tied to Applet, AWT, and Swing). When we eventually get to remove these methods then we expect the impact will not be too significant. Mandy Chung has done a static analysis over 20,000 projects to locate usages of these methods and found only 3 so we have some useful evidence to demonstrate that they aren't used very often. For now we are just proposing to deprecate the methods and the proposed patch is here:
>> 
>> http://cr.openjdk.java.net/~alanb/7192274/webrev/jdk.patch
>> 
>> Thanks,
>> Alan.
>> 
>> [1] http://openjdk.java.net/jeps/162


From alan.bateman at oracle.com  Wed Oct 10 19:47:09 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 10 Oct 2012 19:47:09 +0000
Subject: hg: jdk8/tl/jdk: 7192274: Deprecate LogManager
	addPropertyChangeListener and removePropertyChangeLister methods
Message-ID: <20121010194731.31C134728D@hg.openjdk.java.net>

Changeset: 6455182d2797
Author:    alanb
Date:      2012-10-10 20:47 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6455182d2797

7192274: Deprecate LogManager addPropertyChangeListener and removePropertyChangeLister methods
Reviewed-by: mchung, lancea, chegar

! src/share/classes/java/util/logging/LogManager.java



From iris.clark at oracle.com  Wed Oct 10 20:03:44 2012
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 10 Oct 2012 13:03:44 -0700 (PDT)
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5075B65D.1020709@oracle.com>
References: <5075B65D.1020709@oracle.com>
Message-ID: <2a56378e-86fa-43ac-8d87-54fb5203c345@default>

Hi, Sherman.

I'm glad to see this coming in.  As you said, long overdue.

I'm curious.  What are the plans are to encourage migration from the JDK private and unsupported sun.misc.BASE64{En,DE}coder classes?  Compile-time warning?  Documentation?  Something else?

Thanks,
iris

-----Original Message-----
From: Xueming Shen 
Sent: Wednesday, October 10, 2012 10:55 AM
To: core-libs-dev
Subject: Review/comment needed for the new public java.util.Base64 class


A standard/public API for Base64 encoding and decoding has been long overdue. JDK8  has a JEP [1] for this particular request.

Here is the draft proposal to add a public Base64 utility class for JDK8.

http://cr.openjdk.java.net/~sherman/4235519/webrev

This class basically provides 4 variants of Base64 encoding scheme,

(1) the default RFC 4648, which uses standard mapping, no line breaks,
(2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace "+" and
     "/" for the mapping
(3) the default MIME style, as in RFC 2045 (and its earlier versions), which uses
     "standard" base64 mapping, a 76 characters per line limit and uses crlf pair
      \r\n for line break.
(4) an extend-able MIME base64, with the char-per-line and the line
separator(s)
      specified by developer.

The encoder/decoder now provides encoding and decoding for byte[], String, ByteBuffer and a pair of "EncoderInputStream" and "DecoderOutputStrream", which we believe/hope should satisfy most of the common use cases. 
Additional
method(s) can be added if strongly desired.

We tried couple slightly different styles of design for such this "simple" utility class [2].  We kinda concluded that the version proposed probably provides the best balance among readability, usability and extensibility.

Please help review and comment on the API and implementation.

Thanks!
-Sherman

[1] http://openjdk.java.net/jeps/135
[2] http://cr.openjdk.java.net/~sherman/base64/


From dan.xu at oracle.com  Wed Oct 10 20:18:46 2012
From: dan.xu at oracle.com (Dan Xu)
Date: Wed, 10 Oct 2012 13:18:46 -0700
Subject: Review Request: 7186817 - Remove Windows 95/98/ME Support
In-Reply-To: <507554D2.5000203@oracle.com>
References: <507462F3.7040205@oracle.com> <50747B65.20303@oracle.com>
	<507482E4.7060607@oracle.com> <507554D2.5000203@oracle.com>
Message-ID: <5075D826.2050509@oracle.com>

Thanks for your good comments.

I have changed access modifiers for methods in WinNTFileSystem.java. 
And the new webrev can be viewed at 
http://cr.openjdk.java.net/~dxu/7186817/webrev.01/

I did not change the hashCode implementation in this version. It will 
need further complete tests and another round of code review. But it is 
a good point to improve our code performance. Please log another bug to 
address this issue. Thanks!

-Dan



On Wed 10 Oct 2012 03:58:26 AM PDT, Alan Bateman wrote:
> On 09/10/2012 21:02, Dan Xu wrote:
>> :
>>
>> There are no code changes when moving them from Win32FileSystem to
>> WinNTFileSystem.
>
> Thanks for confirming, that makes it a lot easier to review.
>
> I've looked through the changes and it looks that you've done a very
> thorough job, thank you! The only thing I notice is that a couple of
> the methods that are moved don't need protected access anymore,
> examples are rename0, delete0, getDriveDirectory,
> canonicalizeWithPrefix and probably a few others.
>
> I see Ulf's suggestion to change the hashCode implementation while you
> are there but I agree that this should be looked at separately as the
> focus with this patch is removing code that isn't used anymore.
>
> -Alan
>
>
>


From jim.gish at oracle.com  Wed Oct 10 20:19:24 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 10 Oct 2012 16:19:24 -0400
Subject: RFR: 6206780 (str) Forwarding append methods in String{Buffer,
	Builder} are inconsistent
In-Reply-To: <5071FF68.8030804@gmail.com>
References: <50622A25.4050605@oracle.com> <5062D4F8.9040201@oracle.com>
	<506339D1.6050909@oracle.com> <5065E7D4.6000705@oracle.com>
	<5068025A.5010303@oracle.com> <50685F03.6040706@oracle.com>
	<506A0995.6030905@oracle.com> <506AAEE1.8080207@oracle.com>
	<506AED3C.7080000@oracle.com>
	<CAHjP37Ekhyo1dQa92ZYvG_e7zjTATCKGmHKh=fv6ES_rcXvd7g@mail.gmail.com>
	<506B281F.1090005@oracle.com> <506F80B0.4040105@oracle.com>
	<5071CD10.5050109@oracle.com> <5071FF68.8030804@gmail.com>
Message-ID: <5075D84C.5000405@oracle.com>

Thank you, Peter.

Alan -- could you please do a final review with the changes I made to 
the test and push it for me?

http://cr.openjdk.java.net/~jgish/Bug6206780-sb-append-forward/

Thanks,
    Jim

On 10/07/2012 06:17 PM, Peter Levart wrote:
> On 10/07/2012 08:42 PM, Alan Bateman wrote:
>> On 06/10/2012 01:52, Jim Gish wrote:
>>> I've revamped the previous proposed change.  Please review the 
>>> update at 
>>> http://cr.openjdk.java.net/~jgish/Bug6206780-sb-append-forward/ 
>>> <http://cr.openjdk.java.net/%7Ejgish/Bug6206780-sb-append-forward/>
>>>
>>> This revision contains the following additions/changes:
>>> 1. consistent usage of @Overrides
>>> 2. comments on unsynchronized methods depending on other 
>>> synchronized methods
>>> 3. overall more code coverage of insert, append, indexOf, 
>>> lastIndexOf, etc. for both StringBuffer and StringBuilder
>>> 4. testing of StringBuffer to ensure that all public un-synchronized 
>>> methods are actually synchronized along their call chain.  the 
>>> StringBuffer/TestSynchronization class uses reflection to decide 
>>> which methods to test and could be (with a bit of work on method 
>>> parameter setup), be used to test any class for these 
>>> synchronization properties.  The motivation for this test is to 
>>> provide some degree of assurance that modifications to StringBuffer, 
>>> particularly addition of new methods, do not break the 
>>> synchronization contract. The code also includes a self-test to 
>>> guard against breaking the test program itself.
>>>
>> I'm skimmed over this and StringBuffer looks a lot better, thanks for 
>> reverting back and adding the comments.
>>
>> I don't have time to review the tests just now but it looks like 
>> you've added a test of useful tests. I did look at 
>> TestSynchronization.testSynchronized and the approach looks right. 
>> The timeout is short so there will periodically be false positives 
>> but that's okay as increasing the timeout will slow down the test 
>> (the main thing I was looking for was the potential for false 
>> negatives).
>>
>> -Alan
>
> Hi Jim,
>
> Here's a way to test for synchronization deterministically. And it 
> takes as much time as the testing methods runs (no timeouts):
>
>
> public class SyncTest
> {
>     public static class MyClass
>     {
>         public synchronized void synchronized_method() throws 
> InterruptedException
>         {
>             Thread.sleep(1000);
>         }
>
>         public void not_synchronized_method() throws InterruptedException
>         {
>             Thread.sleep(1000);
>         }
>
>         public void indirectly_synchronized_method() throws 
> InterruptedException
>         {
>             Thread.sleep(100);
>             synchronized_method();
>         }
>     }
>
>     private static boolean isSynchronized(Method m, Object target)
>     {
>         Thread t = new Thread(new InvokeTask(m, target));
>
>         Boolean isSynchronized = null;
>
>         synchronized (target)
>         {
>             t.start();
>
>             while (isSynchronized == null)
>             {
>                 switch (t.getState())
>                 {
>                     case NEW:
>                     case RUNNABLE:
>                     case WAITING:
>                     case TIMED_WAITING:
>                         Thread.yield();
>                         break;
>                     case BLOCKED:
>                         isSynchronized = true;
>                         break;
>                     case TERMINATED:
>                         isSynchronized = false;
>                         break;
>                 }
>             }
>         }
>
>         try
>         {
>             t.join();
>         }
>         catch (InterruptedException ex)
>         {
>             ex.printStackTrace();
>         }
>
>         return isSynchronized;
>     }
>
>     public static void main(String[] args)
>     {
>         Method[] methods = MyClass.class.getDeclaredMethods();
>         Object target = new MyClass();
>
>         for (Method m : methods)
>         {
>             System.out.println(m + " - isSynchronized: " + 
> isSynchronized(m, target));;
>         }
>     }
>
>     static class InvokeTask implements Runnable
>     {
>         private final Method m;
>         private final Object target;
>         private final Object[] args;
>
>         InvokeTask(Method m, Object target, Object...args)
>         {
>             this.m = m;
>             this.target = target;
>             this.args = args;
>         }
>
>         @Override
>         public void run()
>         {
>             try
>             {
>                 m.invoke(target, args);
>             }
>             catch (Exception e)
>             {
>                 e.printStackTrace();
>             }
>         }
>     }
> }
>
>
>
> Regards, Peter
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From joe.darcy at oracle.com  Wed Oct 10 20:40:40 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 10 Oct 2012 13:40:40 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <2a56378e-86fa-43ac-8d87-54fb5203c345@default>
References: <5075B65D.1020709@oracle.com>
	<2a56378e-86fa-43ac-8d87-54fb5203c345@default>
Message-ID: <5075DD48.4030705@oracle.com>

Hello,

On 10/10/2012 1:03 PM, Iris Clark wrote:
> Hi, Sherman.
>
> I'm glad to see this coming in.  As you said, long overdue.
>
> I'm curious.  What are the plans are to encourage migration from the JDK private and unsupported sun.misc.BASE64{En,DE}coder classes?  Compile-time warning?  Documentation?  Something else?

On that point, sun.misc.BASE64{En,DE}coder may present a fine 
opportunity to use the @Deprecated annotation...

-Joe

>
> Thanks,
> iris
>
> -----Original Message-----
> From: Xueming Shen
> Sent: Wednesday, October 10, 2012 10:55 AM
> To: core-libs-dev
> Subject: Review/comment needed for the new public java.util.Base64 class
>
>
> A standard/public API for Base64 encoding and decoding has been long overdue. JDK8  has a JEP [1] for this particular request.
>
> Here is the draft proposal to add a public Base64 utility class for JDK8.
>
> http://cr.openjdk.java.net/~sherman/4235519/webrev
>
> This class basically provides 4 variants of Base64 encoding scheme,
>
> (1) the default RFC 4648, which uses standard mapping, no line breaks,
> (2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace "+" and
>       "/" for the mapping
> (3) the default MIME style, as in RFC 2045 (and its earlier versions), which uses
>       "standard" base64 mapping, a 76 characters per line limit and uses crlf pair
>        \r\n for line break.
> (4) an extend-able MIME base64, with the char-per-line and the line
> separator(s)
>        specified by developer.
>
> The encoder/decoder now provides encoding and decoding for byte[], String, ByteBuffer and a pair of "EncoderInputStream" and "DecoderOutputStrream", which we believe/hope should satisfy most of the common use cases.
> Additional
> method(s) can be added if strongly desired.
>
> We tried couple slightly different styles of design for such this "simple" utility class [2].  We kinda concluded that the version proposed probably provides the best balance among readability, usability and extensibility.
>
> Please help review and comment on the API and implementation.
>
> Thanks!
> -Sherman
>
> [1] http://openjdk.java.net/jeps/135
> [2] http://cr.openjdk.java.net/~sherman/base64/



From Lance.Andersen at oracle.com  Wed Oct 10 21:06:09 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Wed, 10 Oct 2012 17:06:09 -0400
Subject: Review Request for 8000712
Message-ID: <55AE6A24-3DA1-45D6-8255-07C3E5822DD9@oracle.com>

Hi,  

Looking for a reviewer for the removal of the following non-used fields in SyncFactory

 private static String default_provider
>    private static Level rsLevel
>    private static Object logSync
>    private static java.io.PrintWriter logWriter


Best
Lance

new-host-2:spi lanceandersen$ hg diff SyncFactory.java 
diff -r 3c4be36de073 src/share/classes/javax/sql/rowset/spi/SyncFactory.java
--- a/src/share/classes/javax/sql/rowset/spi/SyncFactory.java	Wed Oct 10 11:15:27 2012 -0400
+++ b/src/share/classes/javax/sql/rowset/spi/SyncFactory.java	Wed Oct 10 16:57:46 2012 -0400
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2011, 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
@@ -229,11 +229,7 @@
      * The standard resource file name.
      */
     private static String ROWSET_PROPERTIES = "rowset.properties";
-    /**
-     * The RI Optimistic Provider.
-     */
-    private static String default_provider =
-            "com.sun.rowset.providers.RIOptimisticProvider";
+
     /**
      *  Permission required to invoke setJNDIContext and setLogger
      */
@@ -248,24 +244,13 @@
      * The <code>Logger</code> object to be used by the <code>SyncFactory</code>.
      */
     private static volatile Logger rsLogger;
-    /**
-     *
-     */
-    private static Level rsLevel;
+
     /**
      * The registry of available <code>SyncProvider</code> implementations.
      * See section 2.0 of the class comment for <code>SyncFactory</code> for an
      * explanation of how a provider can be added to this registry.
      */
     private static Hashtable<String, SyncProvider> implementations;
-    /**
-     * Internal sync object used to maintain the SPI as a singleton
-     */
-    private static Object logSync = new Object();
-    /**
-     * Internal PrintWriter field for logging facility
-     */
-    private static java.io.PrintWriter logWriter = null;
 
     /**
      * Adds the the given synchronization provider to the factory register. Guidelines
new-host-2:spi lanceandersen$




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From mandy.chung at oracle.com  Wed Oct 10 21:20:31 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 10 Oct 2012 14:20:31 -0700
Subject: Review Request for 8000712
In-Reply-To: <55AE6A24-3DA1-45D6-8255-07C3E5822DD9@oracle.com>
References: <55AE6A24-3DA1-45D6-8255-07C3E5822DD9@oracle.com>
Message-ID: <5075E69F.4070106@oracle.com>

Looks good to me.

Mandy

On 10/10/2012 2:06 PM, Lance Andersen - Oracle wrote:
> Hi,
>
> Looking for a reviewer for the removal of the following non-used fields in SyncFactory
>
>   private static String default_provider
>>     private static Level rsLevel
>>     private static Object logSync
>>     private static java.io.PrintWriter logWriter
>
> Best
> Lance
>
> new-host-2:spi lanceandersen$ hg diff SyncFactory.java
> diff -r 3c4be36de073 src/share/classes/javax/sql/rowset/spi/SyncFactory.java
> --- a/src/share/classes/javax/sql/rowset/spi/SyncFactory.java	Wed Oct 10 11:15:27 2012 -0400
> +++ b/src/share/classes/javax/sql/rowset/spi/SyncFactory.java	Wed Oct 10 16:57:46 2012 -0400
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2003, 2011, 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
> @@ -229,11 +229,7 @@
>        * The standard resource file name.
>        */
>       private static String ROWSET_PROPERTIES = "rowset.properties";
> -    /**
> -     * The RI Optimistic Provider.
> -     */
> -    private static String default_provider =
> -            "com.sun.rowset.providers.RIOptimisticProvider";
> +
>       /**
>        *  Permission required to invoke setJNDIContext and setLogger
>        */
> @@ -248,24 +244,13 @@
>        * The<code>Logger</code>  object to be used by the<code>SyncFactory</code>.
>        */
>       private static volatile Logger rsLogger;
> -    /**
> -     *
> -     */
> -    private static Level rsLevel;
> +
>       /**
>        * The registry of available<code>SyncProvider</code>  implementations.
>        * See section 2.0 of the class comment for<code>SyncFactory</code>  for an
>        * explanation of how a provider can be added to this registry.
>        */
>       private static Hashtable<String, SyncProvider>  implementations;
> -    /**
> -     * Internal sync object used to maintain the SPI as a singleton
> -     */
> -    private static Object logSync = new Object();
> -    /**
> -     * Internal PrintWriter field for logging facility
> -     */
> -    private static java.io.PrintWriter logWriter = null;
>
>       /**
>        * Adds the the given synchronization provider to the factory register. Guidelines
> new-host-2:spi lanceandersen$
>
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>


From lance.andersen at oracle.com  Wed Oct 10 21:34:43 2012
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Wed, 10 Oct 2012 21:34:43 +0000
Subject: hg: jdk8/tl/jdk: 8000712: Remove unused fields in SyncFactory
Message-ID: <20121010213505.A649847297@hg.openjdk.java.net>

Changeset: 734ca9f4719c
Author:    lancea
Date:      2012-10-10 17:34 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/734ca9f4719c

8000712: Remove unused fields in SyncFactory
Reviewed-by: mchung

! src/share/classes/javax/sql/rowset/spi/SyncFactory.java



From jonathan.gibbons at oracle.com  Wed Oct 10 23:48:58 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 10 Oct 2012 23:48:58 +0000
Subject: hg: jdk8/tl/langtools: 8000665: fix "internal API" comments on
	javadoc files
Message-ID: <20121010234903.EFFAF472A3@hg.openjdk.java.net>

Changeset: 25e14ad23cef
Author:    jjg
Date:      2012-10-10 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/25e14ad23cef

8000665: fix "internal API" comments on javadoc files
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeOptionalMemberWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstructorWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/FieldWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/MethodWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/NestedClassWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/XMLNode.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseExecutableMemberTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseInlineTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DeprecatedTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DocRootTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritableTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LegacyTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/CommentedMethodFinder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodFinder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/TaggedMethodFinder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/TextTag.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java
! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java
! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java
! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java
! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java
! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/Comment.java
! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java
! src/share/classes/com/sun/tools/javadoc/DocEnv.java
! src/share/classes/com/sun/tools/javadoc/DocImpl.java
! src/share/classes/com/sun/tools/javadoc/DocLocale.java
! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java
! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java
! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java
! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java
! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java
! src/share/classes/com/sun/tools/javadoc/JavadocTodo.java
! src/share/classes/com/sun/tools/javadoc/JavadocTool.java
! src/share/classes/com/sun/tools/javadoc/Main.java
! src/share/classes/com/sun/tools/javadoc/MemberDocImpl.java
! src/share/classes/com/sun/tools/javadoc/Messager.java
! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java
! src/share/classes/com/sun/tools/javadoc/ModifierFilter.java
! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java
! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java
! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java
! src/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java
! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java
! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java
! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java
! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java
! src/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java
! src/share/classes/com/sun/tools/javadoc/SerializedForm.java
! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java
! src/share/classes/com/sun/tools/javadoc/Start.java
! src/share/classes/com/sun/tools/javadoc/TagImpl.java
! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java
! src/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java



From jonathan.gibbons at oracle.com  Thu Oct 11 01:08:56 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 11 Oct 2012 01:08:56 +0000
Subject: hg: jdk8/tl/langtools: 8000743: docencoding not available to
	stylesheet
Message-ID: <20121011010901.292FA472A5@hg.openjdk.java.net>

Changeset: 560d4a5d14e6
Author:    jjg
Date:      2012-10-10 18:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/560d4a5d14e6

8000743: docencoding not available to stylesheet
Reviewed-by: jjg
Contributed-by: jviswana at linux.vnet.ibm.com

! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
+ test/com/sun/javadoc/testDocEncoding/TestDocEncoding.java
+ test/com/sun/javadoc/testDocEncoding/pkg/Test.java



From jonathan.gibbons at oracle.com  Thu Oct 11 01:35:22 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 11 Oct 2012 01:35:22 +0000
Subject: hg: jdk8/tl/langtools: 8000418: javadoc should used a standard
	"generated by javadoc" string
Message-ID: <20121011013525.E77F8472A8@hg.openjdk.java.net>

Changeset: 6517bf8e50d0
Author:    jjg
Date:      2012-10-10 18:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6517bf8e50d0

8000418: javadoc should used a standard "generated by javadoc" string
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! test/com/sun/javadoc/VersionNumber/VersionNumber.java
+ test/com/sun/javadoc/testGeneratedBy/TestGeneratedBy.java
+ test/com/sun/javadoc/testGeneratedBy/pkg/MyClass.java



From jonathan.gibbons at oracle.com  Thu Oct 11 01:44:52 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 11 Oct 2012 01:44:52 +0000
Subject: hg: jdk8/tl/langtools: 8000310: Clean up use of StringBuffer in
	langtools
Message-ID: <20121011014457.34203472A9@hg.openjdk.java.net>

Changeset: c46e0c9940d6
Author:    jjg
Date:      2012-10-10 18:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c46e0c9940d6

8000310: Clean up use of StringBuffer in langtools
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/classfile/Descriptor.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/util/Convert.java
! src/share/classes/com/sun/tools/javac/util/List.java
! src/share/classes/com/sun/tools/javah/Gen.java
! src/share/classes/com/sun/tools/javah/LLNI.java
! src/share/classes/com/sun/tools/javah/Mangle.java



From weijun.wang at oracle.com  Thu Oct 11 01:51:25 2012
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 11 Oct 2012 09:51:25 +0800
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5075B65D.1020709@oracle.com>
References: <5075B65D.1020709@oracle.com>
Message-ID: <5076261D.9020906@oracle.com>

Several questions:

1. In encode0(byte[] src, byte[] dst)

  281                 if (linepos == linemax && (atom != 0 || sp < sl)) {

Maybe atom != 0 is not necessary?

2. Is it necessary to explicitly mention in the spec that there is no 
CrLf at the end of a MIME encoded string?

3. The test confirms decoding can correctly reverse the encoding but it 
says nothing about the correctness of the encoding. Maybe we can just 
use "10.  Test Vectors" of RFC 4648?

Thanks
Max

On 10/11/2012 01:54 AM, Xueming Shen wrote:
>
> A standard/public API for Base64 encoding and decoding has been long
> overdue. JDK8  has a JEP [1] for this particular request.
>
> Here is the draft proposal to add a public Base64 utility class for JDK8.
>
> http://cr.openjdk.java.net/~sherman/4235519/webrev
>
> This class basically provides 4 variants of Base64 encoding scheme,
>
> (1) the default RFC 4648, which uses standard mapping, no line breaks,
> (2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace
> "+" and
>      "/" for the mapping
> (3) the default MIME style, as in RFC 2045 (and its earlier versions),
> which uses
>      "standard" base64 mapping, a 76 characters per line limit and uses
> crlf pair
>       \r\n for line break.
> (4) an extend-able MIME base64, with the char-per-line and the line
> separator(s)
>       specified by developer.
>
> The encoder/decoder now provides encoding and decoding for byte[], String,
> ByteBuffer and a pair of "EncoderInputStream" and "DecoderOutputStrream",
> which we believe/hope should satisfy most of the common use cases.
> Additional
> method(s) can be added if strongly desired.
>
> We tried couple slightly different styles of design for such this
> "simple" utility
> class [2].  We kinda concluded that the version proposed probably provides
> the best balance among readability, usability and extensibility.
>
> Please help review and comment on the API and implementation.
>
> Thanks!
> -Sherman
>
> [1] http://openjdk.java.net/jeps/135
> [2] http://cr.openjdk.java.net/~sherman/base64/


From xueming.shen at oracle.com  Thu Oct 11 03:09:29 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 10 Oct 2012 20:09:29 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5076261D.9020906@oracle.com>
References: <5075B65D.1020709@oracle.com> <5076261D.9020906@oracle.com>
Message-ID: <50763869.20708@oracle.com>

On 10/10/12 6:51 PM, Weijun Wang wrote:
> Several questions:
>
> 1. In encode0(byte[] src, byte[] dst)
>
>  281                 if (linepos == linemax && (atom != 0 || sp < sl)) {
>
> Maybe atom != 0 is not necessary?

The logic here is that if we reached the last atom (atom == 0), but if there
is still byte(s) in src (sp < sl), we will need to output the last 
special unit,
which has one or two padding charactere '=', in this case, we still need to
output the line separator(s).

>
> 2. Is it necessary to explicitly mention in the spec that there is no 
> CrLf at the end of a MIME encoded string?

I'm struggling with which is the appropriate/desired behavior, output 
the crlf for the last line
or not. Apache's common coder appears to append the crlf for the last 
line, but our sun.misc
version does not (but sun.misc.BASE64 actually appends the line 
separator if the last line
happens to have 76 characters, I would assume this is a bug though). The 
current implement
tries to match the sun.misc. I'm happy to go either way.

But, as you suggested, it might be worth explicitly describing whatever 
behavior we choose.

>
> 3. The test confirms decoding can correctly reverse the encoding but 
> it says nothing about the correctness of the encoding. Maybe we can 
> just use "10.  Test Vectors" of RFC 4648?
>

I do have a version of TestBase64 actually compares encoded results of 
j.u.Base64,
sun.misc.BASE64Encoder and org.apache.commons.codec.binary.Base64. Maybe 
I should
at least plug in the code for comparing with sun.misc.Base64Encoder.

Thanks!
-Sherman


>
>
> On 10/11/2012 01:54 AM, Xueming Shen wrote:
>>
>> A standard/public API for Base64 encoding and decoding has been long
>> overdue. JDK8  has a JEP [1] for this particular request.
>>
>> Here is the draft proposal to add a public Base64 utility class for 
>> JDK8.
>>
>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>
>> This class basically provides 4 variants of Base64 encoding scheme,
>>
>> (1) the default RFC 4648, which uses standard mapping, no line breaks,
>> (2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace
>> "+" and
>>      "/" for the mapping
>> (3) the default MIME style, as in RFC 2045 (and its earlier versions),
>> which uses
>>      "standard" base64 mapping, a 76 characters per line limit and uses
>> crlf pair
>>       \r\n for line break.
>> (4) an extend-able MIME base64, with the char-per-line and the line
>> separator(s)
>>       specified by developer.
>>
>> The encoder/decoder now provides encoding and decoding for byte[], 
>> String,
>> ByteBuffer and a pair of "EncoderInputStream" and 
>> "DecoderOutputStrream",
>> which we believe/hope should satisfy most of the common use cases.
>> Additional
>> method(s) can be added if strongly desired.
>>
>> We tried couple slightly different styles of design for such this
>> "simple" utility
>> class [2].  We kinda concluded that the version proposed probably 
>> provides
>> the best balance among readability, usability and extensibility.
>>
>> Please help review and comment on the API and implementation.
>>
>> Thanks!
>> -Sherman
>>
>> [1] http://openjdk.java.net/jeps/135
>> [2] http://cr.openjdk.java.net/~sherman/base64/



From xueming.shen at oracle.com  Thu Oct 11 03:15:25 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 10 Oct 2012 20:15:25 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5075DD48.4030705@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<2a56378e-86fa-43ac-8d87-54fb5203c345@default>
	<5075DD48.4030705@oracle.com>
Message-ID: <507639CC.5060901@oracle.com>

There is no plan yet. The sun.misc.BASE64En/Decoder should already 
trigger a compiler
warning for it's a sun private API. @Deprecated annotation might be a 
good fit.

-Sherman

On 10/10/12 1:40 PM, Joe Darcy wrote:
> Hello,
>
> On 10/10/2012 1:03 PM, Iris Clark wrote:
>> Hi, Sherman.
>>
>> I'm glad to see this coming in.  As you said, long overdue.
>>
>> I'm curious.  What are the plans are to encourage migration from the 
>> JDK private and unsupported sun.misc.BASE64{En,DE}coder classes?  
>> Compile-time warning?  Documentation?  Something else?
>
> On that point, sun.misc.BASE64{En,DE}coder may present a fine 
> opportunity to use the @Deprecated annotation...
>
> -Joe
>
>>
>> Thanks,
>> iris
>>
>> -----Original Message-----
>> From: Xueming Shen
>> Sent: Wednesday, October 10, 2012 10:55 AM
>> To: core-libs-dev
>> Subject: Review/comment needed for the new public java.util.Base64 class
>>
>>
>> A standard/public API for Base64 encoding and decoding has been long 
>> overdue. JDK8  has a JEP [1] for this particular request.
>>
>> Here is the draft proposal to add a public Base64 utility class for 
>> JDK8.
>>
>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>
>> This class basically provides 4 variants of Base64 encoding scheme,
>>
>> (1) the default RFC 4648, which uses standard mapping, no line breaks,
>> (2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace 
>> "+" and
>>       "/" for the mapping
>> (3) the default MIME style, as in RFC 2045 (and its earlier 
>> versions), which uses
>>       "standard" base64 mapping, a 76 characters per line limit and 
>> uses crlf pair
>>        \r\n for line break.
>> (4) an extend-able MIME base64, with the char-per-line and the line
>> separator(s)
>>        specified by developer.
>>
>> The encoder/decoder now provides encoding and decoding for byte[], 
>> String, ByteBuffer and a pair of "EncoderInputStream" and 
>> "DecoderOutputStrream", which we believe/hope should satisfy most of 
>> the common use cases.
>> Additional
>> method(s) can be added if strongly desired.
>>
>> We tried couple slightly different styles of design for such this 
>> "simple" utility class [2].  We kinda concluded that the version 
>> proposed probably provides the best balance among readability, 
>> usability and extensibility.
>>
>> Please help review and comment on the API and implementation.
>>
>> Thanks!
>> -Sherman
>>
>> [1] http://openjdk.java.net/jeps/135
>> [2] http://cr.openjdk.java.net/~sherman/base64/
>



From weijun.wang at oracle.com  Thu Oct 11 03:16:58 2012
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 11 Oct 2012 11:16:58 +0800
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <50763869.20708@oracle.com>
References: <5075B65D.1020709@oracle.com> <5076261D.9020906@oracle.com>
	<50763869.20708@oracle.com>
Message-ID: <50763A2A.1050901@oracle.com>



On 10/11/2012 11:09 AM, Xueming Shen wrote:
> On 10/10/12 6:51 PM, Weijun Wang wrote:
>> Several questions:
>>
>> 1. In encode0(byte[] src, byte[] dst)
>>
>>  281                 if (linepos == linemax && (atom != 0 || sp < sl)) {
>>
>> Maybe atom != 0 is not necessary?
>
> The logic here is that if we reached the last atom (atom == 0), but if
> there
> is still byte(s) in src (sp < sl), we will need to output the last
> special unit,
> which has one or two padding charactere '=', in this case, we still need to
> output the line separator(s).

But when atom != 0, it seems sp < sl should always be true.

-Max

>
>>
>> 2. Is it necessary to explicitly mention in the spec that there is no
>> CrLf at the end of a MIME encoded string?
>
> I'm struggling with which is the appropriate/desired behavior, output
> the crlf for the last line
> or not. Apache's common coder appears to append the crlf for the last
> line, but our sun.misc
> version does not (but sun.misc.BASE64 actually appends the line
> separator if the last line
> happens to have 76 characters, I would assume this is a bug though). The
> current implement
> tries to match the sun.misc. I'm happy to go either way.
>
> But, as you suggested, it might be worth explicitly describing whatever
> behavior we choose.
>
>>
>> 3. The test confirms decoding can correctly reverse the encoding but
>> it says nothing about the correctness of the encoding. Maybe we can
>> just use "10.  Test Vectors" of RFC 4648?
>>
>
> I do have a version of TestBase64 actually compares encoded results of
> j.u.Base64,
> sun.misc.BASE64Encoder and org.apache.commons.codec.binary.Base64. Maybe
> I should
> at least plug in the code for comparing with sun.misc.Base64Encoder.
>
> Thanks!
> -Sherman
>
>
>>
>>
>> On 10/11/2012 01:54 AM, Xueming Shen wrote:
>>>
>>> A standard/public API for Base64 encoding and decoding has been long
>>> overdue. JDK8  has a JEP [1] for this particular request.
>>>
>>> Here is the draft proposal to add a public Base64 utility class for
>>> JDK8.
>>>
>>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>>
>>> This class basically provides 4 variants of Base64 encoding scheme,
>>>
>>> (1) the default RFC 4648, which uses standard mapping, no line breaks,
>>> (2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace
>>> "+" and
>>>      "/" for the mapping
>>> (3) the default MIME style, as in RFC 2045 (and its earlier versions),
>>> which uses
>>>      "standard" base64 mapping, a 76 characters per line limit and uses
>>> crlf pair
>>>       \r\n for line break.
>>> (4) an extend-able MIME base64, with the char-per-line and the line
>>> separator(s)
>>>       specified by developer.
>>>
>>> The encoder/decoder now provides encoding and decoding for byte[],
>>> String,
>>> ByteBuffer and a pair of "EncoderInputStream" and
>>> "DecoderOutputStrream",
>>> which we believe/hope should satisfy most of the common use cases.
>>> Additional
>>> method(s) can be added if strongly desired.
>>>
>>> We tried couple slightly different styles of design for such this
>>> "simple" utility
>>> class [2].  We kinda concluded that the version proposed probably
>>> provides
>>> the best balance among readability, usability and extensibility.
>>>
>>> Please help review and comment on the API and implementation.
>>>
>>> Thanks!
>>> -Sherman
>>>
>>> [1] http://openjdk.java.net/jeps/135
>>> [2] http://cr.openjdk.java.net/~sherman/base64/
>


From xueming.shen at oracle.com  Thu Oct 11 03:32:41 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 10 Oct 2012 20:32:41 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <50763A2A.1050901@oracle.com>
References: <5075B65D.1020709@oracle.com> <5076261D.9020906@oracle.com>
	<50763869.20708@oracle.com> <50763A2A.1050901@oracle.com>
Message-ID: <50763DD9.5050306@oracle.com>

On 10/10/12 8:16 PM, Weijun Wang wrote:
>
>
> On 10/11/2012 11:09 AM, Xueming Shen wrote:
>> On 10/10/12 6:51 PM, Weijun Wang wrote:
>>> Several questions:
>>>
>>> 1. In encode0(byte[] src, byte[] dst)
>>>
>>>  281                 if (linepos == linemax && (atom != 0 || sp < 
>>> sl)) {
>>>
>>> Maybe atom != 0 is not necessary?
>>
>> The logic here is that if we reached the last atom (atom == 0), but if
>> there
>> is still byte(s) in src (sp < sl), we will need to output the last
>> special unit,
>> which has one or two padding charactere '=', in this case, we still 
>> need to
>> output the line separator(s).
>
> But when atom != 0, it seems sp < sl should always be true.

Yes, the sp < sl part only counts if atom == 0. Means if it's NOT last atom,
(atom != 0) output the line feeds, if it IS the last atom (atom == 0), only
output the line feeds if there are leftover byte (sp < sl), which means the
last 4-byte unit (with one or two '=') will be after this line feed.

-Sherman

>
> -Max
>
>>
>>>
>>> 2. Is it necessary to explicitly mention in the spec that there is no
>>> CrLf at the end of a MIME encoded string?
>>
>> I'm struggling with which is the appropriate/desired behavior, output
>> the crlf for the last line
>> or not. Apache's common coder appears to append the crlf for the last
>> line, but our sun.misc
>> version does not (but sun.misc.BASE64 actually appends the line
>> separator if the last line
>> happens to have 76 characters, I would assume this is a bug though). The
>> current implement
>> tries to match the sun.misc. I'm happy to go either way.
>>
>> But, as you suggested, it might be worth explicitly describing whatever
>> behavior we choose.
>>
>>>
>>> 3. The test confirms decoding can correctly reverse the encoding but
>>> it says nothing about the correctness of the encoding. Maybe we can
>>> just use "10.  Test Vectors" of RFC 4648?
>>>
>>
>> I do have a version of TestBase64 actually compares encoded results of
>> j.u.Base64,
>> sun.misc.BASE64Encoder and org.apache.commons.codec.binary.Base64. Maybe
>> I should
>> at least plug in the code for comparing with sun.misc.Base64Encoder.
>>
>> Thanks!
>> -Sherman
>>
>>
>>>
>>>
>>> On 10/11/2012 01:54 AM, Xueming Shen wrote:
>>>>
>>>> A standard/public API for Base64 encoding and decoding has been long
>>>> overdue. JDK8  has a JEP [1] for this particular request.
>>>>
>>>> Here is the draft proposal to add a public Base64 utility class for
>>>> JDK8.
>>>>
>>>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>>>
>>>> This class basically provides 4 variants of Base64 encoding scheme,
>>>>
>>>> (1) the default RFC 4648, which uses standard mapping, no line breaks,
>>>> (2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace
>>>> "+" and
>>>>      "/" for the mapping
>>>> (3) the default MIME style, as in RFC 2045 (and its earlier versions),
>>>> which uses
>>>>      "standard" base64 mapping, a 76 characters per line limit and 
>>>> uses
>>>> crlf pair
>>>>       \r\n for line break.
>>>> (4) an extend-able MIME base64, with the char-per-line and the line
>>>> separator(s)
>>>>       specified by developer.
>>>>
>>>> The encoder/decoder now provides encoding and decoding for byte[],
>>>> String,
>>>> ByteBuffer and a pair of "EncoderInputStream" and
>>>> "DecoderOutputStrream",
>>>> which we believe/hope should satisfy most of the common use cases.
>>>> Additional
>>>> method(s) can be added if strongly desired.
>>>>
>>>> We tried couple slightly different styles of design for such this
>>>> "simple" utility
>>>> class [2].  We kinda concluded that the version proposed probably
>>>> provides
>>>> the best balance among readability, usability and extensibility.
>>>>
>>>> Please help review and comment on the API and implementation.
>>>>
>>>> Thanks!
>>>> -Sherman
>>>>
>>>> [1] http://openjdk.java.net/jeps/135
>>>> [2] http://cr.openjdk.java.net/~sherman/base64/
>>



From weijun.wang at oracle.com  Thu Oct 11 03:39:52 2012
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 11 Oct 2012 11:39:52 +0800
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <50763DD9.5050306@oracle.com>
References: <5075B65D.1020709@oracle.com> <5076261D.9020906@oracle.com>
	<50763869.20708@oracle.com> <50763A2A.1050901@oracle.com>
	<50763DD9.5050306@oracle.com>
Message-ID: <50763F88.8010804@oracle.com>



On 10/11/2012 11:32 AM, Xueming Shen wrote:
> On 10/10/12 8:16 PM, Weijun Wang wrote:
>>
>>
>> On 10/11/2012 11:09 AM, Xueming Shen wrote:
>>> On 10/10/12 6:51 PM, Weijun Wang wrote:
>>>> Several questions:
>>>>
>>>> 1. In encode0(byte[] src, byte[] dst)
>>>>
>>>>  281                 if (linepos == linemax && (atom != 0 || sp <
>>>> sl)) {
>>>>
>>>> Maybe atom != 0 is not necessary?
>>>
>>> The logic here is that if we reached the last atom (atom == 0), but if
>>> there
>>> is still byte(s) in src (sp < sl), we will need to output the last
>>> special unit,
>>> which has one or two padding charactere '=', in this case, we still
>>> need to
>>> output the line separator(s).
>>
>> But when atom != 0, it seems sp < sl should always be true.
>
> Yes, the sp < sl part only counts if atom == 0. Means if it's NOT last
> atom,
> (atom != 0) output the line feeds, if it IS the last atom (atom == 0), only
> output the line feeds if there are leftover byte (sp < sl), which means the
> last 4-byte unit (with one or two '=') will be after this line feed.

So, the value of sp < sl is always the same as (atom != 0 || sp < sl). 
That's why I said atom != 0 is not necessary.

-Max

>
> -Sherman
>
>>
>> -Max
>>
>>>
>>>>
>>>> 2. Is it necessary to explicitly mention in the spec that there is no
>>>> CrLf at the end of a MIME encoded string?
>>>
>>> I'm struggling with which is the appropriate/desired behavior, output
>>> the crlf for the last line
>>> or not. Apache's common coder appears to append the crlf for the last
>>> line, but our sun.misc
>>> version does not (but sun.misc.BASE64 actually appends the line
>>> separator if the last line
>>> happens to have 76 characters, I would assume this is a bug though). The
>>> current implement
>>> tries to match the sun.misc. I'm happy to go either way.
>>>
>>> But, as you suggested, it might be worth explicitly describing whatever
>>> behavior we choose.
>>>
>>>>
>>>> 3. The test confirms decoding can correctly reverse the encoding but
>>>> it says nothing about the correctness of the encoding. Maybe we can
>>>> just use "10.  Test Vectors" of RFC 4648?
>>>>
>>>
>>> I do have a version of TestBase64 actually compares encoded results of
>>> j.u.Base64,
>>> sun.misc.BASE64Encoder and org.apache.commons.codec.binary.Base64. Maybe
>>> I should
>>> at least plug in the code for comparing with sun.misc.Base64Encoder.
>>>
>>> Thanks!
>>> -Sherman
>>>
>>>
>>>>
>>>>
>>>> On 10/11/2012 01:54 AM, Xueming Shen wrote:
>>>>>
>>>>> A standard/public API for Base64 encoding and decoding has been long
>>>>> overdue. JDK8  has a JEP [1] for this particular request.
>>>>>
>>>>> Here is the draft proposal to add a public Base64 utility class for
>>>>> JDK8.
>>>>>
>>>>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>>>>
>>>>> This class basically provides 4 variants of Base64 encoding scheme,
>>>>>
>>>>> (1) the default RFC 4648, which uses standard mapping, no line breaks,
>>>>> (2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace
>>>>> "+" and
>>>>>      "/" for the mapping
>>>>> (3) the default MIME style, as in RFC 2045 (and its earlier versions),
>>>>> which uses
>>>>>      "standard" base64 mapping, a 76 characters per line limit and
>>>>> uses
>>>>> crlf pair
>>>>>       \r\n for line break.
>>>>> (4) an extend-able MIME base64, with the char-per-line and the line
>>>>> separator(s)
>>>>>       specified by developer.
>>>>>
>>>>> The encoder/decoder now provides encoding and decoding for byte[],
>>>>> String,
>>>>> ByteBuffer and a pair of "EncoderInputStream" and
>>>>> "DecoderOutputStrream",
>>>>> which we believe/hope should satisfy most of the common use cases.
>>>>> Additional
>>>>> method(s) can be added if strongly desired.
>>>>>
>>>>> We tried couple slightly different styles of design for such this
>>>>> "simple" utility
>>>>> class [2].  We kinda concluded that the version proposed probably
>>>>> provides
>>>>> the best balance among readability, usability and extensibility.
>>>>>
>>>>> Please help review and comment on the API and implementation.
>>>>>
>>>>> Thanks!
>>>>> -Sherman
>>>>>
>>>>> [1] http://openjdk.java.net/jeps/135
>>>>> [2] http://cr.openjdk.java.net/~sherman/base64/
>>>
>


From xueming.shen at oracle.com  Thu Oct 11 03:48:30 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 10 Oct 2012 20:48:30 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <50763F88.8010804@oracle.com>
References: <5075B65D.1020709@oracle.com> <5076261D.9020906@oracle.com>
	<50763869.20708@oracle.com> <50763A2A.1050901@oracle.com>
	<50763DD9.5050306@oracle.com> <50763F88.8010804@oracle.com>
Message-ID: <5076418E.1060809@oracle.com>

On 10/10/12 8:39 PM, Weijun Wang wrote:
>
>
> On 10/11/2012 11:32 AM, Xueming Shen wrote:
>> On 10/10/12 8:16 PM, Weijun Wang wrote:
>>>
>>>
>>> On 10/11/2012 11:09 AM, Xueming Shen wrote:
>>>> On 10/10/12 6:51 PM, Weijun Wang wrote:
>>>>> Several questions:
>>>>>
>>>>> 1. In encode0(byte[] src, byte[] dst)
>>>>>
>>>>>  281                 if (linepos == linemax && (atom != 0 || sp <
>>>>> sl)) {
>>>>>
>>>>> Maybe atom != 0 is not necessary?
>>>>
>>>> The logic here is that if we reached the last atom (atom == 0), but if
>>>> there
>>>> is still byte(s) in src (sp < sl), we will need to output the last
>>>> special unit,
>>>> which has one or two padding charactere '=', in this case, we still
>>>> need to
>>>> output the line separator(s).
>>>
>>> But when atom != 0, it seems sp < sl should always be true.
>>
>> Yes, the sp < sl part only counts if atom == 0. Means if it's NOT last
>> atom,
>> (atom != 0) output the line feeds, if it IS the last atom (atom == 
>> 0), only
>> output the line feeds if there are leftover byte (sp < sl), which 
>> means the
>> last 4-byte unit (with one or two '=') will be after this line feed.
>
> So, the value of sp < sl is always the same as (atom != 0 || sp < sl). 
> That's why I said atom != 0 is not necessary.
>
You're absolutely correct! Somehow I kept thinking you were saying sp < 
sl is not necessary:-)
not the other way around.

webrev will be updated shortly.

Thanks!
-Sherman



> -Max
>
>>
>> -Sherman
>>
>>>
>>> -Max
>>>
>>>>
>>>>>
>>>>> 2. Is it necessary to explicitly mention in the spec that there is no
>>>>> CrLf at the end of a MIME encoded string?
>>>>
>>>> I'm struggling with which is the appropriate/desired behavior, output
>>>> the crlf for the last line
>>>> or not. Apache's common coder appears to append the crlf for the last
>>>> line, but our sun.misc
>>>> version does not (but sun.misc.BASE64 actually appends the line
>>>> separator if the last line
>>>> happens to have 76 characters, I would assume this is a bug 
>>>> though). The
>>>> current implement
>>>> tries to match the sun.misc. I'm happy to go either way.
>>>>
>>>> But, as you suggested, it might be worth explicitly describing 
>>>> whatever
>>>> behavior we choose.
>>>>
>>>>>
>>>>> 3. The test confirms decoding can correctly reverse the encoding but
>>>>> it says nothing about the correctness of the encoding. Maybe we can
>>>>> just use "10.  Test Vectors" of RFC 4648?
>>>>>
>>>>
>>>> I do have a version of TestBase64 actually compares encoded results of
>>>> j.u.Base64,
>>>> sun.misc.BASE64Encoder and org.apache.commons.codec.binary.Base64. 
>>>> Maybe
>>>> I should
>>>> at least plug in the code for comparing with sun.misc.Base64Encoder.
>>>>
>>>> Thanks!
>>>> -Sherman
>>>>
>>>>
>>>>>
>>>>>
>>>>> On 10/11/2012 01:54 AM, Xueming Shen wrote:
>>>>>>
>>>>>> A standard/public API for Base64 encoding and decoding has been long
>>>>>> overdue. JDK8  has a JEP [1] for this particular request.
>>>>>>
>>>>>> Here is the draft proposal to add a public Base64 utility class for
>>>>>> JDK8.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>>>>>
>>>>>> This class basically provides 4 variants of Base64 encoding scheme,
>>>>>>
>>>>>> (1) the default RFC 4648, which uses standard mapping, no line 
>>>>>> breaks,
>>>>>> (2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to 
>>>>>> replace
>>>>>> "+" and
>>>>>>      "/" for the mapping
>>>>>> (3) the default MIME style, as in RFC 2045 (and its earlier 
>>>>>> versions),
>>>>>> which uses
>>>>>>      "standard" base64 mapping, a 76 characters per line limit and
>>>>>> uses
>>>>>> crlf pair
>>>>>>       \r\n for line break.
>>>>>> (4) an extend-able MIME base64, with the char-per-line and the line
>>>>>> separator(s)
>>>>>>       specified by developer.
>>>>>>
>>>>>> The encoder/decoder now provides encoding and decoding for byte[],
>>>>>> String,
>>>>>> ByteBuffer and a pair of "EncoderInputStream" and
>>>>>> "DecoderOutputStrream",
>>>>>> which we believe/hope should satisfy most of the common use cases.
>>>>>> Additional
>>>>>> method(s) can be added if strongly desired.
>>>>>>
>>>>>> We tried couple slightly different styles of design for such this
>>>>>> "simple" utility
>>>>>> class [2].  We kinda concluded that the version proposed probably
>>>>>> provides
>>>>>> the best balance among readability, usability and extensibility.
>>>>>>
>>>>>> Please help review and comment on the API and implementation.
>>>>>>
>>>>>> Thanks!
>>>>>> -Sherman
>>>>>>
>>>>>> [1] http://openjdk.java.net/jeps/135
>>>>>> [2] http://cr.openjdk.java.net/~sherman/base64/
>>>>
>>



From Alan.Bateman at oracle.com  Thu Oct 11 08:05:04 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Oct 2012 09:05:04 +0100
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <507639CC.5060901@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<2a56378e-86fa-43ac-8d87-54fb5203c345@default>
	<5075DD48.4030705@oracle.com> <507639CC.5060901@oracle.com>
Message-ID: <50767DB0.7020801@oracle.com>

On 11/10/2012 04:15, Xueming Shen wrote:
> There is no plan yet. The sun.misc.BASE64En/Decoder should already 
> trigger a compiler
> warning for it's a sun private API. @Deprecated annotation might be a 
> good fit.
>
> -Sherman
Yes, I think we should deprecate them. The other thing suggested in the 
JEP is that we would also look usages in the JDK, also other 
implementations (as there are many) to see if they can be retired. This 
can of course be done later. It also an opportunity for contributions, 
say for example someone might like to look at java.util.prefs to retire 
the implementation there. Another one that might be able to retire is 
the implementation in the com.sun.net.httpserver.BasicAuthenticator 
class and there are others.

-Alan


From scolebourne at joda.org  Thu Oct 11 09:43:20 2012
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 11 Oct 2012 10:43:20 +0100
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5075B65D.1020709@oracle.com>
References: <5075B65D.1020709@oracle.com>
Message-ID: <CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>

The class level javadoc is quite short. It also has hyperlinks in the
first sentence, which means that they are visible in package level
javadoc. Consider having no hyperlinks in the first sentence, and
expanding a little on what base 64 is.

There are lots of other public base 64 implementations to test/check against.
http://commons.apache.org/net/api-3.1/org/apache/commons/net/util/Base64.html
http://www.cs.berkeley.edu/~jonah/bc/org/bouncycastle/util/encoders/Base64.html
http://migbase64.sourceforge.net/  (claims to be fast)

The arrays are defined inconsistently within the code (3 styles).
  private Encoder(byte[] base64, byte[] newline, int linemax)
  byte [] getBytes(ByteBuffer bb)
  private static final byte toBase64[] =
I'd strongly encourage one style be used, and that it is the first of
the three above.

Stephen


On 10 October 2012 18:54, Xueming Shen <xueming.shen at oracle.com> wrote:
>
> A standard/public API for Base64 encoding and decoding has been long
> overdue. JDK8  has a JEP [1] for this particular request.
>
> Here is the draft proposal to add a public Base64 utility class for JDK8.
>
> http://cr.openjdk.java.net/~sherman/4235519/webrev
>
> This class basically provides 4 variants of Base64 encoding scheme,
>
> (1) the default RFC 4648, which uses standard mapping, no line breaks,
> (2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace "+"
> and
>     "/" for the mapping
> (3) the default MIME style, as in RFC 2045 (and its earlier versions), which
> uses
>     "standard" base64 mapping, a 76 characters per line limit and uses crlf
> pair
>      \r\n for line break.
> (4) an extend-able MIME base64, with the char-per-line and the line
> separator(s)
>      specified by developer.
>
> The encoder/decoder now provides encoding and decoding for byte[], String,
> ByteBuffer and a pair of "EncoderInputStream" and "DecoderOutputStrream",
> which we believe/hope should satisfy most of the common use cases.
> Additional
> method(s) can be added if strongly desired.
>
> We tried couple slightly different styles of design for such this "simple"
> utility
> class [2].  We kinda concluded that the version proposed probably provides
> the best balance among readability, usability and extensibility.
>
> Please help review and comment on the API and implementation.
>
> Thanks!
> -Sherman
>
> [1] http://openjdk.java.net/jeps/135
> [2] http://cr.openjdk.java.net/~sherman/base64/


From Alan.Bateman at oracle.com  Thu Oct 11 10:42:36 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Oct 2012 11:42:36 +0100
Subject: Review Request: 7186817 - Remove Windows 95/98/ME Support
In-Reply-To: <5075D826.2050509@oracle.com>
References: <507462F3.7040205@oracle.com> <50747B65.20303@oracle.com>
	<507482E4.7060607@oracle.com> <507554D2.5000203@oracle.com>
	<5075D826.2050509@oracle.com>
Message-ID: <5076A29C.90406@oracle.com>

On 10/10/2012 21:18, Dan Xu wrote:
> Thanks for your good comments.
>
> I have changed access modifiers for methods in WinNTFileSystem.java. 
> And the new webrev can be viewed at 
> http://cr.openjdk.java.net/~dxu/7186817/webrev.01/
>
> I did not change the hashCode implementation in this version. It will 
> need further complete tests and another round of code review. But it 
> is a good point to improve our code performance. Please log another 
> bug to address this issue. Thanks!
>
> -Dan
>
Thanks Dan, it looks good to me. I'll push this shortly for you.

-Alan.


From alan.bateman at oracle.com  Thu Oct 11 10:48:55 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Thu, 11 Oct 2012 10:48:55 +0000
Subject: hg: jdk8/tl/jdk: 7186817: Remove Windows 95/98/ME Support
Message-ID: <20121011104917.8EB17472B5@hg.openjdk.java.net>

Changeset: c2be39b27e1c
Author:    dxu
Date:      2012-10-11 11:47 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2be39b27e1c

7186817: Remove Windows 95/98/ME Support
Reviewed-by: alanb

! make/java/java/Makefile
! makefiles/CompileNativeLibraries.gmk
- src/windows/classes/java/io/Win32FileSystem.java
! src/windows/classes/java/io/WinNTFileSystem.java
! src/windows/native/java/io/FileSystem_md.c
- src/windows/native/java/io/Win32FileSystem_md.c
! src/windows/native/java/io/WinNTFileSystem_md.c
! src/windows/native/java/io/io_util_md.c
! src/windows/native/java/lang/ProcessImpl_md.c
! src/windows/native/java/util/TimeZone_md.c
! test/java/io/pathNames/win32/bug6344646.java



From Alan.Bateman at oracle.com  Thu Oct 11 10:55:34 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Oct 2012 11:55:34 +0100
Subject: Review Request: 7186817 - Remove Windows 95/98/ME Support
In-Reply-To: <5076A29C.90406@oracle.com>
References: <507462F3.7040205@oracle.com> <50747B65.20303@oracle.com>
	<507482E4.7060607@oracle.com> <507554D2.5000203@oracle.com>
	<5075D826.2050509@oracle.com> <5076A29C.90406@oracle.com>
Message-ID: <5076A5A6.3020704@oracle.com>

On 11/10/2012 11:42, Alan Bateman wrote:
> On 10/10/2012 21:18, Dan Xu wrote:
>> Thanks for your good comments.
>>
>> I have changed access modifiers for methods in WinNTFileSystem.java. 
>> And the new webrev can be viewed at 
>> http://cr.openjdk.java.net/~dxu/7186817/webrev.01/
>>
>> I did not change the hashCode implementation in this version. It will 
>> need further complete tests and another round of code review. But it 
>> is a good point to improve our code performance. Please log another 
>> bug to address this issue. Thanks!
>>
>> -Dan
>>
> Thanks Dan, it looks good to me. I'll push this shortly for you.
Dan - I've pushed this for you but without the change to the following file:

make/tools/sharing/classlist.windows

The reason is that file is auto-generated and has a hash at the end so 
it's not meant to be manually edited. The class list is used by 
-Xshare:dump to generate the shared archive for class data sharing and 
is tolerant of missing classes. I think the class lists are a bit of 
date anyway and are overdue a refresh.

-Alan


From Alan.Bateman at oracle.com  Thu Oct 11 13:40:10 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Oct 2012 14:40:10 +0100
Subject: 8000362: (pack200) Deprecate Packer/Unpacker addPropertyChangeLister
	and removePropertyChangeListener methods
Message-ID: <5076CC3A.1050906@oracle.com>


This is a follow-on from yesterday's mail on deprecating the 
LogManager's add/removePropertyChangeListener methods. The other 4 
problematic methods identified in JEP 162 [1] are the same name methods 
on Pack200.Packer and Pack200.Unpacker. The webrev to deprecate these 
methods is here:

http://cr.openjdk.java.net/~alanb/8000362/webrev/

As with the LogManager methods, Mandy Chung searched >20000 projects. In 
this case we didn't find any usages of these methods and this gives us 
confidence that these methods are rarely used. We don't propose to 
provide a replacement for these methods but instead just include wording 
to suggest that applications poll the value of the progress property if 
they really need to provide some progress indication.

Kumar is the pack200 guru here and I know he's busy/away at the moment 
so I plan to hold onto this patch until I at least hear from him.

-Alan.

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


From Roger.Riggs at oracle.com  Thu Oct 11 14:10:52 2012
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 11 Oct 2012 10:10:52 -0400
Subject: Reviewer needed: 6282196 There should be Math.mod(number, modulo)
	methods
In-Reply-To: <CACzrW9DLhOb_aJ0t5z9k7ouGtZOveJ1XARczD4rhpOpff8OciQ@mail.gmail.com>
References: <50758497.104@oracle.com>
	<CACzrW9DLhOb_aJ0t5z9k7ouGtZOveJ1XARczD4rhpOpff8OciQ@mail.gmail.com>
Message-ID: <5076D36C.9010807@oracle.com>

The floorDiv/floorMod functions do not throw exceptions for out of range 
values
to be consistent with the builtin language math operations.
The |toIntExact |method is used by developers because it does the
range check and throws an exception.
It is cleaner not to mix the semantics of the two operations.

Roger



On 10/10/2012 10:30 AM, Stephen Colebourne wrote:
> On 10 October 2012 15:22, Roger Riggs<Roger.Riggs at oracle.com>  wrote:
>> A reviewer is needed for:
>>
>> 6282196 There should be Math.mod(number, modulo) methods
>>
>> The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/
> Just to note that floorMod(long, int) is not present. This is often
> useful as the mod side generally fits in 32 bits, which means the
> result can fit in 32 bits. This often saves the need to call
> toIntExact() on the result.
>
> Stephen

-- 
Thanks, Roger

Oracle Java Platform Group

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



From chris.hegarty at oracle.com  Thu Oct 11 14:11:54 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 11 Oct 2012 15:11:54 +0100
Subject: 8000362: (pack200) Deprecate Packer/Unpacker
	addPropertyChangeLister and removePropertyChangeListener methods
In-Reply-To: <5076CC3A.1050906@oracle.com>
References: <5076CC3A.1050906@oracle.com>
Message-ID: <5076D3AA.3090507@oracle.com>

The changes look ok to me.

-Chris.

On 11/10/12 14:40, Alan Bateman wrote:
>
> This is a follow-on from yesterday's mail on deprecating the
> LogManager's add/removePropertyChangeListener methods. The other 4
> problematic methods identified in JEP 162 [1] are the same name methods
> on Pack200.Packer and Pack200.Unpacker. The webrev to deprecate these
> methods is here:
>
> http://cr.openjdk.java.net/~alanb/8000362/webrev/
>
> As with the LogManager methods, Mandy Chung searched >20000 projects. In
> this case we didn't find any usages of these methods and this gives us
> confidence that these methods are rarely used. We don't propose to
> provide a replacement for these methods but instead just include wording
> to suggest that applications poll the value of the progress property if
> they really need to provide some progress indication.
>
> Kumar is the pack200 guru here and I know he's busy/away at the moment
> so I plan to hold onto this patch until I at least hear from him.
>
> -Alan.
>
> [1] http://openjdk.java.net/jeps/162


From Lance.Andersen at oracle.com  Thu Oct 11 15:24:08 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 11 Oct 2012 11:24:08 -0400
Subject: 8000362: (pack200) Deprecate Packer/Unpacker
	addPropertyChangeLister and removePropertyChangeListener methods
In-Reply-To: <5076CC3A.1050906@oracle.com>
References: <5076CC3A.1050906@oracle.com>
Message-ID: <9A8EA397-BBC3-46FA-A49A-E17A39E786CD@oracle.com>

looks fine alan
On Oct 11, 2012, at 9:40 AM, Alan Bateman wrote:

> 
> This is a follow-on from yesterday's mail on deprecating the LogManager's add/removePropertyChangeListener methods. The other 4 problematic methods identified in JEP 162 [1] are the same name methods on Pack200.Packer and Pack200.Unpacker. The webrev to deprecate these methods is here:
> 
> http://cr.openjdk.java.net/~alanb/8000362/webrev/
> 
> As with the LogManager methods, Mandy Chung searched >20000 projects. In this case we didn't find any usages of these methods and this gives us confidence that these methods are rarely used. We don't propose to provide a replacement for these methods but instead just include wording to suggest that applications poll the value of the progress property if they really need to provide some progress indication.
> 
> Kumar is the pack200 guru here and I know he's busy/away at the moment so I plan to hold onto this patch until I at least hear from him.
> 
> -Alan.
> 
> [1] http://openjdk.java.net/jeps/162


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 xueming.shen at oracle.com  Thu Oct 11 16:40:42 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 11 Oct 2012 09:40:42 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
Message-ID: <5076F68A.3020501@oracle.com>

On 10/11/2012 02:43 AM, Stephen Colebourne wrote:
> The class level javadoc is quite short. It also has hyperlinks in the
> first sentence, which means that they are visible in package level
> javadoc. Consider having no hyperlinks in the first sentence, and
> expanding a little on what base 64 is.
>

Sure, will come up something longer.
> There are lots of other public base 64 implementations to test/check against.
> http://commons.apache.org/net/api-3.1/org/apache/commons/net/util/Base64.html
> http://www.cs.berkeley.edu/~jonah/bc/org/bouncycastle/util/encoders/Base64.html
> http://migbase64.sourceforge.net/  (claims to be fast)

I did compare the result against the apache version, the difference 
appears to
be the apache (1)append line feeds at the end of the encoded bytes 
(2)skip the
padding '=' characters for URL-safe style.  Will try other implementations.

> The arrays are defined inconsistently within the code (3 styles).
>    private Encoder(byte[] base64, byte[] newline, int linemax)
>    byte [] getBytes(ByteBuffer bb)
>    private static final byte toBase64[] =
> I'd strongly encourage one style be used, and that it is the first of
> the three above.

Good catch, the later two are not intentional, the leftover of old code. 
webrev has
been updated according.

Thanks!
-Sherman


> Stephen
>
>
> On 10 October 2012 18:54, Xueming Shen<xueming.shen at oracle.com>  wrote:
>> A standard/public API for Base64 encoding and decoding has been long
>> overdue. JDK8  has a JEP [1] for this particular request.
>>
>> Here is the draft proposal to add a public Base64 utility class for JDK8.
>>
>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>
>> This class basically provides 4 variants of Base64 encoding scheme,
>>
>> (1) the default RFC 4648, which uses standard mapping, no line breaks,
>> (2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace "+"
>> and
>>      "/" for the mapping
>> (3) the default MIME style, as in RFC 2045 (and its earlier versions), which
>> uses
>>      "standard" base64 mapping, a 76 characters per line limit and uses crlf
>> pair
>>       \r\n for line break.
>> (4) an extend-able MIME base64, with the char-per-line and the line
>> separator(s)
>>       specified by developer.
>>
>> The encoder/decoder now provides encoding and decoding for byte[], String,
>> ByteBuffer and a pair of "EncoderInputStream" and "DecoderOutputStrream",
>> which we believe/hope should satisfy most of the common use cases.
>> Additional
>> method(s) can be added if strongly desired.
>>
>> We tried couple slightly different styles of design for such this "simple"
>> utility
>> class [2].  We kinda concluded that the version proposed probably provides
>> the best balance among readability, usability and extensibility.
>>
>> Please help review and comment on the API and implementation.
>>
>> Thanks!
>> -Sherman
>>
>> [1] http://openjdk.java.net/jeps/135
>> [2] http://cr.openjdk.java.net/~sherman/base64/



From Lance.Andersen at oracle.com  Thu Oct 11 16:45:10 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 11 Oct 2012 12:45:10 -0400
Subject: Reviewer needed for 8000763: use XXX.valueOf methods instead of
	constructors
Message-ID: <BCC48A6C-6B40-4515-BE80-272A1E72E805@oracle.com>

Hi,

Need a review for changing to use the XXX.valueOf methods from constructors.

Thank you

Best
Lance



new-host-2:rowset lanceandersen$ hg status -m
M src/share/classes/com/sun/rowset/CachedRowSetImpl.java
M src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
M src/share/classes/javax/sql/rowset/BaseRowSet.java
M src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java

new-host-2:rowset lanceandersen$ hg diff
diff -r c2be39b27e1c src/share/classes/com/sun/rowset/CachedRowSetImpl.java
--- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java	Thu Oct 11 11:47:05 2012 +0100
+++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java	Thu Oct 11 12:43:57 2012 -0400
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2011, 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
@@ -1747,7 +1747,7 @@
         // convert to a Double and compare to zero
         try {
             Double d = new Double(value.toString());
-            if (d.compareTo(new Double((double)0)) == 0) {
+            if (d.compareTo(Double.valueOf(0)) == 0) {
                 return false;
             } else {
                 return true;
@@ -4432,7 +4432,7 @@
         // make sure the cursor is on a valid row
         checkCursor();
 
-        Object obj = convertNumeric(new Float(x),
+        Object obj = convertNumeric(Float.valueOf(x),
         java.sql.Types.REAL,
         RowSetMD.getColumnType(columnIndex));
 
@@ -4467,7 +4467,7 @@
         checkIndex(columnIndex);
         // make sure the cursor is on a valid row
         checkCursor();
-        Object obj = convertNumeric(new Double(x),
+        Object obj = convertNumeric(Double.valueOf(x),
         java.sql.Types.DOUBLE,
         RowSetMD.getColumnType(columnIndex));
 
diff -r c2be39b27e1c src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
--- a/src/share/classes/com/sun/rowset/FilteredRowSetImpl.java	Thu Oct 11 11:47:05 2012 +0100
+++ b/src/share/classes/com/sun/rowset/FilteredRowSetImpl.java	Thu Oct 11 12:43:57 2012 -0400
@@ -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
@@ -839,7 +839,7 @@
 
       if(onInsertRow) {
          if(p != null) {
-            bool = p.evaluate(new Float(x) , columnIndex);
+            bool = p.evaluate(Float.valueOf(x) , columnIndex);
 
             if(!bool) {
                throw new SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
@@ -906,7 +906,7 @@
 
       if(onInsertRow) {
          if(p != null) {
-            bool = p.evaluate(new Double(x) , columnIndex);
+            bool = p.evaluate(Double.valueOf(x) , columnIndex);
 
             if(!bool) {
                throw new SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
diff -r c2be39b27e1c src/share/classes/javax/sql/rowset/BaseRowSet.java
--- a/src/share/classes/javax/sql/rowset/BaseRowSet.java	Thu Oct 11 11:47:05 2012 +0100
+++ b/src/share/classes/javax/sql/rowset/BaseRowSet.java	Thu Oct 11 12:43:57 2012 -0400
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2011, 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
@@ -1850,7 +1850,7 @@
         if(params == null){
              throw new SQLException("Set initParams() before setFloat");
         }
-        params.put(Integer.valueOf(parameterIndex - 1), new Float(x));
+        params.put(Integer.valueOf(parameterIndex - 1), Float.valueOf(x));
     }
 
     /**
@@ -1882,7 +1882,7 @@
         if(params == null){
              throw new SQLException("Set initParams() before setDouble");
         }
-        params.put(Integer.valueOf(parameterIndex - 1), new Double(x));
+        params.put(Integer.valueOf(parameterIndex - 1), Double.valueOf(x));
     }
 
     /**
diff -r c2be39b27e1c src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java
--- a/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java	Thu Oct 11 11:47:05 2012 +0100
+++ b/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java	Thu Oct 11 12:43:57 2012 -0400
@@ -215,7 +215,7 @@
      */
     @SuppressWarnings("unchecked")
     public void writeFloat(float x) throws SQLException {
-        attribs.add(new Float(x));
+        attribs.add(Float.valueOf(x));
     }
 
     /**
@@ -230,7 +230,7 @@
      */
     @SuppressWarnings("unchecked")
     public void writeDouble(double x) throws SQLException{
-        attribs.add(new Double(x));
+        attribs.add(Double.valueOf(x));
     }
 
     /**
new-host-2:rowset lanceandersen$

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From forax at univ-mlv.fr  Thu Oct 11 16:59:30 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 11 Oct 2012 18:59:30 +0200
Subject: Reviewer needed for 8000763: use XXX.valueOf methods instead
	of constructors
In-Reply-To: <BCC48A6C-6B40-4515-BE80-272A1E72E805@oracle.com>
References: <BCC48A6C-6B40-4515-BE80-272A1E72E805@oracle.com>
Message-ID: <5076FAF2.4080600@univ-mlv.fr>

On 10/11/2012 06:45 PM, Lance Andersen - Oracle wrote:
> Hi,
>
> Need a review for changing to use the XXX.valueOf methods from constructors.
>
> Thank you
>
> Best
> Lance

Hi Lance,
in CachedRowSetImpl, the code is equivalent to
   return Double.compare(Double.parseDouble(value.toString()), 0) != 0;
which avoid to create the Double objects.

the rest looks good.

cheers,
R?mi

>
>
>
> new-host-2:rowset lanceandersen$ hg status -m
> M src/share/classes/com/sun/rowset/CachedRowSetImpl.java
> M src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
> M src/share/classes/javax/sql/rowset/BaseRowSet.java
> M src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java
>
> new-host-2:rowset lanceandersen$ hg diff
> diff -r c2be39b27e1c src/share/classes/com/sun/rowset/CachedRowSetImpl.java
> --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java	Thu Oct 11 11:47:05 2012 +0100
> +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java	Thu Oct 11 12:43:57 2012 -0400
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2003, 2011, 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
> @@ -1747,7 +1747,7 @@
>           // convert to a Double and compare to zero
>           try {
>               Double d = new Double(value.toString());
> -            if (d.compareTo(new Double((double)0)) == 0) {
> +            if (d.compareTo(Double.valueOf(0)) == 0) {
>                   return false;
>               } else {
>                   return true;
> @@ -4432,7 +4432,7 @@
>           // make sure the cursor is on a valid row
>           checkCursor();
>   
> -        Object obj = convertNumeric(new Float(x),
> +        Object obj = convertNumeric(Float.valueOf(x),
>           java.sql.Types.REAL,
>           RowSetMD.getColumnType(columnIndex));
>   
> @@ -4467,7 +4467,7 @@
>           checkIndex(columnIndex);
>           // make sure the cursor is on a valid row
>           checkCursor();
> -        Object obj = convertNumeric(new Double(x),
> +        Object obj = convertNumeric(Double.valueOf(x),
>           java.sql.Types.DOUBLE,
>           RowSetMD.getColumnType(columnIndex));
>   
> diff -r c2be39b27e1c src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
> --- a/src/share/classes/com/sun/rowset/FilteredRowSetImpl.java	Thu Oct 11 11:47:05 2012 +0100
> +++ b/src/share/classes/com/sun/rowset/FilteredRowSetImpl.java	Thu Oct 11 12:43:57 2012 -0400
> @@ -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
> @@ -839,7 +839,7 @@
>   
>         if(onInsertRow) {
>            if(p != null) {
> -            bool = p.evaluate(new Float(x) , columnIndex);
> +            bool = p.evaluate(Float.valueOf(x) , columnIndex);
>   
>               if(!bool) {
>                  throw new SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
> @@ -906,7 +906,7 @@
>   
>         if(onInsertRow) {
>            if(p != null) {
> -            bool = p.evaluate(new Double(x) , columnIndex);
> +            bool = p.evaluate(Double.valueOf(x) , columnIndex);
>   
>               if(!bool) {
>                  throw new SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
> diff -r c2be39b27e1c src/share/classes/javax/sql/rowset/BaseRowSet.java
> --- a/src/share/classes/javax/sql/rowset/BaseRowSet.java	Thu Oct 11 11:47:05 2012 +0100
> +++ b/src/share/classes/javax/sql/rowset/BaseRowSet.java	Thu Oct 11 12:43:57 2012 -0400
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2003, 2011, 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
> @@ -1850,7 +1850,7 @@
>           if(params == null){
>                throw new SQLException("Set initParams() before setFloat");
>           }
> -        params.put(Integer.valueOf(parameterIndex - 1), new Float(x));
> +        params.put(Integer.valueOf(parameterIndex - 1), Float.valueOf(x));
>       }
>   
>       /**
> @@ -1882,7 +1882,7 @@
>           if(params == null){
>                throw new SQLException("Set initParams() before setDouble");
>           }
> -        params.put(Integer.valueOf(parameterIndex - 1), new Double(x));
> +        params.put(Integer.valueOf(parameterIndex - 1), Double.valueOf(x));
>       }
>   
>       /**
> diff -r c2be39b27e1c src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java
> --- a/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java	Thu Oct 11 11:47:05 2012 +0100
> +++ b/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java	Thu Oct 11 12:43:57 2012 -0400
> @@ -215,7 +215,7 @@
>        */
>       @SuppressWarnings("unchecked")
>       public void writeFloat(float x) throws SQLException {
> -        attribs.add(new Float(x));
> +        attribs.add(Float.valueOf(x));
>       }
>   
>       /**
> @@ -230,7 +230,7 @@
>        */
>       @SuppressWarnings("unchecked")
>       public void writeDouble(double x) throws SQLException{
> -        attribs.add(new Double(x));
> +        attribs.add(Double.valueOf(x));
>       }
>   
>       /**
> new-host-2:rowset lanceandersen$
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>



From lance.andersen at oracle.com  Thu Oct 11 17:19:48 2012
From: lance.andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 11 Oct 2012 13:19:48 -0400
Subject: Resend: Reviewer needed for 8000763: use XXX.valueOf methods instead
	of constructors
Message-ID: <FD40B559-D1BC-4407-92E5-F4F420F333AA@oracle.com>

Hi,

Revised CachedRowSetImpl  as I noticed Findbugs missed a scenario where  you should use the XXX.valueOf methods from constructors.

Thank you

Best
Lance



new-host-2:rowset lanceandersen$ hg status -m
M src/share/classes/com/sun/rowset/CachedRowSetImpl.java
M src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
M src/share/classes/javax/sql/rowset/BaseRowSet.java
M src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java

new-host-2:rowset lanceandersen$ hg diff
diff -r c2be39b27e1c src/share/classes/com/sun/rowset/CachedRowSetImpl.java
--- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java	Thu Oct 11 11:47:05 2012 +0100
+++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java	Thu Oct 11 13:17:26 2012 -0400
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2011, 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
@@ -1746,8 +1746,8 @@
 
         // convert to a Double and compare to zero
         try {
-            Double d = new Double(value.toString());
-            if (d.compareTo(new Double((double)0)) == 0) {
+            Double d = Double.valueOf(value.toString());
+            if (d.compareTo(Double.valueOf(0)) == 0) {
                 return false;
             } else {
                 return true;
@@ -4432,7 +4432,7 @@
         // make sure the cursor is on a valid row
         checkCursor();
 
-        Object obj = convertNumeric(new Float(x),
+        Object obj = convertNumeric(Float.valueOf(x),
         java.sql.Types.REAL,
         RowSetMD.getColumnType(columnIndex));
 
@@ -4467,7 +4467,7 @@
         checkIndex(columnIndex);
         // make sure the cursor is on a valid row
         checkCursor();
-        Object obj = convertNumeric(new Double(x),
+        Object obj = convertNumeric(Double.valueOf(x),
         java.sql.Types.DOUBLE,
         RowSetMD.getColumnType(columnIndex));
 
diff -r c2be39b27e1c src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
--- a/src/share/classes/com/sun/rowset/FilteredRowSetImpl.java	Thu Oct 11 11:47:05 2012 +0100
+++ b/src/share/classes/com/sun/rowset/FilteredRowSetImpl.java	Thu Oct 11 13:17:26 2012 -0400
@@ -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
@@ -839,7 +839,7 @@
 
       if(onInsertRow) {
          if(p != null) {
-            bool = p.evaluate(new Float(x) , columnIndex);
+            bool = p.evaluate(Float.valueOf(x) , columnIndex);
 
             if(!bool) {
                throw new SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
@@ -906,7 +906,7 @@
 
       if(onInsertRow) {
          if(p != null) {
-            bool = p.evaluate(new Double(x) , columnIndex);
+            bool = p.evaluate(Double.valueOf(x) , columnIndex);
 
             if(!bool) {
                throw new SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
diff -r c2be39b27e1c src/share/classes/javax/sql/rowset/BaseRowSet.java
--- a/src/share/classes/javax/sql/rowset/BaseRowSet.java	Thu Oct 11 11:47:05 2012 +0100
+++ b/src/share/classes/javax/sql/rowset/BaseRowSet.java	Thu Oct 11 13:17:26 2012 -0400
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2011, 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
@@ -1850,7 +1850,7 @@
         if(params == null){
              throw new SQLException("Set initParams() before setFloat");
         }
-        params.put(Integer.valueOf(parameterIndex - 1), new Float(x));
+        params.put(Integer.valueOf(parameterIndex - 1), Float.valueOf(x));
     }
 
     /**
@@ -1882,7 +1882,7 @@
         if(params == null){
              throw new SQLException("Set initParams() before setDouble");
         }
-        params.put(Integer.valueOf(parameterIndex - 1), new Double(x));
+        params.put(Integer.valueOf(parameterIndex - 1), Double.valueOf(x));
     }
 
     /**
diff -r c2be39b27e1c src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java
--- a/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java	Thu Oct 11 11:47:05 2012 +0100
+++ b/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java	Thu Oct 11 13:17:26 2012 -0400
@@ -215,7 +215,7 @@
      */
     @SuppressWarnings("unchecked")
     public void writeFloat(float x) throws SQLException {
-        attribs.add(new Float(x));
+        attribs.add(Float.valueOf(x));
     }
 
     /**
@@ -230,7 +230,7 @@
      */
     @SuppressWarnings("unchecked")
     public void writeDouble(double x) throws SQLException{
-        attribs.add(new Double(x));
+        attribs.add(Double.valueOf(x));
     }
 
     /**
new-host-2:rowset lanceandersen$ 
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com



From rob.mckenna at oracle.com  Thu Oct 11 17:22:05 2012
From: rob.mckenna at oracle.com (rob.mckenna at oracle.com)
Date: Thu, 11 Oct 2012 17:22:05 +0000
Subject: hg: jdk8/tl/jdk: 7152183: TEST_BUG:
	java/lang/ProcessBuilder/Basic.java failing intermittently [sol]
Message-ID: <20121011172249.A4DF2472C4@hg.openjdk.java.net>

Changeset: 7c2f5e52863c
Author:    robm
Date:      2012-10-11 18:24 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c2f5e52863c

7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol]
Reviewed-by: alanb, martin, dholmes

! test/java/lang/ProcessBuilder/Basic.java



From Lance.Andersen at oracle.com  Thu Oct 11 17:34:15 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 11 Oct 2012 13:34:15 -0400
Subject: Reviewer needed for 8000763: use XXX.valueOf methods instead of
	constructors
In-Reply-To: <5076FAF2.4080600@univ-mlv.fr>
References: <BCC48A6C-6B40-4515-BE80-272A1E72E805@oracle.com>
	<5076FAF2.4080600@univ-mlv.fr>
Message-ID: <18396697-B615-49EB-B549-CDF6F0E44077@oracle.com>

Hi Remi,

Thank you for the suggestion, I had forgotten about parseDouble.  I made your suggested change below.

Best
Lance


new-host-2:rowset lanceandersen$ hg diff
diff -r c2be39b27e1c src/share/classes/com/sun/rowset/CachedRowSetImpl.java
--- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java	Thu Oct 11 11:47:05 2012 +0100
+++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java	Thu Oct 11 13:32:41 2012 -0400
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2011, 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
@@ -1746,12 +1746,7 @@
 
         // convert to a Double and compare to zero
         try {
-            Double d = new Double(value.toString());
-            if (d.compareTo(new Double((double)0)) == 0) {
-                return false;
-            } else {
-                return true;
-            }
+            return Double.compare(Double.parseDouble(value.toString()), 0) != 0;
         } catch (NumberFormatException ex) {
             throw new SQLException(MessageFormat.format(resBundle.handleGetObject("cachedrowsetimpl.boolfail").toString(),
                   new Object[] {value.toString().trim(), columnIndex}));
@@ -4432,7 +4427,7 @@
         // make sure the cursor is on a valid row
         checkCursor();
 
-        Object obj = convertNumeric(new Float(x),
+        Object obj = convertNumeric(Float.valueOf(x),
         java.sql.Types.REAL,
         RowSetMD.getColumnType(columnIndex));
 
@@ -4467,7 +4462,7 @@
         checkIndex(columnIndex);
         // make sure the cursor is on a valid row
         checkCursor();
-        Object obj = convertNumeric(new Double(x),
+        Object obj = convertNumeric(Double.valueOf(x),
         java.sql.Types.DOUBLE,
         RowSetMD.getColumnType(columnIndex));
 
diff -r c2be39b27e1c src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
--- a/src/share/classes/com/sun/rowset/FilteredRowSetImpl.java	Thu Oct 11 11:47:05 2012 +0100
+++ b/src/share/classes/com/sun/rowset/FilteredRowSetImpl.java	Thu Oct 11 13:32:41 2012 -0400
@@ -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
@@ -839,7 +839,7 @@
 
       if(onInsertRow) {
          if(p != null) {
-            bool = p.evaluate(new Float(x) , columnIndex);
+            bool = p.evaluate(Float.valueOf(x) , columnIndex);
 
             if(!bool) {
                throw new SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
@@ -906,7 +906,7 @@
 
       if(onInsertRow) {
          if(p != null) {
-            bool = p.evaluate(new Double(x) , columnIndex);
+            bool = p.evaluate(Double.valueOf(x) , columnIndex);
 
             if(!bool) {
                throw new SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
diff -r c2be39b27e1c src/share/classes/javax/sql/rowset/BaseRowSet.java
--- a/src/share/classes/javax/sql/rowset/BaseRowSet.java	Thu Oct 11 11:47:05 2012 +0100
+++ b/src/share/classes/javax/sql/rowset/BaseRowSet.java	Thu Oct 11 13:32:41 2012 -0400
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2011, 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
@@ -1850,7 +1850,7 @@
         if(params == null){
              throw new SQLException("Set initParams() before setFloat");
         }
-        params.put(Integer.valueOf(parameterIndex - 1), new Float(x));
+        params.put(Integer.valueOf(parameterIndex - 1), Float.valueOf(x));
     }
 
     /**
@@ -1882,7 +1882,7 @@
         if(params == null){
              throw new SQLException("Set initParams() before setDouble");
         }
-        params.put(Integer.valueOf(parameterIndex - 1), new Double(x));
+        params.put(Integer.valueOf(parameterIndex - 1), Double.valueOf(x));
     }
 
     /**
diff -r c2be39b27e1c src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java
--- a/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java	Thu Oct 11 11:47:05 2012 +0100
+++ b/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java	Thu Oct 11 13:32:41 2012 -0400
@@ -215,7 +215,7 @@
      */
     @SuppressWarnings("unchecked")
     public void writeFloat(float x) throws SQLException {
-        attribs.add(new Float(x));
+        attribs.add(Float.valueOf(x));
     }
 
     /**
@@ -230,7 +230,7 @@
      */
     @SuppressWarnings("unchecked")
     public void writeDouble(double x) throws SQLException{
-        attribs.add(new Double(x));
+        attribs.add(Double.valueOf(x));
     }
 
     /**
new-host-2:rowset lanceandersen$
On Oct 11, 2012, at 12:59 PM, Remi Forax wrote:

> return Double.compare(Double.parseDouble(value.toString()), 0) != 0;


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 ariel at weisberg.ws  Thu Oct 11 18:30:56 2012
From: ariel at weisberg.ws (Ariel Weisberg)
Date: Thu, 11 Oct 2012 14:30:56 -0400
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5076F68A.3020501@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
Message-ID: <1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>

Hi,

It looks like it tackles the issue of encoding binary data as text in an
isolated fashion and doesn't seem open to adding other ways of encoding
binary data as text such as hex or yEnc. Having a common interface in
java.util for different encodings would be great. I am not asking for
more implementation, just a more abstract interface for Decoder and
Encoder.

I know that ByteBuffers are pain, but I did notice that you can't
specify a source/dest pair when using ByteBuffers and that ByteBuffers
without arrays have to be copied. I don't see a simple safe way to
normalize access to them the way you can if everything is a byte array.

Thanks,
Ariel

On Thu, Oct 11, 2012, at 12:40 PM, Xueming Shen wrote:
> On 10/11/2012 02:43 AM, Stephen Colebourne wrote:
> > The class level javadoc is quite short. It also has hyperlinks in the
> > first sentence, which means that they are visible in package level
> > javadoc. Consider having no hyperlinks in the first sentence, and
> > expanding a little on what base 64 is.
> >
> 
> Sure, will come up something longer.
> > There are lots of other public base 64 implementations to test/check against.
> > http://commons.apache.org/net/api-3.1/org/apache/commons/net/util/Base64.html
> > http://www.cs.berkeley.edu/~jonah/bc/org/bouncycastle/util/encoders/Base64.html
> > http://migbase64.sourceforge.net/  (claims to be fast)
> 
> I did compare the result against the apache version, the difference 
> appears to
> be the apache (1)append line feeds at the end of the encoded bytes 
> (2)skip the
> padding '=' characters for URL-safe style.  Will try other
> implementations.
> 
> > The arrays are defined inconsistently within the code (3 styles).
> >    private Encoder(byte[] base64, byte[] newline, int linemax)
> >    byte [] getBytes(ByteBuffer bb)
> >    private static final byte toBase64[] =
> > I'd strongly encourage one style be used, and that it is the first of
> > the three above.
> 
> Good catch, the later two are not intentional, the leftover of old code. 
> webrev has
> been updated according.
> 
> Thanks!
> -Sherman
> 
> 
> > Stephen
> >
> >
> > On 10 October 2012 18:54, Xueming Shen<xueming.shen at oracle.com>  wrote:
> >> A standard/public API for Base64 encoding and decoding has been long
> >> overdue. JDK8  has a JEP [1] for this particular request.
> >>
> >> Here is the draft proposal to add a public Base64 utility class for JDK8.
> >>
> >> http://cr.openjdk.java.net/~sherman/4235519/webrev
> >>
> >> This class basically provides 4 variants of Base64 encoding scheme,
> >>
> >> (1) the default RFC 4648, which uses standard mapping, no line breaks,
> >> (2) the URL-safe RFE 4648, no line breaks, use "-" and "_" to replace "+"
> >> and
> >>      "/" for the mapping
> >> (3) the default MIME style, as in RFC 2045 (and its earlier versions), which
> >> uses
> >>      "standard" base64 mapping, a 76 characters per line limit and uses crlf
> >> pair
> >>       \r\n for line break.
> >> (4) an extend-able MIME base64, with the char-per-line and the line
> >> separator(s)
> >>       specified by developer.
> >>
> >> The encoder/decoder now provides encoding and decoding for byte[], String,
> >> ByteBuffer and a pair of "EncoderInputStream" and "DecoderOutputStrream",
> >> which we believe/hope should satisfy most of the common use cases.
> >> Additional
> >> method(s) can be added if strongly desired.
> >>
> >> We tried couple slightly different styles of design for such this "simple"
> >> utility
> >> class [2].  We kinda concluded that the version proposed probably provides
> >> the best balance among readability, usability and extensibility.
> >>
> >> Please help review and comment on the API and implementation.
> >>
> >> Thanks!
> >> -Sherman
> >>
> >> [1] http://openjdk.java.net/jeps/135
> >> [2] http://cr.openjdk.java.net/~sherman/base64/
> 


From mandy.chung at oracle.com  Thu Oct 11 19:31:20 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 11 Oct 2012 12:31:20 -0700
Subject: 8000362: (pack200) Deprecate Packer/Unpacker
	addPropertyChangeLister and removePropertyChangeListener methods
In-Reply-To: <5076CC3A.1050906@oracle.com>
References: <5076CC3A.1050906@oracle.com>
Message-ID: <50771E88.7020301@oracle.com>

Looks fine with me.
Mandy

On 10/11/2012 6:40 AM, Alan Bateman wrote:
>
> This is a follow-on from yesterday's mail on deprecating the 
> LogManager's add/removePropertyChangeListener methods. The other 4 
> problematic methods identified in JEP 162 [1] are the same name 
> methods on Pack200.Packer and Pack200.Unpacker. The webrev to 
> deprecate these methods is here:
>
> http://cr.openjdk.java.net/~alanb/8000362/webrev/
>
> As with the LogManager methods, Mandy Chung searched >20000 projects. 
> In this case we didn't find any usages of these methods and this gives 
> us confidence that these methods are rarely used. We don't propose to 
> provide a replacement for these methods but instead just include 
> wording to suggest that applications poll the value of the progress 
> property if they really need to provide some progress indication.
>
> Kumar is the pack200 guru here and I know he's busy/away at the moment 
> so I plan to hold onto this patch until I at least hear from him.
>
> -Alan.
>
> [1] http://openjdk.java.net/jeps/162


From rob.mckenna at oracle.com  Thu Oct 11 20:22:48 2012
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 11 Oct 2012 21:22:48 +0100
Subject: Request for review: 8000487: Java JNDI connection library on ldap
	conn is not honoring configured timeout
Message-ID: <50772A98.5020105@oracle.com>

Hi folks,

Seemingly when using ldap's simple authentication we perform a 
readReply. (an operation which is subject to
com.sun.jndi.ldap.read.timeout as opposed to 
com.sun.jndi.ldap.connect.timeout) This makes an apparent connection to 
a faulty host appear to take much longer than the specified connect 
timeout. The proposed solution is to set the read timeout value to the 
same value as the connect for the duration of the authentication call.

In addition to this I've merged the testcase for this issue with the 
testcases for other ldap timeout issues.

http://cr.openjdk.java.net/~robm/8000487/webrev.01/ 
<http://cr.openjdk.java.net/%7Erobm/8000487/webrev.01/>

Thanks,

     -Rob



From dan.xu at oracle.com  Thu Oct 11 21:25:10 2012
From: dan.xu at oracle.com (Dan Xu)
Date: Thu, 11 Oct 2012 14:25:10 -0700
Subject: Review Request: 7186817 - Remove Windows 95/98/ME Support
In-Reply-To: <5076A5A6.3020704@oracle.com>
References: <507462F3.7040205@oracle.com> <50747B65.20303@oracle.com>
	<507482E4.7060607@oracle.com> <507554D2.5000203@oracle.com>
	<5075D826.2050509@oracle.com> <5076A29C.90406@oracle.com>
	<5076A5A6.3020704@oracle.com>
Message-ID: <50773936.9050901@oracle.com>

I see. I was not aware of -Xshare:dump. Thanks, Alan.

-Dan

On Thu 11 Oct 2012 03:55:34 AM PDT, Alan Bateman wrote:
> On 11/10/2012 11:42, Alan Bateman wrote:
>> On 10/10/2012 21:18, Dan Xu wrote:
>>> Thanks for your good comments.
>>>
>>> I have changed access modifiers for methods in WinNTFileSystem.java.
>>> And the new webrev can be viewed at
>>> http://cr.openjdk.java.net/~dxu/7186817/webrev.01/
>>>
>>> I did not change the hashCode implementation in this version. It
>>> will need further complete tests and another round of code review.
>>> But it is a good point to improve our code performance. Please log
>>> another bug to address this issue. Thanks!
>>>
>>> -Dan
>>>
>> Thanks Dan, it looks good to me. I'll push this shortly for you.
> Dan - I've pushed this for you but without the change to the following
> file:
>
> make/tools/sharing/classlist.windows
>
> The reason is that file is auto-generated and has a hash at the end so
> it's not meant to be manually edited. The class list is used by
> -Xshare:dump to generate the shared archive for class data sharing and
> is tolerant of missing classes. I think the class lists are a bit of
> date anyway and are overdue a refresh.
>
> -Alan


From jim.gish at oracle.com  Thu Oct 11 21:37:43 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Thu, 11 Oct 2012 17:37:43 -0400
Subject: RFR: 7159567 - inconsistent configuration of MemoryHandler
In-Reply-To: <5066176D.6040005@oracle.com>
References: <50637167.4060006@oracle.com> <5063BD8C.2010607@oracle.com>
	<50645D19.4050505@oracle.com> <5065F6DD.7010801@oracle.com>
	<5066176D.6040005@oracle.com>
Message-ID: <50773C27.3050407@oracle.com>

Please review the updated changes at 
http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/

I've changed as you've requested, added some additional tests, did some 
better error handling in the case of a MemoryHandler not specifying a 
target (now throws RuntimeException with an appropriate message instead 
of attempting to load a null class and throwing NPE).  I also corrected 
the copyrights, tested with JCK, all jdk_lang tests and have submitted a 
JPRT job with core tests.

I've forwarded a CCC request (separately) and will await its approval 
and further review of this change.

Thanks,
     Jim

On 09/28/2012 05:32 PM, Mandy Chung wrote:
> On 9/28/2012 12:13 PM, Jim Gish wrote:
>> I've re-spun the change with additional usage notes in the spec to 
>> reflect the long-standing actual behavior.  Note that it doesn't 
>> change the spec per se, as it was already stated in LogManager. This 
>> change simply replicates that language with an example in each 
>> *Handler class to make it easier to find.
>>
>
> Thanks for looking into it.  This statement in LogManager does
> specify the properties for handlers:
>
>   The properties for loggers and Handlers will have names starting
>   with the dot-separated name for the handler or logger.
>
> Replicating that statement with an example is one way to do it.
> Would it be clearer if the prefix of the properties referenced
> in the bullet list is replaced from "java.util.logging" to
> some kind of prefix - something like this:
>
>  *<b>Configuration:</b>
>  * By default each<tt>ConsoleHandler</tt>  is initialized using the 
> following
>  *<tt>LogManager</tt>  configuration properties.  If properties are 
> not defined
>  * (or have invalid values) then the specified default values are used.
>  *<ul>
>  *<li>    <handler's classname>.level
>  *        specifies the default level for the<tt>Handler</tt>
>  *        (defaults to<tt>Level.INFO</tt>).
>  ...<snip>
>  *</ul>
>  *
>  * For example, the properties for {@code ConsoleHandler} would be:
>  *     java.util.logging.ConsoleHandler.level=INFO
>  * 
> java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
>  *
>  * For a custom handler, e.g. com.foo.MyHandler, the properties would be:
>  *     com.foo.MyHandler.level=INFO
>  * com.foo.MyHandler.formatter=java.util.logging.SimpleFormatter
>
> This might add some clarity to the spec.
>
> This is a spec bug fix that I would suggest to file a CCC to
> track for compatibility.  I would also suggest running the JCK
> tests to find out if there is any regression due to this fix.
>
>
>> The webrev, as posted at 
>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/
>
> See my comment above w.r.t. the spec change.
>
> test/java/util/logging/MemoryHandler.java
>   L27: "via via" typo
>   L28: @run tag specifies the test name
>        So it should be @run main/othervm MemoryHandler
>
>   L43: jtreg runs the test in a different working directory
>   other than the test source.  So the test has to read
>   the system property ("test.src") to determine the location
>   of the properties file.  Typically, we will do this:
>     String src = System.getProperty("test.src", ".);
>     File   fname  = new File(src, LM_PROP_FNAME);
>
>   You don't need L44. You can reference LoggingDeadlock3.java test.
>
>   L51: this catch block to throw a RuntimeException doesn't seem
>   necessary.  If NPE is thrown, the test will fail anyway.
>
>   One suggestion to the test is to test both cases (one with
>   the specified target handler and one without).  You can
>   define a custom target handler so that the test can verify
>   if the expected one is used.  A simple handler to count
>   the number of log messages will do the work.
>
> test/java/util/logging/MemoryHandlerTest.props
>   I suggest to take out the comments and just keep the
>   properties the test needs to make it easier to tell
>   what's configured.
>   Perhaps you should also specify
>   java.util.logging.MemoryHandler.target to make sure
>   that the custom handler with no target handler specified
>   will not use j.u.l.MemoryHandler.target as the default.
>
> Mandy
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From forax at univ-mlv.fr  Thu Oct 11 21:52:43 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 11 Oct 2012 23:52:43 +0200
Subject: Reviewer needed for 8000763: use XXX.valueOf methods instead
	of constructors
In-Reply-To: <18396697-B615-49EB-B549-CDF6F0E44077@oracle.com>
References: <BCC48A6C-6B40-4515-BE80-272A1E72E805@oracle.com>
	<5076FAF2.4080600@univ-mlv.fr>
	<18396697-B615-49EB-B549-CDF6F0E44077@oracle.com>
Message-ID: <50773FAB.70401@univ-mlv.fr>

On 10/11/2012 07:34 PM, Lance Andersen - Oracle wrote:
> Hi Remi,
>
> Thank you for the suggestion, I had forgotten about parseDouble.  I 
> made your suggested change below.
>
> Best
> Lance

thumb up.

regards,
R?mi

>
>
> new-host-2:rowset lanceandersen$ hg diff
> diff -r c2be39b27e1c 
> src/share/classes/com/sun/rowset/CachedRowSetImpl.java
> --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.javaThu Oct 11 
> 11:47:05 2012 +0100
> +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.javaThu Oct 11 
> 13:32:41 2012 -0400
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2003, 2011, 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
> @@ -1746,12 +1746,7 @@
>          // convert to a Double and compare to zero
>          try {
> -            Double d = new Double(value.toString());
> -            if (d.compareTo(new Double((double)0)) == 0) {
> -                return false;
> -            } else {
> -                return true;
> -            }
> +            return 
> Double.compare(Double.parseDouble(value.toString()), 0) != 0;
>          } catch (NumberFormatException ex) {
>              throw new 
> SQLException(MessageFormat.format(resBundle.handleGetObject("cachedrowsetimpl.boolfail").toString(),
>                    new Object[] {value.toString().trim(), columnIndex}));
> @@ -4432,7 +4427,7 @@
>          // make sure the cursor is on a valid row
>          checkCursor();
> -        Object obj = convertNumeric(new Float(x),
> +        Object obj = convertNumeric(Float.valueOf(x),
>          java.sql.Types.REAL,
>          RowSetMD.getColumnType(columnIndex));
> @@ -4467,7 +4462,7 @@
>          checkIndex(columnIndex);
>          // make sure the cursor is on a valid row
>          checkCursor();
> -        Object obj = convertNumeric(new Double(x),
> +        Object obj = convertNumeric(Double.valueOf(x),
>          java.sql.Types.DOUBLE,
>          RowSetMD.getColumnType(columnIndex));
> diff -r c2be39b27e1c 
> src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
> --- a/src/share/classes/com/sun/rowset/FilteredRowSetImpl.javaThu Oct 
> 11 11:47:05 2012 +0100
> +++ b/src/share/classes/com/sun/rowset/FilteredRowSetImpl.javaThu Oct 
> 11 13:32:41 2012 -0400
> @@ -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
> @@ -839,7 +839,7 @@
>        if(onInsertRow) {
>           if(p != null) {
> -            bool = p.evaluate(new Float(x) , columnIndex);
> +            bool = p.evaluate(Float.valueOf(x) , columnIndex);
>              if(!bool) {
>                 throw new 
> SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
> @@ -906,7 +906,7 @@
>        if(onInsertRow) {
>           if(p != null) {
> -            bool = p.evaluate(new Double(x) , columnIndex);
> +            bool = p.evaluate(Double.valueOf(x) , columnIndex);
>              if(!bool) {
>                 throw new 
> SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
> diff -r c2be39b27e1c src/share/classes/javax/sql/rowset/BaseRowSet.java
> --- a/src/share/classes/javax/sql/rowset/BaseRowSet.javaThu Oct 11 
> 11:47:05 2012 +0100
> +++ b/src/share/classes/javax/sql/rowset/BaseRowSet.javaThu Oct 11 
> 13:32:41 2012 -0400
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2003, 2011, 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
> @@ -1850,7 +1850,7 @@
>          if(params == null){
>               throw new SQLException("Set initParams() before setFloat");
>          }
> -        params.put(Integer.valueOf(parameterIndex - 1), new Float(x));
> +        params.put(Integer.valueOf(parameterIndex - 1), 
> Float.valueOf(x));
>      }
>      /**
> @@ -1882,7 +1882,7 @@
>          if(params == null){
>               throw new SQLException("Set initParams() before setDouble");
>          }
> -        params.put(Integer.valueOf(parameterIndex - 1), new Double(x));
> +        params.put(Integer.valueOf(parameterIndex - 1), 
> Double.valueOf(x));
>      }
>      /**
> diff -r c2be39b27e1c 
> src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java
> --- a/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.javaThu 
> Oct 11 11:47:05 2012 +0100
> +++ b/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.javaThu 
> Oct 11 13:32:41 2012 -0400
> @@ -215,7 +215,7 @@
>       */
>      @SuppressWarnings("unchecked")
>      public void writeFloat(float x) throws SQLException {
> -        attribs.add(new Float(x));
> +        attribs.add(Float.valueOf(x));
>      }
>      /**
> @@ -230,7 +230,7 @@
>       */
>      @SuppressWarnings("unchecked")
>      public void writeDouble(double x) throws SQLException{
> -        attribs.add(new Double(x));
> +        attribs.add(Double.valueOf(x));
>      }
>      /**
> new-host-2:rowset lanceandersen$
> On Oct 11, 2012, at 12:59 PM, Remi Forax wrote:
>
>> return Double.compare(Double.parseDouble(value.toString()), 0) != 0;
>
> <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 mandy.chung at oracle.com  Thu Oct 11 22:38:02 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 11 Oct 2012 15:38:02 -0700
Subject: Reviewer needed for 8000763: use XXX.valueOf methods instead
	of constructors
In-Reply-To: <18396697-B615-49EB-B549-CDF6F0E44077@oracle.com>
References: <BCC48A6C-6B40-4515-BE80-272A1E72E805@oracle.com>
	<5076FAF2.4080600@univ-mlv.fr>
	<18396697-B615-49EB-B549-CDF6F0E44077@oracle.com>
Message-ID: <50774A4A.6070709@oracle.com>

Lance - this looks good to me.

In FilteredRowSetImpl.java -
-            bool = p.evaluate(new Float(x) , columnIndex);
+            bool = p.evaluate(Float.valueOf(x) , columnIndex);

I was tempted to suggest removing the space before ','.  But I
found that the coding convention is kinda inconsistent locally
in the FilteredRowSetImpl.java itself and so you can either leave
it as it is or clean that up incrementally when you modify that
file.  Really minor nit.

Mandy

On 10/11/2012 10:34 AM, Lance Andersen - Oracle wrote:
> Hi Remi,
>
> Thank you for the suggestion, I had forgotten about parseDouble.  I made your suggested change below.
>
> Best
> Lance
>
>
> new-host-2:rowset lanceandersen$ hg diff
> diff -r c2be39b27e1c src/share/classes/com/sun/rowset/CachedRowSetImpl.java
> --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java	Thu Oct 11 11:47:05 2012 +0100
> +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java	Thu Oct 11 13:32:41 2012 -0400
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2003, 2011, 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
> @@ -1746,12 +1746,7 @@
>
>           // convert to a Double and compare to zero
>           try {
> -            Double d = new Double(value.toString());
> -            if (d.compareTo(new Double((double)0)) == 0) {
> -                return false;
> -            } else {
> -                return true;
> -            }
> +            return Double.compare(Double.parseDouble(value.toString()), 0) != 0;
>           } catch (NumberFormatException ex) {
>               throw new SQLException(MessageFormat.format(resBundle.handleGetObject("cachedrowsetimpl.boolfail").toString(),
>                     new Object[] {value.toString().trim(), columnIndex}));
> @@ -4432,7 +4427,7 @@
>           // make sure the cursor is on a valid row
>           checkCursor();
>
> -        Object obj = convertNumeric(new Float(x),
> +        Object obj = convertNumeric(Float.valueOf(x),
>           java.sql.Types.REAL,
>           RowSetMD.getColumnType(columnIndex));
>
> @@ -4467,7 +4462,7 @@
>           checkIndex(columnIndex);
>           // make sure the cursor is on a valid row
>           checkCursor();
> -        Object obj = convertNumeric(new Double(x),
> +        Object obj = convertNumeric(Double.valueOf(x),
>           java.sql.Types.DOUBLE,
>           RowSetMD.getColumnType(columnIndex));
>
> diff -r c2be39b27e1c src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
> --- a/src/share/classes/com/sun/rowset/FilteredRowSetImpl.java	Thu Oct 11 11:47:05 2012 +0100
> +++ b/src/share/classes/com/sun/rowset/FilteredRowSetImpl.java	Thu Oct 11 13:32:41 2012 -0400
> @@ -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
> @@ -839,7 +839,7 @@
>
>         if(onInsertRow) {
>            if(p != null) {
> -            bool = p.evaluate(new Float(x) , columnIndex);
> +            bool = p.evaluate(Float.valueOf(x) , columnIndex);
>
>               if(!bool) {
>                  throw new SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
> @@ -906,7 +906,7 @@
>
>         if(onInsertRow) {
>            if(p != null) {
> -            bool = p.evaluate(new Double(x) , columnIndex);
> +            bool = p.evaluate(Double.valueOf(x) , columnIndex);
>
>               if(!bool) {
>                  throw new SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
> diff -r c2be39b27e1c src/share/classes/javax/sql/rowset/BaseRowSet.java
> --- a/src/share/classes/javax/sql/rowset/BaseRowSet.java	Thu Oct 11 11:47:05 2012 +0100
> +++ b/src/share/classes/javax/sql/rowset/BaseRowSet.java	Thu Oct 11 13:32:41 2012 -0400
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2003, 2011, 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
> @@ -1850,7 +1850,7 @@
>           if(params == null){
>                throw new SQLException("Set initParams() before setFloat");
>           }
> -        params.put(Integer.valueOf(parameterIndex - 1), new Float(x));
> +        params.put(Integer.valueOf(parameterIndex - 1), Float.valueOf(x));
>       }
>
>       /**
> @@ -1882,7 +1882,7 @@
>           if(params == null){
>                throw new SQLException("Set initParams() before setDouble");
>           }
> -        params.put(Integer.valueOf(parameterIndex - 1), new Double(x));
> +        params.put(Integer.valueOf(parameterIndex - 1), Double.valueOf(x));
>       }
>
>       /**
> diff -r c2be39b27e1c src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java
> --- a/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java	Thu Oct 11 11:47:05 2012 +0100
> +++ b/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java	Thu Oct 11 13:32:41 2012 -0400
> @@ -215,7 +215,7 @@
>        */
>       @SuppressWarnings("unchecked")
>       public void writeFloat(float x) throws SQLException {
> -        attribs.add(new Float(x));
> +        attribs.add(Float.valueOf(x));
>       }
>
>       /**
> @@ -230,7 +230,7 @@
>        */
>       @SuppressWarnings("unchecked")
>       public void writeDouble(double x) throws SQLException{
> -        attribs.add(new Double(x));
> +        attribs.add(Double.valueOf(x));
>       }
>
>       /**
> new-host-2:rowset lanceandersen$
> On Oct 11, 2012, at 12:59 PM, Remi Forax wrote:
>
>> return Double.compare(Double.parseDouble(value.toString()), 0) != 0;
>
> 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  Thu Oct 11 22:47:24 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 11 Oct 2012 18:47:24 -0400
Subject: Reviewer needed for 8000763: use XXX.valueOf methods instead of
	constructors
In-Reply-To: <50774A4A.6070709@oracle.com>
References: <BCC48A6C-6B40-4515-BE80-272A1E72E805@oracle.com>
	<5076FAF2.4080600@univ-mlv.fr>
	<18396697-B615-49EB-B549-CDF6F0E44077@oracle.com>
	<50774A4A.6070709@oracle.com>
Message-ID: <6A8F8336-EE77-4D60-B087-BB777AFFB7F5@oracle.com>

Thank you Mandy and Remi.

Mandy, I addressed the nit below before the push

Best
Lance
On Oct 11, 2012, at 6:38 PM, Mandy Chung wrote:

> Lance - this looks good to me.
> 
> In FilteredRowSetImpl.java -
> -            bool = p.evaluate(new Float(x) , columnIndex);
> +            bool = p.evaluate(Float.valueOf(x) , columnIndex);
> 
> I was tempted to suggest removing the space before ','.  But I
> found that the coding convention is kinda inconsistent locally
> in the FilteredRowSetImpl.java itself and so you can either leave
> it as it is or clean that up incrementally when you modify that
> file.  Really minor nit.
> 
> Mandy
> 
> On 10/11/2012 10:34 AM, Lance Andersen - Oracle wrote:
>> Hi Remi,
>> 
>> Thank you for the suggestion, I had forgotten about parseDouble.  I made your suggested change below.
>> 
>> Best
>> Lance
>> 
>> 
>> new-host-2:rowset lanceandersen$ hg diff
>> diff -r c2be39b27e1c src/share/classes/com/sun/rowset/CachedRowSetImpl.java
>> --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java	Thu Oct 11 11:47:05 2012 +0100
>> +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java	Thu Oct 11 13:32:41 2012 -0400
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 2003, 2011, 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
>> @@ -1746,12 +1746,7 @@
>> 
>>          // convert to a Double and compare to zero
>>          try {
>> -            Double d = new Double(value.toString());
>> -            if (d.compareTo(new Double((double)0)) == 0) {
>> -                return false;
>> -            } else {
>> -                return true;
>> -            }
>> +            return Double.compare(Double.parseDouble(value.toString()), 0) != 0;
>>          } catch (NumberFormatException ex) {
>>              throw new SQLException(MessageFormat.format(resBundle.handleGetObject("cachedrowsetimpl.boolfail").toString(),
>>                    new Object[] {value.toString().trim(), columnIndex}));
>> @@ -4432,7 +4427,7 @@
>>          // make sure the cursor is on a valid row
>>          checkCursor();
>> 
>> -        Object obj = convertNumeric(new Float(x),
>> +        Object obj = convertNumeric(Float.valueOf(x),
>>          java.sql.Types.REAL,
>>          RowSetMD.getColumnType(columnIndex));
>> 
>> @@ -4467,7 +4462,7 @@
>>          checkIndex(columnIndex);
>>          // make sure the cursor is on a valid row
>>          checkCursor();
>> -        Object obj = convertNumeric(new Double(x),
>> +        Object obj = convertNumeric(Double.valueOf(x),
>>          java.sql.Types.DOUBLE,
>>          RowSetMD.getColumnType(columnIndex));
>> 
>> diff -r c2be39b27e1c src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
>> --- a/src/share/classes/com/sun/rowset/FilteredRowSetImpl.java	Thu Oct 11 11:47:05 2012 +0100
>> +++ b/src/share/classes/com/sun/rowset/FilteredRowSetImpl.java	Thu Oct 11 13:32:41 2012 -0400
>> @@ -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
>> @@ -839,7 +839,7 @@
>> 
>>        if(onInsertRow) {
>>           if(p != null) {
>> -            bool = p.evaluate(new Float(x) , columnIndex);
>> +            bool = p.evaluate(Float.valueOf(x) , columnIndex);
>> 
>>              if(!bool) {
>>                 throw new SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
>> @@ -906,7 +906,7 @@
>> 
>>        if(onInsertRow) {
>>           if(p != null) {
>> -            bool = p.evaluate(new Double(x) , columnIndex);
>> +            bool = p.evaluate(Double.valueOf(x) , columnIndex);
>> 
>>              if(!bool) {
>>                 throw new SQLException(resBundle.handleGetObject("filteredrowsetimpl.notallowed").toString());
>> diff -r c2be39b27e1c src/share/classes/javax/sql/rowset/BaseRowSet.java
>> --- a/src/share/classes/javax/sql/rowset/BaseRowSet.java	Thu Oct 11 11:47:05 2012 +0100
>> +++ b/src/share/classes/javax/sql/rowset/BaseRowSet.java	Thu Oct 11 13:32:41 2012 -0400
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 2003, 2011, 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
>> @@ -1850,7 +1850,7 @@
>>          if(params == null){
>>               throw new SQLException("Set initParams() before setFloat");
>>          }
>> -        params.put(Integer.valueOf(parameterIndex - 1), new Float(x));
>> +        params.put(Integer.valueOf(parameterIndex - 1), Float.valueOf(x));
>>      }
>> 
>>      /**
>> @@ -1882,7 +1882,7 @@
>>          if(params == null){
>>               throw new SQLException("Set initParams() before setDouble");
>>          }
>> -        params.put(Integer.valueOf(parameterIndex - 1), new Double(x));
>> +        params.put(Integer.valueOf(parameterIndex - 1), Double.valueOf(x));
>>      }
>> 
>>      /**
>> diff -r c2be39b27e1c src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java
>> --- a/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java	Thu Oct 11 11:47:05 2012 +0100
>> +++ b/src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java	Thu Oct 11 13:32:41 2012 -0400
>> @@ -215,7 +215,7 @@
>>       */
>>      @SuppressWarnings("unchecked")
>>      public void writeFloat(float x) throws SQLException {
>> -        attribs.add(new Float(x));
>> +        attribs.add(Float.valueOf(x));
>>      }
>> 
>>      /**
>> @@ -230,7 +230,7 @@
>>       */
>>      @SuppressWarnings("unchecked")
>>      public void writeDouble(double x) throws SQLException{
>> -        attribs.add(new Double(x));
>> +        attribs.add(Double.valueOf(x));
>>      }
>> 
>>      /**
>> new-host-2:rowset lanceandersen$
>> On Oct 11, 2012, at 12:59 PM, Remi Forax wrote:
>> 
>>> return Double.compare(Double.parseDouble(value.toString()), 0) != 0;
>> 
>> 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  Thu Oct 11 22:46:48 2012
From: lance.andersen at oracle.com (lance.andersen at oracle.com)
Date: Thu, 11 Oct 2012 22:46:48 +0000
Subject: hg: jdk8/tl/jdk: 8000763: use XXX.valueOf methods instead of
	constructors
Message-ID: <20121011224713.E2717472FA@hg.openjdk.java.net>

Changeset: daabaafd6798
Author:    lancea
Date:      2012-10-11 18:46 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/daabaafd6798

8000763: use XXX.valueOf methods instead of constructors
Reviewed-by: mchung, forax

! src/share/classes/com/sun/rowset/CachedRowSetImpl.java
! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java
! src/share/classes/javax/sql/rowset/BaseRowSet.java
! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java



From kurchi.subhra.hazra at oracle.com  Fri Oct 12 00:21:11 2012
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Thu, 11 Oct 2012 17:21:11 -0700
Subject: Code Review Request: 7198073: (prefs) user prefs not saved [macosx]
In-Reply-To: <505B8907.2090006@oracle.com>
References: <505B8907.2090006@oracle.com>
Message-ID: <50776277.9080305@oracle.com>

Hi,

    This is a regression introduced by the fix for 7160252[1] that I 
pushed a few weeks ago. We should
really be using the class member field isUser, rather than the argument 
passed in the constructor as a parameter
for cfFileForNode(). Due to this wrong parameter being passed, user 
preferences were never getting stored into
permanent storage.

Webrev: http://cr.openjdk.java.net/~khazra/7198073/webrev.00/
Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198073

Thanks,
Kurchi

[1] http://cr.openjdk.java.net/~khazra/7160252/webrev.02/


From joe.darcy at oracle.com  Fri Oct 12 00:40:22 2012
From: joe.darcy at oracle.com (Joseph Darcy)
Date: Thu, 11 Oct 2012 17:40:22 -0700
Subject: Reviewer needed: 6282196 There should be Math.mod(number, modulo)
	methods
In-Reply-To: <50758497.104@oracle.com>
References: <50758497.104@oracle.com>
Message-ID: <507766F6.7020906@oracle.com>

Hi Roger,

The changes look fine.  However, I suggest adding an explanatory note 
along the lines of "Normal integer division operates under the round to 
zero rounding mode (truncation).  This operation instead acts under the 
round to negative infinity (floor) rounding mode. The floor rounding 
mode gives different results than truncation when the exact result is 
negative."

Thanks,

-Joe

On 10/10/2012 7:22 AM, Roger Riggs wrote:
> A reviewer is needed for:
>
> 6282196 There should be Math.mod(number, modulo) methods
>
> The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/
>
> Thanks, Roger



From xueming.shen at oracle.com  Fri Oct 12 06:38:31 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 11 Oct 2012 23:38:31 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5076F68A.3020501@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
Message-ID: <5077BAE7.7000009@oracle.com>


> On 10/11/2012 02:43 AM, Stephen Colebourne wrote:
>
>> There are lots of other public base 64 implementations to test/check 
>> against.
>> http://commons.apache.org/net/api-3.1/org/apache/commons/net/util/Base64.html 
>>
>> http://www.cs.berkeley.edu/~jonah/bc/org/bouncycastle/util/encoders/Base64.html 
>>
>> http://migbase64.sourceforge.net/  (claims to be fast)
>

I did a quick performance check against migbase64 with the basic base64 
de/encoding
using this non-scientific benchmark.
http://cr.openjdk.java.net/~sherman/4235519/PermBase64.java

Here is the scores
http://cr.openjdk.java.net/~sherman/4235519/scores

It's a tie, j.u.Base64 wins the decoding, but needs some work on 
encoding side.

java -server PermBase64 200000 50
  j.u.Base64.encode() : 1390212
   migBase64.encode() : 720517
  j.u.Base64.decode() : 1200642
   migBase64.decode() : 2070015

java -server PermBase64 200000 100
  j.u.Base64.encode() : 1239407
   migBase64.encode() : 740404
  j.u.Base64.decode() : 1257092
   migBase64.decode() : 2012910

java -server PermBase64 200000 1000
  j.u.Base64.encode() : 1062212
   migBase64.encode() : 657342
  j.u.Base64.decode() : 1133740
   migBase64.decode() : 1930612

java -client PermBase64 200000 50
  j.u.Base64.encode() : 961331
   migBase64.encode() : 875635
  j.u.Base64.decode() : 1528790
   migBase64.decode() : 2188473

java -client PermBase64 200000 100
  j.u.Base64.encode() : 966453
   migBase64.encode() : 858082
  j.u.Base64.decode() : 1459159
   migBase64.decode() : 2115045

java -client PermBase64 200000 1000
  j.u.Base64.encode() : 954401
   migBase64.encode() : 854903
  j.u.Base64.decode() : 1444603
   migBase64.decode() : 2038865




From Alan.Bateman at oracle.com  Fri Oct 12 07:43:59 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Oct 2012 08:43:59 +0100
Subject: Code Review Request: 7198073: (prefs) user prefs not saved
	[macosx]
In-Reply-To: <50776277.9080305@oracle.com>
References: <505B8907.2090006@oracle.com> <50776277.9080305@oracle.com>
Message-ID: <5077CA3F.5010601@oracle.com>

On 12/10/2012 01:21, Kurchi Hazra wrote:
> Hi,
>
>    This is a regression introduced by the fix for 7160252[1] that I 
> pushed a few weeks ago. We should
> really be using the class member field isUser, rather than the 
> argument passed in the constructor as a parameter
> for cfFileForNode(). Due to this wrong parameter being passed, user 
> preferences were never getting stored into
> permanent storage.
>
> Webrev: http://cr.openjdk.java.net/~khazra/7198073/webrev.00/
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198073
>
> Thanks,
> Kurchi
>
> [1] http://cr.openjdk.java.net/~khazra/7160252/webrev.02/
Kurchi - thanks for tracking this one down, looking at it now it is 
obvious how this slipped through. I think the proposed change is okay 
although I think we need to do a bit of clean-up on this code at some 
point (not for this change, I realize this one needs to be fixed in 7u 
and I don't want to muddy the waters).

The other things is tests. The preferences implementation that came via 
the Mac port is turning out to have a bit of a bug tail and one or two 
regressions have sneaked in along the way too. Do you think you could 
add a test for this issue? Also at some point we need to look at the 
test coverage and quality of the tests for this area as most/all of 
these Mac specific issues should have been caught before it ever went in.

-Alan


From brucechapman at paradise.net.nz  Fri Oct 12 07:51:51 2012
From: brucechapman at paradise.net.nz (Bruce Chapman)
Date: Fri, 12 Oct 2012 20:51:51 +1300
Subject: Reviewer needed: 6282196 There should be Math.mod(number,
	modulo) methods
In-Reply-To: <507766F6.7020906@oracle.com>
References: <50758497.104@oracle.com> <507766F6.7020906@oracle.com>
Message-ID: <5077CC17.5030307@paradise.net.nz>

And maybe say "round toward" rather than "round to", the first implies a 
direction, the second implies a destination.

Bruce

On 12/10/2012 1:40 p.m., Joseph Darcy wrote:
> Hi Roger,
>
> The changes look fine.  However, I suggest adding an explanatory note 
> along the lines of "Normal integer division operates under the round 
> to zero rounding mode (truncation).  This operation instead acts under 
> the round to negative infinity (floor) rounding mode. The floor 
> rounding mode gives different results than truncation when the exact 
> result is negative."
>
> Thanks,
>
> -Joe
>
> On 10/10/2012 7:22 AM, Roger Riggs wrote:
>> A reviewer is needed for:
>>
>> 6282196 There should be Math.mod(number, modulo) methods
>>
>> The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/
>>
>> Thanks, Roger
>
>



From Alan.Bateman at oracle.com  Fri Oct 12 10:19:29 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Oct 2012 11:19:29 +0100
Subject: 8000685: (props) Properties.storeToXML/loadFromXML should only require
	UTF-8 and UTF-16 to be supported
Message-ID: <5077EEB1.30404@oracle.com>


A few days ago we added a JDK private provider interface [1] to which 
the Properties loadFromXML and storeToXML methods will delegate. The 
motive as I mentioned is to allow for a smaller environments where JAXP 
might not be present (so motivated by both modules and the compact 
profiles work).

The next step in this effort is dealing with the issue of arbitrary 
encodings. The storeToXML method allows the encoding to be specified, 
the loadFromXML method assumes that the implementation can decode the 
stream and read the encoding declaration. The specification doesn't make 
it clear how either method behaves with unrecognized encodings and this 
is something that we need to fix in order to allow for alternative 
implementations, in particular tiny parsers that might not support more 
than a few.

The webrev the proposed changes is here:

http://cr.openjdk.java.net/~alanb/8000685/webrev/

The proposal is that an implementation minimally supports UTF-8 and 
UTF-16, which I think is consistent with the W3C XML specification [2].

Based on a search of a large number of projects then it appears that 
these methods aren't used very much so I don't think this will have any 
significant impact. In addition the same set of encodings [ which is not 
exactly the same set as Charsets.availableCharsets().keySet() ] that 
works today will continue to work when the service provider that uses 
JAXP is installed.

In addition, to specifying the required encodings, I have also changed 
both methods to specify that UnsupportedEncodingException may be thrown. 
In the case of loadFromXML then this is the long standing behavior 
anyway. In the case of storeToXML then the long standing behavior is 
somewhat bizarre. If the method is invoked with an unsupported encoding 
then the underlying Xalan code prints a warning to System.out and 
changes the encoding under the covers to UTF-8. I've submitted a bug on 
this oddity; in the mean-time I've added a check in the platform 
provider to always fail for charsets that aren't recognized.

-Alan.

[1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f65871e75fde
[2] http://www.w3.org/TR/REC-xml/#charencoding


From Alan.Bateman at oracle.com  Fri Oct 12 10:56:29 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Oct 2012 11:56:29 +0100
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
Message-ID: <5077F75D.2020003@oracle.com>

On 11/10/2012 19:30, Ariel Weisberg wrote:
> :
>
> I know that ByteBuffers are pain, but I did notice that you can't
> specify a source/dest pair when using ByteBuffers and that ByteBuffers
> without arrays have to be copied. I don't see a simple safe way to
> normalize access to them the way you can if everything is a byte array.
>
I agree, encode/decode methods where the destination is a given 
ByteBuffer would be desirable (and probably more useful than returning a 
new ByteBuffer each time). Byte arrays are so commonly used that it 
probably justifying having both variants as proposed.

-Alan


From rob.mckenna at oracle.com  Fri Oct 12 14:32:52 2012
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 12 Oct 2012 15:32:52 +0100
Subject: RFR: 8000817: Reinstate accidentally removed sleep() from
	ProcessBuilder/Basic.java
In-Reply-To: <CA+kOe09RmETEA3xJJ7751hF5nCQ6L3oyONy10+syGYHzzzN0Tw@mail.gmail.com>
References: <506CB1C3.5050009@oracle.com> <506D3D14.4070304@oracle.com>
	<CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
	<5071DC80.3080507@oracle.com>
	<CA+kOe08mRoVVXAR6K7j3PgDuNmiv+V=AkwxUoxAWcyTG+AXGqA@mail.gmail.com>
	<50734498.40100@oracle.com>
	<CA+kOe09RmETEA3xJJ7751hF5nCQ6L3oyONy10+syGYHzzzN0Tw@mail.gmail.com>
Message-ID: <50782A14.1060701@oracle.com>

Hi folks,

Managed to remove the Thread.sleep(10) from the test when fixing 
7152183. Sorry about that.

http://cr.openjdk.java.net/~robm/8000817/webrev.01/ 
<http://cr.openjdk.java.net/%7Erobm/8000817/webrev.01/>

     -Rob



From kurchi.subhra.hazra at oracle.com  Fri Oct 12 14:57:59 2012
From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra)
Date: Fri, 12 Oct 2012 07:57:59 -0700
Subject: Code Review Request: 7198073: (prefs) user prefs not saved
	[macosx]
In-Reply-To: <5077CA3F.5010601@oracle.com>
References: <505B8907.2090006@oracle.com> <50776277.9080305@oracle.com>
	<5077CA3F.5010601@oracle.com>
Message-ID: <50782FF7.60200@oracle.com>

On 10/12/12 12:43 AM, Alan Bateman wrote:
> On 12/10/2012 01:21, Kurchi Hazra wrote:
>> Hi,
>>
>>    This is a regression introduced by the fix for 7160252[1] that I 
>> pushed a few weeks ago. We should
>> really be using the class member field isUser, rather than the 
>> argument passed in the constructor as a parameter
>> for cfFileForNode(). Due to this wrong parameter being passed, user 
>> preferences were never getting stored into
>> permanent storage.
>>
>> Webrev: http://cr.openjdk.java.net/~khazra/7198073/webrev.00/
>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198073
>>
>> Thanks,
>> Kurchi
>>
>> [1] http://cr.openjdk.java.net/~khazra/7160252/webrev.02/
> Kurchi - thanks for tracking this one down, looking at it now it is 
> obvious how this slipped through. I think the proposed change is okay 
> although I think we need to do a bit of clean-up on this code at some 
> point (not for this change, I realize this one needs to be fixed in 7u 
> and I don't want to muddy the waters).
  Right, I will have to spend more time cleaning up this after 
committing this fix.

> The other thin is tests. The preferences implementation that came via 
> the Mac port is turning out to have a bit of a bug tail and one or two 
> regressions have sneaked in along the way too. Do you think you could 
> add a test for this issue? 
  Let me get back to you on this.

> Also at some point we need to look at the test coverage and quality of 
> the tests for this area as most/all of these Mac specific issues 
> should have been caught before it ever went in.
  I agree. Again, this will be a longer time goal for me.

- Kurchi



From martinrb at google.com  Fri Oct 12 16:17:57 2012
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 12 Oct 2012 09:17:57 -0700
Subject: RFR: 8000817: Reinstate accidentally removed sleep() from
	ProcessBuilder/Basic.java
In-Reply-To: <50782A14.1060701@oracle.com>
References: <506CB1C3.5050009@oracle.com> <506D3D14.4070304@oracle.com>
	<CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
	<5071DC80.3080507@oracle.com>
	<CA+kOe08mRoVVXAR6K7j3PgDuNmiv+V=AkwxUoxAWcyTG+AXGqA@mail.gmail.com>
	<50734498.40100@oracle.com>
	<CA+kOe09RmETEA3xJJ7751hF5nCQ6L3oyONy10+syGYHzzzN0Tw@mail.gmail.com>
	<50782A14.1060701@oracle.com>
Message-ID: <CA+kOe09=NiWhN3HFy5wUKBkP-dqvKCCYZHFgJAJYDtnEy1wNcw@mail.gmail.com>

On Fri, Oct 12, 2012 at 7:32 AM, Rob McKenna <rob.mckenna at oracle.com> wrote:

> Hi folks,
>
> Managed to remove the Thread.sleep(10) from the test when fixing 7152183.
> Sorry about that.
>
>
I thought you had done that intentionally, and so "if it passes, then OK".

The way the code's been written, it should now be robustly race-free on
Solaris.  Do you actually see racy failures on other OSes?

Perhaps do the sleep conditionally, only in the non-Solaris case?

In the Linux case, the reading thread will eventually acquire the monitor
lock on the input stream.  It might work to wait for that using the hacky
but non-racy:

if (stream instanceof BufferedInputStream) {
...

while (Unsafe.tryMonitorEnter(stream)) {
  Unsafe.MonitorExit(stream);
  Thread.sleep(1);
}

http://cr.openjdk.java.net/~**robm/8000817/webrev.01/<http://cr.openjdk.java.net/~robm/8000817/webrev.01/><
> http://cr.openjdk.java.net/%**7Erobm/8000817/webrev.01/<http://cr.openjdk.java.net/%7Erobm/8000817/webrev.01/>
> >
>
>     -Rob
>
>


From jim.gish at oracle.com  Fri Oct 12 16:55:45 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Fri, 12 Oct 2012 12:55:45 -0400
Subject: Please review: 7146552 LoggingMXBeanTest intermittent failure
Message-ID: <50784B91.40508@oracle.com>

Please review 
http://cr.openjdk.java.net/~jgish/Bug7146552-LoggingMXBeanTest-failure/ 
<http://cr.openjdk.java.net/%7Ejgish/Bug7146552-LoggingMXBeanTest-failure/>

The LoggingMXBeanTest has been intermittently failing because garbage 
collection can cause the (weak) references to Logger instances to go 
away.  LoggingMXBeanTest2 has the same issue, but no bug has (yet) been 
filed against it.

The fix is to simply make the Logger variables static so they don't get 
gc'd.

Thanks,
    Jim

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From Alan.Bateman at oracle.com  Fri Oct 12 18:06:00 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Oct 2012 19:06:00 +0100
Subject: RFR: 8000817: Reinstate accidentally removed sleep() from
	ProcessBuilder/Basic.java
In-Reply-To: <CA+kOe09=NiWhN3HFy5wUKBkP-dqvKCCYZHFgJAJYDtnEy1wNcw@mail.gmail.com>
References: <506CB1C3.5050009@oracle.com> <506D3D14.4070304@oracle.com>
	<CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
	<5071DC80.3080507@oracle.com>
	<CA+kOe08mRoVVXAR6K7j3PgDuNmiv+V=AkwxUoxAWcyTG+AXGqA@mail.gmail.com>
	<50734498.40100@oracle.com>
	<CA+kOe09RmETEA3xJJ7751hF5nCQ6L3oyONy10+syGYHzzzN0Tw@mail.gmail.com>
	<50782A14.1060701@oracle.com>
	<CA+kOe09=NiWhN3HFy5wUKBkP-dqvKCCYZHFgJAJYDtnEy1wNcw@mail.gmail.com>
Message-ID: <50785C08.7050202@oracle.com>

On 12/10/2012 17:17, Martin Buchholz wrote:
> On Fri, Oct 12, 2012 at 7:32 AM, Rob McKenna<rob.mckenna at oracle.com>  wrote:
>
>> Hi folks,
>>
>> Managed to remove the Thread.sleep(10) from the test when fixing 7152183.
>> Sorry about that.
>>
>>
> I thought you had done that intentionally, and so "if it passes, then OK".
>
> The way the code's been written, it should now be robustly race-free on
> Solaris.  Do you actually see racy failures on other OSes?
>
Yes, here's an example on Linux with a build of jdk8/tl that has Rob's 
last change:

----------messages:(3/117)----------
command: main Basic
reason: User specified action: run main/othervm/timeout=300 Basic
elapsed time (seconds): 8.869
----------System.out:(20/750)*----------
This appears to be a Unix system.
Testing ASCII environment values
Testing Latin1 environment values
Testing Unicode environment values
Testing directory .
Testing directory ..
Testing directory /
Testing directory /bin
cmdp
cmdp 0: /export/home/aurora/sandbox/jdk/jre/bin/java
cmdp 1: -classpath
cmdp 2: /export/home/aurora/sandbox/jtreg/lib/javatest.jar:/export/home/aurora/sandbox/jtreg/lib/jtreg.jar:/export/home/aurora/sandbox/gresults/testoutput/jdk_lang/JTwork/classes/java/lang/ProcessBuilder:/export/home/aurora/sandbox/testbase/test/java/lang/ProcessBuilder:/export/home/aurora/sandbox/jdk/lib/tools.jar
cmdp 3: Basic$JavaChild
cmdp 4: System.getenv()
envp
envp 0: LC_ALL=C\u0000\u0000
envp 1: FO\u0000=B\u0000R

Passed = 9018, failed = 1

----------System.err:(18/967)----------
java.io.IOException: Stream closed
	at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:162)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:206)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
	at Basic$64.run(Basic.java:1954)
java.lang.AssertionError: Some tests failed
	at Basic.main(Basic.java:2418)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:474)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:722)

JavaTest Message: Test threw exception: java.lang.AssertionError: Some tests failed
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.AssertionError: Some tests failed
result: Failed. Execution failed: `main' threw exception: java.lang.AssertionError: Some tests failed


test result: Failed. Execution failed: `main' threw exception: java.lang.AssertionError: Some tests failed




From Alan.Bateman at oracle.com  Fri Oct 12 18:18:35 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Oct 2012 19:18:35 +0100
Subject: Reviewer and committer request for 7198496
In-Reply-To: <0B9A0CA9-2104-4F88-9D31-9C6FB1DF689C@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com>
	<3AC99BDE-5EC9-4F18-B1E6-64FF5C6093FB@oracle.com>
	<506D583F.2010808@oracle.com>
	<6C8D595A-765D-4555-BD63-C244D1B043E8@oracle.com>
	<506D66DF.9050505@oracle.com>
	<A2809AFE-1C5F-4DA3-8A92-C41E89F12720@oracle.com>
	<506D9125.7020103@oracle.com>
	<0B9A0CA9-2104-4F88-9D31-9C6FB1DF689C@oracle.com>
Message-ID: <50785EFB.3000903@oracle.com>

Paul - where did we leave this one? We got side tracked on how the TCCL 
is specified but I think we concluded that the proposed change to 
ServiceLoader was okay, is that right?

-Alan


From Alan.Bateman at oracle.com  Fri Oct 12 18:21:43 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Oct 2012 19:21:43 +0100
Subject: Please review: 7146552 LoggingMXBeanTest intermittent failure
In-Reply-To: <50784B91.40508@oracle.com>
References: <50784B91.40508@oracle.com>
Message-ID: <50785FB7.70809@oracle.com>

On 12/10/2012 17:55, Jim Gish wrote:
> Please review 
> http://cr.openjdk.java.net/~jgish/Bug7146552-LoggingMXBeanTest-failure/ <http://cr.openjdk.java.net/%7Ejgish/Bug7146552-LoggingMXBeanTest-failure/> 
>
>
> The LoggingMXBeanTest has been intermittently failing because garbage 
> collection can cause the (weak) references to Logger instances to go 
> away.  LoggingMXBeanTest2 has the same issue, but no bug has (yet) 
> been filed against it.
>
> The fix is to simply make the Logger variables static so they don't 
> get gc'd.
This looks fine to me and I'd suggesting using the one bug for both.

-Alan


From martinrb at google.com  Fri Oct 12 18:25:53 2012
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 12 Oct 2012 11:25:53 -0700
Subject: RFR: 8000817: Reinstate accidentally removed sleep() from
	ProcessBuilder/Basic.java
In-Reply-To: <50785C08.7050202@oracle.com>
References: <506CB1C3.5050009@oracle.com> <506D3D14.4070304@oracle.com>
	<CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
	<5071DC80.3080507@oracle.com>
	<CA+kOe08mRoVVXAR6K7j3PgDuNmiv+V=AkwxUoxAWcyTG+AXGqA@mail.gmail.com>
	<50734498.40100@oracle.com>
	<CA+kOe09RmETEA3xJJ7751hF5nCQ6L3oyONy10+syGYHzzzN0Tw@mail.gmail.com>
	<50782A14.1060701@oracle.com>
	<CA+kOe09=NiWhN3HFy5wUKBkP-dqvKCCYZHFgJAJYDtnEy1wNcw@mail.gmail.com>
	<50785C08.7050202@oracle.com>
Message-ID: <CA+kOe0_EAyWSJbH50CEu+7Cm-ro3APqac5ZY47WDQE_dDXhKcQ@mail.gmail.com>

On Fri, Oct 12, 2012 at 11:06 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

> The way the code's been written, it should now be robustly race-free on
> Solaris.  Do you actually see racy failures on other OSes?
>
>
>  Yes, here's an example on Linux with a build of jdk8/tl that has Rob's
> last change:
>
>
Yeah, this kind of race is hard to eradicate.  The bug remains on Linux?

Maybe we should throw away what we did and instead loop until we see
something like

java.io.FileInputStream.readBytes(Native Method)

in the read-ing thread's stack trace.


From schierlm at gmx.de  Fri Oct 12 18:39:24 2012
From: schierlm at gmx.de (Michael Schierl)
Date: Fri, 12 Oct 2012 20:39:24 +0200
Subject: Review/comment needed for the new public java.util.Base64 class
Message-ID: <507863DC.706@gmx.de>

Hello,

(sorry if the threading is broken, but I was not subscribed to the list
and only found the discussion on Twitter and read it in the mailing list
archive)

Ariel Weisberg wrote on Thu Oct 11 11:30:56 PDT 2012:
> I know that ByteBuffers are pain, but I did notice that you can't
> specify a source/dest pair when using ByteBuffers and that ByteBuffers
> without arrays have to be copied. I don't see a simple safe way to
> normalize access to them the way you can if everything is a byte array.

Agreed. One of the advantages of using byte buffers is reducing
allocations, resulting in fewer garbage collections.

In addition, in this implementation the ByteBuffers have to contain the
full data.

What I like about most byte buffers APIs is that I can pass in a
ByteBuffer with incomplete data or maybe an output ByteBuffer that is
too small to hold the complete result, and it will just process as much
as it can, and leave the rest for the next round (which should work well
for Base64, too, as it always processes chunks of 3 or 4 bytes).

So, a useful ByteBuffer API in my opinion needs a method like

public boolean encode(ByteBuffer in, ByteBuffer out,
  boolean endOfInput);

public boolean decode(ByteBuffer in, ByteBuffer out,
  boolean endOfInput);

(similar to CharsetEncoder#encode) that can process partial input and
will return true if all processable input has been processed (i. e. in
has to be refilled) or false if some input could not have been processed
(i. e. out has to be flushed).

Users have to call it again and again until they call it with
endOfInput=true and get true back (Using an enum as result similar to
CoderResult#UNDERFLOW and CoderResult#OVERFLOW might be another option
if the boolean results are too cryptic).

Having a ByteBuffer Base64 API might be useful (although I'm not sure
yet if I ever need it), but as it is now, it is mostly useless for
serious ByteBuffer usage, as if I have to split and copy the data
manually anyway, I can as well use the array APIs.


Just my 0.02 EUR,


Michael


From Alan.Bateman at oracle.com  Fri Oct 12 18:47:23 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Oct 2012 19:47:23 +0100
Subject: RFR: 8000817: Reinstate accidentally removed sleep() from
	ProcessBuilder/Basic.java
In-Reply-To: <CA+kOe0_EAyWSJbH50CEu+7Cm-ro3APqac5ZY47WDQE_dDXhKcQ@mail.gmail.com>
References: <506CB1C3.5050009@oracle.com> <506D3D14.4070304@oracle.com>
	<CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
	<5071DC80.3080507@oracle.com>
	<CA+kOe08mRoVVXAR6K7j3PgDuNmiv+V=AkwxUoxAWcyTG+AXGqA@mail.gmail.com>
	<50734498.40100@oracle.com>
	<CA+kOe09RmETEA3xJJ7751hF5nCQ6L3oyONy10+syGYHzzzN0Tw@mail.gmail.com>
	<50782A14.1060701@oracle.com>
	<CA+kOe09=NiWhN3HFy5wUKBkP-dqvKCCYZHFgJAJYDtnEy1wNcw@mail.gmail.com>
	<50785C08.7050202@oracle.com>
	<CA+kOe0_EAyWSJbH50CEu+7Cm-ro3APqac5ZY47WDQE_dDXhKcQ@mail.gmail.com>
Message-ID: <507865BB.5040006@oracle.com>

On 12/10/2012 19:25, Martin Buchholz wrote:
> :
>
>
> Yeah, this kind of race is hard to eradicate.  The bug remains on Linux?
>
> Maybe we should throw away what we did and instead loop until we see 
> something like
>
> java.io.FileInputStream.readBytes(Native Method)
>
> in the read-ing thread's stack trace.
Yes, this one remains on Linux, and the original one that Rob fixed was 
in response to a couple of intermittent failures on Solaris.

Checking for readBytes should be better but it might still be fragile 
because there isn't any guarantee that the thread is in the read syscall 
(although the window should be a lot smaller). Although none of us like 
using sleep, this may be a case where we need a short sleep to improve 
our chances.

-Alan


From xueming.shen at oracle.com  Fri Oct 12 18:56:39 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 12 Oct 2012 11:56:39 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <507863DC.706@gmx.de>
References: <507863DC.706@gmx.de>
Message-ID: <507867E7.9010103@oracle.com>

Hi,

The exactly reason I was trying to skip en/decode(ByteBuffer in, 
ByteByuffer out)
for now. I'm struggling with/can't make up my mind on whether or not the 
en/decoder
should  have internal state, like the charset en/decoder. It appears the 
API is being
pushed going that direction though:-)

-Sherman

On 10/12/2012 11:39 AM, Michael Schierl wrote:
> Hello,
>
> (sorry if the threading is broken, but I was not subscribed to the list
> and only found the discussion on Twitter and read it in the mailing list
> archive)
>
> Ariel Weisberg wrote on Thu Oct 11 11:30:56 PDT 2012:
>> I know that ByteBuffers are pain, but I did notice that you can't
>> specify a source/dest pair when using ByteBuffers and that ByteBuffers
>> without arrays have to be copied. I don't see a simple safe way to
>> normalize access to them the way you can if everything is a byte array.
> Agreed. One of the advantages of using byte buffers is reducing
> allocations, resulting in fewer garbage collections.
>
> In addition, in this implementation the ByteBuffers have to contain the
> full data.
>
> What I like about most byte buffers APIs is that I can pass in a
> ByteBuffer with incomplete data or maybe an output ByteBuffer that is
> too small to hold the complete result, and it will just process as much
> as it can, and leave the rest for the next round (which should work well
> for Base64, too, as it always processes chunks of 3 or 4 bytes).
>
> So, a useful ByteBuffer API in my opinion needs a method like
>
> public boolean encode(ByteBuffer in, ByteBuffer out,
>    boolean endOfInput);
>
> public boolean decode(ByteBuffer in, ByteBuffer out,
>    boolean endOfInput);
>
> (similar to CharsetEncoder#encode) that can process partial input and
> will return true if all processable input has been processed (i. e. in
> has to be refilled) or false if some input could not have been processed
> (i. e. out has to be flushed).
>
> Users have to call it again and again until they call it with
> endOfInput=true and get true back (Using an enum as result similar to
> CoderResult#UNDERFLOW and CoderResult#OVERFLOW might be another option
> if the boolean results are too cryptic).
>
> Having a ByteBuffer Base64 API might be useful (although I'm not sure
> yet if I ever need it), but as it is now, it is mostly useless for
> serious ByteBuffer usage, as if I have to split and copy the data
> manually anyway, I can as well use the array APIs.
>
>
> Just my 0.02 EUR,
>
>
> Michael



From martinrb at google.com  Fri Oct 12 18:54:07 2012
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 12 Oct 2012 11:54:07 -0700
Subject: RFR: 8000817: Reinstate accidentally removed sleep() from
	ProcessBuilder/Basic.java
In-Reply-To: <507865BB.5040006@oracle.com>
References: <506CB1C3.5050009@oracle.com> <506D3D14.4070304@oracle.com>
	<CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
	<5071DC80.3080507@oracle.com>
	<CA+kOe08mRoVVXAR6K7j3PgDuNmiv+V=AkwxUoxAWcyTG+AXGqA@mail.gmail.com>
	<50734498.40100@oracle.com>
	<CA+kOe09RmETEA3xJJ7751hF5nCQ6L3oyONy10+syGYHzzzN0Tw@mail.gmail.com>
	<50782A14.1060701@oracle.com>
	<CA+kOe09=NiWhN3HFy5wUKBkP-dqvKCCYZHFgJAJYDtnEy1wNcw@mail.gmail.com>
	<50785C08.7050202@oracle.com>
	<CA+kOe0_EAyWSJbH50CEu+7Cm-ro3APqac5ZY47WDQE_dDXhKcQ@mail.gmail.com>
	<507865BB.5040006@oracle.com>
Message-ID: <CA+kOe08k+RFzXsDbHmduZRinHmaJb=arqUY6064tCWOWKU-oxQ@mail.gmail.com>

On Fri, Oct 12, 2012 at 11:47 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

>
> Checking for readBytes should be better but it might still be fragile
> because there isn't any guarantee that the thread is in the read syscall
> (although the window should be a lot smaller). Although none of us like
> using sleep, this may be a case where we need a short sleep to improve our
> chances.
>
>
Yup.

Sure would be nice if we could see native methods in the stacktraces, kind
of like this:

   java.lang.Thread.State: RUNNABLE
at (C/C++) __kernel_vsyscall( ())
at (C/C++) readBytes( (jre/lib/i386/libjava.so))
at (C/C++) Java_java_io_FileInputStream_readBytes(
(jre/lib/i386/libjava.so))
at java.io.FileInputStream.readBytes(Native Method)


From ariel at weisberg.ws  Fri Oct 12 19:47:59 2012
From: ariel at weisberg.ws (Ariel Weisberg)
Date: Fri, 12 Oct 2012 15:47:59 -0400
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <507867E7.9010103@oracle.com>
References: <507863DC.706@gmx.de> <507867E7.9010103@oracle.com>
Message-ID: <1350071279.6532.140661139990653.4285F2F2@webmail.messagingengine.com>

Hi,

Thanks for doing this BTW.

I think that including ByteBuffer API even if it isn't as efficient as
raw byte arrays is better then not having it in the API at all. If that
means allocating a byte array for the output and then doing a put on the
ByteBuffer that is fine.

Down the line if someone has a particularly powerful itch to scratch WRT
to performance they can add more code to the library to make it more
efficient at handling them and then everyone will benefit or they can do
their own implementation.

Thanks,
Ariel


On Fri, Oct 12, 2012, at 02:56 PM, Xueming Shen wrote:
> Hi,
> 
> The exactly reason I was trying to skip en/decode(ByteBuffer in, 
> ByteByuffer out)
> for now. I'm struggling with/can't make up my mind on whether or not the 
> en/decoder
> should  have internal state, like the charset en/decoder. It appears the 
> API is being
> pushed going that direction though:-)
> 
> -Sherman
> 
> On 10/12/2012 11:39 AM, Michael Schierl wrote:
> > Hello,
> >
> > (sorry if the threading is broken, but I was not subscribed to the list
> > and only found the discussion on Twitter and read it in the mailing list
> > archive)
> >
> > Ariel Weisberg wrote on Thu Oct 11 11:30:56 PDT 2012:
> >> I know that ByteBuffers are pain, but I did notice that you can't
> >> specify a source/dest pair when using ByteBuffers and that ByteBuffers
> >> without arrays have to be copied. I don't see a simple safe way to
> >> normalize access to them the way you can if everything is a byte array.
> > Agreed. One of the advantages of using byte buffers is reducing
> > allocations, resulting in fewer garbage collections.
> >
> > In addition, in this implementation the ByteBuffers have to contain the
> > full data.
> >
> > What I like about most byte buffers APIs is that I can pass in a
> > ByteBuffer with incomplete data or maybe an output ByteBuffer that is
> > too small to hold the complete result, and it will just process as much
> > as it can, and leave the rest for the next round (which should work well
> > for Base64, too, as it always processes chunks of 3 or 4 bytes).
> >
> > So, a useful ByteBuffer API in my opinion needs a method like
> >
> > public boolean encode(ByteBuffer in, ByteBuffer out,
> >    boolean endOfInput);
> >
> > public boolean decode(ByteBuffer in, ByteBuffer out,
> >    boolean endOfInput);
> >
> > (similar to CharsetEncoder#encode) that can process partial input and
> > will return true if all processable input has been processed (i. e. in
> > has to be refilled) or false if some input could not have been processed
> > (i. e. out has to be flushed).
> >
> > Users have to call it again and again until they call it with
> > endOfInput=true and get true back (Using an enum as result similar to
> > CoderResult#UNDERFLOW and CoderResult#OVERFLOW might be another option
> > if the boolean results are too cryptic).
> >
> > Having a ByteBuffer Base64 API might be useful (although I'm not sure
> > yet if I ever need it), but as it is now, it is mostly useless for
> > serious ByteBuffer usage, as if I have to split and copy the data
> > manually anyway, I can as well use the array APIs.
> >
> >
> > Just my 0.02 EUR,
> >
> >
> > Michael
> 


From xueming.shen at oracle.com  Fri Oct 12 20:12:57 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 12 Oct 2012 13:12:57 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <1350071279.6532.140661139990653.4285F2F2@webmail.messagingengine.com>
References: <507863DC.706@gmx.de> <507867E7.9010103@oracle.com>
	<1350071279.6532.140661139990653.4285F2F2@webmail.messagingengine.com>
Message-ID: <507879C9.2050106@oracle.com>

Hi,

It appears to be possible to do something like

boolean de/encode(ByteBuffer src, ByteBuffer dst);

returns true if all remaining bytes in src are en/decoded, false, the dst
is not big enough for all output bytes, the src.position() will be advanced
to the position of next un-en/decoded byte, dst.position() will be updated
accordingly as well.

to avoid the en/decoder to hold an internal state.

-Sherman

On 10/12/2012 12:47 PM, Ariel Weisberg wrote:
> Hi,
>
> Thanks for doing this BTW.
>
> I think that including ByteBuffer API even if it isn't as efficient as
> raw byte arrays is better then not having it in the API at all. If that
> means allocating a byte array for the output and then doing a put on the
> ByteBuffer that is fine.
>
> Down the line if someone has a particularly powerful itch to scratch WRT
> to performance they can add more code to the library to make it more
> efficient at handling them and then everyone will benefit or they can do
> their own implementation.
>
> Thanks,
> Ariel
>
>
> On Fri, Oct 12, 2012, at 02:56 PM, Xueming Shen wrote:
>> Hi,
>>
>> The exactly reason I was trying to skip en/decode(ByteBuffer in,
>> ByteByuffer out)
>> for now. I'm struggling with/can't make up my mind on whether or not the
>> en/decoder
>> should  have internal state, like the charset en/decoder. It appears the
>> API is being
>> pushed going that direction though:-)
>>
>> -Sherman
>>
>> On 10/12/2012 11:39 AM, Michael Schierl wrote:
>>> Hello,
>>>
>>> (sorry if the threading is broken, but I was not subscribed to the list
>>> and only found the discussion on Twitter and read it in the mailing list
>>> archive)
>>>
>>> Ariel Weisberg wrote on Thu Oct 11 11:30:56 PDT 2012:
>>>> I know that ByteBuffers are pain, but I did notice that you can't
>>>> specify a source/dest pair when using ByteBuffers and that ByteBuffers
>>>> without arrays have to be copied. I don't see a simple safe way to
>>>> normalize access to them the way you can if everything is a byte array.
>>> Agreed. One of the advantages of using byte buffers is reducing
>>> allocations, resulting in fewer garbage collections.
>>>
>>> In addition, in this implementation the ByteBuffers have to contain the
>>> full data.
>>>
>>> What I like about most byte buffers APIs is that I can pass in a
>>> ByteBuffer with incomplete data or maybe an output ByteBuffer that is
>>> too small to hold the complete result, and it will just process as much
>>> as it can, and leave the rest for the next round (which should work well
>>> for Base64, too, as it always processes chunks of 3 or 4 bytes).
>>>
>>> So, a useful ByteBuffer API in my opinion needs a method like
>>>
>>> public boolean encode(ByteBuffer in, ByteBuffer out,
>>>     boolean endOfInput);
>>>
>>> public boolean decode(ByteBuffer in, ByteBuffer out,
>>>     boolean endOfInput);
>>>
>>> (similar to CharsetEncoder#encode) that can process partial input and
>>> will return true if all processable input has been processed (i. e. in
>>> has to be refilled) or false if some input could not have been processed
>>> (i. e. out has to be flushed).
>>>
>>> Users have to call it again and again until they call it with
>>> endOfInput=true and get true back (Using an enum as result similar to
>>> CoderResult#UNDERFLOW and CoderResult#OVERFLOW might be another option
>>> if the boolean results are too cryptic).
>>>
>>> Having a ByteBuffer Base64 API might be useful (although I'm not sure
>>> yet if I ever need it), but as it is now, it is mostly useless for
>>> serious ByteBuffer usage, as if I have to split and copy the data
>>> manually anyway, I can as well use the array APIs.
>>>
>>>
>>> Just my 0.02 EUR,
>>>
>>>
>>> Michael



From Alan.Bateman at oracle.com  Fri Oct 12 20:16:14 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Oct 2012 21:16:14 +0100
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <507879C9.2050106@oracle.com>
References: <507863DC.706@gmx.de> <507867E7.9010103@oracle.com>
	<1350071279.6532.140661139990653.4285F2F2@webmail.messagingengine.com>
	<507879C9.2050106@oracle.com>
Message-ID: <50787A8E.9030004@oracle.com>

On 12/10/2012 21:12, Xueming Shen wrote:
> Hi,
>
> It appears to be possible to do something like
>
> boolean de/encode(ByteBuffer src, ByteBuffer dst);
>
> returns true if all remaining bytes in src are en/decoded, false, the dst
> is not big enough for all output bytes, the src.position() will be 
> advanced
> to the position of next un-en/decoded byte, dst.position() will be 
> updated
> accordingly as well.
>
> to avoid the en/decoder to hold an internal state.
Right, there shouldn't be any need for internal state and 
src.remaining() will indicate if there are any bytes in src that 
couldn't be encoded into dst because of insufficient space. The return 
value should probably be the number of bytes written to dst.

-Alan


From rob.mckenna at oracle.com  Fri Oct 12 20:18:13 2012
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 12 Oct 2012 21:18:13 +0100
Subject: RFR: 8000817: Reinstate accidentally removed sleep() from
	ProcessBuilder/Basic.java
In-Reply-To: <CA+kOe08k+RFzXsDbHmduZRinHmaJb=arqUY6064tCWOWKU-oxQ@mail.gmail.com>
References: <506CB1C3.5050009@oracle.com> <506D3D14.4070304@oracle.com>
	<CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
	<5071DC80.3080507@oracle.com>
	<CA+kOe08mRoVVXAR6K7j3PgDuNmiv+V=AkwxUoxAWcyTG+AXGqA@mail.gmail.com>
	<50734498.40100@oracle.com>
	<CA+kOe09RmETEA3xJJ7751hF5nCQ6L3oyONy10+syGYHzzzN0Tw@mail.gmail.com>
	<50782A14.1060701@oracle.com>
	<CA+kOe09=NiWhN3HFy5wUKBkP-dqvKCCYZHFgJAJYDtnEy1wNcw@mail.gmail.com>
	<50785C08.7050202@oracle.com>
	<CA+kOe0_EAyWSJbH50CEu+7Cm-ro3APqac5ZY47WDQE_dDXhKcQ@mail.gmail.com>
	<507865BB.5040006@oracle.com>
	<CA+kOe08k+RFzXsDbHmduZRinHmaJb=arqUY6064tCWOWKU-oxQ@mail.gmail.com>
Message-ID: <50787B05.6060506@oracle.com>

Sorry for not responding sooner, I was out for the evening.

I threw this fix into our test infrastructure (jprt) before I left 
though, and I see it has passed.

http://cr.openjdk.java.net/~robm/8000817/webrev.02/ 
<http://cr.openjdk.java.net/%7Erobm/8000817/webrev.02/>

I'm a little unclear as to why you'd prefer to throw that away, can you 
elaborate?

As ugly as a Thread.sleep(10) is, it hasn't historically been a problem 
on platforms other than Solaris. Perhaps this in combination with the 
stack hackery?

Let me know either way and I'll get it integrated sharpish! Thanks,

     -Rob


On 12/10/12 19:54, Martin Buchholz wrote:
>
>
> On Fri, Oct 12, 2012 at 11:47 AM, Alan Bateman 
> <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>
>
>     Checking for readBytes should be better but it might still be
>     fragile because there isn't any guarantee that the thread is in
>     the read syscall (although the window should be a lot smaller).
>     Although none of us like using sleep, this may be a case where we
>     need a short sleep to improve our chances.
>
>
> Yup.
>
> Sure would be nice if we could see native methods in the stacktraces, 
> kind of like this:
>
>    java.lang.Thread.State: RUNNABLE
> at (C/C++) __kernel_vsyscall( ())
> at (C/C++) readBytes( (jre/lib/i386/libjava.so))
> at (C/C++) Java_java_io_FileInputStream_readBytes( 
> (jre/lib/i386/libjava.so))
> at java.io.FileInputStream.readBytes(Native Method)
>



From schierlm at gmx.de  Fri Oct 12 20:48:41 2012
From: schierlm at gmx.de (Michael Schierl)
Date: Fri, 12 Oct 2012 22:48:41 +0200
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <507879C9.2050106@oracle.com>
References: <507863DC.706@gmx.de> <507867E7.9010103@oracle.com>
	<1350071279.6532.140661139990653.4285F2F2@webmail.messagingengine.com>
	<507879C9.2050106@oracle.com>
Message-ID: <50788229.2080900@gmx.de>

Am 12.10.2012 22:12, schrieb Xueming Shen:
> Hi,
> 
> It appears to be possible to do something like
> 
> boolean de/encode(ByteBuffer src, ByteBuffer dst);
> 
> returns true if all remaining bytes in src are en/decoded, false, the dst
> is not big enough for all output bytes, the src.position() will be advanced
> to the position of next un-en/decoded byte, dst.position() will be updated
> accordingly as well.
> 
> to avoid the en/decoder to hold an internal state.

If it was unclear, that was what I tried to suggest. I thought you
refered to the automatic adding of newlines when you said you'd need
internal state (although that state is small enough - how many encoded
bytes remaining before adding the next newline - so that it might be
possible to pass it as a parameter, too). I'm not sure how important
that adding of newlines really is (in all cases where I was guilty of
using sun.misc.Base64Encoder, I always replaced them out after
encoding), so maybe the ByteBuffer API could live without it.

Note that without an explicit end of stream flag, it might not be easily
possible to encode the last block - if you have a 16 byte buffer with 14
bytes filled, you cannot be sure whether you can encode the last two
bytes to XYZ= because it is end of stream or you have to wait for the
next byte. An option without the flag might be to assume when the input
is less than 3 bytes that it is the end of the stream. But I doubt it
will make the API easier to understand or use. :-)


Regards,


Michael


From xueming.shen at oracle.com  Fri Oct 12 20:58:12 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 12 Oct 2012 13:58:12 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <50788229.2080900@gmx.de>
References: <507863DC.706@gmx.de>
	<507867E7.9010103@oracle.com>	<1350071279.6532.140661139990653.4285F2F2@webmail.messagingengine.com>	<507879C9.2050106@oracle.com>
	<50788229.2080900@gmx.de>
Message-ID: <50788464.3020503@oracle.com>


Yes, I'm trying to figure out where to have this  position info stored...

On 10/12/2012 01:48 PM, Michael Schierl wrote:
> Am 12.10.2012 22:12, schrieb Xueming Shen:
>> Hi,
>>
>> It appears to be possible to do something like
>>
>> boolean de/encode(ByteBuffer src, ByteBuffer dst);
>>
>> returns true if all remaining bytes in src are en/decoded, false, the dst
>> is not big enough for all output bytes, the src.position() will be advanced
>> to the position of next un-en/decoded byte, dst.position() will be updated
>> accordingly as well.
>>
>> to avoid the en/decoder to hold an internal state.
> If it was unclear, that was what I tried to suggest. I thought you
> refered to the automatic adding of newlines when you said you'd need
> internal state (although that state is small enough - how many encoded
> bytes remaining before adding the next newline - so that it might be
> possible to pass it as a parameter, too). I'm not sure how important
> that adding of newlines really is (in all cases where I was guilty of
> using sun.misc.Base64Encoder, I always replaced them out after
> encoding), so maybe the ByteBuffer API could live without it.
>
> Note that without an explicit end of stream flag, it might not be easily
> possible to encode the last block - if you have a 16 byte buffer with 14
> bytes filled, you cannot be sure whether you can encode the last two
> bytes to XYZ= because it is end of stream or you have to wait for the
> next byte. An option without the flag might be to assume when the input
> is less than 3 bytes that it is the end of the stream. But I doubt it
> will make the API easier to understand or use. :-)
>
>
> Regards,
>
>
> Michael



From martinrb at google.com  Fri Oct 12 22:20:53 2012
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 12 Oct 2012 15:20:53 -0700
Subject: RFR: 8000817: Reinstate accidentally removed sleep() from
	ProcessBuilder/Basic.java
In-Reply-To: <50787B05.6060506@oracle.com>
References: <506CB1C3.5050009@oracle.com> <506D3D14.4070304@oracle.com>
	<CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
	<5071DC80.3080507@oracle.com>
	<CA+kOe08mRoVVXAR6K7j3PgDuNmiv+V=AkwxUoxAWcyTG+AXGqA@mail.gmail.com>
	<50734498.40100@oracle.com>
	<CA+kOe09RmETEA3xJJ7751hF5nCQ6L3oyONy10+syGYHzzzN0Tw@mail.gmail.com>
	<50782A14.1060701@oracle.com>
	<CA+kOe09=NiWhN3HFy5wUKBkP-dqvKCCYZHFgJAJYDtnEy1wNcw@mail.gmail.com>
	<50785C08.7050202@oracle.com>
	<CA+kOe0_EAyWSJbH50CEu+7Cm-ro3APqac5ZY47WDQE_dDXhKcQ@mail.gmail.com>
	<507865BB.5040006@oracle.com>
	<CA+kOe08k+RFzXsDbHmduZRinHmaJb=arqUY6064tCWOWKU-oxQ@mail.gmail.com>
	<50787B05.6060506@oracle.com>
Message-ID: <CA+kOe0-C3RLJpJbGf+y3f9mu593w+eaZJCA3gLBKGavDo9dyiQ@mail.gmail.com>

Thanks, Rob.

I'm OK with your webrev.02, and I'm OK with putting back a 10ms sleep, if
you want to also do that.  I'm not sure what happens on macosx or windows -
you might want to think about that.

Martin

On Fri, Oct 12, 2012 at 1:18 PM, Rob McKenna <rob.mckenna at oracle.com> wrote:

>  Sorry for not responding sooner, I was out for the evening.
>
> I threw this fix into our test infrastructure (jprt) before I left though,
> and I see it has passed.
>
> http://cr.openjdk.java.net/~robm/8000817/webrev.02/
>
> I'm a little unclear as to why you'd prefer to throw that away, can you
> elaborate?
>
> As ugly as a Thread.sleep(10) is, it hasn't historically been a problem on
> platforms other than Solaris. Perhaps this in combination with the stack
> hackery?
>
> Let me know either way and I'll get it integrated sharpish! Thanks,
>
>     -Rob
>
>
>
> On 12/10/12 19:54, Martin Buchholz wrote:
>
>
>
> On Fri, Oct 12, 2012 at 11:47 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:
>
>>
>>  Checking for readBytes should be better but it might still be fragile
>> because there isn't any guarantee that the thread is in the read syscall
>> (although the window should be a lot smaller). Although none of us like
>> using sleep, this may be a case where we need a short sleep to improve our
>> chances.
>>
>>
>  Yup.
>
>  Sure would be nice if we could see native methods in the stacktraces,
> kind of like this:
>
>     java.lang.Thread.State: RUNNABLE
>  at (C/C++) __kernel_vsyscall( ())
>  at (C/C++) readBytes( (jre/lib/i386/libjava.so))
>  at (C/C++) Java_java_io_FileInputStream_readBytes(
> (jre/lib/i386/libjava.so))
>  at java.io.FileInputStream.readBytes(Native Method)
>
>
>


From lana.steuck at oracle.com  Fri Oct 12 22:27:56 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 12 Oct 2012 22:27:56 +0000
Subject: hg: jdk8/tl: 6 new changesets
Message-ID: <20121012222757.3269A4733F@hg.openjdk.java.net>

Changeset: dae9821589cc
Author:    katleman
Date:      2012-09-27 11:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/dae9821589cc

Added tag jdk8-b58 for changeset 936702480487

! .hgtags

Changeset: b9d574659206
Author:    katleman
Date:      2012-10-04 14:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/b9d574659206

Added tag jdk8-b59 for changeset dae9821589cc

! .hgtags

Changeset: 4b54d77a6831
Author:    dholmes
Date:      2012-10-09 02:08 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/4b54d77a6831

8000461: Top level build doesn't pass OPENJDK=true through to the hotspot build
Summary: Add OPENJDK to the COMMON_BUILD_ARGUMENTS
Reviewed-by: tbell

! make/Defs-internal.gmk

Changeset: e07f499b9dcc
Author:    katleman
Date:      2012-10-10 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/e07f499b9dcc

Merge


Changeset: 20ff117b5090
Author:    katleman
Date:      2012-10-11 09:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/20ff117b5090

Added tag jdk8-b60 for changeset e07f499b9dcc

! .hgtags

Changeset: ce2b111ee869
Author:    lana
Date:      2012-10-12 14:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/ce2b111ee869

Merge




From lana.steuck at oracle.com  Fri Oct 12 22:28:04 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 12 Oct 2012 22:28:04 +0000
Subject: hg: jdk8/tl/corba: 6 new changesets
Message-ID: <20121012222808.64F7847340@hg.openjdk.java.net>

Changeset: d54dc53e223e
Author:    katleman
Date:      2012-09-27 11:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/d54dc53e223e

Added tag jdk8-b58 for changeset 18462a19f7bd

! .hgtags

Changeset: 207ef43ba69e
Author:    katleman
Date:      2012-10-04 14:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/207ef43ba69e

Added tag jdk8-b59 for changeset d54dc53e223e

! .hgtags

Changeset: 41bb9e606efd
Author:    katleman
Date:      2012-10-11 09:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/41bb9e606efd

Added tag jdk8-b60 for changeset 207ef43ba69e

! .hgtags

Changeset: d9c1dab1515b
Author:    lana
Date:      2012-10-08 15:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/d9c1dab1515b

Merge


Changeset: 0e08ba7648fb
Author:    lana
Date:      2012-10-11 16:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/0e08ba7648fb

Merge


Changeset: 706684c5a058
Author:    lana
Date:      2012-10-12 14:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/706684c5a058

Merge




From lana.steuck at oracle.com  Fri Oct 12 22:30:09 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 12 Oct 2012 22:30:09 +0000
Subject: hg: jdk8/tl/hotspot: 68 new changesets
Message-ID: <20121012223233.15DB147342@hg.openjdk.java.net>

Changeset: 04ed664b7e30
Author:    amurillo
Date:      2012-09-21 14:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04ed664b7e30

7200236: new hotspot build - hs25-b03
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: fac3dd92ebaf
Author:    bpittore
Date:      2012-09-19 17:22 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fac3dd92ebaf

7195372: Wrong copyright in new files
Summary: Fixed copyrights
Reviewed-by: dholmes
Contributed-by: Bill Pittore <bill.pittore at oracle.com>

! agent/make/saenv.sh
! agent/make/start-debug-server-proc.sh
! agent/src/share/classes/sun/jvm/hotspot/debugger/ThreadContext.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/amd64/AMD64ThreadContext.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/ia64/IA64ThreadContext.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/sparc/SPARCThreadContext.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/x86/X86ThreadContext.java
! make/linux/makefiles/sa.make

Changeset: ef7fe63a2d39
Author:    vladidan
Date:      2012-09-24 19:00 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ef7fe63a2d39

Merge


Changeset: 15ba0e7a3ff4
Author:    sla
Date:      2012-09-17 11:46 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15ba0e7a3ff4

7193201: [OS X] The development launcher should be signed and given task_for_pid privileges
Reviewed-by: sspitsyn, nloodin, mgronlun, coleenp

! make/bsd/makefiles/launcher.make
+ src/os/bsd/launcher/Info-privileged.plist

Changeset: a7509aff1b06
Author:    dholmes
Date:      2012-09-17 07:36 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a7509aff1b06

7194254: jstack reports wrong thread priorities
Reviewed-by: dholmes, sla, fparain
Contributed-by: Dmytro Sheyko <dmytro_sheyko at hotmail.com>

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/thread.cpp
+ test/runtime/7194254/Test7194254.java

Changeset: 7b41bee02500
Author:    dholmes
Date:      2012-09-17 08:44 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b41bee02500

Merge


Changeset: 716e6ef4482a
Author:    zgu
Date:      2012-09-17 10:20 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/716e6ef4482a

7190089: NMT ON: NMT failed assertion on thread's stack base address
Summary: Solaris only, record stack info to NMT after stack size adjustment was made for primordial threads
Reviewed-by: kvn, acorn, coleenp

! src/os/solaris/vm/os_solaris.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp
! src/share/vm/runtime/os.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/services/memTracker.cpp
! src/share/vm/services/memTracker.hpp

Changeset: c088e2e95e69
Author:    zgu
Date:      2012-09-17 13:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c088e2e95e69

Merge

! src/share/vm/runtime/thread.cpp

Changeset: 9a86ddfc6c8f
Author:    zgu
Date:      2012-09-17 16:37 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9a86ddfc6c8f

7188594: Print statistic collected by NMT with VM flag
Summary: Print out statistics of collected NMT data if it is on at VM exits
Reviewed-by: kvn, coleenp, twisti

! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/java.cpp
! src/share/vm/services/memTracker.hpp

Changeset: 45f22ba9348d
Author:    zgu
Date:      2012-09-18 11:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/45f22ba9348d

Merge


Changeset: 1cb8583c3da8
Author:    minqi
Date:      2012-09-18 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cb8583c3da8

7191786: retransformClasses() does not pass in LocalVariableTypeTable of a method
Summary: JVMTI REtruncformClasses must support LocalVariableTypeTable attribute
Reviewed-by: dcubed, dsamersoff, rbackman
Contributed-by: serguei.spitsyn at oracle.com

! src/share/vm/prims/jvmtiClassFileReconstituter.cpp
! src/share/vm/prims/jvmtiClassFileReconstituter.hpp

Changeset: 26994b6e10d5
Author:    minqi
Date:      2012-09-19 08:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/26994b6e10d5

Merge


Changeset: 989cf02ca531
Author:    ihse
Date:      2012-09-17 11:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/989cf02ca531

7172012: Make test-in-build an option (Queens)
Reviewed-by: ohair, dholmes

! make/bsd/Makefile
! make/defs.make
! make/linux/Makefile
! make/solaris/Makefile

Changeset: 06be7f06c2de
Author:    ohair
Date:      2012-09-18 10:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/06be7f06c2de

Merge


Changeset: 37518f191ddb
Author:    ohair
Date:      2012-09-18 13:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37518f191ddb

7198329: Add $(sort) to object files used in links makes binarties more consistent
Reviewed-by: dholmes, tbell, erikj, ihse, ohrstrom

! make/bsd/makefiles/launcher.make
! make/bsd/makefiles/vm.make
! make/linux/makefiles/launcher.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/launcher.make
! make/solaris/makefiles/vm.make

Changeset: 0e5be2138cd6
Author:    jcoomes
Date:      2012-09-18 19:44 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0e5be2138cd6

Merge


Changeset: 2c527daec02c
Author:    jcoomes
Date:      2012-09-19 16:18 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c527daec02c

Merge


Changeset: 6af8f3562069
Author:    kevinw
Date:      2012-09-19 15:24 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6af8f3562069

7196045: Possible JVM deadlock in ThreadTimesClosure when using HotspotInternal non-public API.
Reviewed-by: sspitsyn, dholmes

! src/share/vm/services/management.cpp
+ test/runtime/7196045/Test7196045.java

Changeset: 8440414b0fd8
Author:    kevinw
Date:      2012-09-20 03:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8440414b0fd8

Merge


Changeset: b711844284e2
Author:    nloodin
Date:      2012-09-21 10:56 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b711844284e2

7200092: Make NMT a bit friendlier to work with
Reviewed-by: kvn, ysr, azeemj

! src/share/vm/services/memTracker.cpp

Changeset: 5a98bf7d847b
Author:    minqi
Date:      2012-09-24 12:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a98bf7d847b

6879063: SA should use hsdis for disassembly
Summary: We should in SA to use hsdis for it like the JVM does to replace the current java based disassembler.
Reviewed-by: twisti, jrose, sla
Contributed-by: yumin.qi at oracle.com

- agent/make/ClosureFinder.java
! agent/make/Makefile
! agent/src/os/bsd/MacosxDebuggerLocal.m
! agent/src/os/linux/Makefile
! agent/src/os/linux/mapfile
! agent/src/os/solaris/proc/Makefile
! agent/src/os/solaris/proc/mapfile
! agent/src/os/win32/windbg/Makefile
! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java
! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java
- agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Address.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java
! agent/src/share/classes/sun/jvm/hotspot/asm/Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java
- agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java
! agent/src/share/classes/sun/jvm/hotspot/asm/InstructionVisitor.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java
! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java
! agent/src/share/classes/sun/jvm/hotspot/code/CodeBlob.java
! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/SADebugServer.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RegisterMap.java
! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js
+ agent/src/share/native/sadis.c
! agent/test/jdi/jstack.sh
! agent/test/jdi/jstack64.sh
! agent/test/jdi/runsa.sh
! agent/test/jdi/sasanity.sh
! agent/test/libproc/libproctest.sh
! agent/test/libproc/libproctest64.sh
! make/bsd/makefiles/sa.make
! make/bsd/makefiles/saproc.make
! make/linux/makefiles/sa.make
! make/linux/makefiles/saproc.make
! make/sa.files
! make/solaris/makefiles/sa.make
! make/solaris/makefiles/saproc.make
! make/windows/makefiles/sa.make
! src/share/tools/hsdis/Makefile
! src/share/tools/hsdis/README
! src/share/tools/hsdis/hsdis-demo.c
! src/share/tools/hsdis/hsdis.c
! src/share/tools/hsdis/hsdis.h
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/compiler/disassembler.hpp

Changeset: 3d739d45d9fd
Author:    minqi
Date:      2012-09-24 20:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3d739d45d9fd

Merge

- agent/make/ClosureFinder.java
- agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Address.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java
- agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java

Changeset: 45535ab90688
Author:    dholmes
Date:      2012-09-25 07:58 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/45535ab90688

7200065: Cross-compilation changes to support the new-build
Reviewed-by: dholmes, ohair
Contributed-by: Fredrik Ohrstrom <fredrik.ohrstrom at oracle.com>

! make/linux/makefiles/adlc.make
! make/linux/makefiles/defs.make

Changeset: b86575d092a2
Author:    dsamersoff
Date:      2012-09-27 20:22 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b86575d092a2

Merge

- agent/make/ClosureFinder.java
- agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Address.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java
- agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java
! make/linux/makefiles/sa.make
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 5baec2e69518
Author:    jmasa
Date:      2012-09-25 07:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5baec2e69518

7200615: NPG: optimized VM build is broken
Reviewed-by: kvn

! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp
! src/share/vm/memory/metaspace.cpp

Changeset: 8966c2d65d96
Author:    brutisso
Date:      2012-09-25 14:58 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8966c2d65d96

7200470: KeepAliveClosure not needed in CodeCache::do_unloading
Summary: Removed the unused keep_alive parameter
Reviewed-by: stefank, dholmes, kamg, coleenp

! src/share/vm/code/codeCache.cpp
! src/share/vm/code/codeCache.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/memory/genMarkSweep.cpp

Changeset: 7c2fd5948145
Author:    brutisso
Date:      2012-09-25 18:28 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c2fd5948145

Merge


Changeset: 15fba4382765
Author:    stefank
Date:      2012-09-28 14:14 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/15fba4382765

Merge


Changeset: 2cb2f30450c7
Author:    twisti
Date:      2012-09-17 12:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2cb2f30450c7

7196262: JSR 292: java/lang/invoke/PrivateInvokeTest.java fails on solaris-sparc
Reviewed-by: kvn, jrose, bdelsart

! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/share/vm/asm/register.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp

Changeset: 8d3cc6612bd1
Author:    kvn
Date:      2012-09-17 17:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8d3cc6612bd1

7197033: missing ResourceMark for assert in Method::bci_from()
Summary: Added missing ResourceMark.
Reviewed-by: dholmes, coleenp, jmasa

! src/share/vm/oops/method.cpp

Changeset: 137868b7aa6f
Author:    kvn
Date:      2012-09-17 19:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/137868b7aa6f

7196199: java/text/Bidi/Bug6665028.java failed: Bidi run count incorrect
Summary: Save whole XMM/YMM registers in safepoint interrupt handler.
Reviewed-by: roland, twisti

! src/cpu/sparc/vm/sharedRuntime_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/sharedRuntime_x86_32.cpp
! src/cpu/x86/vm/sharedRuntime_x86_64.cpp
! src/cpu/x86/vm/x86.ad
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciEnv.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/sharedRuntime.hpp
+ test/compiler/7196199/Test7196199.java

Changeset: 9d89c76b0505
Author:    twisti
Date:      2012-09-19 10:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d89c76b0505

7198499: TraceTypeProfile as diagnostic option
Reviewed-by: kvn
Contributed-by: Aleksey Shipilev <aleksey.shipilev at oracle.com>

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/doCall.cpp

Changeset: 8ae8f9dd7099
Author:    kvn
Date:      2012-09-19 16:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8ae8f9dd7099

7199010: incorrect vector alignment
Summary: Fixed vectors alignment when several arrays are accessed in one loop.
Reviewed-by: roland, twisti

! src/cpu/x86/vm/vm_version_x86.cpp
! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/superword.hpp

Changeset: 7eca5de9e0b6
Author:    roland
Date:      2012-09-20 16:49 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7eca5de9e0b6

7023898: Intrinsify AtomicLongFieldUpdater.getAndIncrement()
Summary: use shorter instruction sequences for atomic add and atomic exchange when possible.
Reviewed-by: kvn, jrose

! src/cpu/sparc/vm/assembler_sparc.inline.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/x86.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Canonicalizer.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_Instruction.hpp
! src/share/vm/c1/c1_InstructionPrinter.cpp
! src/share/vm/c1/c1_InstructionPrinter.hpp
! src/share/vm/c1/c1_LIR.cpp
! src/share/vm/c1/c1_LIR.hpp
! src/share/vm/c1/c1_LIRAssembler.cpp
! src/share/vm/c1/c1_LIRAssembler.hpp
! src/share/vm/c1/c1_LIRGenerator.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/c1/c1_ValueMap.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/escape.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/runtime/vm_version.hpp

Changeset: b31471cdc53e
Author:    kvn
Date:      2012-09-24 10:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b31471cdc53e

7200163: add CodeComments functionality to assember stubs
Summary: Pass the codeBuffer to the Stub constructor, and adapts the disassembler to print the comments.
Reviewed-by: jrose, kvn, twisti
Contributed-by: goetz.lindenmaier at sap.com

! src/share/vm/asm/codeBuffer.cpp
! src/share/vm/asm/codeBuffer.hpp
! src/share/vm/code/codeBlob.cpp
! src/share/vm/code/codeBlob.hpp
! src/share/vm/code/icBuffer.hpp
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/code/stubs.cpp
! src/share/vm/code/stubs.hpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/compiler/disassembler.hpp
! src/share/vm/interpreter/interpreter.cpp
! src/share/vm/interpreter/interpreter.hpp
! src/share/vm/runtime/sharedRuntime.cpp

Changeset: 3a327d0b8586
Author:    twisti
Date:      2012-09-24 11:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3a327d0b8586

7188176: The JVM should differentiate between T and M series and adjust GC ergonomics
Reviewed-by: kvn
Contributed-by: Tao Mao <tao.mao at oracle.com>

! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/sparc/vm/vm_version_sparc.hpp

Changeset: f7c1f489db55
Author:    twisti
Date:      2012-09-24 12:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f7c1f489db55

Merge


Changeset: c92f43386117
Author:    kvn
Date:      2012-09-24 14:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c92f43386117

Merge

! src/share/vm/classfile/vmSymbols.hpp

Changeset: 9191895df19d
Author:    twisti
Date:      2012-09-24 17:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9191895df19d

7200001: failed C1 OSR compile doesn't get recompiled with C2
Reviewed-by: kvn

! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/compiler/compileLog.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/method.hpp
! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/compilationPolicy.cpp
! src/share/vm/runtime/simpleThresholdPolicy.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/accessFlags.hpp

Changeset: 1a9b9cfcef41
Author:    neliasso
Date:      2012-03-29 16:43 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a9b9cfcef41

7163863: Updated projectcreator
Summary: Enable source browsing for all platform dependent code
Reviewed-by: brutisso, coleenp

! make/windows/makefiles/projectcreator.make
! src/share/tools/ProjectCreator/BuildConfig.java
- src/share/tools/ProjectCreator/DirectoryTree.java
- src/share/tools/ProjectCreator/DirectoryTreeNode.java
- src/share/tools/ProjectCreator/FileFormatException.java
+ src/share/tools/ProjectCreator/FileTreeCreator.java
+ src/share/tools/ProjectCreator/FileTreeCreatorVC10.java
+ src/share/tools/ProjectCreator/FileTreeCreatorVC7.java
! src/share/tools/ProjectCreator/ProjectCreator.java
! src/share/tools/ProjectCreator/Util.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java
- src/share/tools/ProjectCreator/WinGammaPlatformVC6.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java

Changeset: 0702f188baeb
Author:    kvn
Date:      2012-09-25 10:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0702f188baeb

7200233: C2: can't use expand rules for vector instruction rules
Summary: Added missed _bottom_type set in ArchDesc::defineExpand() and missed vector nodes in MatchRule::is_vector().
Reviewed-by: twisti, roland, dlong

! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 06f52c4d0e18
Author:    kvn
Date:      2012-09-25 15:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/06f52c4d0e18

7200264: 7192963 changes disabled shift vectors
Summary: Replaced is_vector_use() call with explicit check for vector shift's count.
Reviewed-by: twisti, roland, dlong, vlivanov

! src/share/vm/opto/superword.cpp
+ test/compiler/7200264/Test7200264.sh
+ test/compiler/7200264/TestIntVect.java

Changeset: e626685e9f6c
Author:    kvn
Date:      2012-09-27 09:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e626685e9f6c

7193318: C2: remove number of inputs requirement from Node's new operator
Summary: Deleted placement new operator of Node - node(size_t, Compile *, int).
Reviewed-by: kvn, twisti
Contributed-by: bharadwaj.yadavalli at oracle.com

! src/share/vm/adlc/output_c.cpp
! src/share/vm/opto/addnode.cpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/chaitin.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/divnode.cpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/generateOptoStub.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/ifnode.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopPredicate.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopUnswitch.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/macro.hpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/mulnode.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/output.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/reg_split.cpp
! src/share/vm/opto/split_if.cpp
! src/share/vm/opto/stringopts.cpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp

Changeset: 69fb89ec6fa7
Author:    kvn
Date:      2012-09-27 15:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69fb89ec6fa7

7198084: NPG: distance is too big for short branches in test_invocation_counter_for_mdp()
Summary: use long branches in test_invocation_counter_for_mdp()
Reviewed-by: twisti

! src/cpu/sparc/vm/interp_masm_sparc.cpp

Changeset: f2e12eb74117
Author:    kvn
Date:      2012-09-28 10:16 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f2e12eb74117

Merge

- src/share/tools/ProjectCreator/DirectoryTree.java
- src/share/tools/ProjectCreator/DirectoryTreeNode.java
- src/share/tools/ProjectCreator/FileFormatException.java
- src/share/tools/ProjectCreator/WinGammaPlatformVC6.java
! src/share/vm/code/nmethod.cpp
! src/share/vm/code/nmethod.hpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/compiler/disassembler.hpp

Changeset: 9f008ad79470
Author:    amurillo
Date:      2012-09-28 13:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9f008ad79470

Added tag hs25-b03 for changeset f2e12eb74117

! .hgtags

Changeset: 2dd08e86a2bf
Author:    katleman
Date:      2012-09-27 11:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2dd08e86a2bf

Added tag jdk8-b58 for changeset 6bb378c50828

! .hgtags

Changeset: 8a1a6b9b4f20
Author:    katleman
Date:      2012-10-03 15:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8a1a6b9b4f20

Merge

! .hgtags
- agent/make/ClosureFinder.java
- agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Address.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java
- agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java
- src/share/tools/ProjectCreator/DirectoryTree.java
- src/share/tools/ProjectCreator/DirectoryTreeNode.java
- src/share/tools/ProjectCreator/FileFormatException.java
- src/share/tools/ProjectCreator/WinGammaPlatformVC6.java

Changeset: a3fd4914ac81
Author:    katleman
Date:      2012-10-04 14:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a3fd4914ac81

Added tag jdk8-b59 for changeset 8a1a6b9b4f20

! .hgtags

Changeset: 1b582b1bf7cb
Author:    amurillo
Date:      2012-09-28 14:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b582b1bf7cb

8000251: new hotspot build - hs25-b04
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 988bf00cc564
Author:    johnc
Date:      2012-09-27 15:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/988bf00cc564

7200261: G1: Liveness counting inconsistencies during marking verification
Summary: The clipping code in the routine that sets the bits for a range of cards, in the liveness accounting verification code was incorrect. It set all the bits in the card bitmap from the given starting index which would lead to spurious marking verification failures.
Reviewed-by: brutisso, jwilhelm, jmasa

! 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

Changeset: 5c8fbbfed964
Author:    stefank
Date:      2012-10-01 11:07 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c8fbbfed964

Merge

- agent/make/ClosureFinder.java
- agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Address.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java
- agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java
- src/share/tools/ProjectCreator/DirectoryTree.java
- src/share/tools/ProjectCreator/DirectoryTreeNode.java
- src/share/tools/ProjectCreator/FileFormatException.java
- src/share/tools/ProjectCreator/WinGammaPlatformVC6.java

Changeset: 85f1cded9793
Author:    stefank
Date:      2012-09-28 15:34 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/85f1cded9793

8000230: Change os::print_location to be more descriptive when a location is pointing into an object
Reviewed-by: mgerdin, twisti

! src/share/vm/runtime/os.cpp

Changeset: 86af3dacab81
Author:    stefank
Date:      2012-10-01 13:29 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/86af3dacab81

8000227: [obj|type]ArrayKlass::oop_print_on prints one line to tty instead of the provided output stream
Reviewed-by: brutisso, sla, jmasa, coleenp

! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.cpp

Changeset: 87ac5c0a404d
Author:    stefank
Date:      2012-10-01 13:29 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/87ac5c0a404d

8000228: Missing call to cr() when printing entry_point in nmethod, in os::print_location
Reviewed-by: brutisso, neliasso

! src/share/vm/runtime/os.cpp

Changeset: f81a7c0c618d
Author:    jmasa
Date:      2012-10-03 08:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f81a7c0c618d

7199349: NPG: PS: Crash seen in jprt
Reviewed-by: johnc

! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp
! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 22b8d3d181d9
Author:    jwilhelm
Date:      2012-10-03 20:31 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22b8d3d181d9

8000351: Tenuring threshold should be unsigned
Summary: Change the flags and variables related to tenuring threshold to be unsigned
Reviewed-by: jmasa, johnc

! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/parallelScavenge/psAdaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp
! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.cpp
! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/shared/ageTable.cpp
! src/share/vm/gc_implementation/shared/ageTable.hpp
! src/share/vm/gc_implementation/shared/gcAdaptivePolicyCounters.hpp
! src/share/vm/memory/defNewGeneration.hpp
! src/share/vm/memory/threadLocalAllocBuffer.hpp
! src/share/vm/oops/markOop.hpp
! src/share/vm/oops/oop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/biasedLocking.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 2e6857353b2c
Author:    johnc
Date:      2012-10-04 10:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2e6857353b2c

8000311: G1: ParallelGCThreads==0 broken
Summary: Divide by zero error, if ParallelGCThreads is 0, when adjusting the PLAB size.
Reviewed-by: jmasa, jcoomes

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.cpp
! src/share/vm/gc_implementation/shared/parGCAllocBuffer.hpp

Changeset: 097d78aaf2b5
Author:    jmasa
Date:      2012-10-04 10:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/097d78aaf2b5

7198873: NPG: VM Does not unload classes with UseConcMarkSweepGC
Reviewed-by: johnc, mgerdin, jwilhelm

! src/share/vm/gc_implementation/shared/vmGCOperations.cpp

Changeset: ca70b919819f
Author:    jmasa
Date:      2012-10-04 14:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca70b919819f

Merge


Changeset: f6b0eb4e44cf
Author:    twisti
Date:      2012-10-01 14:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f6b0eb4e44cf

7200949: JSR 292: rubybench/bench/time/bench_base64.rb fails with jruby.jar not on boot class path
Reviewed-by: jrose, kvn

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/ci/ciClassList.hpp
+ src/share/vm/ci/ciMethodType.hpp
! src/share/vm/ci/ciObject.hpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/ci/ciSignature.cpp
! src/share/vm/ci/ciSignature.hpp
! src/share/vm/ci/ciStreams.cpp
! src/share/vm/ci/ciStreams.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/interpreter/linkResolver.cpp
! src/share/vm/interpreter/linkResolver.hpp
! src/share/vm/interpreter/rewriter.cpp
! src/share/vm/interpreter/rewriter.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/cpCache.cpp
! src/share/vm/oops/cpCache.hpp

Changeset: 859c45fb8cea
Author:    kvn
Date:      2012-10-02 12:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/859c45fb8cea

7201026: add vector for shift count
Summary: Add generation of vectors for scalar shift count.
Reviewed-by: roland, twisti, dlong

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86.ad
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp
! src/share/vm/opto/vectornode.hpp
! test/compiler/7200264/Test7200264.sh

Changeset: f13867c41f73
Author:    kvn
Date:      2012-10-02 14:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f13867c41f73

7199742: A lot of C2 OSR compilations of the same method's bci
Summary: Don't clone head of OSR loop.
Reviewed-by: jrose, twisti

! src/share/vm/ci/ciTypeFlow.cpp
! src/share/vm/opto/parse1.cpp
+ test/compiler/7199742/Test7199742.java

Changeset: bf2edd3c9b0f
Author:    neliasso
Date:      2012-10-04 06:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf2edd3c9b0f

8000102: Resolve include conflicts
Summary: Removing include of c1/c1_runtime.hpp and opto/runtime.hpp from all os-files.
Reviewed-by: kvn
Contributed-by: nils.eliasson at oracle.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/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.cpp

Changeset: 685457683e86
Author:    kvn
Date:      2012-10-05 10:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/685457683e86

Merge


Changeset: 1cc7a2a11d00
Author:    amurillo
Date:      2012-10-05 13:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1cc7a2a11d00

Merge


Changeset: 3cfd05b2219a
Author:    amurillo
Date:      2012-10-05 13:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3cfd05b2219a

Added tag hs25-b04 for changeset 1cc7a2a11d00

! .hgtags

Changeset: 0cc77f9b31ad
Author:    katleman
Date:      2012-10-11 09:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0cc77f9b31ad

Added tag jdk8-b60 for changeset 3cfd05b2219a

! .hgtags



From lana.steuck at oracle.com  Fri Oct 12 22:35:02 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 12 Oct 2012 22:35:02 +0000
Subject: hg: jdk8/tl/jaxp: 4 new changesets
Message-ID: <20121012223514.05DCF47344@hg.openjdk.java.net>

Changeset: af9e8b0f1900
Author:    katleman
Date:      2012-09-27 11:24 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/af9e8b0f1900

Added tag jdk8-b58 for changeset 1cb19abb3f7b

! .hgtags

Changeset: 2d1dff5310da
Author:    katleman
Date:      2012-10-04 14:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2d1dff5310da

Added tag jdk8-b59 for changeset af9e8b0f1900

! .hgtags

Changeset: 6b1db0b41d2f
Author:    katleman
Date:      2012-10-11 09:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6b1db0b41d2f

Added tag jdk8-b60 for changeset 2d1dff5310da

! .hgtags

Changeset: b545c99e4f5e
Author:    lana
Date:      2012-10-12 14:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b545c99e4f5e

Merge




From lana.steuck at oracle.com  Fri Oct 12 22:35:19 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 12 Oct 2012 22:35:19 +0000
Subject: hg: jdk8/tl/jaxws: 3 new changesets
Message-ID: <20121012223526.DD16847346@hg.openjdk.java.net>

Changeset: ae107401be11
Author:    katleman
Date:      2012-09-27 11:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/ae107401be11

Added tag jdk8-b58 for changeset cac4c3937063

! .hgtags

Changeset: 5c5a65ad5291
Author:    katleman
Date:      2012-10-04 14:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/5c5a65ad5291

Added tag jdk8-b59 for changeset ae107401be11

! .hgtags

Changeset: 97e5e74e2a34
Author:    katleman
Date:      2012-10-11 09:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/97e5e74e2a34

Added tag jdk8-b60 for changeset 5c5a65ad5291

! .hgtags



From lana.steuck at oracle.com  Fri Oct 12 22:36:28 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 12 Oct 2012 22:36:28 +0000
Subject: hg: jdk8/tl/jdk: 22 new changesets
Message-ID: <20121012224050.66FFF47347@hg.openjdk.java.net>

Changeset: abad1f417bd3
Author:    katleman
Date:      2012-09-27 11:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abad1f417bd3

Added tag jdk8-b58 for changeset d94613ac03d8

! .hgtags

Changeset: cec8fa02f156
Author:    katleman
Date:      2012-10-04 14:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cec8fa02f156

Added tag jdk8-b59 for changeset abad1f417bd3

! .hgtags

Changeset: 869519bc17ce
Author:    katleman
Date:      2012-10-11 09:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/869519bc17ce

Added tag jdk8-b60 for changeset cec8fa02f156

! .hgtags

Changeset: 4d8b411a2bc1
Author:    jgodinez
Date:      2012-09-25 09:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d8b411a2bc1

7158350: [macosx] Strange results of SwingUIText printing
Reviewed-by: bae, prr

! src/macosx/native/sun/awt/CTextPipe.m

Changeset: 5aff878baaf6
Author:    lana
Date:      2012-09-28 11:45 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5aff878baaf6

Merge

- make/common/Defs-embedded.gmk
- make/common/Release-embedded.gmk
- src/macosx/classes/sun/awt/SunToolkitSubclass.java
- src/share/classes/sun/management/LockDataConverter.java
- src/share/classes/sun/management/LockDataConverterMXBean.java
- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
- test/sun/misc/URLClassPath/ClassnameCharTest.sh
- test/sun/net/www/httptest/HttpServer.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java

Changeset: 8dd4cae72975
Author:    ceisserer
Date:      2012-10-01 13:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8dd4cae72975

7188093: closed/sun/java2d/pipe/ScaleQualityTest.java fails
Reviewed-by: prr, flar

! src/solaris/classes/sun/java2d/xr/XRDrawImage.java

Changeset: 89a1094e384f
Author:    bae
Date:      2012-10-05 16:21 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89a1094e384f

8000176: Need automated test for checking scale quality
Reviewed-by: prr, bae
Contributed-by: Vadim Pakhnushev <vadim.pakhnushev at oracle.com>

+ test/sun/java2d/pipe/InterpolationQualityTest.java

Changeset: 2bc7669294cc
Author:    lana
Date:      2012-10-08 15:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2bc7669294cc

Merge


Changeset: 9aa37a39cf39
Author:    zhouyx
Date:      2012-09-20 17:39 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9aa37a39cf39

7194184: JColorChooser swatch cannot accessed from keyboard
Reviewed-by: rupashka, alexsch

! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java
+ test/javax/swing/JColorChooser/Test7194184.java

Changeset: 4f519691520c
Author:    vkarnauk
Date:      2012-09-20 17:55 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4f519691520c

7123767: Wrong tooltip location in Multi-Monitor configurations
Reviewed-by: rupashka

! src/share/classes/javax/swing/ToolTipManager.java
+ test/javax/swing/ToolTipManager/7123767/bug7123767.java

Changeset: adddc599e551
Author:    alexsch
Date:      2012-09-21 13:48 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/adddc599e551

7199180: [macosx] Dead keys handling for input methods
Reviewed-by: kizune, anthony

! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
! src/macosx/native/sun/awt/AWTEvent.m
! src/macosx/native/sun/awt/AWTView.m
+ test/java/awt/event/KeyEvent/DeadKey/DeadKeyMacOSXInputText.java

Changeset: 88048b34405e
Author:    leonidr
Date:      2012-09-24 15:25 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/88048b34405e

7124239: [macosx] sun.awt.SunToolkit.InfiniteLoop exception in realSync called from SwingTestHelper
Reviewed-by: anthony

! src/macosx/native/sun/awt/LWCToolkit.m
! src/macosx/native/sun/osxapp/NSApplicationAWT.h
! src/macosx/native/sun/osxapp/NSApplicationAWT.m

Changeset: d6cba7bfbb3d
Author:    leonidr
Date:      2012-09-24 18:24 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6cba7bfbb3d

7179349: [macosx] Java processes on Mac should not use default Apple icon
Reviewed-by: anthony

! make/sun/osxapp/Makefile
+ make/sun/osxapp/ToBin.java
! src/macosx/native/sun/osxapp/NSApplicationAWT.m
+ src/macosx/native/sun/osxapp/resource/icons/JavaApp.icns

Changeset: 39227bb92978
Author:    serb
Date:      2012-09-24 21:33 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39227bb92978

7160627: [macosx] TextArea has wrong initial size
7124213: [macosx] pack() does ignore size of a component; doesn't on the other platforms
Reviewed-by: anthony, art

! src/macosx/classes/sun/lwawt/LWCanvasPeer.java
! src/macosx/classes/sun/lwawt/LWCheckboxPeer.java
! src/macosx/classes/sun/lwawt/LWComponentPeer.java
! src/macosx/classes/sun/lwawt/LWContainerPeer.java
! src/macosx/classes/sun/lwawt/LWLabelPeer.java
! src/macosx/classes/sun/lwawt/LWListPeer.java
! src/macosx/classes/sun/lwawt/LWPanelPeer.java
! src/macosx/classes/sun/lwawt/LWScrollBarPeer.java
! src/macosx/classes/sun/lwawt/LWTextAreaPeer.java
! src/macosx/classes/sun/lwawt/LWTextComponentPeer.java
! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java
! src/macosx/classes/sun/lwawt/LWToolkit.java
+ test/java/awt/ScrollPane/ScrollPanePreferredSize/ScrollPanePreferredSize.java
+ test/java/awt/TextArea/TextAreaTwicePack/TextAreaTwicePack.java

Changeset: c8da47a4d441
Author:    alexsch
Date:      2012-09-26 18:59 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c8da47a4d441

7124515: [macosx] Test fail like 6366126 (ArrayIndexOutOfBoundException pressing ENTER after removing items)
Reviewed-by: serb, anthony

+ test/java/awt/List/EmptyListEventTest/EmptyListEventTest.java

Changeset: ad467dee852a
Author:    alexsch
Date:      2012-09-28 14:54 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad467dee852a

7197619: Using modifiers for the dead key detection on Windows
Reviewed-by: bagiras, leonidr

! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_Component.h

Changeset: 4b8bb77fdda9
Author:    lana
Date:      2012-09-28 10:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b8bb77fdda9

Merge

- make/common/Defs-embedded.gmk
- make/common/Release-embedded.gmk
- src/share/classes/sun/management/LockDataConverter.java
- src/share/classes/sun/management/LockDataConverterMXBean.java
- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
- test/sun/misc/URLClassPath/ClassnameCharTest.sh
- test/sun/net/www/httptest/HttpServer.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java

Changeset: 3ac112755bb5
Author:    bagiras
Date:      2012-10-03 21:01 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3ac112755bb5

7171412: awt Choice doesn't fire ItemStateChange when selecting item after select() call
Reviewed-by: art, denis

! src/macosx/native/sun/awt/InitIDs.m
! src/share/classes/java/awt/Choice.java
! src/solaris/native/sun/awt/initIDs.c
! src/windows/native/sun/windows/awt_Choice.cpp
! src/windows/native/sun/windows/awt_Choice.h
+ test/java/awt/Choice/ItemStateChangeTest/ItemStateChangeTest.java

Changeset: 27ee94051373
Author:    lana
Date:      2012-10-08 15:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27ee94051373

Merge


Changeset: d8581143e11d
Author:    lana
Date:      2012-10-08 15:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8581143e11d

Merge

- src/share/classes/sun/util/xml/XMLUtils.java
- src/share/test/pack200/pack.conf

Changeset: 61ddb3fd000a
Author:    lana
Date:      2012-10-11 16:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61ddb3fd000a

Merge

- src/share/classes/sun/util/xml/XMLUtils.java
- src/share/test/pack200/pack.conf

Changeset: e23f8e0a1d89
Author:    lana
Date:      2012-10-12 14:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e23f8e0a1d89

Merge




From mandy.chung at oracle.com  Fri Oct 12 22:43:34 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 Oct 2012 15:43:34 -0700
Subject: 8000685: (props) Properties.storeToXML/loadFromXML should only
	require UTF-8 and UTF-16 to be supported
In-Reply-To: <5077EEB1.30404@oracle.com>
References: <5077EEB1.30404@oracle.com>
Message-ID: <50789D16.7070409@oracle.com>

On 10/12/2012 3:19 AM, Alan Bateman wrote:
> ...
>
> The next step in this effort is dealing with the issue of arbitrary 
> encodings. The storeToXML method allows the encoding to be specified, 
> the loadFromXML method assumes that the implementation can decode the 
> stream and read the encoding declaration. The specification doesn't 
> make it clear how either method behaves with unrecognized encodings 
> and this is something that we need to fix in order to allow for 
> alternative implementations, in particular tiny parsers that might not 
> support more than a few.
>
> The webrev the proposed changes is here:
>
> http://cr.openjdk.java.net/~alanb/8000685/webrev/
>

This looks good to me.

> The proposal is that an implementation minimally supports UTF-8 and 
> UTF-16, which I think is consistent with the W3C XML specification [2].
>
> Based on a search of a large number of projects then it appears that 
> these methods aren't used very much so I don't think this will have 
> any significant impact. In addition the same set of encodings [ which 
> is not exactly the same set as Charsets.availableCharsets().keySet() ] 
> that works today will continue to work when the service provider that 
> uses JAXP is installed.
>
> In addition, to specifying the required encodings, I have also changed 
> both methods to specify that UnsupportedEncodingException may be 
> thrown. In the case of loadFromXML then this is the long standing 
> behavior anyway. In the case of storeToXML then the long standing 
> behavior is somewhat bizarre. If the method is invoked with an 
> unsupported encoding then the underlying Xalan code prints a warning 
> to System.out and changes the encoding under the covers to UTF-8. I've 
> submitted a bug on this oddity; in the mean-time I've added a check in 
> the platform provider to always fail for charsets that aren't recognized.

Good find.

Mandy



From lana.steuck at oracle.com  Fri Oct 12 22:44:23 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Fri, 12 Oct 2012 22:44:23 +0000
Subject: hg: jdk8/tl/langtools: 6 new changesets
Message-ID: <20121012224440.3214447348@hg.openjdk.java.net>

Changeset: f299927fc316
Author:    katleman
Date:      2012-09-27 11:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f299927fc316

Added tag jdk8-b58 for changeset 804a3fbc86e2

! .hgtags

Changeset: 3d2b98ffcb53
Author:    katleman
Date:      2012-10-04 14:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d2b98ffcb53

Added tag jdk8-b59 for changeset f299927fc316

! .hgtags

Changeset: 67f7408d935e
Author:    katleman
Date:      2012-10-11 09:50 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/67f7408d935e

Added tag jdk8-b60 for changeset 3d2b98ffcb53

! .hgtags

Changeset: aa3ef5c09b1b
Author:    lana
Date:      2012-10-08 15:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aa3ef5c09b1b

Merge


Changeset: 26020b247ad3
Author:    lana
Date:      2012-10-11 17:00 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/26020b247ad3

Merge


Changeset: 0d1818e9d4ae
Author:    lana
Date:      2012-10-12 14:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d1818e9d4ae

Merge




From rob.mckenna at oracle.com  Fri Oct 12 22:58:35 2012
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 12 Oct 2012 23:58:35 +0100
Subject: RFR: 8000817: Reinstate accidentally removed sleep() from
	ProcessBuilder/Basic.java
In-Reply-To: <CA+kOe0-C3RLJpJbGf+y3f9mu593w+eaZJCA3gLBKGavDo9dyiQ@mail.gmail.com>
References: <506CB1C3.5050009@oracle.com> <506D3D14.4070304@oracle.com>
	<CA+kOe09tLkDLa3jKb1Y2hnz6sY7LANyBMYFRmjFVgKU3tnmUUA@mail.gmail.com>
	<5071DC80.3080507@oracle.com>
	<CA+kOe08mRoVVXAR6K7j3PgDuNmiv+V=AkwxUoxAWcyTG+AXGqA@mail.gmail.com>
	<50734498.40100@oracle.com>
	<CA+kOe09RmETEA3xJJ7751hF5nCQ6L3oyONy10+syGYHzzzN0Tw@mail.gmail.com>
	<50782A14.1060701@oracle.com>
	<CA+kOe09=NiWhN3HFy5wUKBkP-dqvKCCYZHFgJAJYDtnEy1wNcw@mail.gmail.com>
	<50785C08.7050202@oracle.com>
	<CA+kOe0_EAyWSJbH50CEu+7Cm-ro3APqac5ZY47WDQE_dDXhKcQ@mail.gmail.com>
	<507865BB.5040006@oracle.com>
	<CA+kOe08k+RFzXsDbHmduZRinHmaJb=arqUY6064tCWOWKU-oxQ@mail.gmail.com>
	<50787B05.6060506@oracle.com>
	<CA+kOe0-C3RLJpJbGf+y3f9mu593w+eaZJCA3gLBKGavDo9dyiQ@mail.gmail.com>
Message-ID: <5078A09B.2070702@oracle.com>

The test passes. But as far as the race goes that may be a fluke. I'll 
add the sleep to be on the safe side. Thanks Martin,

     -Rob

On 12/10/12 23:20, Martin Buchholz wrote:
> Thanks, Rob.
>
> I'm OK with your webrev.02, and I'm OK with putting back a 10ms sleep, 
> if you want to also do that.  I'm not sure what happens on macosx or 
> windows - you might want to think about that.
>
> Martin
>
> On Fri, Oct 12, 2012 at 1:18 PM, Rob McKenna <rob.mckenna at oracle.com 
> <mailto:rob.mckenna at oracle.com>> wrote:
>
>     Sorry for not responding sooner, I was out for the evening.
>
>     I threw this fix into our test infrastructure (jprt) before I left
>     though, and I see it has passed.
>
>     http://cr.openjdk.java.net/~robm/8000817/webrev.02/
>     <http://cr.openjdk.java.net/%7Erobm/8000817/webrev.02/>
>
>     I'm a little unclear as to why you'd prefer to throw that away,
>     can you elaborate?
>
>     As ugly as a Thread.sleep(10) is, it hasn't historically been a
>     problem on platforms other than Solaris. Perhaps this in
>     combination with the stack hackery?
>
>     Let me know either way and I'll get it integrated sharpish! Thanks,
>
>         -Rob
>
>
>
>     On 12/10/12 19:54, Martin Buchholz wrote:
>>
>>
>>     On Fri, Oct 12, 2012 at 11:47 AM, Alan Bateman
>>     <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>>
>>         Checking for readBytes should be better but it might still be
>>         fragile because there isn't any guarantee that the thread is
>>         in the read syscall (although the window should be a lot
>>         smaller). Although none of us like using sleep, this may be a
>>         case where we need a short sleep to improve our chances.
>>
>>
>>     Yup.
>>
>>     Sure would be nice if we could see native methods in the
>>     stacktraces, kind of like this:
>>
>>        java.lang.Thread.State: RUNNABLE
>>     at (C/C++) __kernel_vsyscall( ())
>>     at (C/C++) readBytes( (jre/lib/i386/libjava.so))
>>     at (C/C++) Java_java_io_FileInputStream_readBytes(
>>     (jre/lib/i386/libjava.so))
>>     at java.io.FileInputStream.readBytes(Native Method)
>>
>
>



From mandy.chung at oracle.com  Fri Oct 12 22:59:27 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 Oct 2012 15:59:27 -0700
Subject: Please review: 7146552 LoggingMXBeanTest intermittent failure
In-Reply-To: <50784B91.40508@oracle.com>
References: <50784B91.40508@oracle.com>
Message-ID: <5078A0CF.2070501@oracle.com>

On 10/12/2012 9:55 AM, Jim Gish wrote:
> Please review 
> http://cr.openjdk.java.net/~jgish/Bug7146552-LoggingMXBeanTest-failure/ <http://cr.openjdk.java.net/%7Ejgish/Bug7146552-LoggingMXBeanTest-failure/> 
>
>
> The LoggingMXBeanTest has been intermittently failing because garbage 
> collection can cause the (weak) references to Logger instances to go 
> away.  LoggingMXBeanTest2 has the same issue, but no bug has (yet) 
> been filed against it.
>
> The fix is to simply make the Logger variables static so they don't 
> get gc'd.

Looks okay to me.   Like Alan said, you can use the same bug for both 
tests as it's the same issue.

I checked the nightly failure statistics and these 2 tests have been 
passing for some time.  Were you able to reproduce the intermittent 
failure (it may require to modify the test and force GC) and verify the 
fix?

I am not up to whether all logging tests have been audit if they may run 
into the same issue per the suggestion [2] ([1] was the thread reviewing 
a similar test bug fix).   It'd be good to look at all logging tests if 
you have the cycle.

Thanks
Mandy
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-November/008136.html
[2] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-November/008148.html


From jim.gish at oracle.com  Sat Oct 13 03:54:05 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Fri, 12 Oct 2012 20:54:05 -0700 (PDT)
Subject: Please review: 7146552 LoggingMXBeanTest intermittent failure
Message-ID: <5bfdf3da-cf76-4356-b4eb-7cf04cf581e7@default>

I was able to reproduce the failure rather easily although for some runs it took many thousands of iterations.  I reviewed all the logging tests in test/java/util/logging and it appears that only the two that I fixed have the problem.

Jim

----- Original Message -----
From: mandy.chung at oracle.com
To: jim.gish at oracle.com
Cc: core-libs-dev at openjdk.java.net
Sent: Friday, October 12, 2012 6:59:45 PM GMT -05:00 US/Canada Eastern
Subject: Re: Please review: 7146552 LoggingMXBeanTest intermittent failure

On 10/12/2012 9:55 AM, Jim Gish wrote:
> Please review 
> http://cr.openjdk.java.net/~jgish/Bug7146552-LoggingMXBeanTest-failure/ <http://cr.openjdk.java.net/%7Ejgish/Bug7146552-LoggingMXBeanTest-failure/> 
>
>
> The LoggingMXBeanTest has been intermittently failing because garbage 
> collection can cause the (weak) references to Logger instances to go 
> away.  LoggingMXBeanTest2 has the same issue, but no bug has (yet) 
> been filed against it.
>
> The fix is to simply make the Logger variables static so they don't 
> get gc'd.

Looks okay to me.   Like Alan said, you can use the same bug for both 
tests as it's the same issue.

I checked the nightly failure statistics and these 2 tests have been 
passing for some time.  Were you able to reproduce the intermittent 
failure (it may require to modify the test and force GC) and verify the 
fix?

I am not up to whether all logging tests have been audit if they may run 
into the same issue per the suggestion [2] ([1] was the thread reviewing 
a similar test bug fix).   It'd be good to look at all logging tests if 
you have the cycle.

Thanks
Mandy
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-November/008136.html
[2] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-November/008148.html


From mandy.chung at oracle.com  Sat Oct 13 06:13:54 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 Oct 2012 23:13:54 -0700
Subject: Please review: 7146552 LoggingMXBeanTest intermittent failure
In-Reply-To: <5bfdf3da-cf76-4356-b4eb-7cf04cf581e7@default>
References: <5bfdf3da-cf76-4356-b4eb-7cf04cf581e7@default>
Message-ID: <507906A2.4030206@oracle.com>

On 10/12/2012 8:54 PM, Jim Gish wrote:
> I was able to reproduce the failure rather easily although for some runs it took many thousands of iterations.  I reviewed all the logging tests in test/java/util/logging and it appears that only the two that I fixed have the problem.

Thanks for reviewing all the logging tests and making them reliable.

Mandy

> Jim
>
> ----- Original Message -----
> From: mandy.chung at oracle.com
> To: jim.gish at oracle.com
> Cc: core-libs-dev at openjdk.java.net
> Sent: Friday, October 12, 2012 6:59:45 PM GMT -05:00 US/Canada Eastern
> Subject: Re: Please review: 7146552 LoggingMXBeanTest intermittent failure
>
> On 10/12/2012 9:55 AM, Jim Gish wrote:
>> Please review
>> http://cr.openjdk.java.net/~jgish/Bug7146552-LoggingMXBeanTest-failure/<http://cr.openjdk.java.net/%7Ejgish/Bug7146552-LoggingMXBeanTest-failure/>
>>
>>
>> The LoggingMXBeanTest has been intermittently failing because garbage
>> collection can cause the (weak) references to Logger instances to go
>> away.  LoggingMXBeanTest2 has the same issue, but no bug has (yet)
>> been filed against it.
>>
>> The fix is to simply make the Logger variables static so they don't
>> get gc'd.
> Looks okay to me.   Like Alan said, you can use the same bug for both
> tests as it's the same issue.
>
> I checked the nightly failure statistics and these 2 tests have been
> passing for some time.  Were you able to reproduce the intermittent
> failure (it may require to modify the test and force GC) and verify the
> fix?
>
> I am not up to whether all logging tests have been audit if they may run
> into the same issue per the suggestion [2] ([1] was the thread reviewing
> a similar test bug fix).   It'd be good to look at all logging tests if
> you have the cycle.
>
> Thanks
> Mandy
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-November/008136.html
> [2]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-November/008148.html


From chris.hegarty at oracle.com  Sat Oct 13 06:49:35 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 13 Oct 2012 07:49:35 +0100
Subject: 8000685: (props) Properties.storeToXML/loadFromXML should only
	require UTF-8 and UTF-16 to be supported
In-Reply-To: <5077EEB1.30404@oracle.com>
References: <5077EEB1.30404@oracle.com>
Message-ID: <4DF21CF7-EAC3-442D-ACC6-B343BBEF83CB@oracle.com>

Changes Look fine. Nice test too.

-Chris

On 12 Oct 2012, at 11:19, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> 
> A few days ago we added a JDK private provider interface [1] to which the Properties loadFromXML and storeToXML methods will delegate. The motive as I mentioned is to allow for a smaller environments where JAXP might not be present (so motivated by both modules and the compact profiles work).
> 
> The next step in this effort is dealing with the issue of arbitrary encodings. The storeToXML method allows the encoding to be specified, the loadFromXML method assumes that the implementation can decode the stream and read the encoding declaration. The specification doesn't make it clear how either method behaves with unrecognized encodings and this is something that we need to fix in order to allow for alternative implementations, in particular tiny parsers that might not support more than a few.
> 
> The webrev the proposed changes is here:
> 
> http://cr.openjdk.java.net/~alanb/8000685/webrev/
> 
> The proposal is that an implementation minimally supports UTF-8 and UTF-16, which I think is consistent with the W3C XML specification [2].
> 
> Based on a search of a large number of projects then it appears that these methods aren't used very much so I don't think this will have any significant impact. In addition the same set of encodings [ which is not exactly the same set as Charsets.availableCharsets().keySet() ] that works today will continue to work when the service provider that uses JAXP is installed.
> 
> In addition, to specifying the required encodings, I have also changed both methods to specify that UnsupportedEncodingException may be thrown. In the case of loadFromXML then this is the long standing behavior anyway. In the case of storeToXML then the long standing behavior is somewhat bizarre. If the method is invoked with an unsupported encoding then the underlying Xalan code prints a warning to System.out and changes the encoding under the covers to UTF-8. I've submitted a bug on this oddity; in the mean-time I've added a check in the platform provider to always fail for charsets that aren't recognized.
> 
> -Alan.
> 
> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f65871e75fde
> [2] http://www.w3.org/TR/REC-xml/#charencoding


From alan.bateman at oracle.com  Sat Oct 13 09:16:08 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 13 Oct 2012 09:16:08 +0000
Subject: hg: jdk8/tl/jdk: 7146552: java/util/logging/LoggingMXBeanTest.java
	failing intermittently
Message-ID: <20121013091652.5534847359@hg.openjdk.java.net>

Changeset: ff641c5b329b
Author:    jgish
Date:      2012-10-13 10:15 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff641c5b329b

7146552: java/util/logging/LoggingMXBeanTest.java failing intermittently
Reviewed-by: alanb, mchung

! test/java/util/logging/LoggingMXBeanTest.java
! test/java/util/logging/LoggingMXBeanTest2.java



From peter.levart at gmail.com  Sat Oct 13 09:21:32 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 13 Oct 2012 11:21:32 +0200
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <50788464.3020503@oracle.com>
References: <507863DC.706@gmx.de>
	<507867E7.9010103@oracle.com>	<1350071279.6532.140661139990653.4285F2F2@webmail.messagingengine.com>	<507879C9.2050106@oracle.com>
	<50788229.2080900@gmx.de> <50788464.3020503@oracle.com>
Message-ID: <5079329C.1090400@gmail.com>

One way to do it without state in encoder is 1st as suggested to have 
the 'endOfStream' flag and in addition when new-line breaks are 
requested, to only encode "full lines" at each invocation. So If one 
wants to use this line-breakage feature he/she must make sure that there 
is enough space (line_size+2 at worst) left in destination buffer to do 
any encoding or the encoder will not do anything (return 0 or false).

Regards, Peter

On 10/12/2012 10:58 PM, Xueming Shen wrote:
>
> Yes, I'm trying to figure out where to have this  position info stored...
>
> On 10/12/2012 01:48 PM, Michael Schierl wrote:
>> Am 12.10.2012 22:12, schrieb Xueming Shen:
>>> Hi,
>>>
>>> It appears to be possible to do something like
>>>
>>> boolean de/encode(ByteBuffer src, ByteBuffer dst);
>>>
>>> returns true if all remaining bytes in src are en/decoded, false, 
>>> the dst
>>> is not big enough for all output bytes, the src.position() will be 
>>> advanced
>>> to the position of next un-en/decoded byte, dst.position() will be 
>>> updated
>>> accordingly as well.
>>>
>>> to avoid the en/decoder to hold an internal state.
>> If it was unclear, that was what I tried to suggest. I thought you
>> refered to the automatic adding of newlines when you said you'd need
>> internal state (although that state is small enough - how many encoded
>> bytes remaining before adding the next newline - so that it might be
>> possible to pass it as a parameter, too). I'm not sure how important
>> that adding of newlines really is (in all cases where I was guilty of
>> using sun.misc.Base64Encoder, I always replaced them out after
>> encoding), so maybe the ByteBuffer API could live without it.
>>
>> Note that without an explicit end of stream flag, it might not be easily
>> possible to encode the last block - if you have a 16 byte buffer with 14
>> bytes filled, you cannot be sure whether you can encode the last two
>> bytes to XYZ= because it is end of stream or you have to wait for the
>> next byte. An option without the flag might be to assume when the input
>> is less than 3 bytes that it is the end of the stream. But I doubt it
>> will make the API easier to understand or use. :-)
>>
>>
>> Regards,
>>
>>
>> Michael
>



From peter.levart at gmail.com  Sat Oct 13 09:32:51 2012
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 13 Oct 2012 11:32:51 +0200
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5079329C.1090400@gmail.com>
References: <507863DC.706@gmx.de>
	<507867E7.9010103@oracle.com>	<1350071279.6532.140661139990653.4285F2F2@webmail.messagingengine.com>	<507879C9.2050106@oracle.com>
	<50788229.2080900@gmx.de> <50788464.3020503@oracle.com>
	<5079329C.1090400@gmail.com>
Message-ID: <50793543.8000908@gmail.com>

On 10/13/2012 11:21 AM, Peter Levart wrote:
> One way to do it without state in encoder is 1st as suggested to have 
> the 'endOfStream' flag and in addition when new-line breaks are 
> requested, to only encode "full lines" at each invocation. So If one 
> wants to use this line-breakage feature he/she must make sure that 
> there is enough space (line_size+2 at worst) left in destination buffer
...and (forgot to add) enough bytes remaining in source buffer or the 
endOfStream==true...
> to do any encoding or the encoder will not do anything (return 0 or 
> false).
>
> Regards, Peter
>
> On 10/12/2012 10:58 PM, Xueming Shen wrote:
>>
>> Yes, I'm trying to figure out where to have this  position info 
>> stored...
>>
>> On 10/12/2012 01:48 PM, Michael Schierl wrote:
>>> Am 12.10.2012 22:12, schrieb Xueming Shen:
>>>> Hi,
>>>>
>>>> It appears to be possible to do something like
>>>>
>>>> boolean de/encode(ByteBuffer src, ByteBuffer dst);
>>>>
>>>> returns true if all remaining bytes in src are en/decoded, false, 
>>>> the dst
>>>> is not big enough for all output bytes, the src.position() will be 
>>>> advanced
>>>> to the position of next un-en/decoded byte, dst.position() will be 
>>>> updated
>>>> accordingly as well.
>>>>
>>>> to avoid the en/decoder to hold an internal state.
>>> If it was unclear, that was what I tried to suggest. I thought you
>>> refered to the automatic adding of newlines when you said you'd need
>>> internal state (although that state is small enough - how many encoded
>>> bytes remaining before adding the next newline - so that it might be
>>> possible to pass it as a parameter, too). I'm not sure how important
>>> that adding of newlines really is (in all cases where I was guilty of
>>> using sun.misc.Base64Encoder, I always replaced them out after
>>> encoding), so maybe the ByteBuffer API could live without it.
>>>
>>> Note that without an explicit end of stream flag, it might not be 
>>> easily
>>> possible to encode the last block - if you have a 16 byte buffer 
>>> with 14
>>> bytes filled, you cannot be sure whether you can encode the last two
>>> bytes to XYZ= because it is end of stream or you have to wait for the
>>> next byte. An option without the flag might be to assume when the input
>>> is less than 3 bytes that it is the end of the stream. But I doubt it
>>> will make the API easier to understand or use. :-)
>>>
>>>
>>> Regards,
>>>
>>>
>>> Michael
>>
>



From fuyou001 at gmail.com  Sat Oct 13 10:44:25 2012
From: fuyou001 at gmail.com (fuyou)
Date: Sat, 13 Oct 2012 18:44:25 +0800
Subject: about JavaOne2012 Finding and Solving Java Deadlocks
Message-ID: <CAE=739u=NjFmOpdQyxPhsFAUhp5kt4+Pz1Z+e7PD4dyXqtKC0g@mail.gmail.com>

hi all

I  am very interested in session of  HOL6500 - Finding and Solving Java
Deadlocks(JavaOne 2012) .how can i watch video or download  slides.

Thanks!

-- 
   =============================================

  fuyou001
Best Regards


From Roger.Riggs at Oracle.com  Sat Oct 13 15:20:42 2012
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Sat, 13 Oct 2012 11:20:42 -0400
Subject: Reviewer needed: 6282196 There should be Math.mod(number, modulo)
	methods
In-Reply-To: <CACBEn46xV9ewQ4efwooWaX=wwa+24gtGtGCj24Wiwx_OTahwuQ@mail.gmail.com>
References: <50758497.104@oracle.com>
	<CACBEn46xV9ewQ4efwooWaX=wwa+24gtGtGCj24Wiwx_OTahwuQ@mail.gmail.com>
Message-ID: <507986CA.1060004@Oracle.com>

Thanks for pointing out that omission.
I will fix the spec and the tests to note the special case as
described for the division operator in the JLS.

The other result returning MAX_VALUE from floorDiv(Integer.MIN_VALUE, -1)
does not seem any more beneficial.

Thanks, Roger


On 10/10/2012 12:12 PM, Eamonn McManus wrote:
> One edge case: the spec for floorDiv implies that
> floorDiv(Integer.MIN_VALUE, -1) should be Integer.MAX_VALUE but I
> believe the code produces Integer.MIN_VALUE. EIther the spec or the
> code should be fixed.
>
> ?amonn
>
>
> 2012/10/10 Roger Riggs <Roger.Riggs at oracle.com>:
>> A reviewer is needed for:
>>
>> 6282196 There should be Math.mod(number, modulo) methods
>>
>> The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/
>>
>> Thanks, Roger



From Roger.Riggs at Oracle.com  Sat Oct 13 16:21:24 2012
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Sat, 13 Oct 2012 12:21:24 -0400
Subject: Reviewer needed: 6282196 There should be Math.mod(number, modulo)
	methods
In-Reply-To: <507766F6.7020906@oracle.com>
References: <50758497.104@oracle.com> <507766F6.7020906@oracle.com>
Message-ID: <50799504.6060305@Oracle.com>

Thanks for the comments and suggestions from Eamonn, Joe, and Bruce.
The updates add the suggested text and note the special case for 
floorDiv(MIN_VALUE/-1).

Updated webrev:

     http://cr.openjdk.java.net/~rriggs/6282196.5/

Roger


On 10/11/2012 08:40 PM, Joseph Darcy wrote:
> Hi Roger,
>
> The changes look fine.  However, I suggest adding an explanatory note 
> along the lines of "Normal integer division operates under the round 
> to zero rounding mode (truncation).  This operation instead acts under 
> the round to negative infinity (floor) rounding mode. The floor 
> rounding mode gives different results than truncation when the exact 
> result is negative."
>
> Thanks,
>
> -Joe
>
> On 10/10/2012 7:22 AM, Roger Riggs wrote:
>> A reviewer is needed for:
>>
>> 6282196 There should be Math.mod(number, modulo) methods
>>
>> The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/
>>
>> Thanks, Roger
>



From steve.sides at oracle.com  Fri Oct 12 17:58:40 2012
From: steve.sides at oracle.com (Steve Sides)
Date: Fri, 12 Oct 2012 10:58:40 -0700
Subject: Heads up: large sets of copyright year updates going into jdk8/tl/jdk
Message-ID: <50785A50.9090407@oracle.com>

Hi All,
This is a heads up notice, all files in jdk repositories which have been 
updated in 2012, and have not had the copyright year updated, are now 
doing so.  All other repositories have completed this chore and we've 
saved this largest for last.   Individually, each of these changes is 
trivial to update the copyright year in the copyright header, however, 
there are many of them.

A first push to jdk8/tl over the weekend will update 2000+ files.  Once 
this is in master and down in jdk8/awt,  the script will run again to 
update the remaining 1000 or so files.

Once these first large pushes are completed, periodic updates through 
til GA should be of a much smaller size and much easier to deal with.

-steve







From xueming.shen at oracle.com  Sat Oct 13 17:21:47 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sat, 13 Oct 2012 10:21:47 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5077BAE7.7000009@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com> <5077BAE7.7000009@oracle.com>
Message-ID: <5079A32B.7050006@oracle.com>


With moving some code piece around (moved those lookup table into 
En/Decoder)
and some array access code tuning (with the hope of eliminating the 
array boundary
access) in encode0(), it appears the hotspot now can better optimize the 
decoder
loop for the -server mode for encoding. decode0 also get 10% +boost with 
simply
moving in the lookup table.

The latest version is at (decode0() vs decode1())

http://cr.openjdk.java.net/~sherman/4235519/Base64.java

The latest scores is at

http://cr.openjdk.java.net/~sherman/4235519/score2

(compared to http://cr.openjdk.java.net/~sherman/4235519/score1)

-Sherman


On 10/11/12 11:38 PM, Xueming Shen wrote:
>
>> On 10/11/2012 02:43 AM, Stephen Colebourne wrote:
>>
>>> There are lots of other public base 64 implementations to test/check 
>>> against.
>>> http://commons.apache.org/net/api-3.1/org/apache/commons/net/util/Base64.html 
>>>
>>> http://www.cs.berkeley.edu/~jonah/bc/org/bouncycastle/util/encoders/Base64.html 
>>>
>>> http://migbase64.sourceforge.net/  (claims to be fast)
>>
>
> I did a quick performance check against migbase64 with the basic 
> base64 de/encoding
> using this non-scientific benchmark.
> http://cr.openjdk.java.net/~sherman/4235519/PermBase64.java
>
> Here is the scores
> http://cr.openjdk.java.net/~sherman/4235519/scores
>
> It's a tie, j.u.Base64 wins the decoding, but needs some work on 
> encoding side.
>
> java -server PermBase64 200000 50
>  j.u.Base64.encode() : 1390212
>   migBase64.encode() : 720517
>  j.u.Base64.decode() : 1200642
>   migBase64.decode() : 2070015
>
> java -server PermBase64 200000 100
>  j.u.Base64.encode() : 1239407
>   migBase64.encode() : 740404
>  j.u.Base64.decode() : 1257092
>   migBase64.decode() : 2012910
>
> java -server PermBase64 200000 1000
>  j.u.Base64.encode() : 1062212
>   migBase64.encode() : 657342
>  j.u.Base64.decode() : 1133740
>   migBase64.decode() : 1930612
>
> java -client PermBase64 200000 50
>  j.u.Base64.encode() : 961331
>   migBase64.encode() : 875635
>  j.u.Base64.decode() : 1528790
>   migBase64.decode() : 2188473
>
> java -client PermBase64 200000 100
>  j.u.Base64.encode() : 966453
>   migBase64.encode() : 858082
>  j.u.Base64.decode() : 1459159
>   migBase64.decode() : 2115045
>
> java -client PermBase64 200000 1000
>  j.u.Base64.encode() : 954401
>   migBase64.encode() : 854903
>  j.u.Base64.decode() : 1444603
>   migBase64.decode() : 2038865
>
>



From xueming.shen at oracle.com  Sat Oct 13 17:23:51 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sat, 13 Oct 2012 10:23:51 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5079A32B.7050006@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com> <5077BAE7.7000009@oracle.com>
	<5079A32B.7050006@oracle.com>
Message-ID: <5079A3A7.9030803@oracle.com>

On 10/13/12 10:21 AM, Xueming Shen wrote:
>
> With moving some code piece around (moved those lookup table into 
> En/Decoder)
> and some array access code tuning (with the hope of eliminating the 
> array boundary
> access) in encode0(), it appears the hotspot now can better optimize 
> the decoder
> loop for the -server mode for encoding. decode0 also get 10% +boost 
> with simply
> moving in the lookup table.
>
> The latest version is at (decode0() vs decode1())
--> encode0() vs encode1())

encode0 is the latest/faster one. encode1 is the one in webrev.

-Sherman

>
> http://cr.openjdk.java.net/~sherman/4235519/Base64.java
>
> The latest scores is at
>
> http://cr.openjdk.java.net/~sherman/4235519/score2
>
> (compared to http://cr.openjdk.java.net/~sherman/4235519/score1)
>
> -Sherman
>
>
> On 10/11/12 11:38 PM, Xueming Shen wrote:
>>
>>> On 10/11/2012 02:43 AM, Stephen Colebourne wrote:
>>>
>>>> There are lots of other public base 64 implementations to 
>>>> test/check against.
>>>> http://commons.apache.org/net/api-3.1/org/apache/commons/net/util/Base64.html 
>>>>
>>>> http://www.cs.berkeley.edu/~jonah/bc/org/bouncycastle/util/encoders/Base64.html 
>>>>
>>>> http://migbase64.sourceforge.net/  (claims to be fast)
>>>
>>
>> I did a quick performance check against migbase64 with the basic 
>> base64 de/encoding
>> using this non-scientific benchmark.
>> http://cr.openjdk.java.net/~sherman/4235519/PermBase64.java
>>
>> Here is the scores
>> http://cr.openjdk.java.net/~sherman/4235519/scores
>>
>> It's a tie, j.u.Base64 wins the decoding, but needs some work on 
>> encoding side.
>>
>> java -server PermBase64 200000 50
>>  j.u.Base64.encode() : 1390212
>>   migBase64.encode() : 720517
>>  j.u.Base64.decode() : 1200642
>>   migBase64.decode() : 2070015
>>
>> java -server PermBase64 200000 100
>>  j.u.Base64.encode() : 1239407
>>   migBase64.encode() : 740404
>>  j.u.Base64.decode() : 1257092
>>   migBase64.decode() : 2012910
>>
>> java -server PermBase64 200000 1000
>>  j.u.Base64.encode() : 1062212
>>   migBase64.encode() : 657342
>>  j.u.Base64.decode() : 1133740
>>   migBase64.decode() : 1930612
>>
>> java -client PermBase64 200000 50
>>  j.u.Base64.encode() : 961331
>>   migBase64.encode() : 875635
>>  j.u.Base64.decode() : 1528790
>>   migBase64.decode() : 2188473
>>
>> java -client PermBase64 200000 100
>>  j.u.Base64.encode() : 966453
>>   migBase64.encode() : 858082
>>  j.u.Base64.decode() : 1459159
>>   migBase64.decode() : 2115045
>>
>> java -client PermBase64 200000 1000
>>  j.u.Base64.encode() : 954401
>>   migBase64.encode() : 854903
>>  j.u.Base64.decode() : 1444603
>>   migBase64.decode() : 2038865
>>
>>
>



From forax at univ-mlv.fr  Sun Oct 14 16:19:16 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 14 Oct 2012 18:19:16 +0200
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
Message-ID: <507AE604.3060204@univ-mlv.fr>

Hi everybody,
CloneNotSupportedException is thrown when a developer calls 
Object.clone() and forget to mark the current object as Cloneable. 
Because it's clearly a developer error, CloneNotSupportedException 
should be a subtype of RuntimeException and not of Exception.

I believe this change is backward compatible because RuntimeException is 
a subclass of Exception,
so I propose to first change CloneNotSupportedException to extends 
RuntimeException.

diff -r ff641c5b329b 
src/share/classes/java/lang/CloneNotSupportedException.java
--- a/src/share/classes/java/lang/CloneNotSupportedException.java Sat 
Oct 13 10:15:57 2012 +0100
+++ b/src/share/classes/java/lang/CloneNotSupportedException.java Sun 
Oct 14 18:16:35 2012 +0200
@@ -42,7 +42,7 @@
   */

  public
-class CloneNotSupportedException extends Exception {
+class CloneNotSupportedException extends RuntimeException {
      private static final long serialVersionUID = 5195511250079656443L;

      /**


And then to clean up the whole JDK (in several patches) to remove all 
the unnecessary
try/catch like the one in by example ArrayList.clone()

     public Object clone() {
         try {
             ArrayList<?> v = (ArrayList<?>) super.clone();
             v.elementData = Arrays.copyOf(elementData, size);
             v.modCount = 0;
             return v;
         } catch (CloneNotSupportedException e) {
             // this shouldn't happen, since we are Cloneable
             throw new InternalError(e);
         }
     }

will become

     public Object clone() {
         ArrayList<?> v = (ArrayList<?>) super.clone();
         v.elementData = Arrays.copyOf(elementData, size);
         v.modCount = 0;
         return v;
     }


cheers,
R?mi



From paul.sandoz at oracle.com  Sun Oct 14 16:54:03 2012
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Sun, 14 Oct 2012 17:54:03 +0100
Subject: Reviewer and committer request for 7198496
In-Reply-To: <50785EFB.3000903@oracle.com>
References: <EF2EE6B7-9301-48D8-95AE-B994106CD55C@oracle.com>
	<506C3288.6040907@gmail.com>
	<F3923CC9-C293-4EDD-B2EB-1A07C0BA155D@oracle.com>
	<506C3AF4.2010007@oracle.com>
	<37A14496-560E-4D60-938C-C30974293660@oracle.com>
	<506CBD22.7090107@oracle.com>
	<639E3CC6-09A8-4551-A146-AF218593C1F6@oracle.com>
	<506D457E.8030309@oracle.com>
	<3AC99BDE-5EC9-4F18-B1E6-64FF5C6093FB@oracle.com>
	<506D583F.2010808@oracle.com>
	<6C8D595A-765D-4555-BD63-C244D1B043E8@oracle.com>
	<506D66DF.9050505@oracle.com>
	<A2809AFE-1C5F-4DA3-8A92-C41E89F12720@oracle.com>
	<506D9125.7020103@oracle.com>
	<0B9A0CA9-2104-4F88-9D31-9C6FB1DF689C@oracle.com>
	<50785EFB.3000903@oracle.com>
Message-ID: <B0E9D2E7-B0F1-4EA1-81F3-5FE6D5AB60C9@oracle.com>

On Oct 12, 2012, at 7:18 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> Paul - where did we leave this one? We got side tracked on how the TCCL is specified but I think we concluded that the proposed change to ServiceLoader was okay, is that right?
> 

Yes, i think so.

Paul.

From mike.duigou at oracle.com  Sun Oct 14 18:06:54 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Sun, 14 Oct 2012 11:06:54 -0700
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
In-Reply-To: <507AE604.3060204@univ-mlv.fr>
References: <507AE604.3060204@univ-mlv.fr>
Message-ID: <0D07F1F9-7DFD-4C09-9793-540FDB45CB32@oracle.com>

Seems reasonable to me at first glance. I am still reviewing this but wanted to add two clarify notes:

- This change means that CloneNotSupportedException is no longer a checked exception. This change is generally harmless.

- Cases where CloneNotSupportedException is being caught were probably added because it was a checked exception. They can be safely left in.

Mike


On Oct 14 2012, at 09:19 , Remi Forax wrote:

> Hi everybody,
> CloneNotSupportedException is thrown when a developer calls Object.clone() and forget to mark the current object as Cloneable. Because it's clearly a developer error, CloneNotSupportedException should be a subtype of RuntimeException and not of Exception.
> 
> I believe this change is backward compatible because RuntimeException is a subclass of Exception,
> so I propose to first change CloneNotSupportedException to extends RuntimeException.
> 
> diff -r ff641c5b329b src/share/classes/java/lang/CloneNotSupportedException.java
> --- a/src/share/classes/java/lang/CloneNotSupportedException.java Sat Oct 13 10:15:57 2012 +0100
> +++ b/src/share/classes/java/lang/CloneNotSupportedException.java Sun Oct 14 18:16:35 2012 +0200
> @@ -42,7 +42,7 @@
>  */
> 
> public
> -class CloneNotSupportedException extends Exception {
> +class CloneNotSupportedException extends RuntimeException {
>     private static final long serialVersionUID = 5195511250079656443L;
> 
>     /**
> 
> 
> And then to clean up the whole JDK (in several patches) to remove all the unnecessary
> try/catch like the one in by example ArrayList.clone()
> 
>    public Object clone() {
>        try {
>            ArrayList<?> v = (ArrayList<?>) super.clone();
>            v.elementData = Arrays.copyOf(elementData, size);
>            v.modCount = 0;
>            return v;
>        } catch (CloneNotSupportedException e) {
>            // this shouldn't happen, since we are Cloneable
>            throw new InternalError(e);
>        }
>    }
> 
> will become
> 
>    public Object clone() {
>        ArrayList<?> v = (ArrayList<?>) super.clone();
>        v.elementData = Arrays.copyOf(elementData, size);
>        v.modCount = 0;
>        return v;
>    }
> 
> 
> cheers,
> R?mi
> 



From brian.goetz at oracle.com  Sun Oct 14 21:31:06 2012
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 14 Oct 2012 22:31:06 +0100
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
In-Reply-To: <0D07F1F9-7DFD-4C09-9793-540FDB45CB32@oracle.com>
References: <507AE604.3060204@univ-mlv.fr>
	<0D07F1F9-7DFD-4C09-9793-540FDB45CB32@oracle.com>
Message-ID: <733694CA-6EAC-4966-9851-5A91020A9486@oracle.com>

I believe this change is not source compatible.  If a user says:

try { clone() } 
catch (RuntimeException e) { ... }
catch (CloneNotSupportedException e1) { .... }

this compiles today but would fail to compile under this change.  

On Oct 14, 2012, at 7:06 PM, Mike Duigou wrote:

> Seems reasonable to me at first glance. I am still reviewing this but wanted to add two clarify notes:
> 
> - This change means that CloneNotSupportedException is no longer a checked exception. This change is generally harmless.
> 
> - Cases where CloneNotSupportedException is being caught were probably added because it was a checked exception. They can be safely left in.
> 
> Mike
> 
> 
> On Oct 14 2012, at 09:19 , Remi Forax wrote:
> 
>> Hi everybody,
>> CloneNotSupportedException is thrown when a developer calls Object.clone() and forget to mark the current object as Cloneable. Because it's clearly a developer error, CloneNotSupportedException should be a subtype of RuntimeException and not of Exception.
>> 
>> I believe this change is backward compatible because RuntimeException is a subclass of Exception,
>> so I propose to first change CloneNotSupportedException to extends RuntimeException.
>> 
>> diff -r ff641c5b329b src/share/classes/java/lang/CloneNotSupportedException.java
>> --- a/src/share/classes/java/lang/CloneNotSupportedException.java Sat Oct 13 10:15:57 2012 +0100
>> +++ b/src/share/classes/java/lang/CloneNotSupportedException.java Sun Oct 14 18:16:35 2012 +0200
>> @@ -42,7 +42,7 @@
>> */
>> 
>> public
>> -class CloneNotSupportedException extends Exception {
>> +class CloneNotSupportedException extends RuntimeException {
>>    private static final long serialVersionUID = 5195511250079656443L;
>> 
>>    /**
>> 
>> 
>> And then to clean up the whole JDK (in several patches) to remove all the unnecessary
>> try/catch like the one in by example ArrayList.clone()
>> 
>>   public Object clone() {
>>       try {
>>           ArrayList<?> v = (ArrayList<?>) super.clone();
>>           v.elementData = Arrays.copyOf(elementData, size);
>>           v.modCount = 0;
>>           return v;
>>       } catch (CloneNotSupportedException e) {
>>           // this shouldn't happen, since we are Cloneable
>>           throw new InternalError(e);
>>       }
>>   }
>> 
>> will become
>> 
>>   public Object clone() {
>>       ArrayList<?> v = (ArrayList<?>) super.clone();
>>       v.elementData = Arrays.copyOf(elementData, size);
>>       v.modCount = 0;
>>       return v;
>>   }
>> 
>> 
>> cheers,
>> R?mi
>> 
> 



From eamonn at mcmanus.net  Sun Oct 14 21:41:12 2012
From: eamonn at mcmanus.net (Eamonn McManus)
Date: Sun, 14 Oct 2012 14:41:12 -0700
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
In-Reply-To: <733694CA-6EAC-4966-9851-5A91020A9486@oracle.com>
References: <507AE604.3060204@univ-mlv.fr>
	<0D07F1F9-7DFD-4C09-9793-540FDB45CB32@oracle.com>
	<733694CA-6EAC-4966-9851-5A91020A9486@oracle.com>
Message-ID: <CACBEn45enO7KAuL8AQ884SPC5NkO9sAX2wa_-gRhR-5CpS+oTw@mail.gmail.com>

Brian Goetz <brian.goetz at oracle.com> writes:
> try { clone() }
> catch (RuntimeException e) { ... }
> catch (CloneNotSupportedException e1) { .... }

I guess that means the change is not binary compatible either, since before
the change the second catch block would run but after it the first one
would.

?amonn


2012/10/14 Brian Goetz <brian.goetz at oracle.com>

> I believe this change is not source compatible.  If a user says:
>
> try { clone() }
> catch (RuntimeException e) { ... }
> catch (CloneNotSupportedException e1) { .... }
>
> this compiles today but would fail to compile under this change.
>
> On Oct 14, 2012, at 7:06 PM, Mike Duigou wrote:
>
> > Seems reasonable to me at first glance. I am still reviewing this but
> wanted to add two clarify notes:
> >
> > - This change means that CloneNotSupportedException is no longer a
> checked exception. This change is generally harmless.
> >
> > - Cases where CloneNotSupportedException is being caught were probably
> added because it was a checked exception. They can be safely left in.
> >
> > Mike
> >
> >
> > On Oct 14 2012, at 09:19 , Remi Forax wrote:
> >
> >> Hi everybody,
> >> CloneNotSupportedException is thrown when a developer calls
> Object.clone() and forget to mark the current object as Cloneable. Because
> it's clearly a developer error, CloneNotSupportedException should be a
> subtype of RuntimeException and not of Exception.
> >>
> >> I believe this change is backward compatible because RuntimeException
> is a subclass of Exception,
> >> so I propose to first change CloneNotSupportedException to extends
> RuntimeException.
> >>
> >> diff -r ff641c5b329b
> src/share/classes/java/lang/CloneNotSupportedException.java
> >> --- a/src/share/classes/java/lang/CloneNotSupportedException.java Sat
> Oct 13 10:15:57 2012 +0100
> >> +++ b/src/share/classes/java/lang/CloneNotSupportedException.java Sun
> Oct 14 18:16:35 2012 +0200
> >> @@ -42,7 +42,7 @@
> >> */
> >>
> >> public
> >> -class CloneNotSupportedException extends Exception {
> >> +class CloneNotSupportedException extends RuntimeException {
> >>    private static final long serialVersionUID = 5195511250079656443L;
> >>
> >>    /**
> >>
> >>
> >> And then to clean up the whole JDK (in several patches) to remove all
> the unnecessary
> >> try/catch like the one in by example ArrayList.clone()
> >>
> >>   public Object clone() {
> >>       try {
> >>           ArrayList<?> v = (ArrayList<?>) super.clone();
> >>           v.elementData = Arrays.copyOf(elementData, size);
> >>           v.modCount = 0;
> >>           return v;
> >>       } catch (CloneNotSupportedException e) {
> >>           // this shouldn't happen, since we are Cloneable
> >>           throw new InternalError(e);
> >>       }
> >>   }
> >>
> >> will become
> >>
> >>   public Object clone() {
> >>       ArrayList<?> v = (ArrayList<?>) super.clone();
> >>       v.elementData = Arrays.copyOf(elementData, size);
> >>       v.modCount = 0;
> >>       return v;
> >>   }
> >>
> >>
> >> cheers,
> >> R?mi
> >>
> >
>
>


From alan.bateman at oracle.com  Sun Oct 14 22:06:58 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sun, 14 Oct 2012 22:06:58 +0000
Subject: hg: jdk8/tl/jdk: 7194449: String resources for Key Tool and Policy
	Tool should be in their respective packages
Message-ID: <20121014220728.6528947369@hg.openjdk.java.net>

Changeset: fe28e0b035e7
Author:    sflores
Date:      2012-10-14 22:58 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe28e0b035e7

7194449: String resources for Key Tool and Policy Tool should be in their respective packages
Reviewed-by: alanb, weijun, mullan

! make/common/Release.gmk
! make/launchers/Makefile
! make/sun/security/tools/Makefile
! makefiles/CompileLaunchers.gmk
! makefiles/CreateJars.gmk
- src/share/classes/sun/security/tools/CertAndKeyGen.java
- src/share/classes/sun/security/tools/JarSigner.java
- src/share/classes/sun/security/tools/JarSignerResources.java
- src/share/classes/sun/security/tools/JarSignerResources_ja.java
- src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java
! src/share/classes/sun/security/tools/KeyStoreUtil.java
- src/share/classes/sun/security/tools/KeyTool.java
- src/share/classes/sun/security/tools/TimestampedSigner.java
+ src/share/classes/sun/security/tools/jarsigner/Main.java
+ src/share/classes/sun/security/tools/jarsigner/Resources.java
+ src/share/classes/sun/security/tools/jarsigner/Resources_ja.java
+ src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java
+ src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java
+ src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java
+ src/share/classes/sun/security/tools/keytool/Main.java
+ src/share/classes/sun/security/tools/keytool/Resources.java
+ src/share/classes/sun/security/tools/keytool/Resources_de.java
+ src/share/classes/sun/security/tools/keytool/Resources_es.java
+ src/share/classes/sun/security/tools/keytool/Resources_fr.java
+ src/share/classes/sun/security/tools/keytool/Resources_it.java
+ src/share/classes/sun/security/tools/keytool/Resources_ja.java
+ src/share/classes/sun/security/tools/keytool/Resources_ko.java
+ src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java
+ src/share/classes/sun/security/tools/keytool/Resources_sv.java
+ src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java
+ src/share/classes/sun/security/tools/keytool/Resources_zh_HK.java
+ src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java
! src/share/classes/sun/security/tools/policytool/PolicyTool.java
+ src/share/classes/sun/security/tools/policytool/Resources.java
+ src/share/classes/sun/security/tools/policytool/Resources_de.java
+ src/share/classes/sun/security/tools/policytool/Resources_es.java
+ src/share/classes/sun/security/tools/policytool/Resources_fr.java
+ src/share/classes/sun/security/tools/policytool/Resources_it.java
+ src/share/classes/sun/security/tools/policytool/Resources_ja.java
+ src/share/classes/sun/security/tools/policytool/Resources_ko.java
+ src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java
+ src/share/classes/sun/security/tools/policytool/Resources_sv.java
+ src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java
+ src/share/classes/sun/security/tools/policytool/Resources_zh_HK.java
+ src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java
! src/share/classes/sun/security/util/Resources.java
! src/share/classes/sun/security/util/Resources_de.java
! src/share/classes/sun/security/util/Resources_es.java
! src/share/classes/sun/security/util/Resources_fr.java
! src/share/classes/sun/security/util/Resources_it.java
! src/share/classes/sun/security/util/Resources_ja.java
! src/share/classes/sun/security/util/Resources_ko.java
! src/share/classes/sun/security/util/Resources_pt_BR.java
! src/share/classes/sun/security/util/Resources_sv.java
! src/share/classes/sun/security/util/Resources_zh_CN.java
! src/share/classes/sun/security/util/Resources_zh_TW.java
! test/sun/security/pkcs12/PKCS12SameKeyId.java
! test/sun/security/tools/jarsigner/JarSigningNonAscii.java
! test/sun/security/tools/jarsigner/LargeJarEntry.java
! test/sun/security/tools/keytool/CloseFile.java
! test/sun/security/tools/keytool/KeyToolTest.java
! test/sun/security/tools/keytool/NewSize7.java
! test/sun/security/tools/keytool/StartDateTest.java
! test/sun/security/tools/keytool/UnknownAndUnparseable.java
! test/sun/security/tools/keytool/autotest.sh
! test/sun/security/tools/keytool/standard.sh
! test/sun/security/util/Resources/Format.java
! test/sun/security/util/Resources/NewNamesFormat.java
! test/sun/security/util/Resources/NewResourcesNames.java
! test/sun/security/x509/AlgorithmId/NonStandardNames.java



From david.holmes at oracle.com  Sun Oct 14 22:34:32 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Oct 2012 08:34:32 +1000
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
In-Reply-To: <507AE604.3060204@univ-mlv.fr>
References: <507AE604.3060204@univ-mlv.fr>
Message-ID: <507B3DF8.1030902@oracle.com>

Remi,

This ship has sailed you can't recall it. CloneNotSupportedException is 
a checked exception and needs to remain so for source and binary 
compatibility.

David

On 15/10/2012 2:19 AM, Remi Forax wrote:
> Hi everybody,
> CloneNotSupportedException is thrown when a developer calls
> Object.clone() and forget to mark the current object as Cloneable.
> Because it's clearly a developer error, CloneNotSupportedException
> should be a subtype of RuntimeException and not of Exception.
>
> I believe this change is backward compatible because RuntimeException is
> a subclass of Exception,
> so I propose to first change CloneNotSupportedException to extends
> RuntimeException.
>
> diff -r ff641c5b329b
> src/share/classes/java/lang/CloneNotSupportedException.java
> --- a/src/share/classes/java/lang/CloneNotSupportedException.java Sat
> Oct 13 10:15:57 2012 +0100
> +++ b/src/share/classes/java/lang/CloneNotSupportedException.java Sun
> Oct 14 18:16:35 2012 +0200
> @@ -42,7 +42,7 @@
> */
>
> public
> -class CloneNotSupportedException extends Exception {
> +class CloneNotSupportedException extends RuntimeException {
> private static final long serialVersionUID = 5195511250079656443L;
>
> /**
>
>
> And then to clean up the whole JDK (in several patches) to remove all
> the unnecessary
> try/catch like the one in by example ArrayList.clone()
>
> public Object clone() {
> try {
> ArrayList<?> v = (ArrayList<?>) super.clone();
> v.elementData = Arrays.copyOf(elementData, size);
> v.modCount = 0;
> return v;
> } catch (CloneNotSupportedException e) {
> // this shouldn't happen, since we are Cloneable
> throw new InternalError(e);
> }
> }
>
> will become
>
> public Object clone() {
> ArrayList<?> v = (ArrayList<?>) super.clone();
> v.elementData = Arrays.copyOf(elementData, size);
> v.modCount = 0;
> return v;
> }
>
>
> cheers,
> R?mi
>


From rob.mckenna at oracle.com  Mon Oct 15 02:23:18 2012
From: rob.mckenna at oracle.com (rob.mckenna at oracle.com)
Date: Mon, 15 Oct 2012 02:23:18 +0000
Subject: hg: jdk8/tl/jdk: 8000817: Reinstate accidentally removed sleep() from
	ProcessBuilder/Basic.java
Message-ID: <20121015022331.216EF4736C@hg.openjdk.java.net>

Changeset: 7055257a25c4
Author:    robm
Date:      2012-10-15 03:26 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7055257a25c4

8000817: Reinstate accidentally removed sleep() from ProcessBuilder/Basic.java
Reviewed-by: alanb, martin

! test/java/lang/ProcessBuilder/Basic.java



From david.holmes at oracle.com  Mon Oct 15 03:09:26 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Oct 2012 13:09:26 +1000
Subject: Please review: 7146552 LoggingMXBeanTest intermittent failure
In-Reply-To: <50784B91.40508@oracle.com>
References: <50784B91.40508@oracle.com>
Message-ID: <507B7E66.1070206@oracle.com>

On 13/10/2012 2:55 AM, Jim Gish wrote:
> Please review
> http://cr.openjdk.java.net/~jgish/Bug7146552-LoggingMXBeanTest-failure/
> <http://cr.openjdk.java.net/%7Ejgish/Bug7146552-LoggingMXBeanTest-failure/>
>
> The LoggingMXBeanTest has been intermittently failing because garbage
> collection can cause the (weak) references to Logger instances to go
> away. LoggingMXBeanTest2 has the same issue, but no bug has (yet) been
> filed against it.
>
> The fix is to simply make the Logger variables static so they don't get
> gc'd.

Ouch! Most programmers would naively think that a local variable that is 
still in scope is a strong ref! - not realizing that the JIT may reduce 
its lifetime (or elide it completely) and so allow the logger to be 
collected.

David

> Thanks,
> Jim
>


From zhouyx at linux.vnet.ibm.com  Mon Oct 15 03:50:12 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Mon, 15 Oct 2012 11:50:12 +0800
Subject: TreeMap.putAll has undocumented behavior which has different side
	effect based on parameter
Message-ID: <CAOo=rxXbP+braQHYCky_OYumhWJn+_B-oDHcSYf-CwiYgByfKg@mail.gmail.com>

Hi all,

    It is found TreeMap.putAll method may or may not invoke
TreeMap.put method based on parameter. If TreeMap is extended and the
put method is override, it may behave different from what is expected.
  This behavior should be documented.

    The following test case tries to putAll a hashamp and a treemap in
a class extended from TreeMap.

/////////////// Testcase ////////////////////
/*
 * Copyright (c) 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
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/*
 * Portions Copyright (c) 2012 IBM Corporation
 */

import java.util.HashMap;
import java.util.TreeMap;

public class TreeMapTest {

    static class MyTreeMap extends TreeMap<String, String> {
        public String put(String key, String value) {
            System.out.println("Override put is invoked in MyTreeMap");
            return super.put(key, value);
        }
    }


    public static void main(String[] args) {
        TreeMap<String, String> tm = new TreeMap<>();
        tm.put("treeMap", "treeMap");

        HashMap<String, String> hm = new HashMap<>();
        hm.put("hashMap", "hashMap");

        System.out.println("Test started, the override put method in
MyTreeMap " +
        		            "is not invoked when putAll a TreeMap, but " +
        		            "it is invoked when putAll a HashMap");

        TreeMap<String, String> treeMap = new MyTreeMap();
        TreeMap<String, String> treeMap2 = new MyTreeMap();

        System.out.println("putAll treemap:");
        treeMap.putAll(tm);
        System.out.println("putAll hashmap:");
        treeMap2.putAll(hm);
    }

}




-- 
Best Regards,
Sean Chou

From david.holmes at oracle.com  Mon Oct 15 06:45:17 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Oct 2012 16:45:17 +1000
Subject: TreeMap.putAll has undocumented behavior which has different
	side effect based on parameter
In-Reply-To: <CAOo=rxXbP+braQHYCky_OYumhWJn+_B-oDHcSYf-CwiYgByfKg@mail.gmail.com>
References: <CAOo=rxXbP+braQHYCky_OYumhWJn+_B-oDHcSYf-CwiYgByfKg@mail.gmail.com>
Message-ID: <507BB0FD.1030607@oracle.com>

Hi Sean,

On 15/10/2012 1:50 PM, Sean Chou wrote:
> Hi all,
>
>      It is found TreeMap.putAll method may or may not invoke
> TreeMap.put method based on parameter. If TreeMap is extended and the
> put method is override, it may behave different from what is expected.
>    This behavior should be documented.

TreeMap.putAll doesn't state that it invokes put:

"Copies all of the mappings from the specified map to this map. These 
mappings replace any mappings that this map had for any of the keys 
currently in the specified map."

---

As you can tell from the implementation, if dealing with a compatible 
SortedMap there are more efficient ways to add the entries than 
iterating through and doing a put().

Further, as has been discussed in the past, when a method, like 
Map.putAll is defined as "The effect of this call is equivalent to that 
of calling put(k, v) for each mapping ... in the specified map" it does 
not mean that the implementation has to actually call put() for each item.

David
-----

>
>      The following test case tries to putAll a hashamp and a treemap in
> a class extended from TreeMap.
>
> /////////////// Testcase ////////////////////
> /*
>   * Copyright (c) 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
>   * under the terms of the GNU General Public License version 2 only, as
>   * published by the Free Software Foundation.
>   *
>   * This code is distributed in the hope that it will be useful, but WITHOUT
>   * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>   * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>   * version 2 for more details (a copy is included in the LICENSE file that
>   * accompanied this code).
>   *
>   * You should have received a copy of the GNU General Public License version
>   * 2 along with this work; if not, write to the Free Software Foundation,
>   * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>   *
>   * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>   * or visit www.oracle.com if you need additional information or have any
>   * questions.
>   */
>
> /*
>   * Portions Copyright (c) 2012 IBM Corporation
>   */
>
> import java.util.HashMap;
> import java.util.TreeMap;
>
> public class TreeMapTest {
>
>      static class MyTreeMap extends TreeMap<String, String>  {
>          public String put(String key, String value) {
>              System.out.println("Override put is invoked in MyTreeMap");
>              return super.put(key, value);
>          }
>      }
>
>
>      public static void main(String[] args) {
>          TreeMap<String, String>  tm = new TreeMap<>();
>          tm.put("treeMap", "treeMap");
>
>          HashMap<String, String>  hm = new HashMap<>();
>          hm.put("hashMap", "hashMap");
>
>          System.out.println("Test started, the override put method in
> MyTreeMap " +
>          		            "is not invoked when putAll a TreeMap, but " +
>          		            "it is invoked when putAll a HashMap");
>
>          TreeMap<String, String>  treeMap = new MyTreeMap();
>          TreeMap<String, String>  treeMap2 = new MyTreeMap();
>
>          System.out.println("putAll treemap:");
>          treeMap.putAll(tm);
>          System.out.println("putAll hashmap:");
>          treeMap2.putAll(hm);
>      }
>
> }
>
>
>
>


From forax at univ-mlv.fr  Mon Oct 15 07:27:16 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 15 Oct 2012 09:27:16 +0200
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
In-Reply-To: <507B3DF8.1030902@oracle.com>
References: <507AE604.3060204@univ-mlv.fr> <507B3DF8.1030902@oracle.com>
Message-ID: <507BBAD4.9080807@univ-mlv.fr>

On 10/15/2012 12:34 AM, David Holmes wrote:
> Remi,
>
> This ship has sailed you can't recall it. CloneNotSupportedException 
> is a checked exception and needs to remain so for source and binary 
> compatibility.

yes, it burns into flame :)

too bad, I'm pretty sure that no-one (until now) use a catch that mix 
runtime exception
and clone not supported exception, people tend to catch exceptions 
always in the same way,
but I have no proof.

>
> David

R?mi

>
> On 15/10/2012 2:19 AM, Remi Forax wrote:
>> Hi everybody,
>> CloneNotSupportedException is thrown when a developer calls
>> Object.clone() and forget to mark the current object as Cloneable.
>> Because it's clearly a developer error, CloneNotSupportedException
>> should be a subtype of RuntimeException and not of Exception.
>>
>> I believe this change is backward compatible because RuntimeException is
>> a subclass of Exception,
>> so I propose to first change CloneNotSupportedException to extends
>> RuntimeException.
>>
>> diff -r ff641c5b329b
>> src/share/classes/java/lang/CloneNotSupportedException.java
>> --- a/src/share/classes/java/lang/CloneNotSupportedException.java Sat
>> Oct 13 10:15:57 2012 +0100
>> +++ b/src/share/classes/java/lang/CloneNotSupportedException.java Sun
>> Oct 14 18:16:35 2012 +0200
>> @@ -42,7 +42,7 @@
>> */
>>
>> public
>> -class CloneNotSupportedException extends Exception {
>> +class CloneNotSupportedException extends RuntimeException {
>> private static final long serialVersionUID = 5195511250079656443L;
>>
>> /**
>>
>>
>> And then to clean up the whole JDK (in several patches) to remove all
>> the unnecessary
>> try/catch like the one in by example ArrayList.clone()
>>
>> public Object clone() {
>> try {
>> ArrayList<?> v = (ArrayList<?>) super.clone();
>> v.elementData = Arrays.copyOf(elementData, size);
>> v.modCount = 0;
>> return v;
>> } catch (CloneNotSupportedException e) {
>> // this shouldn't happen, since we are Cloneable
>> throw new InternalError(e);
>> }
>> }
>>
>> will become
>>
>> public Object clone() {
>> ArrayList<?> v = (ArrayList<?>) super.clone();
>> v.elementData = Arrays.copyOf(elementData, size);
>> v.modCount = 0;
>> return v;
>> }
>>
>>
>> cheers,
>> R?mi
>>



From joel.franck at oracle.com  Mon Oct 15 10:28:33 2012
From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Mon, 15 Oct 2012 12:28:33 +0200
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
In-Reply-To: <507B3DF8.1030902@oracle.com>
References: <507AE604.3060204@univ-mlv.fr> <507B3DF8.1030902@oracle.com>
Message-ID: <507BE551.9090607@oracle.com>

On 10/15/2012 12:34 AM, David Holmes wrote:
 > Remi,
 >
 > This ship has sailed you can't recall it. CloneNotSupportedException 
 > is a checked exception and needs to remain so for source and binary
 > compatibility.
 >

I see how this is source incompatible and also behaviorally incompatible 
in a few cases, but how is this binary incompatible?

cheers
/Joel

>
> David
>
> On 15/10/2012 2:19 AM, Remi Forax wrote:
>> Hi everybody,
>> CloneNotSupportedException is thrown when a developer calls
>> Object.clone() and forget to mark the current object as Cloneable.
>> Because it's clearly a developer error, CloneNotSupportedException
>> should be a subtype of RuntimeException and not of Exception.
>>
>> I believe this change is backward compatible because RuntimeException is
>> a subclass of Exception,
>> so I propose to first change CloneNotSupportedException to extends
>> RuntimeException.
>>
>> diff -r ff641c5b329b
>> src/share/classes/java/lang/CloneNotSupportedException.java
>> --- a/src/share/classes/java/lang/CloneNotSupportedException.java Sat
>> Oct 13 10:15:57 2012 +0100
>> +++ b/src/share/classes/java/lang/CloneNotSupportedException.java Sun
>> Oct 14 18:16:35 2012 +0200
>> @@ -42,7 +42,7 @@
>> */
>>
>> public
>> -class CloneNotSupportedException extends Exception {
>> +class CloneNotSupportedException extends RuntimeException {
>> private static final long serialVersionUID = 5195511250079656443L;
>>
>> /**
>>
>>
>> And then to clean up the whole JDK (in several patches) to remove all
>> the unnecessary
>> try/catch like the one in by example ArrayList.clone()
>>
>> public Object clone() {
>> try {
>> ArrayList<?> v = (ArrayList<?>) super.clone();
>> v.elementData = Arrays.copyOf(elementData, size);
>> v.modCount = 0;
>> return v;
>> } catch (CloneNotSupportedException e) {
>> // this shouldn't happen, since we are Cloneable
>> throw new InternalError(e);
>> }
>> }
>>
>> will become
>>
>> public Object clone() {
>> ArrayList<?> v = (ArrayList<?>) super.clone();
>> v.elementData = Arrays.copyOf(elementData, size);
>> v.modCount = 0;
>> return v;
>> }
>>
>>
>> cheers,
>> R?mi
>>


From Alan.Bateman at oracle.com  Mon Oct 15 10:56:16 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 15 Oct 2012 03:56:16 -0700 (PDT)
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
In-Reply-To: <507BE551.9090607@oracle.com>
References: <507AE604.3060204@univ-mlv.fr> <507B3DF8.1030902@oracle.com>
	<507BE551.9090607@oracle.com>
Message-ID: <507BEBD0.1080009@oracle.com>

On 15/10/2012 11:28, Joel Borggr?n-Franck wrote:
> On 10/15/2012 12:34 AM, David Holmes wrote:
> > Remi,
> >
> > This ship has sailed you can't recall it. CloneNotSupportedException 
> > is a checked exception and needs to remain so for source and binary
> > compatibility.
> >
>
> I see how this is source incompatible and also behaviorally 
> incompatible in a few cases, but how is this binary incompatible? 
I think you're right as there wouldn't be a linkage error.

This thread reminds of Joe Darcy's classic blog on compatibility kinds:

https://blogs.oracle.com/darcy/entry/kinds_of_compatibility



From david.holmes at oracle.com  Mon Oct 15 11:47:31 2012
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Oct 2012 21:47:31 +1000
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
In-Reply-To: <507BEBD0.1080009@oracle.com>
References: <507AE604.3060204@univ-mlv.fr> <507B3DF8.1030902@oracle.com>
	<507BE551.9090607@oracle.com> <507BEBD0.1080009@oracle.com>
Message-ID: <507BF7D3.40401@oracle.com>

On 15/10/2012 8:56 PM, Alan Bateman wrote:
> On 15/10/2012 11:28, Joel Borggr?n-Franck wrote:
>> On 10/15/2012 12:34 AM, David Holmes wrote:
>> > Remi,
>> >
>> > This ship has sailed you can't recall it. CloneNotSupportedException
>> > is a checked exception and needs to remain so for source and binary
>> > compatibility.
>> >
>>
>> I see how this is source incompatible and also behaviorally
>> incompatible in a few cases, but how is this binary incompatible?
> I think you're right as there wouldn't be a linkage error.
>
> This thread reminds of Joe Darcy's classic blog on compatibility kinds:
>
> https://blogs.oracle.com/darcy/entry/kinds_of_compatibility

Yes I stand corrected - no "binary compatability" issue.

David



From jeroen at sumatra.nl  Mon Oct 15 11:48:19 2012
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Mon, 15 Oct 2012 11:48:19 +0000
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
In-Reply-To: <507BBAD4.9080807@univ-mlv.fr>
References: <507AE604.3060204@univ-mlv.fr>
	<507B3DF8.1030902@oracle.com>,<507BBAD4.9080807@univ-mlv.fr>
Message-ID: <D395C7FC996C944EBD345AB36164F4B26539AF15@woyla.sumatrasoftware.com>

The solution is actually pretty easy. Just deprecate Object.clone() and add a new method to Object:

protected final native Object shallowClone();

It doesn't require the useless Cloneable interface and doesn't conflate shallow and deep cloning.

(This is similar to .NET's Object.MemberwiseClone().)

Note that this means that any non-final class is cloneable, BUT THAT IS ALREADY THE  CASE even though some people want to pretend otherwise.

Regards,
Jeroen

________________________________________
From: core-libs-dev-bounces at openjdk.java.net [core-libs-dev-bounces at openjdk.java.net] on behalf of Remi Forax [forax at univ-mlv.fr]
Sent: Monday, October 15, 2012 9:27 AM
To: David Holmes
Cc: core-libs-dev at openjdk.java.net
Subject: Re: CloneNotSupportedException should extends RuntimeException not     Exception

On 10/15/2012 12:34 AM, David Holmes wrote:
> Remi,
>
> This ship has sailed you can't recall it. CloneNotSupportedException
> is a checked exception and needs to remain so for source and binary
> compatibility.

yes, it burns into flame :)

too bad, I'm pretty sure that no-one (until now) use a catch that mix
runtime exception
and clone not supported exception, people tend to catch exceptions
always in the same way,
but I have no proof.

>
> David

R?mi

>
> On 15/10/2012 2:19 AM, Remi Forax wrote:
>> Hi everybody,
>> CloneNotSupportedException is thrown when a developer calls
>> Object.clone() and forget to mark the current object as Cloneable.
>> Because it's clearly a developer error, CloneNotSupportedException
>> should be a subtype of RuntimeException and not of Exception.
>>
>> I believe this change is backward compatible because RuntimeException is
>> a subclass of Exception,
>> so I propose to first change CloneNotSupportedException to extends
>> RuntimeException.
>>
>> diff -r ff641c5b329b
>> src/share/classes/java/lang/CloneNotSupportedException.java
>> --- a/src/share/classes/java/lang/CloneNotSupportedException.java Sat
>> Oct 13 10:15:57 2012 +0100
>> +++ b/src/share/classes/java/lang/CloneNotSupportedException.java Sun
>> Oct 14 18:16:35 2012 +0200
>> @@ -42,7 +42,7 @@
>> */
>>
>> public
>> -class CloneNotSupportedException extends Exception {
>> +class CloneNotSupportedException extends RuntimeException {
>> private static final long serialVersionUID = 5195511250079656443L;
>>
>> /**
>>
>>
>> And then to clean up the whole JDK (in several patches) to remove all
>> the unnecessary
>> try/catch like the one in by example ArrayList.clone()
>>
>> public Object clone() {
>> try {
>> ArrayList<?> v = (ArrayList<?>) super.clone();
>> v.elementData = Arrays.copyOf(elementData, size);
>> v.modCount = 0;
>> return v;
>> } catch (CloneNotSupportedException e) {
>> // this shouldn't happen, since we are Cloneable
>> throw new InternalError(e);
>> }
>> }
>>
>> will become
>>
>> public Object clone() {
>> ArrayList<?> v = (ArrayList<?>) super.clone();
>> v.elementData = Arrays.copyOf(elementData, size);
>> v.modCount = 0;
>> return v;
>> }
>>
>>
>> cheers,
>> R?mi
>>

From vincent.x.ryan at oracle.com  Mon Oct 15 14:27:31 2012
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Mon, 15 Oct 2012 15:27:31 +0100
Subject: Request for review: 8000487: Java JNDI connection library on ldap
	conn is not honoring configured timeout
In-Reply-To: <507C14E2.204@oracle.com>
References: <50772A98.5020105@oracle.com> <507C14E2.204@oracle.com>
Message-ID: <1B07A168-F501-48BF-9F87-4A10E060EC2E@oracle.com>

Those changes look good Rob.
Thanks.


On 11 Oct 2012, at 21:22, Rob McKenna wrote:
> Hi folks,
> 
> Seemingly when using ldap's simple authentication we perform a 
> readReply. (an operation which is subject to
> com.sun.jndi.ldap.read.timeout as opposed to 
> com.sun.jndi.ldap.connect.timeout) This makes an apparent connection to 
> a faulty host appear to take much longer than the specified connect 
> timeout. The proposed solution is to set the read timeout value to the 
> same value as the connect for the duration of the authentication call.
> 
> In addition to this I've merged the testcase for this issue with the 
> testcases for other ldap timeout issues.
> 
> http://cr.openjdk.java.net/~robm/8000487/webrev.01/ 
> <http://cr.openjdk.java.net/%7Erobm/8000487/webrev.01/>
> 
> Thanks,
> 
>     -Rob
> 
> 
> 
> 



From forax at univ-mlv.fr  Mon Oct 15 17:08:47 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 15 Oct 2012 19:08:47 +0200
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
In-Reply-To: <D395C7FC996C944EBD345AB36164F4B26539AF15@woyla.sumatrasoftware.com>
References: <507AE604.3060204@univ-mlv.fr> <507B3DF8.1030902@oracle.com>,
	<507BBAD4.9080807@univ-mlv.fr>
	<D395C7FC996C944EBD345AB36164F4B26539AF15@woyla.sumatrasoftware.com>
Message-ID: <507C431F.5010404@univ-mlv.fr>

Hi Jeroen,

On 10/15/2012 01:48 PM, Jeroen Frijters wrote:
> The solution is actually pretty easy. Just deprecate Object.clone() and add a new method to Object:
>
> protected final native Object shallowClone();
>
> It doesn't require the useless Cloneable interface and doesn't conflate shallow and deep cloning.
>
> (This is similar to .NET's Object.MemberwiseClone().)
>
> Note that this means that any non-final class is cloneable, BUT THAT IS ALREADY THE  CASE even though some people want to pretend otherwise.

To avoid collisions it can be a static method of Object or j.u.Objects
that uses generics to be nicely typed.

static native <T> T shallowClone(T object);

and I disagree about Cloneable, while a non-final class is by definition 
mutable, it doesn't mean
that a non final class can be cloned because it may share some states 
that should not be shared,
at least without the consent from the author the class.

The other nice property is that any cloneable class will be publicly 
cloneable.

I also believe that the checkcast generated by javac before calling 
shallowClone can be removed
by the JIT, currently this cast is not removed when you call clone.

>
> Regards,
> Jeroen

regards,
R?mi



From joe.darcy at oracle.com  Mon Oct 15 17:10:24 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 15 Oct 2012 10:10:24 -0700
Subject: Reviewer needed: 6282196 There should be Math.mod(number, modulo)
	methods
In-Reply-To: <50799504.6060305@Oracle.com>
References: <50758497.104@oracle.com> <507766F6.7020906@oracle.com>
	<50799504.6060305@Oracle.com>
Message-ID: <507C4380.1060101@oracle.com>

Looks fine Roger; thanks,

-Joe

On 10/13/2012 9:21 AM, Roger Riggs wrote:
> Thanks for the comments and suggestions from Eamonn, Joe, and Bruce.
> The updates add the suggested text and note the special case for 
> floorDiv(MIN_VALUE/-1).
>
> Updated webrev:
>
>     http://cr.openjdk.java.net/~rriggs/6282196.5/
>
> Roger
>
>
> On 10/11/2012 08:40 PM, Joseph Darcy wrote:
>> Hi Roger,
>>
>> The changes look fine.  However, I suggest adding an explanatory note 
>> along the lines of "Normal integer division operates under the round 
>> to zero rounding mode (truncation).  This operation instead acts 
>> under the round to negative infinity (floor) rounding mode. The floor 
>> rounding mode gives different results than truncation when the exact 
>> result is negative."
>>
>> Thanks,
>>
>> -Joe
>>
>> On 10/10/2012 7:22 AM, Roger Riggs wrote:
>>> A reviewer is needed for:
>>>
>>> 6282196 There should be Math.mod(number, modulo) methods
>>>
>>> The webrev is: http://cr.openjdk.java.net/~rriggs/6282196.4/
>>>
>>> Thanks, Roger
>>
>



From jim.gish at oracle.com  Mon Oct 15 19:18:56 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Mon, 15 Oct 2012 15:18:56 -0400
Subject: RFR: 7159567 - inconsistent configuration of MemoryHandler
In-Reply-To: <50773C27.3050407@oracle.com>
References: <50637167.4060006@oracle.com> <5063BD8C.2010607@oracle.com>
	<50645D19.4050505@oracle.com> <5065F6DD.7010801@oracle.com>
	<5066176D.6040005@oracle.com> <50773C27.3050407@oracle.com>
Message-ID: <507C61A0.6080608@oracle.com>

Here's an updated webrev that fixes some javadoc syntax issues: 
http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/ 
<http://cr.openjdk.java.net/%7Ejgish/Bug7159567-set-logging-MemoryHandler/>

Thanks,
     Jim

On 10/11/2012 05:37 PM, Jim Gish wrote:
> Please review the updated changes at 
> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/
>
> I've changed as you've requested, added some additional tests, did 
> some better error handling in the case of a MemoryHandler not 
> specifying a target (now throws RuntimeException with an appropriate 
> message instead of attempting to load a null class and throwing NPE).  
> I also corrected the copyrights, tested with JCK, all jdk_lang tests 
> and have submitted a JPRT job with core tests.
>
> I've forwarded a CCC request (separately) and will await its approval 
> and further review of this change.
>
> Thanks,
>     Jim
>
> On 09/28/2012 05:32 PM, Mandy Chung wrote:
>> On 9/28/2012 12:13 PM, Jim Gish wrote:
>>> I've re-spun the change with additional usage notes in the spec to 
>>> reflect the long-standing actual behavior.  Note that it doesn't 
>>> change the spec per se, as it was already stated in LogManager. This 
>>> change simply replicates that language with an example in each 
>>> *Handler class to make it easier to find.
>>>
>>
>> Thanks for looking into it.  This statement in LogManager does
>> specify the properties for handlers:
>>
>>   The properties for loggers and Handlers will have names starting
>>   with the dot-separated name for the handler or logger.
>>
>> Replicating that statement with an example is one way to do it.
>> Would it be clearer if the prefix of the properties referenced
>> in the bullet list is replaced from "java.util.logging" to
>> some kind of prefix - something like this:
>>
>>  *<b>Configuration:</b>
>>  * By default each<tt>ConsoleHandler</tt>  is initialized using the 
>> following
>>  *<tt>LogManager</tt>  configuration properties.  If properties are 
>> not defined
>>  * (or have invalid values) then the specified default values are used.
>>  *<ul>
>>  *<li>    <handler's classname>.level
>>  *        specifies the default level for the<tt>Handler</tt>
>>  *        (defaults to<tt>Level.INFO</tt>).
>>  ...<snip>
>>  *</ul>
>>  *
>>  * For example, the properties for {@code ConsoleHandler} would be:
>>  *     java.util.logging.ConsoleHandler.level=INFO
>>  * 
>> java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
>>  *
>>  * For a custom handler, e.g. com.foo.MyHandler, the properties would 
>> be:
>>  *     com.foo.MyHandler.level=INFO
>>  * com.foo.MyHandler.formatter=java.util.logging.SimpleFormatter
>>
>> This might add some clarity to the spec.
>>
>> This is a spec bug fix that I would suggest to file a CCC to
>> track for compatibility.  I would also suggest running the JCK
>> tests to find out if there is any regression due to this fix.
>>
>>
>>> The webrev, as posted at 
>>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/
>>
>> See my comment above w.r.t. the spec change.
>>
>> test/java/util/logging/MemoryHandler.java
>>   L27: "via via" typo
>>   L28: @run tag specifies the test name
>>        So it should be @run main/othervm MemoryHandler
>>
>>   L43: jtreg runs the test in a different working directory
>>   other than the test source.  So the test has to read
>>   the system property ("test.src") to determine the location
>>   of the properties file.  Typically, we will do this:
>>     String src = System.getProperty("test.src", ".);
>>     File   fname  = new File(src, LM_PROP_FNAME);
>>
>>   You don't need L44. You can reference LoggingDeadlock3.java test.
>>
>>   L51: this catch block to throw a RuntimeException doesn't seem
>>   necessary.  If NPE is thrown, the test will fail anyway.
>>
>>   One suggestion to the test is to test both cases (one with
>>   the specified target handler and one without).  You can
>>   define a custom target handler so that the test can verify
>>   if the expected one is used.  A simple handler to count
>>   the number of log messages will do the work.
>>
>> test/java/util/logging/MemoryHandlerTest.props
>>   I suggest to take out the comments and just keep the
>>   properties the test needs to make it easier to tell
>>   what's configured.
>>   Perhaps you should also specify
>>   java.util.logging.MemoryHandler.target to make sure
>>   that the custom handler with no target handler specified
>>   will not use j.u.l.MemoryHandler.target as the default.
>>
>> Mandy
>>
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From jeroen at sumatra.nl  Mon Oct 15 19:30:36 2012
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Mon, 15 Oct 2012 19:30:36 +0000
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
In-Reply-To: <507C431F.5010404@univ-mlv.fr>
References: <507AE604.3060204@univ-mlv.fr>
	<507B3DF8.1030902@oracle.com>,<507BBAD4.9080807@univ-mlv.fr>
	<D395C7FC996C944EBD345AB36164F4B26539AF15@woyla.sumatrasoftware.com>,
	<507C431F.5010404@univ-mlv.fr>
Message-ID: <D395C7FC996C944EBD345AB36164F4B26539C0ED@woyla.sumatrasoftware.com>

Hi R?mi,

The point about a non-final class being cloneable is simply that a base class can always implement Cloneable, so that interface is currently meaningless.

With the static method approach, the Cloneable interface becomes a valid way to opt in to that, but I see two downsides to the static method approach:

1. Once you allow your object to be cloneable, you can't prevent others from cloning your instances. So this pattern wouldn't work:

public Foo copy() {
  Foo theCopy = (Foo)shallowClone();
  theCopy.someArray = theCopy.someArray.clone();
  return theCopy;
}

2. The Cloneable interface check is an unnecessary perf hit. The admittedly ugly downcast in the above code can be easily optimized away.

The perf is not a showstopper, but 1. is in my opinion.

Regards,
Jeroen
________________________________________
From: Remi Forax [forax at univ-mlv.fr]
Sent: Monday, October 15, 2012 7:08 PM
To: Jeroen Frijters
Cc: David Holmes; core-libs-dev at openjdk.java.net
Subject: Re: CloneNotSupportedException should extends RuntimeException not Exception

Hi Jeroen,

On 10/15/2012 01:48 PM, Jeroen Frijters wrote:
> The solution is actually pretty easy. Just deprecate Object.clone() and add a new method to Object:
>
> protected final native Object shallowClone();
>
> It doesn't require the useless Cloneable interface and doesn't conflate shallow and deep cloning.
>
> (This is similar to .NET's Object.MemberwiseClone().)
>
> Note that this means that any non-final class is cloneable, BUT THAT IS ALREADY THE  CASE even though some people want to pretend otherwise.

To avoid collisions it can be a static method of Object or j.u.Objects
that uses generics to be nicely typed.

static native <T> T shallowClone(T object);

and I disagree about Cloneable, while a non-final class is by definition
mutable, it doesn't mean
that a non final class can be cloned because it may share some states
that should not be shared,
at least without the consent from the author the class.

The other nice property is that any cloneable class will be publicly
cloneable.

I also believe that the checkcast generated by javac before calling
shallowClone can be removed
by the JIT, currently this cast is not removed when you call clone.

>
> Regards,
> Jeroen

regards,
R?mi

From jeroen at sumatra.nl  Mon Oct 15 19:34:52 2012
From: jeroen at sumatra.nl (Jeroen Frijters)
Date: Mon, 15 Oct 2012 19:34:52 +0000
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
In-Reply-To: <D395C7FC996C944EBD345AB36164F4B26539C0ED@woyla.sumatrasoftware.com>
References: <507AE604.3060204@univ-mlv.fr>
	<507B3DF8.1030902@oracle.com>,<507BBAD4.9080807@univ-mlv.fr>
	<D395C7FC996C944EBD345AB36164F4B26539AF15@woyla.sumatrasoftware.com>,
	<507C431F.5010404@univ-mlv.fr>,
	<D395C7FC996C944EBD345AB36164F4B26539C0ED@woyla.sumatrasoftware.com>
Message-ID: <D395C7FC996C944EBD345AB36164F4B26539C125@woyla.sumatrasoftware.com>

I wrote:
>The point about a non-final class being cloneable is simply that a base class can always implement Cloneable, so that interface is currently meaningless.

Obviously that should read "... a derived class can always implement Cloneable..."

Regards,
Jeroen
________________________________________
From: core-libs-dev-bounces at openjdk.java.net [core-libs-dev-bounces at openjdk.java.net] on behalf of Jeroen Frijters [jeroen at sumatra.nl]
Sent: Monday, October 15, 2012 9:30 PM
To: Remi Forax
Cc: David Holmes; core-libs-dev at openjdk.java.net
Subject: RE: CloneNotSupportedException should extends RuntimeException not     Exception

Hi R?mi,

The point about a non-final class being cloneable is simply that a base class can always implement Cloneable, so that interface is currently meaningless.

With the static method approach, the Cloneable interface becomes a valid way to opt in to that, but I see two downsides to the static method approach:

1. Once you allow your object to be cloneable, you can't prevent others from cloning your instances. So this pattern wouldn't work:

public Foo copy() {
  Foo theCopy = (Foo)shallowClone();
  theCopy.someArray = theCopy.someArray.clone();
  return theCopy;
}

2. The Cloneable interface check is an unnecessary perf hit. The admittedly ugly downcast in the above code can be easily optimized away.

The perf is not a showstopper, but 1. is in my opinion.

Regards,
Jeroen
________________________________________
From: Remi Forax [forax at univ-mlv.fr]
Sent: Monday, October 15, 2012 7:08 PM
To: Jeroen Frijters
Cc: David Holmes; core-libs-dev at openjdk.java.net
Subject: Re: CloneNotSupportedException should extends RuntimeException not Exception

Hi Jeroen,

On 10/15/2012 01:48 PM, Jeroen Frijters wrote:
> The solution is actually pretty easy. Just deprecate Object.clone() and add a new method to Object:
>
> protected final native Object shallowClone();
>
> It doesn't require the useless Cloneable interface and doesn't conflate shallow and deep cloning.
>
> (This is similar to .NET's Object.MemberwiseClone().)
>
> Note that this means that any non-final class is cloneable, BUT THAT IS ALREADY THE  CASE even though some people want to pretend otherwise.

To avoid collisions it can be a static method of Object or j.u.Objects
that uses generics to be nicely typed.

static native <T> T shallowClone(T object);

and I disagree about Cloneable, while a non-final class is by definition
mutable, it doesn't mean
that a non final class can be cloned because it may share some states
that should not be shared,
at least without the consent from the author the class.

The other nice property is that any cloneable class will be publicly
cloneable.

I also believe that the checkcast generated by javac before calling
shallowClone can be removed
by the JIT, currently this cast is not removed when you call clone.

>
> Regards,
> Jeroen

regards,
R?mi

From rob.mckenna at oracle.com  Mon Oct 15 21:32:40 2012
From: rob.mckenna at oracle.com (rob.mckenna at oracle.com)
Date: Mon, 15 Oct 2012 21:32:40 +0000
Subject: hg: jdk8/tl/jdk: 8000487: Java JNDI connection library on ldap conn
	is not honoring configured timeout
Message-ID: <20121015213301.C26CB47388@hg.openjdk.java.net>

Changeset: c0736b62160e
Author:    robm
Date:      2012-10-15 22:34 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0736b62160e

8000487: Java JNDI connection library on ldap conn is not honoring configured timeout
Reviewed-by: vinnie

! src/share/classes/com/sun/jndi/ldap/Connection.java
! src/share/classes/com/sun/jndi/ldap/LdapClient.java
+ test/com/sun/jndi/ldap/LdapTimeoutTest.java
- test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java
- test/com/sun/jndi/ldap/ReadTimeoutTest.java



From mike.duigou at oracle.com  Mon Oct 15 21:50:27 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 15 Oct 2012 14:50:27 -0700
Subject: about JavaOne2012 Finding and Solving Java Deadlocks
In-Reply-To: <CAE=739u=NjFmOpdQyxPhsFAUhp5kt4+Pz1Z+e7PD4dyXqtKC0g@mail.gmail.com>
References: <CAE=739u=NjFmOpdQyxPhsFAUhp5kt4+Pz1Z+e7PD4dyXqtKC0g@mail.gmail.com>
Message-ID: <CF148525-7ECE-40EF-98D5-8237AC14DB43@oracle.com>

The session was a hands on lab so was not recorded that I can tell. 

Here's the official session page:

https://oracleus.activeevents.com/connect/search.ww?event=javaone#loadSearch-event=javaone&searchPhrase=&searchType=session&tc=0&sortBy=&p=&i%2811424%29=18653&i%2810050%29=&i%2810090%29=&i%2810092%29=&i%2811842%29=&i%2810086%29=

Some of the presenters are subscribers to this list. If they don't respond with the slides perhaps you can contact them.

Mike

On Oct 13 2012, at 03:44 , fuyou wrote:

> hi all
> 
> I  am very interested in session of  HOL6500 - Finding and Solving Java
> Deadlocks(JavaOne 2012) .how can i watch video or download  slides.
> 
> Thanks!
> 
> -- 
>   =============================================
> 
>  fuyou001
> Best Regards



From jonathan.gibbons at oracle.com  Tue Oct 16 00:08:34 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 16 Oct 2012 00:08:34 +0000
Subject: hg: jdk8/tl/langtools: 8000666: javadoc should write directly to
	Writer instead of composing strings
Message-ID: <20121016000836.D6EDF4738B@hg.openjdk.java.net>

Changeset: 8db45b13526e
Author:    jjg
Date:      2012-10-15 17:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8db45b13526e

8000666: javadoc should write directly to Writer instead of composing strings
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java



From kurchi.subhra.hazra at oracle.com  Tue Oct 16 00:53:56 2012
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Mon, 15 Oct 2012 17:53:56 -0700
Subject: Code Review Request: 7198073: (prefs) user prefs not saved
	[macosx]
In-Reply-To: <50782FF7.60200@oracle.com>
References: <505B8907.2090006@oracle.com> <50776277.9080305@oracle.com>
	<5077CA3F.5010601@oracle.com> <50782FF7.60200@oracle.com>
Message-ID: <507CB024.60408@oracle.com>

Hi Alan,

    Please find an updated webrev with a test included: 
http://cr.openjdk.java.net/~khazra/7198073/webrev.01/

CheckUserPrefsStorage.sh is the main entry point - it runs 
CheckUserPrefFirst first (which creates and attempts to store a preference),
and then runs CheckUserPrefLater (which attempts to retrieve the 
preference stored by the former).

Thanks,
Kurchi


On 12.10.2012 07:57, Kurchi Subhra Hazra wrote:
> On 10/12/12 12:43 AM, Alan Bateman wrote:
>> On 12/10/2012 01:21, Kurchi Hazra wrote:
>>> Hi,
>>>
>>>    This is a regression introduced by the fix for 7160252[1] that I 
>>> pushed a few weeks ago. We should
>>> really be using the class member field isUser, rather than the 
>>> argument passed in the constructor as a parameter
>>> for cfFileForNode(). Due to this wrong parameter being passed, user 
>>> preferences were never getting stored into
>>> permanent storage.
>>>
>>> Webrev: http://cr.openjdk.java.net/~khazra/7198073/webrev.00/
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198073
>>>
>>> Thanks,
>>> Kurchi
>>>
>>> [1] http://cr.openjdk.java.net/~khazra/7160252/webrev.02/
>> Kurchi - thanks for tracking this one down, looking at it now it is 
>> obvious how this slipped through. I think the proposed change is okay 
>> although I think we need to do a bit of clean-up on this code at some 
>> point (not for this change, I realize this one needs to be fixed in 
>> 7u and I don't want to muddy the waters).
>  Right, I will have to spend more time cleaning up this after 
> committing this fix.
>
>> The other thin is tests. The preferences implementation that came via 
>> the Mac port is turning out to have a bit of a bug tail and one or 
>> two regressions have sneaked in along the way too. Do you think you 
>> could add a test for this issue? 
>  Let me get back to you on this.
>
>> Also at some point we need to look at the test coverage and quality 
>> of the tests for this area as most/all of these Mac specific issues 
>> should have been caught before it ever went in.
>  I agree. Again, this will be a longer time goal for me.
>
> - Kurchi
>

-- 
-Kurchi



From mike.duigou at oracle.com  Tue Oct 16 01:12:38 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 15 Oct 2012 18:12:38 -0700
Subject: TreeMap.putAll has undocumented behavior which has different side
	effect based on parameter
In-Reply-To: <507BB0FD.1030607@oracle.com>
References: <CAOo=rxXbP+braQHYCky_OYumhWJn+_B-oDHcSYf-CwiYgByfKg@mail.gmail.com>
	<507BB0FD.1030607@oracle.com>
Message-ID: <4B438891-8F09-4639-AA4D-2AF601C9045D@oracle.com>

I am in agreement with David that the TreeMap documentation seems to adequately cover this case. The only possible addition would be to explicitly state that put() might not be called by putAll() or add documentation to Map indicating that if put() is overridden then putAll() must also be overridden.

Mike

On Oct 14 2012, at 23:45 , David Holmes wrote:

> Hi Sean,
> 
> On 15/10/2012 1:50 PM, Sean Chou wrote:
>> Hi all,
>> 
>>     It is found TreeMap.putAll method may or may not invoke
>> TreeMap.put method based on parameter. If TreeMap is extended and the
>> put method is override, it may behave different from what is expected.
>>   This behavior should be documented.
> 
> TreeMap.putAll doesn't state that it invokes put:
> 
> "Copies all of the mappings from the specified map to this map. These mappings replace any mappings that this map had for any of the keys currently in the specified map."
> 
> ---
> 
> As you can tell from the implementation, if dealing with a compatible SortedMap there are more efficient ways to add the entries than iterating through and doing a put().
> 
> Further, as has been discussed in the past, when a method, like Map.putAll is defined as "The effect of this call is equivalent to that of calling put(k, v) for each mapping ... in the specified map" it does not mean that the implementation has to actually call put() for each item.
> 
> David
> -----
> 
>> 
>>     The following test case tries to putAll a hashamp and a treemap in
>> a class extended from TreeMap.
>> 
>> /////////////// Testcase ////////////////////
>> /*
>>  * Copyright (c) 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
>>  * under the terms of the GNU General Public License version 2 only, as
>>  * published by the Free Software Foundation.
>>  *
>>  * This code is distributed in the hope that it will be useful, but WITHOUT
>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>  * version 2 for more details (a copy is included in the LICENSE file that
>>  * accompanied this code).
>>  *
>>  * You should have received a copy of the GNU General Public License version
>>  * 2 along with this work; if not, write to the Free Software Foundation,
>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>  *
>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>  * or visit www.oracle.com if you need additional information or have any
>>  * questions.
>>  */
>> 
>> /*
>>  * Portions Copyright (c) 2012 IBM Corporation
>>  */
>> 
>> import java.util.HashMap;
>> import java.util.TreeMap;
>> 
>> public class TreeMapTest {
>> 
>>     static class MyTreeMap extends TreeMap<String, String>  {
>>         public String put(String key, String value) {
>>             System.out.println("Override put is invoked in MyTreeMap");
>>             return super.put(key, value);
>>         }
>>     }
>> 
>> 
>>     public static void main(String[] args) {
>>         TreeMap<String, String>  tm = new TreeMap<>();
>>         tm.put("treeMap", "treeMap");
>> 
>>         HashMap<String, String>  hm = new HashMap<>();
>>         hm.put("hashMap", "hashMap");
>> 
>>         System.out.println("Test started, the override put method in
>> MyTreeMap " +
>>         		            "is not invoked when putAll a TreeMap, but " +
>>         		            "it is invoked when putAll a HashMap");
>> 
>>         TreeMap<String, String>  treeMap = new MyTreeMap();
>>         TreeMap<String, String>  treeMap2 = new MyTreeMap();
>> 
>>         System.out.println("putAll treemap:");
>>         treeMap.putAll(tm);
>>         System.out.println("putAll hashmap:");
>>         treeMap2.putAll(hm);
>>     }
>> 
>> }
>> 
>> 
>> 
>> 



From neil.richards at ngmr.net  Tue Oct 16 01:29:49 2012
From: neil.richards at ngmr.net (Neil Richards)
Date: Tue, 16 Oct 2012 02:29:49 +0100
Subject: Hashtable.Entry.hashCode() no longer conforms to Map.Entry.hashCode()
Message-ID: <1350350989.32636.43.camel@chalkhill>

Hi,
I notice that the behaviour of java.util.Hashtable.Entry.hashCode() no
longer conforms to the defined behaviour (in the Java API Javadoc [1])
for java.util.Map.Entry.hashCode() implementations.

The code in Hashtable.Entry.hashCode() assumes that the value in
Hashtable.Entry.hash will always be the same as that for
Hashtable.Entry.getKey().hashCode() .

However, since Java bug 7126277 (Alternative String hashing
implementation), the use of Hashtable.hashSeed, a randomizing factor,
has been introduced into the calculation of Hashtable.hash().

It is the result from Hashtable.hash() which ends up stored in the
Hashtable.Entry.hash field.

So the assumption made in Hashtable.Entry.hashCode() is no longer valid,
and the code needs to be corrected, so that it once more complies with
the Java API defined behaviour.


I have created a webrev [2] with my suggested fix for this problem,
together with a simple testcase to demonstrate it.

(I've also checked the other Map implementations modified by 7126277,
and verified that the others still conform to the Java API in this
regard).

Please review the problem and suggested fix, and let me know your
thoughts.

I am not aware of an existing Java bug for this issue. 
Provided you agree with my analysis, could one be raised to allow the
fix to be committed?

Thanks,
Neil

[1] http://docs.oracle.com/javase/7/docs/api/java/util/Map.Entry.html#hashCode%28%29
[2] http://cr.openjdk.java.net/~ngmr/hashtable-entry-hashcode-fix/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 Oct 16 01:48:58 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 15 Oct 2012 18:48:58 -0700
Subject: Hashtable.Entry.hashCode() no longer conforms to
	Map.Entry.hashCode()
In-Reply-To: <1350350989.32636.43.camel@chalkhill>
References: <1350350989.32636.43.camel@chalkhill>
Message-ID: <80D657B8-D710-465D-8256-BF999C5D3FC6@oracle.com>

Good find Neil. 

I have opened JDK-8000955 for this issue along with JDK-8000956 for the Java 7 backport.

The code could be simplified by using Objects.hashCode()

ie.

return Objects.hashCode(key) ^ Objects.hashCode(value);

Any objection to extending the test similar to Collisions.java to test other Map classes?

Mike

On Oct 15 2012, at 18:29 , Neil Richards wrote:

> Hi,
> I notice that the behaviour of java.util.Hashtable.Entry.hashCode() no
> longer conforms to the defined behaviour (in the Java API Javadoc [1])
> for java.util.Map.Entry.hashCode() implementations.
> 
> The code in Hashtable.Entry.hashCode() assumes that the value in
> Hashtable.Entry.hash will always be the same as that for
> Hashtable.Entry.getKey().hashCode() .
> 
> However, since Java bug 7126277 (Alternative String hashing
> implementation), the use of Hashtable.hashSeed, a randomizing factor,
> has been introduced into the calculation of Hashtable.hash().
> 
> It is the result from Hashtable.hash() which ends up stored in the
> Hashtable.Entry.hash field.
> 
> So the assumption made in Hashtable.Entry.hashCode() is no longer valid,
> and the code needs to be corrected, so that it once more complies with
> the Java API defined behaviour.
> 
> 
> I have created a webrev [2] with my suggested fix for this problem,
> together with a simple testcase to demonstrate it.
> 
> (I've also checked the other Map implementations modified by 7126277,
> and verified that the others still conform to the Java API in this
> regard).
> 
> Please review the problem and suggested fix, and let me know your
> thoughts.
> 
> I am not aware of an existing Java bug for this issue. 
> Provided you agree with my analysis, could one be raised to allow the
> fix to be committed?
> 
> Thanks,
> Neil
> 
> [1] http://docs.oracle.com/javase/7/docs/api/java/util/Map.Entry.html#hashCode%28%29
> [2] http://cr.openjdk.java.net/~ngmr/hashtable-entry-hashcode-fix/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 neil.richards at ngmr.net  Tue Oct 16 03:53:29 2012
From: neil.richards at ngmr.net (Neil Richards)
Date: Tue, 16 Oct 2012 04:53:29 +0100
Subject: Hashtable.Entry.hashCode() no longer conforms to
	Map.Entry.hashCode()
In-Reply-To: <80D657B8-D710-465D-8256-BF999C5D3FC6@oracle.com>
References: <1350350989.32636.43.camel@chalkhill>
	<80D657B8-D710-465D-8256-BF999C5D3FC6@oracle.com>
Message-ID: <1350359609.12688.46.camel@chalkhill>

Hi Mike,
Thanks for the swift appraisal.

Good suggestion to expand the test to cover other Map implementations -
I'd toyed with the idea, but hadn't spotted Collisions.java as a
template to follow.

I've posted an new webrev [2] with the updated (and moved) testcase,
which also makes use of Objects.hashCode() . 


Might there be a performance impact of using Objects.hashCode() in the
fix itself, rather than having the logic inline?

On the surface, it looks like it would be an extra method call, but
maybe the JIT would iron that out?

(I fret about this as (unnecessary) impacts in Hashtable performance
tend to widely felt).

I notice that the other Map.Entry implementations (that I've looked at
so far) have this logic inlined, which is one reason why I went that
route.


Thanks for raising 8000956 for the Java 7 backport.
I guess this means you think the fix should get back there fairly
swiftly.

Presumably 8000956 is linked to 8000955, so I would take the same
change, with the same commit comment - crucially using the same,
original bug id, 8000955 - back onto jdk7u-dev ?

(This is what I've done for other items I've helped in taking back to
jdk7u-dev. Using the same bug id makes it easier to track changes that
have been applied across different streams).

I'm guessing I also need to raise this on the jdk7u-dev mailing list and
get the nod (from Sean Coffey) to put it back there ?


Prior to this, I think I need a blessing for this change from a jdk8
"Reviewer" to push the change to jdk8/tl.


Regards,
Neil

[2] http://cr.openjdk.java.net/~ngmr/8000955/webrev.02

On Mon, 2012-10-15 at 18:48 -0700, Mike Duigou wrote:
> Good find Neil. 
> 
> I have opened JDK-8000955 for this issue along with JDK-8000956 for the Java 7 backport.
> 
> The code could be simplified by using Objects.hashCode()
> 
> ie.
> 
> return Objects.hashCode(key) ^ Objects.hashCode(value);
> 
> Any objection to extending the test similar to Collisions.java to test other Map classes?
> 
> Mike
> 
> On Oct 15 2012, at 18:29 , Neil Richards wrote:
> 
> > Hi,
> > I notice that the behaviour of java.util.Hashtable.Entry.hashCode() no
> > longer conforms to the defined behaviour (in the Java API Javadoc [1])
> > for java.util.Map.Entry.hashCode() implementations.
> > 
> > The code in Hashtable.Entry.hashCode() assumes that the value in
> > Hashtable.Entry.hash will always be the same as that for
> > Hashtable.Entry.getKey().hashCode() .
> > 
> > However, since Java bug 7126277 (Alternative String hashing
> > implementation), the use of Hashtable.hashSeed, a randomizing factor,
> > has been introduced into the calculation of Hashtable.hash().
> > 
> > It is the result from Hashtable.hash() which ends up stored in the
> > Hashtable.Entry.hash field.
> > 
> > So the assumption made in Hashtable.Entry.hashCode() is no longer valid,
> > and the code needs to be corrected, so that it once more complies with
> > the Java API defined behaviour.
> > 
> > 
> > I have created a webrev [2] with my suggested fix for this problem,
> > together with a simple testcase to demonstrate it.
> > 
> > (I've also checked the other Map implementations modified by 7126277,
> > and verified that the others still conform to the Java API in this
> > regard).
> > 
> > Please review the problem and suggested fix, and let me know your
> > thoughts.
> > 
> > I am not aware of an existing Java bug for this issue. 
> > Provided you agree with my analysis, could one be raised to allow the
> > fix to be committed?
> > 
> > Thanks,
> > Neil
> > 
> > [1] http://docs.oracle.com/javase/7/docs/api/java/util/Map.Entry.html#hashCode%28%29
> > [2] http://cr.openjdk.java.net/~ngmr/hashtable-entry-hashcode-fix/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
> > 
> 


-- 
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 Oct 16 09:54:09 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Oct 2012 10:54:09 +0100
Subject: Code Review Request: 7198073: (prefs) user prefs not saved
	[macosx]
In-Reply-To: <507CB024.60408@oracle.com>
References: <505B8907.2090006@oracle.com> <50776277.9080305@oracle.com>
	<5077CA3F.5010601@oracle.com> <50782FF7.60200@oracle.com>
	<507CB024.60408@oracle.com>
Message-ID: <507D2EC0.50603@oracle.com>

On 16/10/2012 01:53, Kurchi Hazra wrote:
> Hi Alan,
>
>    Please find an updated webrev with a test included: 
> http://cr.openjdk.java.net/~khazra/7198073/webrev.01/
>
> CheckUserPrefsStorage.sh is the main entry point - it runs 
> CheckUserPrefFirst first (which creates and attempts to store a 
> preference),
> and then runs CheckUserPrefLater (which attempts to retrieve the 
> preference stored by the former).
Thanks for adding a test, it looks good to me, I just wonder if we 
should run with java.util.prefs.userRoot=. so that we don't leave 
anything behind in the event that CheckUserPrefLater doesn't run.

-Alan


From Ulf.Zibis at CoSoCo.de  Tue Oct 16 13:58:36 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 16 Oct 2012 15:58:36 +0200
Subject: Hashtable.Entry.hashCode() no longer conforms to
	Map.Entry.hashCode()
In-Reply-To: <1350359609.12688.46.camel@chalkhill>
References: <1350350989.32636.43.camel@chalkhill>
	<80D657B8-D710-465D-8256-BF999C5D3FC6@oracle.com>
	<1350359609.12688.46.camel@chalkhill>
Message-ID: <507D680C.2010404@CoSoCo.de>

Am 16.10.2012 05:53, schrieb Neil Richards:
> I've posted an new webrev [2] with the updated (and moved) testcase,
> which also makes use of Objects.hashCode() .

I suspect, that it's productive to use the same algorithm in test and test?e. =-O

-Ulf



From forax at univ-mlv.fr  Tue Oct 16 14:53:04 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 16 Oct 2012 16:53:04 +0200
Subject: CloneNotSupportedException should extends RuntimeException not
	Exception
In-Reply-To: <D395C7FC996C944EBD345AB36164F4B26539C125@woyla.sumatrasoftware.com>
References: <507AE604.3060204@univ-mlv.fr> <507B3DF8.1030902@oracle.com>,
	<507BBAD4.9080807@univ-mlv.fr>
	<D395C7FC996C944EBD345AB36164F4B26539AF15@woyla.sumatrasoftware.com>,
	<507C431F.5010404@univ-mlv.fr>,
	<D395C7FC996C944EBD345AB36164F4B26539C0ED@woyla.sumatrasoftware.com>
	<D395C7FC996C944EBD345AB36164F4B26539C125@woyla.sumatrasoftware.com>
Message-ID: <507D74D0.5090805@univ-mlv.fr>

On 10/15/2012 09:34 PM, Jeroen Frijters wrote:
> I wrote:
>> The point about a non-final class being cloneable is simply that a base class can always implement Cloneable, so that interface is currently meaningless.
> Obviously that should read "... a derived class can always implement Cloneable..."

yes, but in that case all fields referencing mutable objects will not be 
deeply cloned,
so if you want to clone something you have to create subclasses for all 
objects of the graph.

>
> Regards,
> Jeroen

rgds,
R?mi

> ________________________________________
> From: core-libs-dev-bounces at openjdk.java.net [core-libs-dev-bounces at openjdk.java.net] on behalf of Jeroen Frijters [jeroen at sumatra.nl]
> Sent: Monday, October 15, 2012 9:30 PM
> To: Remi Forax
> Cc: David Holmes; core-libs-dev at openjdk.java.net
> Subject: RE: CloneNotSupportedException should extends RuntimeException not     Exception
>
> Hi R?mi,
>
> The point about a non-final class being cloneable is simply that a base class can always implement Cloneable, so that interface is currently meaningless.
>
> With the static method approach, the Cloneable interface becomes a valid way to opt in to that, but I see two downsides to the static method approach:
>
> 1. Once you allow your object to be cloneable, you can't prevent others from cloning your instances. So this pattern wouldn't work:
>
> public Foo copy() {
>    Foo theCopy = (Foo)shallowClone();
>    theCopy.someArray = theCopy.someArray.clone();
>    return theCopy;
> }
>
> 2. The Cloneable interface check is an unnecessary perf hit. The admittedly ugly downcast in the above code can be easily optimized away.
>
> The perf is not a showstopper, but 1. is in my opinion.
>
> Regards,
> Jeroen
> ________________________________________
> From: Remi Forax [forax at univ-mlv.fr]
> Sent: Monday, October 15, 2012 7:08 PM
> To: Jeroen Frijters
> Cc: David Holmes; core-libs-dev at openjdk.java.net
> Subject: Re: CloneNotSupportedException should extends RuntimeException not Exception
>
> Hi Jeroen,
>
> On 10/15/2012 01:48 PM, Jeroen Frijters wrote:
>> The solution is actually pretty easy. Just deprecate Object.clone() and add a new method to Object:
>>
>> protected final native Object shallowClone();
>>
>> It doesn't require the useless Cloneable interface and doesn't conflate shallow and deep cloning.
>>
>> (This is similar to .NET's Object.MemberwiseClone().)
>>
>> Note that this means that any non-final class is cloneable, BUT THAT IS ALREADY THE  CASE even though some people want to pretend otherwise.
> To avoid collisions it can be a static method of Object or j.u.Objects
> that uses generics to be nicely typed.
>
> static native <T> T shallowClone(T object);
>
> and I disagree about Cloneable, while a non-final class is by definition
> mutable, it doesn't mean
> that a non final class can be cloned because it may share some states
> that should not be shared,
> at least without the consent from the author the class.
>
> The other nice property is that any cloneable class will be publicly
> cloneable.
>
> I also believe that the checkcast generated by javac before calling
> shallowClone can be removed
> by the JIT, currently this cast is not removed when you call clone.
>
>> Regards,
>> Jeroen
> regards,
> R?mi



From kurchi.subhra.hazra at oracle.com  Tue Oct 16 15:55:46 2012
From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra)
Date: Tue, 16 Oct 2012 08:55:46 -0700
Subject: Code Review Request: 7198073: (prefs) user prefs not saved
	[macosx]
In-Reply-To: <507D2EC0.50603@oracle.com>
References: <505B8907.2090006@oracle.com> <50776277.9080305@oracle.com>
	<5077CA3F.5010601@oracle.com> <50782FF7.60200@oracle.com>
	<507CB024.60408@oracle.com> <507D2EC0.50603@oracle.com>
Message-ID: <507D8382.9080904@oracle.com>

On 10/16/12 2:54 AM, Alan Bateman wrote:
> On 16/10/2012 01:53, Kurchi Hazra wrote:
>> Hi Alan,
>>
>>    Please find an updated webrev with a test included: 
>> http://cr.openjdk.java.net/~khazra/7198073/webrev.01/
>>
>> CheckUserPrefsStorage.sh is the main entry point - it runs 
>> CheckUserPrefFirst first (which creates and attempts to store a 
>> preference),
>> and then runs CheckUserPrefLater (which attempts to retrieve the 
>> preference stored by the former).
> Thanks for adding a test, it looks good to me, I just wonder if we 
> should run with java.util.prefs.userRoot=. so that we don't leave 
> anything behind in the event that CheckUserPrefLater doesn't run.

That did occur to me, but I have not yet checked what 
java.util.prefs.userRoot=. actually implies while using jtreg.
When I get more time to work on 7197662, I will be updating all the 
prefs test including this one.

Thanks,
Kurchi


From mike.duigou at oracle.com  Tue Oct 16 16:13:24 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 16 Oct 2012 09:13:24 -0700
Subject: Hashtable.Entry.hashCode() no longer conforms to
	Map.Entry.hashCode()
In-Reply-To: <1350359609.12688.46.camel@chalkhill>
References: <1350350989.32636.43.camel@chalkhill>
	<80D657B8-D710-465D-8256-BF999C5D3FC6@oracle.com>
	<1350359609.12688.46.camel@chalkhill>
Message-ID: <6B8EF0C1-8817-47C2-9CE2-F64FCEC4D9C3@oracle.com>


On Oct 15 2012, at 20:53 , Neil Richards wrote:

> Hi Mike,
> Thanks for the swift appraisal.
> 
> Good suggestion to expand the test to cover other Map implementations -
> I'd toyed with the idea, but hadn't spotted Collisions.java as a
> template to follow.
> 
> I've posted an new webrev [2] with the updated (and moved) testcase,
> which also makes use of Objects.hashCode() . 

This test looks suspiciously like it anticipates TestNG DataProviders. :-) Soon. 

> Might there be a performance impact of using Objects.hashCode() in the
> fix itself, rather than having the logic inline?

In other cases we found that the JIT always inlined the method and there was no performance penalty. Only if the hashCode method itself got too big did the method invocation matter.

> On the surface, it looks like it would be an extra method call, but
> maybe the JIT would iron that out?

That is the expectation. Hotspot at least will inline this method and there has been talk of making Objects.hashCode() and a few other methods into intrinsics which would further improve inlining. 

> (I fret about this as (unnecessary) impacts in Hashtable performance
> tend to widely felt).

Understood and agreed. 

> 
> I notice that the other Map.Entry implementations (that I've looked at
> so far) have this logic inlined, which is one reason why I went that
> route.

I believe that this is primarily historical from before Objects.hashCode existed. I have started to convert instances of this logic but it's too small of an issue (and I am too busy) to attempt to convert existing instances as an independent task.

> Thanks for raising 8000956 for the Java 7 backport.
> I guess this means you think the fix should get back there fairly
> swiftly.

We should try to get it pushed in to 7 ASAP once we are done in 8.

> Presumably 8000956 is linked to 8000955, so I would take the same
> change, with the same commit comment - crucially using the same,
> original bug id, 8000955 - back onto jdk7u-dev ?

Correct.

> (This is what I've done for other items I've helped in taking back to
> jdk7u-dev. Using the same bug id makes it easier to track changes that
> have been applied across different streams).
> 
> I'm guessing I also need to raise this on the jdk7u-dev mailing list and
> get the nod (from Sean Coffey) to put it back there ?

Yes.

> Prior to this, I think I need a blessing for this change from a jdk8
> "Reviewer" to push the change to jdk8/tl.
> 
> 
> Regards,
> Neil
> 
> [2] http://cr.openjdk.java.net/~ngmr/8000955/webrev.02
> 
> On Mon, 2012-10-15 at 18:48 -0700, Mike Duigou wrote:
>> Good find Neil. 
>> 
>> I have opened JDK-8000955 for this issue along with JDK-8000956 for the Java 7 backport.
>> 
>> The code could be simplified by using Objects.hashCode()
>> 
>> ie.
>> 
>> return Objects.hashCode(key) ^ Objects.hashCode(value);
>> 
>> Any objection to extending the test similar to Collisions.java to test other Map classes?
>> 
>> Mike
>> 
>> On Oct 15 2012, at 18:29 , Neil Richards wrote:
>> 
>>> Hi,
>>> I notice that the behaviour of java.util.Hashtable.Entry.hashCode() no
>>> longer conforms to the defined behaviour (in the Java API Javadoc [1])
>>> for java.util.Map.Entry.hashCode() implementations.
>>> 
>>> The code in Hashtable.Entry.hashCode() assumes that the value in
>>> Hashtable.Entry.hash will always be the same as that for
>>> Hashtable.Entry.getKey().hashCode() .
>>> 
>>> However, since Java bug 7126277 (Alternative String hashing
>>> implementation), the use of Hashtable.hashSeed, a randomizing factor,
>>> has been introduced into the calculation of Hashtable.hash().
>>> 
>>> It is the result from Hashtable.hash() which ends up stored in the
>>> Hashtable.Entry.hash field.
>>> 
>>> So the assumption made in Hashtable.Entry.hashCode() is no longer valid,
>>> and the code needs to be corrected, so that it once more complies with
>>> the Java API defined behaviour.
>>> 
>>> 
>>> I have created a webrev [2] with my suggested fix for this problem,
>>> together with a simple testcase to demonstrate it.
>>> 
>>> (I've also checked the other Map implementations modified by 7126277,
>>> and verified that the others still conform to the Java API in this
>>> regard).
>>> 
>>> Please review the problem and suggested fix, and let me know your
>>> thoughts.
>>> 
>>> I am not aware of an existing Java bug for this issue. 
>>> Provided you agree with my analysis, could one be raised to allow the
>>> fix to be committed?
>>> 
>>> Thanks,
>>> Neil
>>> 
>>> [1] http://docs.oracle.com/javase/7/docs/api/java/util/Map.Entry.html#hashCode%28%29
>>> [2] http://cr.openjdk.java.net/~ngmr/hashtable-entry-hashcode-fix/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
>>> 
>> 
> 
> 
> -- 
> Unless stated above:
> IBM email: neil_richards at uk.ibm.com
> IBM United Kingdom Limited - Registered in England and Wales with number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 



From rob.mckenna at oracle.com  Tue Oct 16 16:15:10 2012
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 16 Oct 2012 17:15:10 +0100
Subject: RFR: 8000975: Merge UNIXProcess.java.bsd & UNIXProcess.java.linux
Message-ID: <507D880E.3020309@oracle.com>

It has been suggested to me (at least twice at this stage) that these 
files should be merged since they're identical. This requires an 
adjustment in perspective from "every platform should have its own 
implementation" to "those platforms that differ from the norm should 
have their own implementation". Given that the latter approach 
simplifies things currently I believe it is the more sensible.

Webrev at:

http://cr.openjdk.java.net/~robm/8000975/webrev.01/ 
<http://cr.openjdk.java.net/%7Erobm/8000975/webrev.01/>

     -Rob


From Alan.Bateman at oracle.com  Tue Oct 16 16:35:02 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Oct 2012 17:35:02 +0100
Subject: RFR: 8000975: Merge UNIXProcess.java.bsd & UNIXProcess.java.linux
In-Reply-To: <507D880E.3020309@oracle.com>
References: <507D880E.3020309@oracle.com>
Message-ID: <507D8CB6.1070704@oracle.com>

On 16/10/2012 17:15, Rob McKenna wrote:
> It has been suggested to me (at least twice at this stage) that these 
> files should be merged since they're identical. This requires an 
> adjustment in perspective from "every platform should have its own 
> implementation" to "those platforms that differ from the norm should 
> have their own implementation". Given that the latter approach 
> simplifies things currently I believe it is the more sensible.
>
> Webrev at:
>
> http://cr.openjdk.java.net/~robm/8000975/webrev.01/ 
> <http://cr.openjdk.java.net/%7Erobm/8000975/webrev.01/>
>
>     -Rob
I don't have any objection to this but at some point I think we need to 
change the Solaris and Mac implementations to use posix_spawn, in which 
case it's possible that the Mac implementation will be different to the 
Linux implementation.

-Alan


From rob.mckenna at oracle.com  Tue Oct 16 16:49:40 2012
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 16 Oct 2012 17:49:40 +0100
Subject: RFR: 8000975: Merge UNIXProcess.java.bsd & UNIXProcess.java.linux
In-Reply-To: <507D8CB6.1070704@oracle.com>
References: <507D880E.3020309@oracle.com> <507D8CB6.1070704@oracle.com>
Message-ID: <507D9024.1010706@oracle.com>

That is true, and I'm just working on bringing Mike's Solaris changes 
forward now. I hadn't considered that it would result in a difference in 
Mac too. I'll get this work completed and see where it stands first.

     -Rob

On 16/10/12 17:35, Alan Bateman wrote:
> On 16/10/2012 17:15, Rob McKenna wrote:
>> It has been suggested to me (at least twice at this stage) that these 
>> files should be merged since they're identical. This requires an 
>> adjustment in perspective from "every platform should have its own 
>> implementation" to "those platforms that differ from the norm should 
>> have their own implementation". Given that the latter approach 
>> simplifies things currently I believe it is the more sensible.
>>
>> Webrev at:
>>
>> http://cr.openjdk.java.net/~robm/8000975/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Erobm/8000975/webrev.01/>
>>
>>     -Rob
> I don't have any objection to this but at some point I think we need 
> to change the Solaris and Mac implementations to use posix_spawn, in 
> which case it's possible that the Mac implementation will be different 
> to the Linux implementation.
>
> -Alan



From naoto.sato at oracle.com  Tue Oct 16 17:59:49 2012
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 16 Oct 2012 17:59:49 +0000
Subject: hg: jdk8/tl/jdk: 8000245: SimpleDateFormat.format(date, StringBuffer, 
	FieldPosition) doesn't work as expected with custom extensions; ...
Message-ID: <20121016180011.C58AC473AF@hg.openjdk.java.net>

Changeset: 32452042b781
Author:    naoto
Date:      2012-10-16 10:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32452042b781

8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) doesn't work as expected with custom extensions
8000273: java.util.Locale.getDisplayVariant(Locale l) isn't transferred to the custom service provider
8000615: JRE adapter: timezone name of en_US is changed when extension directory is added
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java
! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java
! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java
! test/java/util/Locale/LocaleProviders.java
! test/java/util/Locale/LocaleProviders.sh
! test/java/util/PluggableLocale/CurrencyNameProviderTest.java
! test/java/util/PluggableLocale/LocaleNameProviderTest.java
! test/java/util/PluggableLocale/LocaleNameProviderTest.sh
! test/java/util/PluggableLocale/ProviderTest.java
! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java
! test/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java



From christian.thalinger at oracle.com  Tue Oct 16 18:01:04 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 16 Oct 2012 11:01:04 -0700
Subject: RFR (M): 8000989: smaller code changes to make future JSR 292
	backports easier
Message-ID: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>

http://cr.openjdk.java.net/~twisti/8000989

8000989: smaller code changes to make future JSR 292 backports easier
Reviewed-by:

In 8 we added two new constructors to InternalError which we use in
292.  Factor InternalError generation to a method to make future
backports to 7u easier.

src/share/classes/java/lang/invoke/BoundMethodHandle.java
src/share/classes/java/lang/invoke/CallSite.java
src/share/classes/java/lang/invoke/DirectMethodHandle.java
src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
src/share/classes/java/lang/invoke/Invokers.java
src/share/classes/java/lang/invoke/LambdaForm.java
src/share/classes/java/lang/invoke/MemberName.java
src/share/classes/java/lang/invoke/MethodHandle.java
src/share/classes/java/lang/invoke/MethodHandleImpl.java
src/share/classes/java/lang/invoke/MethodHandleStatics.java
src/share/classes/sun/invoke/util/ValueConversions.java
test/java/lang/invoke/BigArityTest.java
test/java/lang/invoke/PrivateInvokeTest.java



From john.r.rose at oracle.com  Tue Oct 16 18:11:30 2012
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 16 Oct 2012 11:11:30 -0700
Subject: RFR (M): 8000989: smaller code changes to make future JSR 292
	backports easier
In-Reply-To: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>
References: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>
Message-ID: <07B9E251-2802-4E06-BFFC-53744355D331@oracle.com>

Reviewed; good.  This removes a significant source of friction (mismerges) for sharing changes between 7 and 8.  ? John

On Oct 16, 2012, at 11:01 AM, Christian Thalinger wrote:

> http://cr.openjdk.java.net/~twisti/8000989
> 
> 8000989: smaller code changes to make future JSR 292 backports easier
> Reviewed-by:
> 
> In 8 we added two new constructors to InternalError which we use in
> 292.  Factor InternalError generation to a method to make future
> backports to 7u easier.
> 
> src/share/classes/java/lang/invoke/BoundMethodHandle.java
> src/share/classes/java/lang/invoke/CallSite.java
> src/share/classes/java/lang/invoke/DirectMethodHandle.java
> src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
> src/share/classes/java/lang/invoke/Invokers.java
> src/share/classes/java/lang/invoke/LambdaForm.java
> src/share/classes/java/lang/invoke/MemberName.java
> src/share/classes/java/lang/invoke/MethodHandle.java
> src/share/classes/java/lang/invoke/MethodHandleImpl.java
> src/share/classes/java/lang/invoke/MethodHandleStatics.java
> src/share/classes/sun/invoke/util/ValueConversions.java
> test/java/lang/invoke/BigArityTest.java
> test/java/lang/invoke/PrivateInvokeTest.java
> 



From christian.thalinger at oracle.com  Tue Oct 16 18:20:59 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 16 Oct 2012 11:20:59 -0700
Subject: RFR (M): 8000989: smaller code changes to make future JSR 292
	backports easier
In-Reply-To: <07B9E251-2802-4E06-BFFC-53744355D331@oracle.com>
References: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>
	<07B9E251-2802-4E06-BFFC-53744355D331@oracle.com>
Message-ID: <80363693-6553-4BA1-9CD2-4929D39FFBD9@oracle.com>

Thank you, John.  After this is in 8 I will send a 7 backport webrev.

-- Chris

On Oct 16, 2012, at 11:11 AM, John Rose <john.r.rose at oracle.com> wrote:

> Reviewed; good.  This removes a significant source of friction (mismerges) for sharing changes between 7 and 8.  ? John
> 
> On Oct 16, 2012, at 11:01 AM, Christian Thalinger wrote:
> 
>> http://cr.openjdk.java.net/~twisti/8000989
>> 
>> 8000989: smaller code changes to make future JSR 292 backports easier
>> Reviewed-by:
>> 
>> In 8 we added two new constructors to InternalError which we use in
>> 292.  Factor InternalError generation to a method to make future
>> backports to 7u easier.
>> 
>> src/share/classes/java/lang/invoke/BoundMethodHandle.java
>> src/share/classes/java/lang/invoke/CallSite.java
>> src/share/classes/java/lang/invoke/DirectMethodHandle.java
>> src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
>> src/share/classes/java/lang/invoke/Invokers.java
>> src/share/classes/java/lang/invoke/LambdaForm.java
>> src/share/classes/java/lang/invoke/MemberName.java
>> src/share/classes/java/lang/invoke/MethodHandle.java
>> src/share/classes/java/lang/invoke/MethodHandleImpl.java
>> src/share/classes/java/lang/invoke/MethodHandleStatics.java
>> src/share/classes/sun/invoke/util/ValueConversions.java
>> test/java/lang/invoke/BigArityTest.java
>> test/java/lang/invoke/PrivateInvokeTest.java
>> 
> 



From christian.thalinger at oracle.com  Tue Oct 16 19:54:31 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Tue, 16 Oct 2012 12:54:31 -0700
Subject: RFR (S): 8000999: backport of JSR 292 to 7u
Message-ID: <83E35F6D-2D0D-44BE-85EC-21C9D6F320B3@oracle.com>

http://cr.openjdk.java.net/~twisti/8000999

8000999: backport of JSR 292 to 7u
Reviewed-by:

This is an umbrella bug for these changes (which are backported in one
changeset):

6983728: JSR 292 remove argument count limitations 
7128512: Javadoc typo in java.lang.invoke.MethodHandle 
7117167: Misc warnings in java.lang.invoke and sun.invoke.* 
7129034: VM crash with a field setter method with a filterArguments 
7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited 
7127687: MethodType leaks memory due to interning 
7023639: JSR 292 method handle invocation needs a fast path for compiled code 
7188911: nightly failures after JSR 292 lazy method handle update (round 2) 
7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize 
7191102: nightly failures after JSR 292 lazy method handle update (round 3) 
7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa 
7194662: JSR 292: PermuteArgsTest times out in nightly test runs

The backport is just copying over the files from JDK 8.  That's why the webrev is so big and pretty useless.  The real changes between 8 and 7 are these:

diff -Nur jdk8/src/share/classes/java/lang/invoke/MethodHandleStatics.java jdk7u/src/share/classes/java/lang/invoke/MethodHandleStatics.java
--- jdk8/src/share/classes/java/lang/invoke/MethodHandleStatics.java    2012-10-15 12:21:52.806052959 -0700
+++ jdk7u/src/share/classes/java/lang/invoke/MethodHandleStatics.java   2012-10-16 10:48:29.728257304 -0700
@@ -94,10 +94,14 @@
 
     // handy shared exception makers (they simplify the common case code)
     /*non-public*/ static InternalError newInternalError(String message, Throwable cause) {
-        return new InternalError(message, cause);
+        InternalError e = new InternalError(message);
+        e.initCause(cause);
+        return e;
     }
     /*non-public*/ static InternalError newInternalError(Throwable cause) {
-        return new InternalError(cause);
+        InternalError e = new InternalError();
+        e.initCause(cause);
+        return e;
     }
     /*non-public*/ static RuntimeException newIllegalStateException(String message) {
         return new IllegalStateException(message);
diff -Nur jdk8/src/share/classes/sun/invoke/util/ValueConversions.java jdk7u/src/share/classes/sun/invoke/util/ValueConversions.java
--- jdk8/src/share/classes/sun/invoke/util/ValueConversions.java        2012-10-16 10:49:36.081911283 -0700
+++ jdk7u/src/share/classes/sun/invoke/util/ValueConversions.java       2012-10-16 10:48:19.626424849 -0700
@@ -1211,9 +1211,13 @@
 
     // handy shared exception makers (they simplify the common case code)
     private static InternalError newInternalError(String message, Throwable cause) {
-        return new InternalError(message, cause);
+        InternalError e = new InternalError(message);
+        e.initCause(cause);
+        return e;
     }
     private static InternalError newInternalError(Throwable cause) {
-        return new InternalError(cause);
+        InternalError e = new InternalError();
+        e.initCause(cause);
+        return e;
     }
 }
diff --git a/src/share/classes/sun/misc/Unsafe.java b/src/share/classes/sun/misc/Unsafe.java
--- a/src/share/classes/sun/misc/Unsafe.java
+++ b/src/share/classes/sun/misc/Unsafe.java
@@ -678,6 +678,14 @@
     public native Object staticFieldBase(Field f);
 
     /**
+     * Detect if the given class may need to be initialized. This is often
+     * needed in conjunction with obtaining the static field base of a
+     * class.
+     * @return false only if a call to {@code ensureClassInitialized} would have no effect
+     */
+    public native boolean shouldBeInitialized(Class c);
+
+    /**
      * Ensure the given class has been initialized. This is often
      * needed in conjunction with obtaining the static field base of a
      * class.



From kurchi.subhra.hazra at oracle.com  Tue Oct 16 22:23:47 2012
From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com)
Date: Tue, 16 Oct 2012 22:23:47 +0000
Subject: hg: jdk8/tl/jdk: 7198073: (prefs) user prefs not saved [macosx]
Message-ID: <20121016222408.4153A473CF@hg.openjdk.java.net>

Changeset: 3a6b76a468bd
Author:    khazra
Date:      2012-10-16 15:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a6b76a468bd

7198073: (prefs) user prefs not saved [macosx]
Summary: Using class member field to get node instead of argument
Reviewed-by: alanb

! src/macosx/classes/java/util/prefs/MacOSXPreferences.java
+ test/java/util/prefs/CheckUserPrefFirst.java
+ test/java/util/prefs/CheckUserPrefLater.java
+ test/java/util/prefs/CheckUserPrefsStorage.sh



From neil.richards at ngmr.net  Tue Oct 16 23:12:17 2012
From: neil.richards at ngmr.net (Neil Richards)
Date: Wed, 17 Oct 2012 00:12:17 +0100
Subject: RFR: 8000955: Hashtable.Entry.hashCode() no longer conforms to
	Map.Entry.hashCode()
In-Reply-To: <6B8EF0C1-8817-47C2-9CE2-F64FCEC4D9C3@oracle.com>
References: <1350350989.32636.43.camel@chalkhill>
	<80D657B8-D710-465D-8256-BF999C5D3FC6@oracle.com>
	<1350359609.12688.46.camel@chalkhill>
	<6B8EF0C1-8817-47C2-9CE2-F64FCEC4D9C3@oracle.com>
Message-ID: <1350429137.11297.13.camel@chalkhill>

Okay, you convinced me. :)

Here's another webrev [1], updated to make use of Objects.hashCode() in
the fix (as well as in the testcase).

Can I now interest a Reviewer in endorsing this fix ?

Thanks,
Neil

[1] http://cr.openjdk.java.net/~ngmr/8000955/webrev.03/

On Tue, 2012-10-16 at 09:13 -0700, Mike Duigou wrote:
> On Oct 15 2012, at 20:53 , Neil Richards wrote:
> 
> > Hi Mike,
> > Thanks for the swift appraisal.
> > 
> > Good suggestion to expand the test to cover other Map implementations -
> > I'd toyed with the idea, but hadn't spotted Collisions.java as a
> > template to follow.
> > 
> > I've posted an new webrev [2] with the updated (and moved) testcase,
> > which also makes use of Objects.hashCode() . 
> 
> This test looks suspiciously like it anticipates TestNG DataProviders. :-) Soon. 
> 
> > Might there be a performance impact of using Objects.hashCode() in the
> > fix itself, rather than having the logic inline?
> 
> In other cases we found that the JIT always inlined the method and there was no performance penalty. Only if the hashCode method itself got too big did the method invocation matter.
> 
> > On the surface, it looks like it would be an extra method call, but
> > maybe the JIT would iron that out?
> 
> That is the expectation. Hotspot at least will inline this method and there has been talk of making Objects.hashCode() and a few other methods into intrinsics which would further improve inlining. 
> 
> > (I fret about this as (unnecessary) impacts in Hashtable performance
> > tend to widely felt).
> 
> Understood and agreed. 
> 
> > 
> > I notice that the other Map.Entry implementations (that I've looked at
> > so far) have this logic inlined, which is one reason why I went that
> > route.
> 
> I believe that this is primarily historical from before Objects.hashCode existed. I have started to convert instances of this logic but it's too small of an issue (and I am too busy) to attempt to convert existing instances as an independent task.
> 
> > Thanks for raising 8000956 for the Java 7 backport.
> > I guess this means you think the fix should get back there fairly
> > swiftly.
> 
> We should try to get it pushed in to 7 ASAP once we are done in 8.
> 
> > Presumably 8000956 is linked to 8000955, so I would take the same
> > change, with the same commit comment - crucially using the same,
> > original bug id, 8000955 - back onto jdk7u-dev ?
> 
> Correct.
> 
> > (This is what I've done for other items I've helped in taking back to
> > jdk7u-dev. Using the same bug id makes it easier to track changes that
> > have been applied across different streams).
> > 
> > I'm guessing I also need to raise this on the jdk7u-dev mailing list and
> > get the nod (from Sean Coffey) to put it back there ?
> 
> Yes.
> 
> > Prior to this, I think I need a blessing for this change from a jdk8
> > "Reviewer" to push the change to jdk8/tl.
> > 
> > 
> > Regards,
> > Neil
> > 
> > [2] http://cr.openjdk.java.net/~ngmr/8000955/webrev.02
> > 
> > On Mon, 2012-10-15 at 18:48 -0700, Mike Duigou wrote:
> >> Good find Neil. 
> >> 
> >> I have opened JDK-8000955 for this issue along with JDK-8000956 for the Java 7 backport.
> >> 
> >> The code could be simplified by using Objects.hashCode()
> >> 
> >> ie.
> >> 
> >> return Objects.hashCode(key) ^ Objects.hashCode(value);
> >> 
> >> Any objection to extending the test similar to Collisions.java to test other Map classes?
> >> 
> >> Mike
> >> 
> >> On Oct 15 2012, at 18:29 , Neil Richards wrote:
> >> 
> >>> Hi,
> >>> I notice that the behaviour of java.util.Hashtable.Entry.hashCode() no
> >>> longer conforms to the defined behaviour (in the Java API Javadoc [1])
> >>> for java.util.Map.Entry.hashCode() implementations.
> >>> 
> >>> The code in Hashtable.Entry.hashCode() assumes that the value in
> >>> Hashtable.Entry.hash will always be the same as that for
> >>> Hashtable.Entry.getKey().hashCode() .
> >>> 
> >>> However, since Java bug 7126277 (Alternative String hashing
> >>> implementation), the use of Hashtable.hashSeed, a randomizing factor,
> >>> has been introduced into the calculation of Hashtable.hash().
> >>> 
> >>> It is the result from Hashtable.hash() which ends up stored in the
> >>> Hashtable.Entry.hash field.
> >>> 
> >>> So the assumption made in Hashtable.Entry.hashCode() is no longer valid,
> >>> and the code needs to be corrected, so that it once more complies with
> >>> the Java API defined behaviour.
> >>> 
> >>> 
> >>> I have created a webrev [2] with my suggested fix for this problem,
> >>> together with a simple testcase to demonstrate it.
> >>> 
> >>> (I've also checked the other Map implementations modified by 7126277,
> >>> and verified that the others still conform to the Java API in this
> >>> regard).
> >>> 
> >>> Please review the problem and suggested fix, and let me know your
> >>> thoughts.
> >>> 
> >>> I am not aware of an existing Java bug for this issue. 
> >>> Provided you agree with my analysis, could one be raised to allow the
> >>> fix to be committed?
> >>> 
> >>> Thanks,
> >>> Neil
> >>> 
> >>> [1] http://docs.oracle.com/javase/7/docs/api/java/util/Map.Entry.html#hashCode%28%29
> >>> [2] http://cr.openjdk.java.net/~ngmr/hashtable-entry-hashcode-fix/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
> >>> 
> >> 
> > 
> > 
> > -- 
> > 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
> > 
> 


-- 
Unless stated above:
IBM email: neil_richards at uk.ibm.com
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From david.holmes at oracle.com  Wed Oct 17 03:54:40 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Oct 2012 13:54:40 +1000
Subject: RFR (M): 8000989: smaller code changes to make future JSR 292
	backports easier
In-Reply-To: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>
References: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>
Message-ID: <507E2C00.8070001@oracle.com>

Not sure what relevance there is to hotspot :)

Not meaning to be difficult but why not just apply this change to the 7u 
code and use the appropriate constructors? As I general rule (there are 
exceptions eg java.util.concurrent) I don't think the libraries code is 
written to be directly usable in multiple JDK versions.

Or even add a package-private InternalError class that subclasses 
java.lang.InternalError to add the new constructors? (for 7u)

David


On 17/10/2012 4:01 AM, Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/8000989
>
> 8000989: smaller code changes to make future JSR 292 backports easier
> Reviewed-by:
>
> In 8 we added two new constructors to InternalError which we use in
> 292.  Factor InternalError generation to a method to make future
> backports to 7u easier.
>
> src/share/classes/java/lang/invoke/BoundMethodHandle.java
> src/share/classes/java/lang/invoke/CallSite.java
> src/share/classes/java/lang/invoke/DirectMethodHandle.java
> src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
> src/share/classes/java/lang/invoke/Invokers.java
> src/share/classes/java/lang/invoke/LambdaForm.java
> src/share/classes/java/lang/invoke/MemberName.java
> src/share/classes/java/lang/invoke/MethodHandle.java
> src/share/classes/java/lang/invoke/MethodHandleImpl.java
> src/share/classes/java/lang/invoke/MethodHandleStatics.java
> src/share/classes/sun/invoke/util/ValueConversions.java
> test/java/lang/invoke/BigArityTest.java
> test/java/lang/invoke/PrivateInvokeTest.java
>


From david.holmes at oracle.com  Wed Oct 17 03:59:10 2012
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Oct 2012 13:59:10 +1000
Subject: RFR (S): 8000999: backport of JSR 292 to 7u
In-Reply-To: <83E35F6D-2D0D-44BE-85EC-21C9D6F320B3@oracle.com>
References: <83E35F6D-2D0D-44BE-85EC-21C9D6F320B3@oracle.com>
Message-ID: <507E2D0E.8080100@oracle.com>

Hi Christian,

Is this just a preliminary review request, as actual backport requests 
have to go to the jdk7u-dev mailing list for approval.

And are these all just bug fixes, or are there any API/spec changes 
involved?

David

On 17/10/2012 5:54 AM, Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/8000999
>
> 8000999: backport of JSR 292 to 7u
> Reviewed-by:
>
> This is an umbrella bug for these changes (which are backported in one
> changeset):
>
> 6983728: JSR 292 remove argument count limitations
> 7128512: Javadoc typo in java.lang.invoke.MethodHandle
> 7117167: Misc warnings in java.lang.invoke and sun.invoke.*
> 7129034: VM crash with a field setter method with a filterArguments
> 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited
> 7127687: MethodType leaks memory due to interning
> 7023639: JSR 292 method handle invocation needs a fast path for compiled code
> 7188911: nightly failures after JSR 292 lazy method handle update (round 2)
> 7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize
> 7191102: nightly failures after JSR 292 lazy method handle update (round 3)
> 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa
> 7194662: JSR 292: PermuteArgsTest times out in nightly test runs
>
> The backport is just copying over the files from JDK 8.  That's why the webrev is so big and pretty useless.  The real changes between 8 and 7 are these:
>
> diff -Nur jdk8/src/share/classes/java/lang/invoke/MethodHandleStatics.java jdk7u/src/share/classes/java/lang/invoke/MethodHandleStatics.java
> --- jdk8/src/share/classes/java/lang/invoke/MethodHandleStatics.java    2012-10-15 12:21:52.806052959 -0700
> +++ jdk7u/src/share/classes/java/lang/invoke/MethodHandleStatics.java   2012-10-16 10:48:29.728257304 -0700
> @@ -94,10 +94,14 @@
>
>       // handy shared exception makers (they simplify the common case code)
>       /*non-public*/ static InternalError newInternalError(String message, Throwable cause) {
> -        return new InternalError(message, cause);
> +        InternalError e = new InternalError(message);
> +        e.initCause(cause);
> +        return e;
>       }
>       /*non-public*/ static InternalError newInternalError(Throwable cause) {
> -        return new InternalError(cause);
> +        InternalError e = new InternalError();
> +        e.initCause(cause);
> +        return e;
>       }
>       /*non-public*/ static RuntimeException newIllegalStateException(String message) {
>           return new IllegalStateException(message);
> diff -Nur jdk8/src/share/classes/sun/invoke/util/ValueConversions.java jdk7u/src/share/classes/sun/invoke/util/ValueConversions.java
> --- jdk8/src/share/classes/sun/invoke/util/ValueConversions.java        2012-10-16 10:49:36.081911283 -0700
> +++ jdk7u/src/share/classes/sun/invoke/util/ValueConversions.java       2012-10-16 10:48:19.626424849 -0700
> @@ -1211,9 +1211,13 @@
>
>       // handy shared exception makers (they simplify the common case code)
>       private static InternalError newInternalError(String message, Throwable cause) {
> -        return new InternalError(message, cause);
> +        InternalError e = new InternalError(message);
> +        e.initCause(cause);
> +        return e;
>       }
>       private static InternalError newInternalError(Throwable cause) {
> -        return new InternalError(cause);
> +        InternalError e = new InternalError();
> +        e.initCause(cause);
> +        return e;
>       }
>   }
> diff --git a/src/share/classes/sun/misc/Unsafe.java b/src/share/classes/sun/misc/Unsafe.java
> --- a/src/share/classes/sun/misc/Unsafe.java
> +++ b/src/share/classes/sun/misc/Unsafe.java
> @@ -678,6 +678,14 @@
>       public native Object staticFieldBase(Field f);
>
>       /**
> +     * Detect if the given class may need to be initialized. This is often
> +     * needed in conjunction with obtaining the static field base of a
> +     * class.
> +     * @return false only if a call to {@code ensureClassInitialized} would have no effect
> +     */
> +    public native boolean shouldBeInitialized(Class c);
> +
> +    /**
>        * Ensure the given class has been initialized. This is often
>        * needed in conjunction with obtaining the static field base of a
>        * class.
>


From jonathan.gibbons at oracle.com  Wed Oct 17 04:04:11 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 17 Oct 2012 04:04:11 +0000
Subject: hg: jdk8/tl/langtools: 8000673: remove dead code from HtmlWriter and
	subtypes
Message-ID: <20121017040414.9AA73473D3@hg.openjdk.java.net>

Changeset: 2013982bee34
Author:    jjg
Date:      2012-10-16 21:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2013982bee34

8000673: remove dead code from HtmlWriter and subtypes
Reviewed-by: bpatel

! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java



From alan.bateman at oracle.com  Wed Oct 17 10:45:23 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 17 Oct 2012 10:45:23 +0000
Subject: hg: jdk8/tl/jdk: 8000685: (props) Properties.storeToXML/loadFromXML
	should only require UTF-8 and UTF-16 to be supported
Message-ID: <20121017104559.88D6E473E0@hg.openjdk.java.net>

Changeset: 14b9e294d049
Author:    alanb
Date:      2012-10-17 11:43 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/14b9e294d049

8000685: (props) Properties.storeToXML/loadFromXML should only require UTF-8 and UTF-16 to be supported
Reviewed-by: mchung, chegar

! src/share/classes/java/util/Properties.java
! src/share/classes/sun/util/spi/XmlPropertiesProvider.java
! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java
! test/java/util/Properties/LoadAndStoreXML.java



From Alan.Bateman at oracle.com  Wed Oct 17 11:09:25 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Oct 2012 12:09:25 +0100
Subject: RFR: 8000955: Hashtable.Entry.hashCode() no longer conforms to
	Map.Entry.hashCode()
In-Reply-To: <1350429137.11297.13.camel@chalkhill>
References: <1350350989.32636.43.camel@chalkhill>
	<80D657B8-D710-465D-8256-BF999C5D3FC6@oracle.com>
	<1350359609.12688.46.camel@chalkhill>
	<6B8EF0C1-8817-47C2-9CE2-F64FCEC4D9C3@oracle.com>
	<1350429137.11297.13.camel@chalkhill>
Message-ID: <507E91E4.1090808@oracle.com>

On 17/10/2012 00:12, Neil Richards wrote:
> Okay, you convinced me. :)
>
> Here's another webrev [1], updated to make use of Objects.hashCode() in
> the fix (as well as in the testcase).
>
> Can I now interest a Reviewer in endorsing this fix ?
>
> Thanks,
> Neil
>
> [1] http://cr.openjdk.java.net/~ngmr/8000955/webrev.03/
>
>
It looks to fine to me too.

-Alan


From neil.richards at ngmr.net  Wed Oct 17 12:41:20 2012
From: neil.richards at ngmr.net (neil.richards at ngmr.net)
Date: Wed, 17 Oct 2012 12:41:20 +0000
Subject: hg: jdk8/tl/jdk: 8000955: Hashtable.Entry.hashCode() does not conform
	to Map.Entry.hashCode() defined behaviour
Message-ID: <20121017124147.B851D473E1@hg.openjdk.java.net>

Changeset: 5eed4a92ca8c
Author:    ngmr
Date:      2012-10-17 13:35 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5eed4a92ca8c

8000955: Hashtable.Entry.hashCode() does not conform to Map.Entry.hashCode() defined behaviour
Reviewed-by: mduigou, alanb

! src/share/classes/java/util/Hashtable.java
+ test/java/util/Map/EntryHashCode.java



From neil.richards at ngmr.net  Wed Oct 17 12:45:36 2012
From: neil.richards at ngmr.net (Neil Richards)
Date: Wed, 17 Oct 2012 13:45:36 +0100
Subject: RFR: 8000955: Hashtable.Entry.hashCode() no longer conforms to
	Map.Entry.hashCode()
In-Reply-To: <507E91E4.1090808@oracle.com>
References: <1350350989.32636.43.camel@chalkhill>
	<80D657B8-D710-465D-8256-BF999C5D3FC6@oracle.com>
	<1350359609.12688.46.camel@chalkhill>
	<6B8EF0C1-8817-47C2-9CE2-F64FCEC4D9C3@oracle.com>
	<1350429137.11297.13.camel@chalkhill>  <507E91E4.1090808@oracle.com>
Message-ID: <1350477936.10436.1.camel@chalkhill>

Now pushed to jdk8/tl/jdk [1].

Regards,
Neil

[1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5eed4a92ca8c

On Wed, 2012-10-17 at 12:09 +0100, Alan Bateman wrote:
> On 17/10/2012 00:12, Neil Richards wrote:
> > Okay, you convinced me. :)
> >
> > Here's another webrev [1], updated to make use of Objects.hashCode() in
> > the fix (as well as in the testcase).
> >
> > Can I now interest a Reviewer in endorsing this fix ?
> >
> > Thanks,
> > Neil
> >
> > [1] http://cr.openjdk.java.net/~ngmr/8000955/webrev.03/
> >
> >
> It looks to fine to me too.
> 
> -Alan


-- 
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 dmitry.samersoff at oracle.com  Wed Oct 17 15:28:18 2012
From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com)
Date: Wed, 17 Oct 2012 15:28:18 +0000
Subject: hg: jdk8/tl/jdk: 6809322: javax.management.timer.Timer does not fire
	all notifications
Message-ID: <20121017152840.D794A473E6@hg.openjdk.java.net>

Changeset: b2d8a99a049e
Author:    dsamersoff
Date:      2012-10-17 18:34 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b2d8a99a049e

6809322: javax.management.timer.Timer does not fire all notifications
Summary: Some notifications get dropped due to ConcurrentModificationException thrown in Timer.notifyAlarmClock() method.
Reviewed-by: dholmes, rbackman
Contributed-by: jaroslav.bachorik at oracle.com

! src/share/classes/javax/management/timer/Timer.java
+ test/javax/management/timer/MissingNotificationTest.java



From Alan.Bateman at oracle.com  Wed Oct 17 15:39:22 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Oct 2012 16:39:22 +0100
Subject: RFR: 7159567 - inconsistent configuration of MemoryHandler
In-Reply-To: <507C61A0.6080608@oracle.com>
References: <50637167.4060006@oracle.com> <5063BD8C.2010607@oracle.com>
	<50645D19.4050505@oracle.com> <5065F6DD.7010801@oracle.com>
	<5066176D.6040005@oracle.com> <50773C27.3050407@oracle.com>
	<507C61A0.6080608@oracle.com>
Message-ID: <507ED12A.8050200@oracle.com>

On 15/10/2012 20:18, Jim Gish wrote:
> Here's an updated webrev that fixes some javadoc syntax issues: 
> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/ <http://cr.openjdk.java.net/%7Ejgish/Bug7159567-set-logging-MemoryHandler/> 
>
>
> Thanks,
>     Jim
I looked through the javadoc updates and it looks fine to me. One small 
thing is that it looks like the end-list-item (</li>) tags are missing.

-Alan


From christian.thalinger at oracle.com  Wed Oct 17 15:40:59 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 17 Oct 2012 08:40:59 -0700
Subject: RFR (M): 8000989: smaller code changes to make future JSR 292
	backports easier
In-Reply-To: <507E2C00.8070001@oracle.com>
References: <59651530-8ABD-41B7-AE81-850892F7402F@oracle.com>
	<507E2C00.8070001@oracle.com>
Message-ID: <AB690D9F-180C-4978-B024-DA6DB8E39959@oracle.com>


On Oct 16, 2012, at 8:54 PM, David Holmes <david.holmes at oracle.com> wrote:

> Not sure what relevance there is to hotspot :)

I don't expect anyone from the core library team to actually review these changes :-)

> 
> Not meaning to be difficult but why not just apply this change to the 7u code and use the appropriate constructors? As I general rule (there are exceptions eg java.util.concurrent) I don't think the libraries code is written to be directly usable in multiple JDK versions.

It's not about running in different JDK versions.  It's about keeping the merging effort to a minimum when we back port future performance work.

-- Chris

> 
> Or even add a package-private InternalError class that subclasses java.lang.InternalError to add the new constructors? (for 7u)
> 
> David
> 
> 
> On 17/10/2012 4:01 AM, Christian Thalinger wrote:
>> http://cr.openjdk.java.net/~twisti/8000989
>> 
>> 8000989: smaller code changes to make future JSR 292 backports easier
>> Reviewed-by:
>> 
>> In 8 we added two new constructors to InternalError which we use in
>> 292.  Factor InternalError generation to a method to make future
>> backports to 7u easier.
>> 
>> src/share/classes/java/lang/invoke/BoundMethodHandle.java
>> src/share/classes/java/lang/invoke/CallSite.java
>> src/share/classes/java/lang/invoke/DirectMethodHandle.java
>> src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
>> src/share/classes/java/lang/invoke/Invokers.java
>> src/share/classes/java/lang/invoke/LambdaForm.java
>> src/share/classes/java/lang/invoke/MemberName.java
>> src/share/classes/java/lang/invoke/MethodHandle.java
>> src/share/classes/java/lang/invoke/MethodHandleImpl.java
>> src/share/classes/java/lang/invoke/MethodHandleStatics.java
>> src/share/classes/sun/invoke/util/ValueConversions.java
>> test/java/lang/invoke/BigArityTest.java
>> test/java/lang/invoke/PrivateInvokeTest.java
>> 


From maurizio.cimadamore at oracle.com  Wed Oct 17 15:43:48 2012
From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com)
Date: Wed, 17 Oct 2012 15:43:48 +0000
Subject: hg: jdk8/tl/langtools: 7192245: Add parser support for default methods
Message-ID: <20121017154353.16E8E473E7@hg.openjdk.java.net>

Changeset: 12cf6bfd8c05
Author:    mcimadamore
Date:      2012-10-17 16:43 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/12cf6bfd8c05

7192245: Add parser support for default methods
Summary: Add support for 'default' keyword in modifier position
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Flags.java
! src/share/classes/com/sun/tools/javac/code/Source.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java
+ test/tools/javac/diags/examples/DefaultMethodNotSupported.java



From christian.thalinger at oracle.com  Wed Oct 17 15:45:00 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Wed, 17 Oct 2012 08:45:00 -0700
Subject: RFR (S): 8000999: backport of JSR 292 to 7u
In-Reply-To: <507E2D0E.8080100@oracle.com>
References: <83E35F6D-2D0D-44BE-85EC-21C9D6F320B3@oracle.com>
	<507E2D0E.8080100@oracle.com>
Message-ID: <DF6B2CC6-04E6-41A1-925A-EB7134D17129@oracle.com>


On Oct 16, 2012, at 8:59 PM, David Holmes <david.holmes at oracle.com> wrote:

> Hi Christian,
> 
> Is this just a preliminary review request, as actual backport requests have to go to the jdk7u-dev mailing list for approval.

Kind of.  I will pass on the reviewed changes to John Coomes to be integrated in a 7u repository to do PIT.  But I guess I have to send a backport request to jdk7u-dev as well.

> 
> And are these all just bug fixes, or are there any API/spec changes involved?

No API changes.  Just bug fixes (which replaced the whole implementation behind the API).  The HotSpot changes are already in HS24.

-- Chris

> 
> David
> 
> On 17/10/2012 5:54 AM, Christian Thalinger wrote:
>> http://cr.openjdk.java.net/~twisti/8000999
>> 
>> 8000999: backport of JSR 292 to 7u
>> Reviewed-by:
>> 
>> This is an umbrella bug for these changes (which are backported in one
>> changeset):
>> 
>> 6983728: JSR 292 remove argument count limitations
>> 7128512: Javadoc typo in java.lang.invoke.MethodHandle
>> 7117167: Misc warnings in java.lang.invoke and sun.invoke.*
>> 7129034: VM crash with a field setter method with a filterArguments
>> 7087658: MethodHandles.Lookup.findVirtual is confused by interface methods that are multiply inherited
>> 7127687: MethodType leaks memory due to interning
>> 7023639: JSR 292 method handle invocation needs a fast path for compiled code
>> 7188911: nightly failures after JSR 292 lazy method handle update (round 2)
>> 7190416: JSR 292: typo in InvokerBytecodeGenerator.getConstantPoolSize
>> 7191102: nightly failures after JSR 292 lazy method handle update (round 3)
>> 7194612: api/java_lang/invoke/MethodHandles/Lookup/index.html#ExceptionsTests[findVirtualNSME] fails w/ -esa
>> 7194662: JSR 292: PermuteArgsTest times out in nightly test runs
>> 
>> The backport is just copying over the files from JDK 8.  That's why the webrev is so big and pretty useless.  The real changes between 8 and 7 are these:
>> 
>> diff -Nur jdk8/src/share/classes/java/lang/invoke/MethodHandleStatics.java jdk7u/src/share/classes/java/lang/invoke/MethodHandleStatics.java
>> --- jdk8/src/share/classes/java/lang/invoke/MethodHandleStatics.java    2012-10-15 12:21:52.806052959 -0700
>> +++ jdk7u/src/share/classes/java/lang/invoke/MethodHandleStatics.java   2012-10-16 10:48:29.728257304 -0700
>> @@ -94,10 +94,14 @@
>> 
>>      // handy shared exception makers (they simplify the common case code)
>>      /*non-public*/ static InternalError newInternalError(String message, Throwable cause) {
>> -        return new InternalError(message, cause);
>> +        InternalError e = new InternalError(message);
>> +        e.initCause(cause);
>> +        return e;
>>      }
>>      /*non-public*/ static InternalError newInternalError(Throwable cause) {
>> -        return new InternalError(cause);
>> +        InternalError e = new InternalError();
>> +        e.initCause(cause);
>> +        return e;
>>      }
>>      /*non-public*/ static RuntimeException newIllegalStateException(String message) {
>>          return new IllegalStateException(message);
>> diff -Nur jdk8/src/share/classes/sun/invoke/util/ValueConversions.java jdk7u/src/share/classes/sun/invoke/util/ValueConversions.java
>> --- jdk8/src/share/classes/sun/invoke/util/ValueConversions.java        2012-10-16 10:49:36.081911283 -0700
>> +++ jdk7u/src/share/classes/sun/invoke/util/ValueConversions.java       2012-10-16 10:48:19.626424849 -0700
>> @@ -1211,9 +1211,13 @@
>> 
>>      // handy shared exception makers (they simplify the common case code)
>>      private static InternalError newInternalError(String message, Throwable cause) {
>> -        return new InternalError(message, cause);
>> +        InternalError e = new InternalError(message);
>> +        e.initCause(cause);
>> +        return e;
>>      }
>>      private static InternalError newInternalError(Throwable cause) {
>> -        return new InternalError(cause);
>> +        InternalError e = new InternalError();
>> +        e.initCause(cause);
>> +        return e;
>>      }
>>  }
>> diff --git a/src/share/classes/sun/misc/Unsafe.java b/src/share/classes/sun/misc/Unsafe.java
>> --- a/src/share/classes/sun/misc/Unsafe.java
>> +++ b/src/share/classes/sun/misc/Unsafe.java
>> @@ -678,6 +678,14 @@
>>      public native Object staticFieldBase(Field f);
>> 
>>      /**
>> +     * Detect if the given class may need to be initialized. This is often
>> +     * needed in conjunction with obtaining the static field base of a
>> +     * class.
>> +     * @return false only if a call to {@code ensureClassInitialized} would have no effect
>> +     */
>> +    public native boolean shouldBeInitialized(Class c);
>> +
>> +    /**
>>       * Ensure the given class has been initialized. This is often
>>       * needed in conjunction with obtaining the static field base of a
>>       * class.
>> 


From jim.gish at oracle.com  Wed Oct 17 16:41:33 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 17 Oct 2012 12:41:33 -0400
Subject: RFR: 7159567 - inconsistent configuration of MemoryHandler
In-Reply-To: <507ED12A.8050200@oracle.com>
References: <50637167.4060006@oracle.com> <5063BD8C.2010607@oracle.com>
	<50645D19.4050505@oracle.com> <5065F6DD.7010801@oracle.com>
	<5066176D.6040005@oracle.com> <50773C27.3050407@oracle.com>
	<507C61A0.6080608@oracle.com> <507ED12A.8050200@oracle.com>
Message-ID: <507EDFBD.1010608@oracle.com>

Thanks.  I believe </li> tags are optional, and since they weren't there 
before, I didn't put them in.  The generated javadoc looks ok.

Jim

On 10/17/2012 11:39 AM, Alan Bateman wrote:
> On 15/10/2012 20:18, Jim Gish wrote:
>> Here's an updated webrev that fixes some javadoc syntax issues: 
>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/ 
>> <http://cr.openjdk.java.net/%7Ejgish/Bug7159567-set-logging-MemoryHandler/> 
>>
>>
>> Thanks,
>>     Jim
> I looked through the javadoc updates and it looks fine to me. One 
> small thing is that it looks like the end-list-item (</li>) tags are 
> missing.
>
> -Alan

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From jim.gish at oracle.com  Wed Oct 17 18:46:23 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 17 Oct 2012 14:46:23 -0400
Subject: RFR: 7159567 - inconsistent configuration of MemoryHandler
In-Reply-To: <507EDFBD.1010608@oracle.com>
References: <50637167.4060006@oracle.com> <5063BD8C.2010607@oracle.com>
	<50645D19.4050505@oracle.com> <5065F6DD.7010801@oracle.com>
	<5066176D.6040005@oracle.com> <50773C27.3050407@oracle.com>
	<507C61A0.6080608@oracle.com> <507ED12A.8050200@oracle.com>
	<507EDFBD.1010608@oracle.com>
Message-ID: <507EFCFF.9040902@oracle.com>

I just discovered a small syntax error in StreamHandler (thanks to 
specdiff :-)).  I'll regenerate the webrev shortly.

Jim


On 10/17/2012 12:41 PM, Jim Gish wrote:
> Thanks. I believe </li> tags are optional, and since they weren't 
> there before, I didn't put them in.  The generated javadoc looks ok.
>
> Jim
>
> On 10/17/2012 11:39 AM, Alan Bateman wrote:
>> On 15/10/2012 20:18, Jim Gish wrote:
>>> Here's an updated webrev that fixes some javadoc syntax issues: 
>>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/ 
>>> <http://cr.openjdk.java.net/%7Ejgish/Bug7159567-set-logging-MemoryHandler/> 
>>>
>>>
>>> Thanks,
>>>     Jim
>> I looked through the javadoc updates and it looks fine to me. One 
>> small thing is that it looks like the end-list-item (</li>) tags are 
>> missing.
>>
>> -Alan
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From mandy.chung at oracle.com  Wed Oct 17 19:03:37 2012
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Wed, 17 Oct 2012 19:03:37 +0000
Subject: hg: jdk8/tl/jdk: 8001012: jdk8 SKIP_BUILD_CYCLE=false build fails
	with BUILD_JAXWS=false
Message-ID: <20121017190401.7B317473EC@hg.openjdk.java.net>

Changeset: 6156b9235758
Author:    mchung
Date:      2012-10-17 12:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6156b9235758

8001012: jdk8 SKIP_BUILD_CYCLE=false build fails with BUILD_JAXWS=false
Reviewed-by: alanb, ohair

! make/common/internal/Defs-jaxws.gmk



From jim.gish at oracle.com  Wed Oct 17 19:33:33 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 17 Oct 2012 15:33:33 -0400
Subject: RFR: 7159567 - inconsistent configuration of MemoryHandler
In-Reply-To: <507EFCFF.9040902@oracle.com>
References: <50637167.4060006@oracle.com> <5063BD8C.2010607@oracle.com>
	<50645D19.4050505@oracle.com> <5065F6DD.7010801@oracle.com>
	<5066176D.6040005@oracle.com> <50773C27.3050407@oracle.com>
	<507C61A0.6080608@oracle.com> <507ED12A.8050200@oracle.com>
	<507EDFBD.1010608@oracle.com> <507EFCFF.9040902@oracle.com>
Message-ID: <507F080D.1040502@oracle.com>

Fixed.  Just needed to change a <ul> to </ul> in StreamHandler.java

Jim

On 10/17/2012 02:46 PM, Jim Gish wrote:
> I just discovered a small syntax error in StreamHandler (thanks to 
> specdiff :-)).  I'll regenerate the webrev shortly.
>
> Jim
>
>
> On 10/17/2012 12:41 PM, Jim Gish wrote:
>> Thanks. I believe </li> tags are optional, and since they weren't 
>> there before, I didn't put them in.  The generated javadoc looks ok.
>>
>> Jim
>>
>> On 10/17/2012 11:39 AM, Alan Bateman wrote:
>>> On 15/10/2012 20:18, Jim Gish wrote:
>>>> Here's an updated webrev that fixes some javadoc syntax issues: 
>>>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/ 
>>>> <http://cr.openjdk.java.net/%7Ejgish/Bug7159567-set-logging-MemoryHandler/> 
>>>>
>>>>
>>>> Thanks,
>>>>     Jim
>>> I looked through the javadoc updates and it looks fine to me. One 
>>> small thing is that it looks like the end-list-item (</li>) tags are 
>>> missing.
>>>
>>> -Alan
>>
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From alan.bateman at oracle.com  Wed Oct 17 19:34:21 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 17 Oct 2012 19:34:21 +0000
Subject: hg: jdk8/tl/jdk: 7198496: (sl) ServiceLoader.load(Class,
	null) behavior differs from spec
Message-ID: <20121017193446.0D5B6473EF@hg.openjdk.java.net>

Changeset: 586028bbf885
Author:    psandoz
Date:      2012-10-17 20:34 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/586028bbf885

7198496: (sl) ServiceLoader.load(Class, null) behavior differs from spec
Reviewed-by: dholmes, alanb

! src/share/classes/java/util/ServiceLoader.java
! test/java/util/ServiceLoader/Basic.java
! test/java/util/ServiceLoader/basic.sh



From mandy.chung at oracle.com  Wed Oct 17 19:46:57 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 17 Oct 2012 12:46:57 -0700
Subject: RFR: 7159567 - inconsistent configuration of MemoryHandler
In-Reply-To: <50773C27.3050407@oracle.com>
References: <50637167.4060006@oracle.com> <5063BD8C.2010607@oracle.com>
	<50645D19.4050505@oracle.com> <5065F6DD.7010801@oracle.com>
	<5066176D.6040005@oracle.com> <50773C27.3050407@oracle.com>
Message-ID: <507F0B31.6030103@oracle.com>

Hi Jim,

On 10/11/2012 2:37 PM, Jim Gish wrote:
> Please review the updated changes at 
> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/
>

The spec change looks good.  As Alan points out, </li> is missing.  
Although they were not there before, I would think it's a good clean up 
while you are in these files if you agree.

The test looks better.   Is SimpleTargetHandler.numPublished intended to 
be checked?  SimpleTargetHandler is set as the target for 
java.util.logging.MemoryHandler.  I guess you want to create a logger 
using the standard MemoryHandler.

Nit: the test is named MemoryHandler and I guess the name conflict 
causes the custom handler classes to extend 
"java.util.logging.MemoryHandler" with a fully-qualified class name.  As 
the properties file is named MemoryHandlerTest.props, do you consider 
renaming the test to MemoryHandlerTest to avoid the name conflict?   I 
don't have strong opinion and just want to point that out.

L62-64:  better not to rethrow a new RuntimeException as the exception 
and stack trace will help diagnostics if it does go wrong.  You can get 
rid of this try-catch block.

L120: is it a leftover debug statement?  I think you meant to add test 
case to exercise this target handler, right?

> I've changed as you've requested, added some additional tests, did 
> some better error handling in the case of a MemoryHandler not 
> specifying a target (now throws RuntimeException with an appropriate 
> message instead of attempting to load a null class and throwing NPE).  
> I also corrected the copyrights, tested with JCK, all jdk_lang tests 
> and have submitted a JPRT job with core tests.
>

Great.  Thanks for doing it.

Mandy

> I've forwarded a CCC request (separately) and will await its approval 
> and further review of this change.
>
> Thanks,
>     Jim
>
> On 09/28/2012 05:32 PM, Mandy Chung wrote:
>> On 9/28/2012 12:13 PM, Jim Gish wrote:
>>> I've re-spun the change with additional usage notes in the spec to 
>>> reflect the long-standing actual behavior.  Note that it doesn't 
>>> change the spec per se, as it was already stated in LogManager. This 
>>> change simply replicates that language with an example in each 
>>> *Handler class to make it easier to find.
>>>
>>
>> Thanks for looking into it.  This statement in LogManager does
>> specify the properties for handlers:
>>
>>   The properties for loggers and Handlers will have names starting
>>   with the dot-separated name for the handler or logger.
>>
>> Replicating that statement with an example is one way to do it.
>> Would it be clearer if the prefix of the properties referenced
>> in the bullet list is replaced from "java.util.logging" to
>> some kind of prefix - something like this:
>>
>>  *<b>Configuration:</b>
>>  * By default each<tt>ConsoleHandler</tt>  is initialized using the 
>> following
>>  *<tt>LogManager</tt>  configuration properties.  If properties are 
>> not defined
>>  * (or have invalid values) then the specified default values are used.
>>  *<ul>
>>  *<li> <handler's classname>.level
>>  *        specifies the default level for the<tt>Handler</tt>
>>  *        (defaults to<tt>Level.INFO</tt>).
>>  ...<snip>
>>  *</ul>
>>  *
>>  * For example, the properties for {@code ConsoleHandler} would be:
>>  *     java.util.logging.ConsoleHandler.level=INFO
>>  * 
>> java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
>>  *
>>  * For a custom handler, e.g. com.foo.MyHandler, the properties would 
>> be:
>>  *     com.foo.MyHandler.level=INFO
>>  * com.foo.MyHandler.formatter=java.util.logging.SimpleFormatter
>>
>> This might add some clarity to the spec.
>>
>> This is a spec bug fix that I would suggest to file a CCC to
>> track for compatibility.  I would also suggest running the JCK
>> tests to find out if there is any regression due to this fix.
>>
>>
>>> The webrev, as posted at 
>>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/
>>
>> See my comment above w.r.t. the spec change.
>>
>> test/java/util/logging/MemoryHandler.java
>>   L27: "via via" typo
>>   L28: @run tag specifies the test name
>>        So it should be @run main/othervm MemoryHandler
>>
>>   L43: jtreg runs the test in a different working directory
>>   other than the test source.  So the test has to read
>>   the system property ("test.src") to determine the location
>>   of the properties file.  Typically, we will do this:
>>     String src = System.getProperty("test.src", ".);
>>     File   fname  = new File(src, LM_PROP_FNAME);
>>
>>   You don't need L44. You can reference LoggingDeadlock3.java test.
>>
>>   L51: this catch block to throw a RuntimeException doesn't seem
>>   necessary.  If NPE is thrown, the test will fail anyway.
>>
>>   One suggestion to the test is to test both cases (one with
>>   the specified target handler and one without).  You can
>>   define a custom target handler so that the test can verify
>>   if the expected one is used.  A simple handler to count
>>   the number of log messages will do the work.
>>
>> test/java/util/logging/MemoryHandlerTest.props
>>   I suggest to take out the comments and just keep the
>>   properties the test needs to make it easier to tell
>>   what's configured.
>>   Perhaps you should also specify
>>   java.util.logging.MemoryHandler.target to make sure
>>   that the custom handler with no target handler specified
>>   will not use j.u.l.MemoryHandler.target as the default.
>>
>> Mandy
>>
>


From alan.bateman at oracle.com  Wed Oct 17 20:13:49 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 17 Oct 2012 20:13:49 +0000
Subject: hg: jdk8/tl/jdk: 8000362: (pack200) Deprecate Packer/Unpacker
	addPropertyChangeLister and removePropertyChangeListener methods
Message-ID: <20121017201412.EC0B5473F0@hg.openjdk.java.net>

Changeset: b265ead7f331
Author:    alanb
Date:      2012-10-17 21:05 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b265ead7f331

8000362: (pack200) Deprecate Packer/Unpacker addPropertyChangeLister and removePropertyChangeListener methods
Reviewed-by: lancea, chegar, mchung, ksrini

! src/share/classes/java/util/jar/Pack200.java



From naoto.sato at oracle.com  Wed Oct 17 20:23:38 2012
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 17 Oct 2012 20:23:38 +0000
Subject: hg: jdk8/tl/jdk: 8001046:
	java/util/PluggableLocale/LocaleNameProviderTest.sh failing
Message-ID: <20121017202352.DE3D2473F1@hg.openjdk.java.net>

Changeset: 60994591be6b
Author:    naoto
Date:      2012-10-17 13:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60994591be6b

8001046: java/util/PluggableLocale/LocaleNameProviderTest.sh failing
Reviewed-by: okutsu

! test/java/util/PluggableLocale/barprovider.jar



From xueming.shen at oracle.com  Thu Oct 18 02:10:25 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 17 Oct 2012 19:10:25 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5077F75D.2020003@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com>
Message-ID: <507F6511.10309@oracle.com>

Hi

Webrev has been updated with following changes

(1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
(2) some minor spec clarification regarding the "end of decoding"
(3) performance tuning.

webrev:
http://cr.openjdk.java.net/~sherman/4235519/webrev

some performance scores:
http://cr.openjdk.java.net/~sherman/4235519/score3

-Sherman


From xuelei.fan at oracle.com  Thu Oct 18 08:15:04 2012
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Thu, 18 Oct 2012 08:15:04 +0000
Subject: hg: jdk8/tl/jdk: 7068321: Support TLS Server Name Indication (SNI)
	Extension in JSSE Server
Message-ID: <20121018081542.3F0824740F@hg.openjdk.java.net>

Changeset: 3f62cfc4e83d
Author:    xuelei
Date:      2012-10-18 01:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f62cfc4e83d

7068321: Support TLS Server Name Indication (SNI) Extension in JSSE Server
Reviewed-by: mullan, weijun, wetmore

! src/share/classes/javax/net/ssl/ExtendedSSLSession.java
! src/share/classes/javax/net/ssl/HandshakeCompletedEvent.java
+ src/share/classes/javax/net/ssl/SNIHostName.java
+ src/share/classes/javax/net/ssl/SNIMatcher.java
+ src/share/classes/javax/net/ssl/SNIServerName.java
! src/share/classes/javax/net/ssl/SSLEngine.java
! src/share/classes/javax/net/ssl/SSLParameters.java
! src/share/classes/javax/net/ssl/SSLServerSocket.java
! src/share/classes/javax/net/ssl/SSLSocket.java
! src/share/classes/javax/net/ssl/SSLSocketFactory.java
+ src/share/classes/javax/net/ssl/StandardConstants.java
! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java
! src/share/classes/sun/security/ssl/ClientHandshaker.java
! src/share/classes/sun/security/ssl/HandshakeInStream.java
! src/share/classes/sun/security/ssl/HandshakeMessage.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/HelloExtensions.java
! src/share/classes/sun/security/ssl/ProtocolList.java
! src/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java
! src/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/share/classes/sun/security/ssl/ServerHandshaker.java
! src/share/classes/sun/security/ssl/SunJSSE.java
+ src/share/classes/sun/security/ssl/Utilities.java
! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java
! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/SSLEngineService.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorer.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerUnmatchedSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithCli.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithSrv.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketConsistentSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorer.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerMatchedSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerUnmatchedSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithCliSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithSrvSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketInconsistentSNI.java
+ test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java
+ test/sun/security/ssl/templates/SSLCapabilities.java
+ test/sun/security/ssl/templates/SSLExplorer.java



From Ulf.Zibis at CoSoCo.de  Thu Oct 18 13:19:47 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 18 Oct 2012 15:19:47 +0200
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <507F6511.10309@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
Message-ID: <508001F3.1050701@CoSoCo.de>

Hi Sherman,

you could create the code table by help of a String constant, which would speed up the loading and 
save a little footprint on the class file. (you have forgotten those tricks from sun.nio.cs coders? 
;-) )

But my main question:
Why don't you enqueue those coders in the well known sun.nio.cs.ext provider?
At least, I think, class Base64 should be hosted in java.nio.charset rather than common java.util.
As I believe, that the usage of this encoding is far from common, adding it to the lazy loaded 
charsets.jar IMO should be more reasonable.

-Ulf


Am 18.10.2012 04:10, schrieb Xueming Shen:
> Hi
>
> Webrev has been updated with following changes
>
> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
> (2) some minor spec clarification regarding the "end of decoding"
> (3) performance tuning.
>
> webrev:
> http://cr.openjdk.java.net/~sherman/4235519/webrev
>
> some performance scores:
> http://cr.openjdk.java.net/~sherman/4235519/score3
>
> -Sherman
>



From xueming.shen at oracle.com  Thu Oct 18 14:04:49 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 18 Oct 2012 07:04:49 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <508001F3.1050701@CoSoCo.de>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508001F3.1050701@CoSoCo.de>
Message-ID: <50800C81.7030501@oracle.com>


On 10/18/2012 6:19 AM, Ulf Zibis wrote:
> Hi Sherman,
>
> you could create the code table by help of a String constant, which 
> would speed up the loading and save a little footprint on the class 
> file. (you have forgotten those tricks from sun.nio.cs coders? ;-) )

The implementation probably needs more tuning.

>
> But my main question:
> Why don't you enqueue those coders in the well known sun.nio.cs.ext 
> provider?

Base64 encoding is not a charset. Mainly it is supposed to be 
byte[]<->byte[] coding.
Even for byte[]<=>char[]/String, Base64 "encode" byte[] to char[]/String 
and "decode"
from char[]/String to byte[]. The "wrong" direction compared to charset 
en/decoder.

> At least, I think, class Base64 should be hosted in java.nio.charset 
> rather than common java.util.
> As I believe, that the usage of this encoding is far from common

you might be surprised how "common" it might be:-)

-Sherman

> , adding it to the lazy loaded charsets.jar IMO should be more 
> reasonable.
>
> -Ulf
>
>
> Am 18.10.2012 04:10, schrieb Xueming Shen:
>> Hi
>>
>> Webrev has been updated with following changes
>>
>> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
>> (2) some minor spec clarification regarding the "end of decoding"
>> (3) performance tuning.
>>
>> webrev:
>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>
>> some performance scores:
>> http://cr.openjdk.java.net/~sherman/4235519/score3
>>
>> -Sherman
>>
>



From Alan.Bateman at oracle.com  Thu Oct 18 14:14:10 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Oct 2012 15:14:10 +0100
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <508001F3.1050701@CoSoCo.de>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508001F3.1050701@CoSoCo.de>
Message-ID: <50800EB2.1000706@oracle.com>

On 18/10/2012 14:19, Ulf Zibis wrote:
> Hi Sherman,
>
> you could create the code table by help of a String constant, which 
> would speed up the loading and save a little footprint on the class 
> file. (you have forgotten those tricks from sun.nio.cs coders? ;-) )
>
> But my main question:
> Why don't you enqueue those coders in the well known sun.nio.cs.ext 
> provider?
> At least, I think, class Base64 should be hosted in java.nio.charset 
> rather than common java.util.
> As I believe, that the usage of this encoding is far from common, 
> adding it to the lazy loaded charsets.jar IMO should be more reasonable.
The encoders and decoders in java.nio.charset are for translating 
between bytes and Unicode characters and that is not the case here. I 
think java.util is probably the right place for this.

-Alan


From Alan.Bateman at oracle.com  Thu Oct 18 14:43:44 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Oct 2012 15:43:44 +0100
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <507F6511.10309@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
Message-ID: <508015A0.9070903@oracle.com>

On 18/10/2012 03:10, Xueming Shen wrote:
> Hi
>
> Webrev has been updated with following changes
>
> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
> (2) some minor spec clarification regarding the "end of decoding"
> (3) performance tuning.
>
> webrev:
> http://cr.openjdk.java.net/~sherman/4235519/webrev
>
> some performance scores:
> http://cr.openjdk.java.net/~sherman/4235519/score3
>
> -Sherman
Have you done any performance tuning on the new methods that 
encode/decode into an existing ByteBuffer? Just wondering as the direct 
buffer case seems more expensive that I would expect. It would be 
interesting to see using the put(int,byte) and fixing up the position at 
the end would help. It might also be something to look at with the 
compiler folks.

In any case, I think encode(ByteBuffer,ByteBuffer,int) looks reasonable 
and just requires using the idiom to get it right. I'm less sure about 
decode returning a boolean. Shouldn't it be an error if there are bytes 
remaining after the = padding? I'm just looking for ways to allow the 
method return an int to indicate the number of bytes written to the 
output buffer (and realize that we aren't going to get symmetry with the 
encode method).

-Alan.



From xueming.shen at oracle.com  Thu Oct 18 15:12:18 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 18 Oct 2012 08:12:18 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <508015A0.9070903@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508015A0.9070903@oracle.com>
Message-ID: <50801C52.5090509@oracle.com>

On 10/18/12 7:43 AM, Alan Bateman wrote:
> On 18/10/2012 03:10, Xueming Shen wrote:
>> Hi
>>
>> Webrev has been updated with following changes
>>
>> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
>> (2) some minor spec clarification regarding the "end of decoding"
>> (3) performance tuning.
>>
>> webrev:
>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>
>> some performance scores:
>> http://cr.openjdk.java.net/~sherman/4235519/score3
>>
>> -Sherman
> Have you done any performance tuning on the new methods that 
> encode/decode into an existing ByteBuffer? Just wondering as the 
> direct buffer case seems more expensive that I would expect. It would 
> be interesting to see using the put(int,byte) and fixing up the 
> position at the end would help. It might also be something to look at 
> with the compiler folks.

no "real" tuning yet on the direct buffer case. Just tried to get the 
API out for review/comment first.

  

>
> In any case, I think encode(ByteBuffer,ByteBuffer,int) looks 
> reasonable and just requires using the idiom to get it right. I'm less 
> sure about decode returning a boolean. Shouldn't it be an error if 
> there are bytes remaining after the = padding? 

It depends on expectation. Padding partially serves as a "end of base64 
byte stream" indicator.

> I'm just looking for ways to allow the method return an int to 
> indicate the number of bytes written to the output buffer (and realize 
> that we aren't going to get symmetry with the encode method).

Yes, even a "int" return value will not get us the symmetry with 
encode(bb, bb). A boolean return provides
a more liberal behavior.

-Sherman
>



From Ulf.Zibis at CoSoCo.de  Thu Oct 18 15:27:26 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 18 Oct 2012 17:27:26 +0200
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <50800C81.7030501@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508001F3.1050701@CoSoCo.de> <50800C81.7030501@oracle.com>
Message-ID: <50801FDE.3090604@CoSoCo.de>

Am 18.10.2012 16:04, schrieb Xueming Shen:
>
> On 10/18/2012 6:19 AM, Ulf Zibis wrote:

Oops, you are working at 6 in the morning?

>> Hi Sherman,
>>
>> you could create the code table by help of a String constant, which would speed up the loading 
>> and save a little footprint on the class file. (you have forgotten those tricks from sun.nio.cs 
>> coders? ;-) )
>
> The implementation probably needs more tuning.

Hopefully, some day we have arrays of primitive types in the class file's constant pool.

>> But my main question:
>> Why don't you enqueue those coders in the well known sun.nio.cs.ext provider?
>
> Base64 encoding is not a charset. Mainly it is supposed to be byte[]<->byte[] coding.
> Even for byte[]<=>char[]/String, Base64 "encode" byte[] to char[]/String and "decode"
> from char[]/String to byte[]. The "wrong" direction compared to charset en/decoder.

1:0 for you.
I only had the ASCII/Unicode characters -> Base64 "en"coding in mind, which seems in fact a 
Java-String to byte[] to char[]/String 2-step-encoding.

>
>> At least, I think, class Base64 should be hosted in java.nio.charset rather than common java.util.
>> As I believe, that the usage of this encoding is far from common
>
> you might be surprised how "common" it might be:-)

or surprised, why it wasn't part of the JDK before.

-Ulf



From schierlm at gmx.de  Thu Oct 18 18:01:47 2012
From: schierlm at gmx.de (Michael Schierl)
Date: Thu, 18 Oct 2012 20:01:47 +0200
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <507F6511.10309@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
Message-ID: <5080440B.2030104@gmx.de>

Am 18.10.2012 04:10, schrieb Xueming Shen:
> Hi
> 
> Webrev has been updated with following changes
> 
> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods

I think line 443 needs an additional check for atom == 0. Same for the
array case. At least if you do not want an endOfInput flag in the
parameters. If you have an endOfInput flag, you can use that in the
condition instead of atom == 0.

Consider this example where trying to encode 25 bytes using an input
ByteBuffer of 16 bytes and an output ByteBuffer of 32 bytes (Of course,
you'd use larger buffers in practice, but the same can happen with
larger buffers too, as long as your buffer size is not divisible by
three, or you do not completely fill the buffer with each read. Both can
happen if the media you are reading from uses a different sector/block
size - like when attaching a base64 attachment of a large file from disk
to an email).

First you fill 16 bytes of input into input buffer, then you call encode
the first time. it will encode the first 15 bytes to 20 bytes of output,
then encode the 16th byte to XY==. You flush the output and fill the
next 9 bytes into the input buffer. The next call to encode will encode
the 9 bytes to 12 bytes. So, in total you have 36 bytes, but the padding
is in the middle.

With the check, the first call will encode the first 15 bytes to 20
bytes of output and leave the 16th byte in the buffer. You flush the
output and load 9 bytes to the 1 remaining byte in the input buffer. The
second call will encode the first 9 bytes to 12 bytes and leave one byte
left over. You flush the buffer and call a third time, which will encode
the last byte to XY==. Still 36 bytes, this time with padding at the end.


Regards,


Michael


From xueming.shen at oracle.com  Thu Oct 18 19:45:42 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 18 Oct 2012 12:45:42 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5080440B.2030104@gmx.de>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<5080440B.2030104@gmx.de>
Message-ID: <50805C66.1050300@oracle.com>

Michael,


The current approach assumes that the base64 en/decoding of a file, stream
will be handled by the en/decoder.wrap(...). The en/decode(bb, bb) is 
basically
for one time invocation input and output from/to existing buffers, with the
hope of avoiding the coding-life-circle management, so it assumes all input
will be passed in in the src buffer and only needs limit support for 
cases that
the existing output buffer is not sufficient. We will probably have to 
go with
the "endOfInput" flag approach, if the current version is still not 
enough for
most of "common" use cases.

-Sherman


On 10/18/2012 11:01 AM, Michael Schierl wrote:
> Am 18.10.2012 04:10, schrieb Xueming Shen:
>> Hi
>>
>> Webrev has been updated with following changes
>>
>> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
> I think line 443 needs an additional check for atom == 0. Same for the
> array case. At least if you do not want an endOfInput flag in the
> parameters. If you have an endOfInput flag, you can use that in the
> condition instead of atom == 0.
>
> Consider this example where trying to encode 25 bytes using an input
> ByteBuffer of 16 bytes and an output ByteBuffer of 32 bytes (Of course,
> you'd use larger buffers in practice, but the same can happen with
> larger buffers too, as long as your buffer size is not divisible by
> three, or you do not completely fill the buffer with each read. Both can
> happen if the media you are reading from uses a different sector/block
> size - like when attaching a base64 attachment of a large file from disk
> to an email).
>
> First you fill 16 bytes of input into input buffer, then you call encode
> the first time. it will encode the first 15 bytes to 20 bytes of output,
> then encode the 16th byte to XY==. You flush the output and fill the
> next 9 bytes into the input buffer. The next call to encode will encode
> the 9 bytes to 12 bytes. So, in total you have 36 bytes, but the padding
> is in the middle.
>
> With the check, the first call will encode the first 15 bytes to 20
> bytes of output and leave the 16th byte in the buffer. You flush the
> output and load 9 bytes to the 1 remaining byte in the input buffer. The
> second call will encode the first 9 bytes to 12 bytes and leave one byte
> left over. You flush the buffer and call a third time, which will encode
> the last byte to XY==. Still 36 bytes, this time with padding at the end.
>
>
> Regards,
>
>
> Michael



From mike.duigou at oracle.com  Thu Oct 18 20:07:39 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Thu, 18 Oct 2012 13:07:39 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <507F6511.10309@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
Message-ID: <F1CD4B8A-31C1-465F-893D-93957DB6A693@oracle.com>

I wonder if there would be advantage in using a SharedSecrets mechanism to allow construction of a String directly from a char array. The intermediate byte array seems wasteful especially for what is likely to be a heavily used path.

Mike

On Oct 17 2012, at 19:10 , Xueming Shen wrote:

> Hi
> 
> Webrev has been updated with following changes
> 
> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
> (2) some minor spec clarification regarding the "end of decoding"
> (3) performance tuning.
> 
> webrev:
> http://cr.openjdk.java.net/~sherman/4235519/webrev
> 
> some performance scores:
> http://cr.openjdk.java.net/~sherman/4235519/score3
> 
> -Sherman



From kurchi.subhra.hazra at oracle.com  Thu Oct 18 20:34:15 2012
From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra)
Date: Thu, 18 Oct 2012 13:34:15 -0700
Subject: [7u12] Request for approval: 7198073: (prefs) user prefs not saved
	[macosx]
In-Reply-To: <503BBEC0.20105@oracle.com>
References: <503BBEC0.20105@oracle.com>
Message-ID: <508067C7.7050703@oracle.com>


This is a request for approval to backport the fix for 7198073 from 8 to 
7u12.

Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198073
Webrev: http://cr.openjdk.java.net/~khazra/7198073/7u12/webrev/

This change been reviewed by Alan Bateman [1] and the fix has been 
pushed into jdk8 [2].
The fix for 7u12 is identical.

Thanks,
Kurchi

[1]http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-October/011767.html
[2]http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a6b76a468bd


From christos at zoulas.com  Thu Oct 18 21:02:43 2012
From: christos at zoulas.com (Christos Zoulas)
Date: Thu, 18 Oct 2012 17:02:43 -0400
Subject: bug fix for native kerberos libraries
Message-ID: <20121018210243.DC05597124@rebar.astron.com>

Hello,

This simple fix allows kerberos authentication to work with:

	-Dsun.security.jgss.native=true

and microsoft's sqljdbc 4.0.2206.100 driver.

Enjoy,

christos

--- a/java/src/sun/security/jgss/GSSUtil.java   Mon Oct 15 17:43:08 2012 -0400
+++ b/java/src/sun/security/jgss/GSSUtil.java   Mon Oct 15 17:44:28 2012 -0400
@@ -333,10 +333,19 @@
                         Subject accSubj = Subject.getSubject(acc);
                         Vector<GSSCredentialSpi> result = null;
                         if (accSubj != null) {
-                            result = new Vector<GSSCredentialSpi>();
                             Iterator<GSSCredentialImpl> iterator =
                                 accSubj.getPrivateCredentials
                                 (GSSCredentialImpl.class).iterator();
+                            // GSSCredentialImpl is only implemented in
+                            // the non-native kerberos implementation,
+                            // so if we don't get any elements here
+                            // assume native and return null so that
+                            // searchSubject does not fail. A better
+                            // fix is to implement the code that handles
+                            // this in native java.
+                            if (!iterator.hasNext())
+                                return null;
+                            result = new Vector<GSSCredentialSpi>();
                             while (iterator.hasNext()) {
                                 GSSCredentialImpl cred = iterator.next();
                                 debug("...Found cred" + cred);



From sean.mullan at oracle.com  Thu Oct 18 21:26:10 2012
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 18 Oct 2012 17:26:10 -0400
Subject: bug fix for native kerberos libraries
In-Reply-To: <20121018210243.DC05597124@rebar.astron.com>
References: <20121018210243.DC05597124@rebar.astron.com>
Message-ID: <508073F2.2020002@oracle.com>


(Forwarding to security-dev as this should be discussed in that group, not
core-libs).

On 10/18/12 5:02 PM, christos at zoulas.com wrote:
> Hello,
> 
> This simple fix allows kerberos authentication to work with:
> 
> 	-Dsun.security.jgss.native=true
> 
> and microsoft's sqljdbc 4.0.2206.100 driver.
> 
> Enjoy,
> 
> christos
> 
> --- a/java/src/sun/security/jgss/GSSUtil.java   Mon Oct 15 17:43:08 2012 -0400
> +++ b/java/src/sun/security/jgss/GSSUtil.java   Mon Oct 15 17:44:28 2012 -0400
> @@ -333,10 +333,19 @@
>                          Subject accSubj = Subject.getSubject(acc);
>                          Vector<GSSCredentialSpi> result = null;
>                          if (accSubj != null) {
> -                            result = new Vector<GSSCredentialSpi>();
>                              Iterator<GSSCredentialImpl> iterator =
>                                  accSubj.getPrivateCredentials
>                                  (GSSCredentialImpl.class).iterator();
> +                            // GSSCredentialImpl is only implemented in
> +                            // the non-native kerberos implementation,
> +                            // so if we don't get any elements here
> +                            // assume native and return null so that
> +                            // searchSubject does not fail. A better
> +                            // fix is to implement the code that handles
> +                            // this in native java.
> +                            if (!iterator.hasNext())
> +                                return null;
> +                            result = new Vector<GSSCredentialSpi>();
>                              while (iterator.hasNext()) {
>                                  GSSCredentialImpl cred = iterator.next();
>                                  debug("...Found cred" + cred);
> 


From xueming.shen at oracle.com  Thu Oct 18 21:45:31 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 18 Oct 2012 14:45:31 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <508015A0.9070903@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508015A0.9070903@oracle.com>
Message-ID: <5080787B.4030903@oracle.com>

On 10/18/2012 07:43 AM, Alan Bateman wrote:
> On 18/10/2012 03:10, Xueming Shen wrote:
>> Hi
>>
>> Webrev has been updated with following changes
>>
>> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
>> (2) some minor spec clarification regarding the "end of decoding"
>> (3) performance tuning.
>>
>> webrev:
>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>
>> some performance scores:
>> http://cr.openjdk.java.net/~sherman/4235519/score3
>>
>> -Sherman
> Have you done any performance tuning on the new methods that 
> encode/decode into an existing ByteBuffer? Just wondering as the 
> direct buffer case seems more expensive that I would expect. It would 
> be interesting to see using the put(int,byte) and fixing up the 
> position at the end would help. It might also be something to look at 
> with the compiler folks.

get(index) and put(index, byte) do help, see 20%+ improvement.

sherman at sherman-linux:~/Workspace/jdk8/test/java/util/Base64$ java 
PermBase64 200000 1000
  j.u.Base64.encode(ba)      : 702000
  j.u.Base64.encode(bb)      : 690024
  j.u.Base64.encode(bb, bb)  : 910582
  j.u.Base64.encode(bb, bb)-D: 1198606
   migBase64.encode(ba)      : 661271
------------------
  j.u.Base64.decode(ba)      : 797152
  j.u.Base64.decode(bb)      : 802968
  j.u.Base64.decode(bb, bb)  : 999577
  j.u.Base64.decode(bb, bb)-D: 1472003
   migBase64.decode(ba)      : 1458450

webrev has been updated accordingly. Now implementations of
de/encodeArray and de/encodeBuffer are identical except the
access operation.

-Sherman



From christian.thalinger at oracle.com  Thu Oct 18 21:43:09 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 18 Oct 2012 14:43:09 -0700
Subject: RFR (XXS): 6771058: TEST_BUG: java/lang/ref/Basic.java may fail with
	-server -Xcomp
Message-ID: <61FF2EC4-18EF-4937-9738-A987CB1DEE9F@oracle.com>

http://cr.openjdk.java.net/~twisti/6771058

6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp
Reviewed-by:

This test can fail if finalizer of Basic is not called for some
reason.  It happens in compiled mode if compilation is more slow than
execution of the main loop.

The fix is to call System.runFinalization() after System.gc() to
ensure that finalizer is run.

test/java/lang/ref/Basic.java



From mandy.chung at oracle.com  Thu Oct 18 22:31:34 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 18 Oct 2012 15:31:34 -0700
Subject: RFR (XXS): 6771058: TEST_BUG: java/lang/ref/Basic.java may fail
	with -server -Xcomp
In-Reply-To: <61FF2EC4-18EF-4937-9738-A987CB1DEE9F@oracle.com>
References: <61FF2EC4-18EF-4937-9738-A987CB1DEE9F@oracle.com>
Message-ID: <50808346.8020702@oracle.com>

Hi Christian,

Thanks for taking on this bug.

Just curious - the test runs with a max of 10 GCs. You
reproduced this bug on a slower machine with fastdebug build.
If you increase the max number of GCs, I wonder how long
the test will take to complete/pass?

With your fix, how many GC does it take to complete?
I suspect it's one.  I am guessing that the test might
want to test that the finalizers are being invoked during
GC and references are dequeued.  I wonder if there is
another alternate fix instead of forcing the finalizers
to be run.  Just a thought.

Mandy


On 10/18/2012 2:43 PM, Christian Thalinger wrote:
> http://cr.openjdk.java.net/~twisti/6771058
>
> 6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp
> Reviewed-by:
>
> This test can fail if finalizer of Basic is not called for some
> reason.  It happens in compiled mode if compilation is more slow than
> execution of the main loop.
>
> The fix is to call System.runFinalization() after System.gc() to
> ensure that finalizer is run.
>
> test/java/lang/ref/Basic.java
>


From christian.thalinger at oracle.com  Thu Oct 18 22:37:36 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 18 Oct 2012 15:37:36 -0700
Subject: RFR (XXS): 6771058: TEST_BUG: java/lang/ref/Basic.java may fail
	with -server -Xcomp
In-Reply-To: <50808346.8020702@oracle.com>
References: <61FF2EC4-18EF-4937-9738-A987CB1DEE9F@oracle.com>
	<50808346.8020702@oracle.com>
Message-ID: <ADA6CBF5-2888-4E74-9D1F-6895F1E118F0@oracle.com>


On Oct 18, 2012, at 3:31 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> Hi Christian,
> 
> Thanks for taking on this bug.

Sure.  I'm trying to get HotSpot nightly failures down.

> 
> Just curious - the test runs with a max of 10 GCs. You
> reproduced this bug on a slower machine with fastdebug build.
> If you increase the max number of GCs, I wonder how long
> the test will take to complete/pass?

Around 14 GCs (runtime with -Xcomp approximately 40 seconds on that particular machine).

> 
> With your fix, how many GC does it take to complete?
> I suspect it's one.  

Between 2 and 3 GCs.

> I am guessing that the test might
> want to test that the finalizers are being invoked during
> GC and references are dequeued.  I wonder if there is
> another alternate fix instead of forcing the finalizers
> to be run.  Just a thought.

The fix was not my idea.  I just picked the bug and tried the suggested fix and it worked.  The other suggested fix is to increase the sleep time (but I don't like that).

-- Chris

> 
> Mandy
> 
> 
> On 10/18/2012 2:43 PM, Christian Thalinger wrote:
>> http://cr.openjdk.java.net/~twisti/6771058
>> 
>> 6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp
>> Reviewed-by:
>> 
>> This test can fail if finalizer of Basic is not called for some
>> reason.  It happens in compiled mode if compilation is more slow than
>> execution of the main loop.
>> 
>> The fix is to call System.runFinalization() after System.gc() to
>> ensure that finalizer is run.
>> 
>> test/java/lang/ref/Basic.java
>> 



From mandy.chung at oracle.com  Thu Oct 18 23:04:28 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 18 Oct 2012 16:04:28 -0700
Subject: RFR (XXS): 6771058: TEST_BUG: java/lang/ref/Basic.java may fail
	with -server -Xcomp
In-Reply-To: <ADA6CBF5-2888-4E74-9D1F-6895F1E118F0@oracle.com>
References: <61FF2EC4-18EF-4937-9738-A987CB1DEE9F@oracle.com>
	<50808346.8020702@oracle.com>
	<ADA6CBF5-2888-4E74-9D1F-6895F1E118F0@oracle.com>
Message-ID: <50808AFC.10401@oracle.com>

On 10/18/2012 3:37 PM, Christian Thalinger wrote:
>
>> Just curious - the test runs with a max of 10 GCs. You
>> reproduced this bug on a slower machine with fastdebug build.
>> If you increase the max number of GCs, I wonder how long
>> the test will take to complete/pass?
> Around 14 GCs (runtime with -Xcomp approximately 40 seconds on that particular machine).

Would increasing the max to 20 fix this bug?  I don't have
a strong objection to call System.runFinalization.  As I don't
know what behavior the test wants to cover, adjusting the
number of max GC invocations seems a good alternative.

Mandy



From christian.thalinger at oracle.com  Thu Oct 18 23:24:33 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Thu, 18 Oct 2012 16:24:33 -0700
Subject: RFR (XXS): 6771058: TEST_BUG: java/lang/ref/Basic.java may fail
	with -server -Xcomp
In-Reply-To: <50808AFC.10401@oracle.com>
References: <61FF2EC4-18EF-4937-9738-A987CB1DEE9F@oracle.com>
	<50808346.8020702@oracle.com>
	<ADA6CBF5-2888-4E74-9D1F-6895F1E118F0@oracle.com>
	<50808AFC.10401@oracle.com>
Message-ID: <6DBE76F7-BE1B-4FBB-B623-B81E5B2C9C65@oracle.com>


On Oct 18, 2012, at 4:04 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> On 10/18/2012 3:37 PM, Christian Thalinger wrote:
>> 
>>> Just curious - the test runs with a max of 10 GCs. You
>>> reproduced this bug on a slower machine with fastdebug build.
>>> If you increase the max number of GCs, I wonder how long
>>> the test will take to complete/pass?
>> Around 14 GCs (runtime with -Xcomp approximately 40 seconds on that particular machine).
> 
> Would increasing the max to 20 fix this bug?  I don't have
> a strong objection to call System.runFinalization.  As I don't
> know what behavior the test wants to cover, adjusting the
> number of max GC invocations seems a good alternative.

I have no idea either.  It's a very old test from Mark.  I would be fine with increasing the GC count but for even slower machines (VMs) it might not be enough.

-- Chris

> 
> Mandy
> 



From david.holmes at oracle.com  Fri Oct 19 00:50:58 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Oct 2012 10:50:58 +1000
Subject: RFR (XXS): 6771058: TEST_BUG: java/lang/ref/Basic.java may fail
	with -server -Xcomp
In-Reply-To: <ADA6CBF5-2888-4E74-9D1F-6895F1E118F0@oracle.com>
References: <61FF2EC4-18EF-4937-9738-A987CB1DEE9F@oracle.com>
	<50808346.8020702@oracle.com>
	<ADA6CBF5-2888-4E74-9D1F-6895F1E118F0@oracle.com>
Message-ID: <5080A3F2.9020109@oracle.com>

Hi Chris,

On 19/10/2012 8:37 AM, Christian Thalinger wrote:
> On Oct 18, 2012, at 3:31 PM, Mandy Chung<mandy.chung at oracle.com>  wrote:
>> Just curious - the test runs with a max of 10 GCs. You
>> reproduced this bug on a slower machine with fastdebug build.
>> If you increase the max number of GCs, I wonder how long
>> the test will take to complete/pass?
>
> Around 14 GCs (runtime with -Xcomp approximately 40 seconds on that particular machine).
>
>>
>> With your fix, how many GC does it take to complete?
>> I suspect it's one.
>
> Between 2 and 3 GCs.

I believe it takes two GC cycles to move a finalizable object into the 
finalization queue.

>> I am guessing that the test might
>> want to test that the finalizers are being invoked during
>> GC and references are dequeued.  I wonder if there is
>> another alternate fix instead of forcing the finalizers
>> to be run.  Just a thought.
>
> The fix was not my idea.  I just picked the bug and tried the suggested fix and it worked.  The other suggested fix is to increase the sleep time (but I don't like that).

The key here is what the test is trying to exercise. From this comment:

  /* Cause a dummy object to be finalized, since the finalizer thread
     might retain a reference to the Basic instance after it's been
     finalized (this happens with java_g) */

we can see there is some intended interaction with the (primary) 
finalizer thread. By calling runFinalization() we're introducing the 
secondary finalizer thread and performing synchronous finalization - 
which may (or may not) negate the intended interaction with the primary 
finalizer thread.

There have been recent changes to other tests that require finalization 
to basically add explicit loops testing a variable that is set by the 
finalizer eg:

while (!obj.finalized) {
   System.gc();
   Thread.sleep(100);
}

It may be that this could be added to the ClearFinalizerThread object?

Unfortunately it can sometimes be very easy to "fix" these tests in a 
way that negates the purpose of the test.

David

> -- Chris
>
>>
>> Mandy
>>
>>
>> On 10/18/2012 2:43 PM, Christian Thalinger wrote:
>>> http://cr.openjdk.java.net/~twisti/6771058
>>>
>>> 6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp
>>> Reviewed-by:
>>>
>>> This test can fail if finalizer of Basic is not called for some
>>> reason.  It happens in compiled mode if compilation is more slow than
>>> execution of the main loop.
>>>
>>> The fix is to call System.runFinalization() after System.gc() to
>>> ensure that finalizer is run.
>>>
>>> test/java/lang/ref/Basic.java
>>>
>


From martinrb at google.com  Fri Oct 19 00:58:29 2012
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 18 Oct 2012 17:58:29 -0700
Subject: RFR (XXS): 6771058: TEST_BUG: java/lang/ref/Basic.java may fail
	with -server -Xcomp
In-Reply-To: <5080A3F2.9020109@oracle.com>
References: <61FF2EC4-18EF-4937-9738-A987CB1DEE9F@oracle.com>
	<50808346.8020702@oracle.com>
	<ADA6CBF5-2888-4E74-9D1F-6895F1E118F0@oracle.com>
	<5080A3F2.9020109@oracle.com>
Message-ID: <CA+kOe09ZH323VSmb1S=8de9GQ7g8-131r+cXL5P8x2vLtD2BHw@mail.gmail.com>

http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java


From david.holmes at oracle.com  Fri Oct 19 01:11:47 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Oct 2012 11:11:47 +1000
Subject: RFR (XXS): 6771058: TEST_BUG: java/lang/ref/Basic.java may fail
	with -server -Xcomp
In-Reply-To: <CA+kOe09ZH323VSmb1S=8de9GQ7g8-131r+cXL5P8x2vLtD2BHw@mail.gmail.com>
References: <61FF2EC4-18EF-4937-9738-A987CB1DEE9F@oracle.com>
	<50808346.8020702@oracle.com>
	<ADA6CBF5-2888-4E74-9D1F-6895F1E118F0@oracle.com>
	<5080A3F2.9020109@oracle.com>
	<CA+kOe09ZH323VSmb1S=8de9GQ7g8-131r+cXL5P8x2vLtD2BHw@mail.gmail.com>
Message-ID: <5080A8D3.9030505@oracle.com>

Hi Martin,

On 19/10/2012 10:58 AM, Martin Buchholz wrote:
> http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java

That code uses runFinalization in places which means it is not 
exercising the primary finalization mechanism. But looking further into 
the whole thing I don't think it really makes much difference 
semantically afterall. All that changes is which thread executes the 
finalizer - the object comes from the same ReferenceQueue regardless.

Which means that runFinalization() will really only help if the main 
finalizer thread is delayed executing another finalizer - which for some 
tests may be caused by compilation of the finalize method.

So Chris/Mandy: I think the original suggested fix is fine here.

Cheers,
David




From weijun.wang at oracle.com  Fri Oct 19 01:11:33 2012
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 19 Oct 2012 09:11:33 +0800
Subject: bug fix for native kerberos libraries
In-Reply-To: <508073F2.2020002@oracle.com>
References: <20121018210243.DC05597124@rebar.astron.com>
	<508073F2.2020002@oracle.com>
Message-ID: <5080A8C5.2070902@oracle.com>

Hi Christos

You mean the exception thrown in NativeGSSFactory.java lines 52-60?

         Vector<GSSCredElement> creds = GSSUtil.searchSubject
             (name, mech, initiate, GSSCredElement.class);

         // If Subject is present but no native creds available
         if (creds != null && creds.isEmpty()) {
             if (GSSUtil.useSubjectCredsOnly(caller)) {
                 throw new GSSException(GSSException.NO_CRED);
             }
         }

Why would you leave GSSUtil.useSubjectCredsOnly to be true? IMHO, there 
is no need to call JGSS through JAAS when you are using a native provider.

Thanks
Max

On 10/19/2012 05:26 AM, Sean Mullan wrote:
>
> (Forwarding to security-dev as this should be discussed in that group, not
> core-libs).
>
> On 10/18/12 5:02 PM, christos at zoulas.com wrote:
>> Hello,
>>
>> This simple fix allows kerberos authentication to work with:
>>
>> 	-Dsun.security.jgss.native=true
>>
>> and microsoft's sqljdbc 4.0.2206.100 driver.
>>
>> Enjoy,
>>
>> christos
>>
>> --- a/java/src/sun/security/jgss/GSSUtil.java   Mon Oct 15 17:43:08 2012 -0400
>> +++ b/java/src/sun/security/jgss/GSSUtil.java   Mon Oct 15 17:44:28 2012 -0400
>> @@ -333,10 +333,19 @@
>>                           Subject accSubj = Subject.getSubject(acc);
>>                           Vector<GSSCredentialSpi> result = null;
>>                           if (accSubj != null) {
>> -                            result = new Vector<GSSCredentialSpi>();
>>                               Iterator<GSSCredentialImpl> iterator =
>>                                   accSubj.getPrivateCredentials
>>                                   (GSSCredentialImpl.class).iterator();
>> +                            // GSSCredentialImpl is only implemented in
>> +                            // the non-native kerberos implementation,
>> +                            // so if we don't get any elements here
>> +                            // assume native and return null so that
>> +                            // searchSubject does not fail. A better
>> +                            // fix is to implement the code that handles
>> +                            // this in native java.
>> +                            if (!iterator.hasNext())
>> +                                return null;
>> +                            result = new Vector<GSSCredentialSpi>();
>>                               while (iterator.hasNext()) {
>>                                   GSSCredentialImpl cred = iterator.next();
>>                                   debug("...Found cred" + cred);
>>


From sean.coffey at oracle.com  Fri Oct 19 01:56:10 2012
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Thu, 18 Oct 2012 18:56:10 -0700
Subject: [7u12] Request for approval: 7198073: (prefs) user prefs not
	saved [macosx]
In-Reply-To: <508067C7.7050703@oracle.com>
References: <503BBEC0.20105@oracle.com> <508067C7.7050703@oracle.com>
Message-ID: <5080B33A.1050800@oracle.com>

Approved for jdk7u-dev.

regards,
Sean.

On 18/10/2012 13:34, Kurchi Hazra wrote:
>
> This is a request for approval to backport the fix for 7198073 from 8 
> to 7u12.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198073
> Webrev: http://cr.openjdk.java.net/~khazra/7198073/7u12/webrev/
>
> This change been reviewed by Alan Bateman [1] and the fix has been 
> pushed into jdk8 [2].
> The fix for 7u12 is identical.
>
> Thanks,
> Kurchi
>
> [1]http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-October/011767.html 
>
> [2]http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a6b76a468bd



From zhouyx at linux.vnet.ibm.com  Fri Oct 19 09:11:50 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Fri, 19 Oct 2012 17:11:50 +0800
Subject: RFR: 6519127 : user.home property not set correctly
Message-ID: <CAOo=rxX=07F-5T_s9wkdZEx_ikc-9H+Fay0zrtwHLsy2qsYjmw@mail.gmail.com>

Hi all,

    This is a fix for 651912. The fix removed the code to read
user.home from registry and get profile directory instead of the
parent of desktop directory. As suggested in
http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx from
the bug page.

Bug: bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519127

Webrev: http://cr.openjdk.java.net/~zhouyx/6519127/webrev.00/

Please take a look.

-- 
Best Regards,
Sean Chou


From Alan.Bateman at oracle.com  Fri Oct 19 09:51:08 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 Oct 2012 10:51:08 +0100
Subject: RFR: 6519127 : user.home property not set correctly
In-Reply-To: <CAOo=rxX=07F-5T_s9wkdZEx_ikc-9H+Fay0zrtwHLsy2qsYjmw@mail.gmail.com>
References: <CAOo=rxX=07F-5T_s9wkdZEx_ikc-9H+Fay0zrtwHLsy2qsYjmw@mail.gmail.com>
Message-ID: <5081228C.1020302@oracle.com>

On 19/10/2012 10:11, Sean Chou wrote:
> Hi all,
>
>      This is a fix for 651912. The fix removed the code to read
> user.home from registry and get profile directory instead of the
> parent of desktop directory. As suggested in
> http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx from
> the bug page.
>
> Bug: bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519127
>
> Webrev: http://cr.openjdk.java.net/~zhouyx/6519127/webrev.00/
>
> Please take a look.
>
Sean - any changes to the value of user.home has the potential to cause 
issues, this is an area whether there has been a lot of ambiguity in 
past as to where the user's home directory is, particularly with 
non-standard configurations. 6519127 and several others have been 
waiting for a brave person to re-examine this issue.

Do you think you could provide a detailed write-up on this topic? I 
think we need to understand how the home directory, as reported by the 
shell API, might differ to the value that the registry reports, also 
USERPROFILE. In addition we've had so many issues over the years with 
different configurations, Windows Terminal Server, local accounts vs. 
accounts in the domain, etc. and I think we need to understand as much 
as possible as what might change. Sorry there is lot more work here than 
you might have expected but this is an area where we have to be very 
careful.

-Alan


From chris.hegarty at oracle.com  Fri Oct 19 11:24:54 2012
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 19 Oct 2012 11:24:54 +0000
Subject: hg: jdk8/tl/jdk: 8000206: Uninitialized variable in
	PlainDatagramSocketImpl.c
Message-ID: <20121019112603.0EF7E47452@hg.openjdk.java.net>

Changeset: 27f854a1e5c5
Author:    chegar
Date:      2012-10-19 11:43 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27f854a1e5c5

8000206: Uninitialized variable in PlainDatagramSocketImpl.c
Reviewed-by: dsamersoff, khazra, chegar
Contributed-by: John Zavgren <john.zavgren at oracle.com>

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



From christos at zoulas.com  Fri Oct 19 12:50:48 2012
From: christos at zoulas.com (Christos Zoulas)
Date: Fri, 19 Oct 2012 08:50:48 -0400
Subject: bug fix for native kerberos libraries
In-Reply-To: <5080A8C5.2070902@oracle.com> from Weijun Wang (Oct 19,  9:11am)
Message-ID: <20121019125048.222A097124@rebar.astron.com>

On Oct 19,  9:11am, weijun.wang at oracle.com (Weijun Wang) wrote:
-- Subject: Re: bug fix for native kerberos libraries

| Hi Christos
| 
| You mean the exception thrown in NativeGSSFactory.java lines 52-60?
| 
|          Vector<GSSCredElement> creds = GSSUtil.searchSubject
|              (name, mech, initiate, GSSCredElement.class);
| 
|          // If Subject is present but no native creds available
|          if (creds != null && creds.isEmpty()) {
|              if (GSSUtil.useSubjectCredsOnly(caller)) {
|                  throw new GSSException(GSSException.NO_CRED);
|              }
|          }
| 
| Why would you leave GSSUtil.useSubjectCredsOnly to be true? IMHO, there 
| is no need to call JGSS through JAAS when you are using a native provider.

Yes, I guess this is new with JDK 7. Thanks I will try that!

christos


From christian.thalinger at oracle.com  Fri Oct 19 16:23:35 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 19 Oct 2012 09:23:35 -0700
Subject: RFR (XXS): 6771058: TEST_BUG: java/lang/ref/Basic.java may fail
	with -server -Xcomp
In-Reply-To: <5080A8D3.9030505@oracle.com>
References: <61FF2EC4-18EF-4937-9738-A987CB1DEE9F@oracle.com>
	<50808346.8020702@oracle.com>
	<ADA6CBF5-2888-4E74-9D1F-6895F1E118F0@oracle.com>
	<5080A3F2.9020109@oracle.com>
	<CA+kOe09ZH323VSmb1S=8de9GQ7g8-131r+cXL5P8x2vLtD2BHw@mail.gmail.com>
	<5080A8D3.9030505@oracle.com>
Message-ID: <B2716BBB-DA42-456A-9DED-D9FC3D89DA93@oracle.com>


On Oct 18, 2012, at 6:11 PM, David Holmes <david.holmes at oracle.com> wrote:

> Hi Martin,
> 
> On 19/10/2012 10:58 AM, Martin Buchholz wrote:
>> http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java
> 
> That code uses runFinalization in places which means it is not exercising the primary finalization mechanism. But looking further into the whole thing I don't think it really makes much difference semantically afterall. All that changes is which thread executes the finalizer - the object comes from the same ReferenceQueue regardless.
> 
> Which means that runFinalization() will really only help if the main finalizer thread is delayed executing another finalizer - which for some tests may be caused by compilation of the finalize method.
> 
> So Chris/Mandy: I think the original suggested fix is fine here.

Thank you for looking into this and verifying that it's okay.

-- Chris

> 
> Cheers,
> David
> 
> 


From mandy.chung at oracle.com  Fri Oct 19 17:42:20 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 19 Oct 2012 10:42:20 -0700
Subject: RFR (XXS): 6771058: TEST_BUG: java/lang/ref/Basic.java may fail
	with -server -Xcomp
In-Reply-To: <5080A8D3.9030505@oracle.com>
References: <61FF2EC4-18EF-4937-9738-A987CB1DEE9F@oracle.com>
	<50808346.8020702@oracle.com>
	<ADA6CBF5-2888-4E74-9D1F-6895F1E118F0@oracle.com>
	<5080A3F2.9020109@oracle.com>
	<CA+kOe09ZH323VSmb1S=8de9GQ7g8-131r+cXL5P8x2vLtD2BHw@mail.gmail.com>
	<5080A8D3.9030505@oracle.com>
Message-ID: <508190FC.2070006@oracle.com>

On 10/18/2012 6:11 PM, David Holmes wrote:
> Hi Martin,
>
> On 19/10/2012 10:58 AM, Martin Buchholz wrote:
>> http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java 
>>
>
> That code uses runFinalization in places which means it is not 
> exercising the primary finalization mechanism. But looking further 
> into the whole thing I don't think it really makes much difference 
> semantically afterall. All that changes is which thread executes the 
> finalizer - the object comes from the same ReferenceQueue regardless.
>
> Which means that runFinalization() will really only help if the main 
> finalizer thread is delayed executing another finalizer - which for 
> some tests may be caused by compilation of the finalize method.
>
> So Chris/Mandy: I think the original suggested fix is fine here.

Thanks David. I looked at the Finalizer class and also concur that what 
Chris has is fine.

Chris - do you have the committer right to push to jdk8/tl?  If not, I 
can push it for you.

Mandy


From christian.thalinger at oracle.com  Fri Oct 19 18:11:13 2012
From: christian.thalinger at oracle.com (Christian Thalinger)
Date: Fri, 19 Oct 2012 11:11:13 -0700
Subject: RFR (XXS): 6771058: TEST_BUG: java/lang/ref/Basic.java may fail
	with -server -Xcomp
In-Reply-To: <508190FC.2070006@oracle.com>
References: <61FF2EC4-18EF-4937-9738-A987CB1DEE9F@oracle.com>
	<50808346.8020702@oracle.com>
	<ADA6CBF5-2888-4E74-9D1F-6895F1E118F0@oracle.com>
	<5080A3F2.9020109@oracle.com>
	<CA+kOe09ZH323VSmb1S=8de9GQ7g8-131r+cXL5P8x2vLtD2BHw@mail.gmail.com>
	<5080A8D3.9030505@oracle.com> <508190FC.2070006@oracle.com>
Message-ID: <A3D8C5E6-559D-46E2-B605-8C52D89F1DCD@oracle.com>


On Oct 19, 2012, at 10:42 AM, Mandy Chung <mandy.chung at oracle.com> wrote:

> On 10/18/2012 6:11 PM, David Holmes wrote:
>> Hi Martin,
>> 
>> On 19/10/2012 10:58 AM, Martin Buchholz wrote:
>>> http://code.google.com/p/guava-libraries/source/browse/guava-testlib/src/com/google/common/testing/GcFinalization.java 
>> 
>> That code uses runFinalization in places which means it is not exercising the primary finalization mechanism. But looking further into the whole thing I don't think it really makes much difference semantically afterall. All that changes is which thread executes the finalizer - the object comes from the same ReferenceQueue regardless.
>> 
>> Which means that runFinalization() will really only help if the main finalizer thread is delayed executing another finalizer - which for some tests may be caused by compilation of the finalize method.
>> 
>> So Chris/Mandy: I think the original suggested fix is fine here.
> 
> Thanks David. I looked at the Finalizer class and also concur that what Chris has is fine.
> 
> Chris - do you have the committer right to push to jdk8/tl?  If not, I can push it for you.

Yes, I'm reviewer of jdk8.  But I would appreciate if you could push it.

-- Chris

> 
> Mandy



From xueming.shen at oracle.com  Sat Oct 20 00:03:59 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 19 Oct 2012 17:03:59 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <F1CD4B8A-31C1-465F-893D-93957DB6A693@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<F1CD4B8A-31C1-465F-893D-93957DB6A693@oracle.com>
Message-ID: <5081EA6F.9040606@oracle.com>


I see a 20% performance gain on server vm if switch to pure char[] based 
encoding
and then use the sharedSecrets to avoid the copy. The dis-advantage is 
(1) have to
use the sharedSecrets and (2) can't share the same between the 
encode(byte[])
and encode(String).

Anyway it appears to be an alternative for performance improvement.

-Sherman


On 10/18/2012 01:07 PM, Mike Duigou wrote:
> I wonder if there would be advantage in using a SharedSecrets mechanism to allow construction of a String directly from a char array. The intermediate byte array seems wasteful especially for what is likely to be a heavily used path.
>
> Mike
>
> On Oct 17 2012, at 19:10 , Xueming Shen wrote:
>
>> Hi
>>
>> Webrev has been updated with following changes
>>
>> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
>> (2) some minor spec clarification regarding the "end of decoding"
>> (3) performance tuning.
>>
>> webrev:
>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>
>> some performance scores:
>> http://cr.openjdk.java.net/~sherman/4235519/score3
>>
>> -Sherman



From mike.duigou at oracle.com  Fri Oct 19 23:59:03 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Fri, 19 Oct 2012 16:59:03 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5081EA6F.9040606@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<F1CD4B8A-31C1-465F-893D-93957DB6A693@oracle.com>
	<5081EA6F.9040606@oracle.com>
Message-ID: <97B95730-B04C-47DB-AB86-6C626C8A5392@oracle.com>

For me the greater concern, which is hard to measure, is the GC pressure added by the discarded byte array.

Mike

On Oct 19 2012, at 17:03 , Xueming Shen wrote:

> 
> I see a 20% performance gain on server vm if switch to pure char[] based encoding
> and then use the sharedSecrets to avoid the copy. The dis-advantage is (1) have to
> use the sharedSecrets and (2) can't share the same between the encode(byte[])
> and encode(String).
> 
> Anyway it appears to be an alternative for performance improvement.
> 
> -Sherman
> 
> 
> On 10/18/2012 01:07 PM, Mike Duigou wrote:
>> I wonder if there would be advantage in using a SharedSecrets mechanism to allow construction of a String directly from a char array. The intermediate byte array seems wasteful especially for what is likely to be a heavily used path.
>> 
>> Mike
>> 
>> On Oct 17 2012, at 19:10 , Xueming Shen wrote:
>> 
>>> Hi
>>> 
>>> Webrev has been updated with following changes
>>> 
>>> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
>>> (2) some minor spec clarification regarding the "end of decoding"
>>> (3) performance tuning.
>>> 
>>> webrev:
>>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>> 
>>> some performance scores:
>>> http://cr.openjdk.java.net/~sherman/4235519/score3
>>> 
>>> -Sherman
> 



From xueming.shen at oracle.com  Sat Oct 20 00:40:04 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 19 Oct 2012 17:40:04 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <97B95730-B04C-47DB-AB86-6C626C8A5392@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<F1CD4B8A-31C1-465F-893D-93957DB6A693@oracle.com>
	<5081EA6F.9040606@oracle.com>
	<97B95730-B04C-47DB-AB86-6C626C8A5392@oracle.com>
Message-ID: <5081F2E4.3000108@oracle.com>

Understood. I do have the code:-) but I'm hesitated to go SharedSecrets 
simply for
performance gain of a utility method. This definitely can be addressed 
if it turns out
to be a real issue standing in critical path.

-Sherman

----------------------------------------------------------------------------
sherman at sherman-linux:~/Workspace/jdk8/test/java/util/Base64$ java  
PermBase64 200000 1000
  j.u.Base64.encode(ba)      : 528745
  j.u.Base64.encodeString(ba): 739703
  j.u.Base64.encode(bb)      : 486216
  j.u.Base64.encode(bb, bb)  : 538544
  j.u.Base64.encode(bb, bb)-D: 850947
   migBase64.encode(ba)      : 659474
  vs

sherman at sherman-linux:~/Workspace/jdk8/test/java/util/Base64$ java  
PermBase64 200000 1000
  j.u.Base64.encode(ba)      : 519391
  j.u.Base64.encodeString(ba): 964854
  j.u.Base64.encode(bb)      : 490138
  j.u.Base64.encode(bb, bb)  : 539027
  j.u.Base64.encode(bb, bb)-D: 786438
   migBase64.encode(ba)      : 660572

-Sherman

On 10/19/2012 04:59 PM, Mike Duigou wrote:
> For me the greater concern, which is hard to measure, is the GC pressure added by the discarded byte array.
>
> Mike
>
> On Oct 19 2012, at 17:03 , Xueming Shen wrote:
>
>> I see a 20% performance gain on server vm if switch to pure char[] based encoding
>> and then use the sharedSecrets to avoid the copy. The dis-advantage is (1) have to
>> use the sharedSecrets and (2) can't share the same between the encode(byte[])
>> and encode(String).
>>
>> Anyway it appears to be an alternative for performance improvement.
>>
>> -Sherman
>>
>>
>> On 10/18/2012 01:07 PM, Mike Duigou wrote:
>>> I wonder if there would be advantage in using a SharedSecrets mechanism to allow construction of a String directly from a char array. The intermediate byte array seems wasteful especially for what is likely to be a heavily used path.
>>>
>>> Mike
>>>
>>> On Oct 17 2012, at 19:10 , Xueming Shen wrote:
>>>
>>>> Hi
>>>>
>>>> Webrev has been updated with following changes
>>>>
>>>> (1) added a pair of en/decode(ByteBuffer src, ByteBuffer dst) methods
>>>> (2) some minor spec clarification regarding the "end of decoding"
>>>> (3) performance tuning.
>>>>
>>>> webrev:
>>>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>>>
>>>> some performance scores:
>>>> http://cr.openjdk.java.net/~sherman/4235519/score3
>>>>
>>>> -Sherman



From xuelei.fan at oracle.com  Sat Oct 20 03:39:29 2012
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Sat, 20 Oct 2012 03:39:29 +0000
Subject: hg: jdk8/tl/jdk: 8000954: Add final keyword to new method in
	SSLParameters
Message-ID: <20121020033955.881164746A@hg.openjdk.java.net>

Changeset: 21f1b88e68ce
Author:    xuelei
Date:      2012-10-19 20:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21f1b88e68ce

8000954: Add final keyword to new method in SSLParameters
Reviewed-by: wetmore

! src/share/classes/javax/net/ssl/SSLParameters.java



From alan.bateman at oracle.com  Sat Oct 20 20:07:58 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 20 Oct 2012 20:07:58 +0000
Subject: hg: jdk8/tl/jdk: 8000941: Remove ftp from the required list of
	protocol handlers
Message-ID: <20121020200842.645E447477@hg.openjdk.java.net>

Changeset: 93303f8a4a8e
Author:    alanb
Date:      2012-10-20 21:07 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93303f8a4a8e

8000941: Remove ftp from the required list of protocol handlers
Reviewed-by: chegar

! src/share/classes/java/net/ProxySelector.java
! src/share/classes/java/net/URL.java
! src/share/classes/java/net/URLStreamHandler.java
! src/share/classes/java/net/package.html



From james.holmlund at oracle.com  Sat Oct 20 21:50:48 2012
From: james.holmlund at oracle.com (james.holmlund at oracle.com)
Date: Sat, 20 Oct 2012 21:50:48 +0000
Subject: hg: jdk8/tl/jdk: 7197401: Add a subset of the org.objectweb.asm
	packages to jdk8
Message-ID: <20121020215111.2BBD447478@hg.openjdk.java.net>

Changeset: a40b0f51613b
Author:    jjh
Date:      2012-10-20 22:49 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a40b0f51613b

7197401: Add a subset of the org.objectweb.asm packages to jdk8
Reviewed-by: ohair, briangoetz, erikj, iris

! THIRD_PARTY_README
! make/Makefile
+ make/jdk/Makefile
+ make/jdk/asm/Makefile
+ src/share/classes/jdk/internal/org/objectweb/asm/AnnotationVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/AnnotationWriter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Attribute.java
+ src/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java
+ src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java
+ src/share/classes/jdk/internal/org/objectweb/asm/ClassVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Edge.java
+ src/share/classes/jdk/internal/org/objectweb/asm/FieldVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/FieldWriter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Frame.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Handle.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Handler.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Item.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Label.java
+ src/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java
+ src/share/classes/jdk/internal/org/objectweb/asm/Type.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingAnnotationAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingClassAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingFieldAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/SimpleRemapper.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/TableSwitchGenerator.java
+ src/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureReader.java
+ src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/AbstractInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/FrameNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/IincInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/InnerClassNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnList.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/IntInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/InvokeDynamicInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/JumpInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/LabelNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/LdcInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/LineNumberNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/MultiANewArrayInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/TableSwitchInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/TryCatchBlockNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/VarInsnNode.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/AnalyzerException.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicInterpreter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicValue.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicVerifier.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SimpleVerifier.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SmallSet.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceInterpreter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceValue.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Subroutine.java
+ src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Value.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifiable.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/CheckAnnotationAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/Textifiable.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/TraceAnnotationVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/TraceClassVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/TraceFieldVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java
+ src/share/classes/jdk/internal/org/objectweb/asm/util/TraceSignatureVisitor.java
! src/share/lib/security/java.security
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/Makefile
+ test/jdk/asm/AsmSanity.java



From martinrb at google.com  Sun Oct 21 19:02:22 2012
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 21 Oct 2012 12:02:22 -0700
Subject: RFR: 8000975: Merge UNIXProcess.java.bsd & UNIXProcess.java.linux
In-Reply-To: <507D880E.3020309@oracle.com>
References: <507D880E.3020309@oracle.com>
Message-ID: <CA+kOe0_B=Ua174v3KxhsuimKRNBRXMh45-MrzdhbP9AY92dQ4g@mail.gmail.com>

On Tue, Oct 16, 2012 at 9:15 AM, Rob McKenna <rob.mckenna at oracle.com> wrote:

> It has been suggested to me (at least twice at this stage) that these
> files should be merged since they're identical. This requires an adjustment
> in perspective from "every platform should have its own implementation"


I've always been strongly opposed to  "every platform should have its own
implementation", since it tends to violate DRY for insufficient
justification.  I would (heretically!) like Java more if there were more
facilities for writing a single source file targeting slightly different
platforms.

 ifeq ($(OPENJDK_TARGET_OS_API),posix)
-    UPSUFFIX:=$(OPENJDK_TARGET_OS)
-    ifeq ($(OPENJDK_TARGET_OS),macosx)
-        UPSUFFIX:=bsd
+    UPSUFFIX:=posix
+    ifeq ($(OPENJDK_TARGET_OS),solaris)
+        UPSUFFIX:=solaris
     endif


I'm inclined to structure things as in the other makefile

if solaris

  solaris code here...

else

  general unix code here ...

endif


From martinrb at google.com  Sun Oct 21 19:07:20 2012
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 21 Oct 2012 12:07:20 -0700
Subject: RFR: 8000975: Merge UNIXProcess.java.bsd & UNIXProcess.java.linux
In-Reply-To: <507D8CB6.1070704@oracle.com>
References: <507D880E.3020309@oracle.com>
	<507D8CB6.1070704@oracle.com>
Message-ID: <CA+kOe09mshJgry9uuLyPLp4+7f3ybymJRCjL-DUcQxF5Fa8TJA@mail.gmail.com>

On Tue, Oct 16, 2012 at 9:35 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

>
>>  I don't have any objection to this but at some point I think we need to
> change the Solaris and Mac implementations to use posix_spawn, in which
> case it's possible that the Mac implementation will be different to the
> Linux implementation.


See also *Bug 10354* <http://sourceware.org/bugzilla/show_bug.cgi?id=10354>
 - posix_spawn should use vfork() in more cases than presently


From weijun.wang at oracle.com  Mon Oct 22 01:59:44 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Mon, 22 Oct 2012 01:59:44 +0000
Subject: hg: jdk8/tl/jdk: 8001204: typo: Unable to obtain Princpal Name for
	authentication
Message-ID: <20121022020007.160B247489@hg.openjdk.java.net>

Changeset: b39ab9c6f4cb
Author:    weijun
Date:      2012-10-22 09:59 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b39ab9c6f4cb

8001204: typo: Unable to obtain Princpal Name for authentication
Reviewed-by: xuelei

! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java



From weijun.wang at oracle.com  Mon Oct 22 09:02:04 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Mon, 22 Oct 2012 09:02:04 +0000
Subject: hg: jdk8/tl/jdk: 8000624: Move MaxRetries.java to ProblemList for the
	moment
Message-ID: <20121022090227.BDC7C4748F@hg.openjdk.java.net>

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

8000624: Move MaxRetries.java to ProblemList for the moment
Reviewed-by: alanb

! test/ProblemList.txt



From christian.thalinger at oracle.com  Mon Oct 22 21:24:48 2012
From: christian.thalinger at oracle.com (christian.thalinger at oracle.com)
Date: Mon, 22 Oct 2012 21:24:48 +0000
Subject: hg: jdk8/tl/jdk: 6771058: TEST_BUG: java/lang/ref/Basic.java may fail
	with -server -Xcomp
Message-ID: <20121022212523.79B13474A9@hg.openjdk.java.net>

Changeset: 2048ce5a12ff
Author:    twisti
Date:      2012-10-22 14:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2048ce5a12ff

6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp
Reviewed-by: dholmes, mchung

! test/java/lang/ref/Basic.java



From weijun.wang at oracle.com  Tue Oct 23 02:02:39 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Tue, 23 Oct 2012 02:02:39 +0000
Subject: hg: jdk8/tl/jdk: 8001208: Fix for KRB5CCNAME not complete
Message-ID: <20121023020303.85D3F474B6@hg.openjdk.java.net>

Changeset: a1e77f7ed52b
Author:    weijun
Date:      2012-10-23 10:02 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1e77f7ed52b

8001208: Fix for KRB5CCNAME not complete
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java
! test/sun/security/krb5/ccache/EmptyCC.java



From zhouyx at linux.vnet.ibm.com  Tue Oct 23 07:52:04 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Tue, 23 Oct 2012 15:52:04 +0800
Subject: RFR: 6519127 : user.home property not set correctly
In-Reply-To: <5081228C.1020302@oracle.com>
References: <CAOo=rxX=07F-5T_s9wkdZEx_ikc-9H+Fay0zrtwHLsy2qsYjmw@mail.gmail.com>
	<5081228C.1020302@oracle.com>
Message-ID: <CAOo=rxW6HpL0nBO6d3iSHboiSt93g0dOkRWMWzJQ3jyHUsPsuA@mail.gmail.com>

Hi Alan,

    I did some search and wrote a brief, hope it helps.

=====================================

A brief about home directory, user profile directory, and "My
Documents" directory of windows users.

In windows NT and early, there is an assigned home directory act as a
user's default folder to "Open and Save files"[1]. It is represented
by environment variable "HOME", "HOMEDRIVE", "HOMEPATH". And this is
still available in windows 7, a home directory can still be assigned
to a user and %HOME% will report the assigned directory[7]. By
default, HOME is set to profile directory which is "C:\Users\username"
in vista and 7, and "C:\Documents and Settings\username" in XP(cmd ->
set HOME).

In windows 2000 and XP, "My Documents" directory is used to keep the
user data which was kept in user home[1]. In the ways how programs
treat "HOME" and "My Documents", it says "In other programs, the home
folder is ignored, regardless of whether the home folder contains any
files." This is a proof that the HOME directory is not encouraged to
use any more. But it is still there. In windows Vista and 7, "My
Documents" directory is becoming a virtual directory, it is seen from
constant CSIDL_MYDOCUMENTS. It was CSIDL_PERSONAL in XP which is a
real directory[4].

Since windows XP, there is a user profile directory[2, 3]. It is
default to "C:\Documents and Settings\username" in XP and
"C:\Users\username" in vista and 7. User profile directory is
available as environment variable "USERPROFILE"; it is available in
Java by System.getenv("USERPROFILE"). USERPROFILE can be modified by
resetting the variable. And it is available through shell function
SHGetFolderLocation which is NOT affected by resetting the
"USERPROFILE " variable.

"Shell Folders" and shell functions
This is totally from this artical[5]. "Shell Folders" registry key is
a mistake in windows 95. When "roaming profile" is considered, it is
decided to use function "SHGetSpecialFolderLocation" to get the
folders represented in "Shell Folders". However, the key is kept as a
shadow. And function SHGetFolderLocation is suggest to replace
function SHGetSpecialFolderLocation in XP[6].
So, the home directory reported by registry is a shadow of the value
from shell API, I think the difference is caused by missed update.
Detail to Java's implementation, there might be another difference:
windows supports changing the location of "Desktop" directory, and
Java takes the parent of "Desktop" from registry, this is not tested.
The "USERPROFILE" is an environment variable which is set to the
profile directory report by shell API, but it can be reset.

Applications' default paths
"cmd" is using profile directory as default path even "HOME" is set to
other directory. Login through telnet will use "HOME" directory as the
default, but Java is not using this "HOME" as user.home, it still uses
the profile shadow in registry. But I don't have an environment to
test domain users. I think the shell function mentions roaming
profile, it should handle.


[1] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/lsm_homedir.mspx?mfr=true
[2] http://msdn.microsoft.com/en-us/library/windows/desktop/bb776896(v=vs.85).aspx
[3] Shell contant CSIDL_PROFILE is available from version5.0 which is
windows 2000 or ME. So the profile directory might be available since
windows 2000 before XP.
[4] http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494(v=vs.85).aspx
[5] http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx
[6] http://msdn.microsoft.com/en-us/library/windows/desktop/bb762203(v=vs.85).aspx
[7] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/lsm_profile_homedirectory.mspx?mfr=true

============================================================

So in my understanding, the "HOME" directory is obsolete since XP, and
"My Documents" is a substitution. And the important thing is, the
directory represented by "HOME" is not a user's home compared with
Unix. User's home contains application data, user data, Desktop and
others. In windows, the USERPROFILE directory is much more similar to
act as a user home. And the current implementation is using the user
profile directory(the parent directory of Desktop, which is the
profile directory by default settings).

About the modified in webrev, I think it is just removing an old hack
which is obsoleted since win95.


On Fri, Oct 19, 2012 at 5:51 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 19/10/2012 10:11, Sean Chou wrote:
>>
>> Hi all,
>>
>>      This is a fix for 651912. The fix removed the code to read
>> user.home from registry and get profile directory instead of the
>> parent of desktop directory. As suggested in
>> http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx from
>> the bug page.
>>
>> Bug: bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519127
>>
>> Webrev: http://cr.openjdk.java.net/~zhouyx/6519127/webrev.00/
>>
>> Please take a look.
>>
> Sean - any changes to the value of user.home has the potential to cause
> issues, this is an area whether there has been a lot of ambiguity in past as
> to where the user's home directory is, particularly with non-standard
> configurations. 6519127 and several others have been waiting for a brave
> person to re-examine this issue.
>
> Do you think you could provide a detailed write-up on this topic? I think we
> need to understand how the home directory, as reported by the shell API,
> might differ to the value that the registry reports, also USERPROFILE. In
> addition we've had so many issues over the years with different
> configurations, Windows Terminal Server, local accounts vs. accounts in the
> domain, etc. and I think we need to understand as much as possible as what
> might change. Sorry there is lot more work here than you might have expected
> but this is an area where we have to be very careful.
>
> -Alan



-- 
Best Regards,
Sean Chou


From zhouyx at linux.vnet.ibm.com  Tue Oct 23 07:55:41 2012
From: zhouyx at linux.vnet.ibm.com (Sean Chou)
Date: Tue, 23 Oct 2012 15:55:41 +0800
Subject: RFR: 6519127 : user.home property not set correctly
In-Reply-To: <CAOo=rxW6HpL0nBO6d3iSHboiSt93g0dOkRWMWzJQ3jyHUsPsuA@mail.gmail.com>
References: <CAOo=rxX=07F-5T_s9wkdZEx_ikc-9H+Fay0zrtwHLsy2qsYjmw@mail.gmail.com>
	<5081228C.1020302@oracle.com>
	<CAOo=rxW6HpL0nBO6d3iSHboiSt93g0dOkRWMWzJQ3jyHUsPsuA@mail.gmail.com>
Message-ID: <CAOo=rxXte2tD_apfDE0pnJjq_ZPa41h3NyjO68DnkE_VQQEpew@mail.gmail.com>

A txt file if the previous mail format is bad. Forget to attach with
previous mail.

On Tue, Oct 23, 2012 at 3:52 PM, Sean Chou <zhouyx at linux.vnet.ibm.com> wrote:
> Hi Alan,
>
>     I did some search and wrote a brief, hope it helps.
>
> =====================================
>
> A brief about home directory, user profile directory, and "My
> Documents" directory of windows users.
>
> In windows NT and early, there is an assigned home directory act as a
> user's default folder to "Open and Save files"[1]. It is represented
> by environment variable "HOME", "HOMEDRIVE", "HOMEPATH". And this is
> still available in windows 7, a home directory can still be assigned
> to a user and %HOME% will report the assigned directory[7]. By
> default, HOME is set to profile directory which is "C:\Users\username"
> in vista and 7, and "C:\Documents and Settings\username" in XP(cmd ->
> set HOME).
>
> In windows 2000 and XP, "My Documents" directory is used to keep the
> user data which was kept in user home[1]. In the ways how programs
> treat "HOME" and "My Documents", it says "In other programs, the home
> folder is ignored, regardless of whether the home folder contains any
> files." This is a proof that the HOME directory is not encouraged to
> use any more. But it is still there. In windows Vista and 7, "My
> Documents" directory is becoming a virtual directory, it is seen from
> constant CSIDL_MYDOCUMENTS. It was CSIDL_PERSONAL in XP which is a
> real directory[4].
>
> Since windows XP, there is a user profile directory[2, 3]. It is
> default to "C:\Documents and Settings\username" in XP and
> "C:\Users\username" in vista and 7. User profile directory is
> available as environment variable "USERPROFILE"; it is available in
> Java by System.getenv("USERPROFILE"). USERPROFILE can be modified by
> resetting the variable. And it is available through shell function
> SHGetFolderLocation which is NOT affected by resetting the
> "USERPROFILE " variable.
>
> "Shell Folders" and shell functions
> This is totally from this artical[5]. "Shell Folders" registry key is
> a mistake in windows 95. When "roaming profile" is considered, it is
> decided to use function "SHGetSpecialFolderLocation" to get the
> folders represented in "Shell Folders". However, the key is kept as a
> shadow. And function SHGetFolderLocation is suggest to replace
> function SHGetSpecialFolderLocation in XP[6].
> So, the home directory reported by registry is a shadow of the value
> from shell API, I think the difference is caused by missed update.
> Detail to Java's implementation, there might be another difference:
> windows supports changing the location of "Desktop" directory, and
> Java takes the parent of "Desktop" from registry, this is not tested.
> The "USERPROFILE" is an environment variable which is set to the
> profile directory report by shell API, but it can be reset.
>
> Applications' default paths
> "cmd" is using profile directory as default path even "HOME" is set to
> other directory. Login through telnet will use "HOME" directory as the
> default, but Java is not using this "HOME" as user.home, it still uses
> the profile shadow in registry. But I don't have an environment to
> test domain users. I think the shell function mentions roaming
> profile, it should handle.
>
>
> [1] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/lsm_homedir.mspx?mfr=true
> [2] http://msdn.microsoft.com/en-us/library/windows/desktop/bb776896(v=vs.85).aspx
> [3] Shell contant CSIDL_PROFILE is available from version5.0 which is
> windows 2000 or ME. So the profile directory might be available since
> windows 2000 before XP.
> [4] http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494(v=vs.85).aspx
> [5] http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx
> [6] http://msdn.microsoft.com/en-us/library/windows/desktop/bb762203(v=vs.85).aspx
> [7] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/lsm_profile_homedirectory.mspx?mfr=true
>
> ============================================================
>
> So in my understanding, the "HOME" directory is obsolete since XP, and
> "My Documents" is a substitution. And the important thing is, the
> directory represented by "HOME" is not a user's home compared with
> Unix. User's home contains application data, user data, Desktop and
> others. In windows, the USERPROFILE directory is much more similar to
> act as a user home. And the current implementation is using the user
> profile directory(the parent directory of Desktop, which is the
> profile directory by default settings).
>
> About the modified in webrev, I think it is just removing an old hack
> which is obsoleted since win95.
>
>
> On Fri, Oct 19, 2012 at 5:51 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> On 19/10/2012 10:11, Sean Chou wrote:
>>>
>>> Hi all,
>>>
>>>      This is a fix for 651912. The fix removed the code to read
>>> user.home from registry and get profile directory instead of the
>>> parent of desktop directory. As suggested in
>>> http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx from
>>> the bug page.
>>>
>>> Bug: bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519127
>>>
>>> Webrev: http://cr.openjdk.java.net/~zhouyx/6519127/webrev.00/
>>>
>>> Please take a look.
>>>
>> Sean - any changes to the value of user.home has the potential to cause
>> issues, this is an area whether there has been a lot of ambiguity in past as
>> to where the user's home directory is, particularly with non-standard
>> configurations. 6519127 and several others have been waiting for a brave
>> person to re-examine this issue.
>>
>> Do you think you could provide a detailed write-up on this topic? I think we
>> need to understand how the home directory, as reported by the shell API,
>> might differ to the value that the registry reports, also USERPROFILE. In
>> addition we've had so many issues over the years with different
>> configurations, Windows Terminal Server, local accounts vs. accounts in the
>> domain, etc. and I think we need to understand as much as possible as what
>> might change. Sorry there is lot more work here than you might have expected
>> but this is an area where we have to be very careful.
>>
>> -Alan
>
>
>
> --
> Best Regards,
> Sean Chou



-- 
Best Regards,
Sean Chou
-------------- next part --------------

A brief about home directory, user profile directory, and "My Documents" directory of windows users.

In windows NT and early, there is an assigned home directory act as a user's default folder to "Open and Save files"[1]. It is represented by environment variable "HOME", "HOMEDRIVE", "HOMEPATH". And this is still available in windows 7, a home directory can still be assigned to a user and %HOME% will report the assigned directory[7]. By default, HOME is set to profile directory which is "C:\Users\username" in vista and 7, and "C:\Documents and Settings\username" in XP(cmd -> set HOME).

In windows 2000 and XP, "My Documents" directory is used to keep the user data which was kept in user home[1]. In the ways how programs treat "HOME" and "My Documents", it says "In other programs, the home folder is ignored, regardless of whether the home folder contains any files." This is a proof that the HOME directory is not encouraged to use any more. But it is still there. In windows Vista and 7, "My Documents" directory is becoming a virtual directory, it is seen from constant CSIDL_MYDOCUMENTS. It was CSIDL_PERSONAL in XP which is a real directory[4].

Since windows XP, there is a user profile directory[2, 3]. It is default to "C:\Documents and Settings\username" in XP and "C:\Users\username" in vista and 7. User profile directory is available as environment variable "USERPROFILE"; it is available in Java by System.getenv("USERPROFILE"). USERPROFILE can be modified by resetting the variable. And it is available through shell function SHGetFolderLocation which is NOT affected by resetting the variable.

"Shell Folders" and shell functions
This is totally from this artical[5]. "Shell Folders" registry key is a mistake in windows 95. When "roaming profile" is considered, it is decided to use function "SHGetSpecialFolderLocation" to get the folders represented in "Shell Folders". However, the key is kept as a shadow. And function SHGetFolderLocation is suggest to replace function SHGetSpecialFolderLocation in XP[6].
So, the home directory reported by registry is a shadow of the value from shell API, I think the difference is caused by missed update. Detail to Java's implementation, there might be another difference: windows supports changing the location of "Desktop" directory, and Java takes the parent of "Desktop" from registry, this is not tested. The "USERPROFILE" is an environment variable which is set to the profile directory report by shell API, but it can be reset.

Applications' default paths
"cmd" is using profile directory as default path even "HOME" is set to other directory. Login through telnet will use "HOME" directory as the default, but Java is not using this "HOME" as user.home, it still uses the profile shadow in registry. But I don't have an environment to test domain users. I think the shell function mentions roaming profile, it should handle.


[1] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/lsm_homedir.mspx?mfr=true
[2] http://msdn.microsoft.com/en-us/library/windows/desktop/bb776896(v=vs.85).aspx
[3] Shell contant CSIDL_PROFILE is available from version5.0 which is windows 2000 or ME. So the profile directory might be available since windows 2000 before XP.
[4] http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494(v=vs.85).aspx
[5] http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx
[6] http://msdn.microsoft.com/en-us/library/windows/desktop/bb762203(v=vs.85).aspx
[7] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/lsm_profile_homedirectory.mspx?mfr=true

============================================================

So in my understanding, the "HOME" directory is obsolete since XP, and "My Documents" is a substitution. And the important thing is, the directory represented by "HOME" is not a user's home compared with Unix. User's home contains application data, user data, Desktop and others. In windows, the USERPROFILE directory is much more similar to act as a user home. And the current implementation is using the USERPROFILE directory(the parent directory of Desktop, which is the profile directory by default settings).
About the modified in webrev, it is just removing an old hack which is obsoleted since win95.



From chris.hegarty at oracle.com  Tue Oct 23 10:58:33 2012
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Tue, 23 Oct 2012 10:58:33 +0000
Subject: hg: jdk8/tl/jdk: 8000204: Memory leak in
	com/sun/security/auth/module/Unix.c
Message-ID: <20121023105924.B3BF4474C8@hg.openjdk.java.net>

Changeset: 29b58cb8e4fc
Author:    chegar
Date:      2012-10-23 11:57 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29b58cb8e4fc

8000204: Memory leak in com/sun/security/auth/module/Unix.c
Reviewed-by: dsamersoff, wetmore, khazra, chegar
Contributed-by: John Zavgren <john.zavgren at oracle.com>

! src/solaris/native/com/sun/security/auth/module/Unix.c



From Ulf.Zibis at CoSoCo.de  Tue Oct 23 12:03:24 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 23 Oct 2012 14:03:24 +0200
Subject: RFR: 6519127 : user.home property not set correctly
In-Reply-To: <CAOo=rxW6HpL0nBO6d3iSHboiSt93g0dOkRWMWzJQ3jyHUsPsuA@mail.gmail.com>
References: <CAOo=rxX=07F-5T_s9wkdZEx_ikc-9H+Fay0zrtwHLsy2qsYjmw@mail.gmail.com>
	<5081228C.1020302@oracle.com>
	<CAOo=rxW6HpL0nBO6d3iSHboiSt93g0dOkRWMWzJQ3jyHUsPsuA@mail.gmail.com>
Message-ID: <5086878C.7060007@CoSoCo.de>

Hi,

after studying many MSDN docs, I think you are right, to use CSIDL_PROFILE.

And as I read ...
      * Note: To save space we want to avoid loading SHELL32.DLL
      * unless really necessary.  However if we do load it, we leave it
      * in memory, as it may be needed again later.
I'm pretty sure, we should not use this trick anymore.

One note from my side on Windows XP:
"HOME": not existent
"HOMEDRIVE": C:
"HOMEPATH": \Documents and Settings\username
So to get "C:\Documents and Settings\username" one has to concatenate "HOMEDRIVE" + "HOMEPATH"

-Ulf


Am 23.10.2012 09:52, schrieb Sean Chou:
> Hi Alan,
>
>      I did some search and wrote a brief, hope it helps.
>
> =====================================
>
> A brief about home directory, user profile directory, and "My
> Documents" directory of windows users.
>
> In windows NT and early, there is an assigned home directory act as a
> user's default folder to "Open and Save files"[1]. It is represented
> by environment variable "HOME", "HOMEDRIVE", "HOMEPATH". And this is
> still available in windows 7, a home directory can still be assigned
> to a user and %HOME% will report the assigned directory[7]. By
> default, HOME is set to profile directory which is "C:\Users\username"
> in vista and 7, and "C:\Documents and Settings\username" in XP(cmd ->
> set HOME).
>
> In windows 2000 and XP, "My Documents" directory is used to keep the
> user data which was kept in user home[1]. In the ways how programs
> treat "HOME" and "My Documents", it says "In other programs, the home
> folder is ignored, regardless of whether the home folder contains any
> files." This is a proof that the HOME directory is not encouraged to
> use any more. But it is still there. In windows Vista and 7, "My
> Documents" directory is becoming a virtual directory, it is seen from
> constant CSIDL_MYDOCUMENTS. It was CSIDL_PERSONAL in XP which is a
> real directory[4].
>
> Since windows XP, there is a user profile directory[2, 3]. It is
> default to "C:\Documents and Settings\username" in XP and
> "C:\Users\username" in vista and 7. User profile directory is
> available as environment variable "USERPROFILE"; it is available in
> Java by System.getenv("USERPROFILE"). USERPROFILE can be modified by
> resetting the variable. And it is available through shell function
> SHGetFolderLocation which is NOT affected by resetting the
> "USERPROFILE " variable.
>
> "Shell Folders" and shell functions
> This is totally from this artical[5]. "Shell Folders" registry key is
> a mistake in windows 95. When "roaming profile" is considered, it is
> decided to use function "SHGetSpecialFolderLocation" to get the
> folders represented in "Shell Folders". However, the key is kept as a
> shadow. And function SHGetFolderLocation is suggest to replace
> function SHGetSpecialFolderLocation in XP[6].
> So, the home directory reported by registry is a shadow of the value
> from shell API, I think the difference is caused by missed update.
> Detail to Java's implementation, there might be another difference:
> windows supports changing the location of "Desktop" directory, and
> Java takes the parent of "Desktop" from registry, this is not tested.
> The "USERPROFILE" is an environment variable which is set to the
> profile directory report by shell API, but it can be reset.
>
> Applications' default paths
> "cmd" is using profile directory as default path even "HOME" is set to
> other directory. Login through telnet will use "HOME" directory as the
> default, but Java is not using this "HOME" as user.home, it still uses
> the profile shadow in registry. But I don't have an environment to
> test domain users. I think the shell function mentions roaming
> profile, it should handle.
>
>
> [1] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/lsm_homedir.mspx?mfr=true
> [2] http://msdn.microsoft.com/en-us/library/windows/desktop/bb776896(v=vs.85).aspx
> [3] Shell contant CSIDL_PROFILE is available from version5.0 which is
> windows 2000 or ME. So the profile directory might be available since
> windows 2000 before XP.
> [4] http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494(v=vs.85).aspx
> [5] http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx
> [6] http://msdn.microsoft.com/en-us/library/windows/desktop/bb762203(v=vs.85).aspx
> [7] http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/lsm_profile_homedirectory.mspx?mfr=true
>
> ============================================================
>
> So in my understanding, the "HOME" directory is obsolete since XP, and
> "My Documents" is a substitution. And the important thing is, the
> directory represented by "HOME" is not a user's home compared with
> Unix. User's home contains application data, user data, Desktop and
> others. In windows, the USERPROFILE directory is much more similar to
> act as a user home. And the current implementation is using the user
> profile directory(the parent directory of Desktop, which is the
> profile directory by default settings).
>
> About the modified in webrev, I think it is just removing an old hack
> which is obsoleted since win95.
>
>
> On Fri, Oct 19, 2012 at 5:51 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> On 19/10/2012 10:11, Sean Chou wrote:
>>> Hi all,
>>>
>>>       This is a fix for 651912. The fix removed the code to read
>>> user.home from registry and get profile directory instead of the
>>> parent of desktop directory. As suggested in
>>> http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx from
>>> the bug page.
>>>
>>> Bug: bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519127
>>>
>>> Webrev: http://cr.openjdk.java.net/~zhouyx/6519127/webrev.00/
>>>
>>> Please take a look.
>>>
>> Sean - any changes to the value of user.home has the potential to cause
>> issues, this is an area whether there has been a lot of ambiguity in past as
>> to where the user's home directory is, particularly with non-standard
>> configurations. 6519127 and several others have been waiting for a brave
>> person to re-examine this issue.
>>
>> Do you think you could provide a detailed write-up on this topic? I think we
>> need to understand how the home directory, as reported by the shell API,
>> might differ to the value that the registry reports, also USERPROFILE. In
>> addition we've had so many issues over the years with different
>> configurations, Windows Terminal Server, local accounts vs. accounts in the
>> domain, etc. and I think we need to understand as much as possible as what
>> might change. Sorry there is lot more work here than you might have expected
>> but this is an area where we have to be very careful.
>>
>> -Alan
>
>



From Alan.Bateman at oracle.com  Tue Oct 23 13:04:12 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 23 Oct 2012 14:04:12 +0100
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <507F6511.10309@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
Message-ID: <508695CC.1080408@oracle.com>

On 18/10/2012 03:10, Xueming Shen wrote:
> :
>
> webrev:
> http://cr.openjdk.java.net/~sherman/4235519/webrev
I took another pass over this, focusing on the API as that is what we 
have to get right. Performance is important too but I think the priority 
has to be the API first.

Overall I think it is quite nice and easy to use.

I wonder if the Base64 class description should try to establish the 
terms "base64" and "base64url" so that they can be referenced from the 
various methods? That would avoid needing to duplicate references to the 
RFC 4668 and RFC 2045 in so many places.

I think it would also be useful if the specification indicated whether 
Encoders and Decoders are safe for use by concurrent threads. Also make 
it clear that NPE is thrown if any of the parameters are passed as null 
(unless otherwise specified of course).

I'm not sure that getUrlEncoder is the most suitable name to get a 
base64url encoder. The reason is that the method name makes it sound 
like it returns a URLEncoder or or at least an encoder for HTML forms. 
While more verbose, getBase64UrlEncoder is clear that it returns a 
base64url encoder.

Do you think getEncoder(int,byte[]) will be used much? If not then 
perhaps it should be left out for the first version (I guess part of 
this is getting used to providing the line separate as a byte array).

For the javadoc then Encoder and Decoder will need @since 1.8. They 
should probably cross reference each other too.

encode(byte[]) should be clearer that it encodes all bytes in the given 
array. Also I think it needs to be clear that the returned byte array is 
appropriately sized -- as currently worded it doesn't make it clear that 
they can't be extra elements at the end (odd as it might be).

Typo at line 215, "byter array" -> "byte array"

Typo at line 246, "methold" -> "method".

Typo at line 247, "arry" -> "array"

Type at line 254, "encocde" -> "encode"

Typo at line 277, "buffter" -> "buffer". Another one at line 702.

Minor comment, but I assume you should move the 
@SuppressWarnings("deprecation") on encodeToString to after the method 
comment rather than before. I see the same thing in decode(String).

I think encode(ByteBuffer) needs to be clear as to the 
position/limit/capacity of the returned buffer.

I'm not sure so about encode(ba, null) returning the required length, it 
feels odd and a bit like some of the win32 APIs. If the intention is 
that the caller allocates the byte[] and then calls encode again then it 
would be easier to just encode(ba).

For the decoder methods then IllegalArgumentException may be thrown 
mid-flight, meaning that some bytes may have been written into output 
buffer or array even though an exception is thrown. I think this needs 
to be made clear in the spec. It also makes me wonder if this is the 
right exception, it feels like a more specialized malformed input exception.

Another point about the decode methods is that they stop at the padding 
bytes and so this allows for bytes after the padding. I'm curious about 
this choice and whether you considered this as an error? I see how this 
influences decode(ByteBuffer,ByteBuffer) to return a boolean and I just 
wonder if there are other choices to consider.

That's mostly it for now. I didn't check in the IDE but there are lot of 
imports that are don't appear to be  used, perhaps left over from 
previous iterations?

-Alan


From Ulf.Zibis at CoSoCo.de  Tue Oct 23 14:57:34 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 23 Oct 2012 16:57:34 +0200
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <508695CC.1080408@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508695CC.1080408@oracle.com>
Message-ID: <5086B05E.1040505@CoSoCo.de>

Am 23.10.2012 15:04, schrieb Alan Bateman:
> I'm not sure that getUrlEncoder is the most suitable name to get a base64url encoder. The reason 
> is that the method name makes it sound like it returns a URLEncoder or or at least an encoder for 
> HTML forms. While more verbose, getBase64UrlEncoder is clear that it returns a base64url encoder.

I'm wondering, why there are those get... methods at all.

Alternatively you could make the appropriate constructors and predifined static variants public. So 
one only should use:
Base64.Encoder encoder = new Base64.Encoder(...);
Base64.Encoder urlEncoder = Base64.Encoder.RFC4648_URLSAFE;

No need for those looong method names.

-Ulf



From bradford.wetmore at oracle.com  Tue Oct 23 19:39:55 2012
From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com)
Date: Tue, 23 Oct 2012 19:39:55 +0000
Subject: hg: jdk8/tl/jdk: 7197071: Makefiles for various security providers
	aren't including the default manifest
Message-ID: <20121023194007.3E062474D9@hg.openjdk.java.net>

Changeset: 940c8cc5a5c4
Author:    wetmore
Date:      2012-10-23 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/940c8cc5a5c4

7197071: Makefiles for various security providers aren't including the default manifest
Reviewed-by: valeriep, mullan, katleman

! make/com/oracle/security/ucrypto/Makefile
! make/javax/crypto/Defs-jce.gmk
! make/sun/security/ec/Makefile
! make/sun/security/mscapi/Makefile
! make/sun/security/pkcs11/Makefile
+ test/javax/crypto/sanity/CheckManifestForRelease.java



From jonathan.gibbons at oracle.com  Tue Oct 23 20:21:08 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 23 Oct 2012 20:21:08 +0000
Subject: hg: jdk8/tl/langtools: 8000741: refactor javadoc to use abstraction
	to handle relative paths
Message-ID: <20121023202111.A030A474DA@hg.openjdk.java.net>

Changeset: 78962d89f283
Author:    jjg
Date:      2012-10-23 13:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/78962d89f283

8000741: refactor javadoc to use abstraction to handle relative paths
Reviewed-by: darcy

! src/share/classes/com/sun/javadoc/SerialFieldTag.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! src/share/classes/com/sun/tools/javadoc/SerializedForm.java
! test/com/sun/javadoc/testIndex/TestIndex.java
! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/com/sun/javadoc/testPackagePage/TestPackagePage.java



From jonathan.gibbons at oracle.com  Tue Oct 23 21:00:44 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 23 Oct 2012 21:00:44 +0000
Subject: hg: jdk8/tl/langtools: 8000416: refactor javadoc to provide and use
	an abstraction for relative URIs
Message-ID: <20121023210046.9501D474DB@hg.openjdk.java.net>

Changeset: 4a1c57a1c410
Author:    jjg
Date:      2012-10-23 13:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a1c57a1c410

8000416: refactor javadoc to provide and use an abstraction for relative URIs
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocLink.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java



From bradford.wetmore at oracle.com  Tue Oct 23 22:51:47 2012
From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com)
Date: Tue, 23 Oct 2012 22:51:47 +0000
Subject: hg: jdk8/tl/jdk: 8001419: Build the JCE portion of JDK-8000970
Message-ID: <20121023225210.82459474E3@hg.openjdk.java.net>

Changeset: 13b46e8eda33
Author:    ohrstrom
Date:      2012-10-23 15:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13b46e8eda33

8001419: Build the JCE portion of JDK-8000970
Summary: Original code done by Fredrik Ohrstrom, separated/pushed by wetmore
Reviewed-by: wetmore

! src/share/classes/com/sun/crypto/provider/KeyProtector.java
+ src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java



From xueming.shen at oracle.com  Wed Oct 24 02:56:07 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 23 Oct 2012 19:56:07 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <508695CC.1080408@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508695CC.1080408@oracle.com>
Message-ID: <508758C7.5030703@oracle.com>

Hi Alan,

Thanks for the review. I hope I addressed most of the comments in the
updated webrev at

http://cr.openjdk.java.net/~sherman/4235519/webrev

mainly

(1) Pulled the base64 "terms" up to the class doc and then be referenced 
from various methods
(2) Gave up the C style de/encode(byte[], null), just leave the invoker 
to have enough space. I
      remember Paul once suggested to have a convenient method to return 
the estimated length
      of the byte[] needed to en/decode a specified input byte 
array/buffer. I think we can do it
      later when it is really desired. I agreed your argument that if 
people need to get the size and
      prepare a "new" array, they bet off just call de/encode(byte[])
(3) Gave up the "liberal" decoding design, tight the spec/impl to treat 
the input as "illegal base64"
      if the padding character appears in the middle of input.
(4) Some clarification of spec for thread safe, null exception and the 
pos/limit of input/output byte
      buffer as suggested.
(5) Fixed the typos

I still don't have a better name for method "getUrlEn/Decoder()", 
Base64.getBase64UrlEn/Decoder()
does not feel good for me.

-Sherman


On 10/23/12 6:04 AM, Alan Bateman wrote:
> On 18/10/2012 03:10, Xueming Shen wrote:
>> :
>>
>> webrev:
>> http://cr.openjdk.java.net/~sherman/4235519/webrev
> I took another pass over this, focusing on the API as that is what we 
> have to get right. Performance is important too but I think the 
> priority has to be the API first.
>
> Overall I think it is quite nice and easy to use.
>
> I wonder if the Base64 class description should try to establish the 
> terms "base64" and "base64url" so that they can be referenced from the 
> various methods? That would avoid needing to duplicate references to 
> the RFC 4668 and RFC 2045 in so many places.
>
> I think it would also be useful if the specification indicated whether 
> Encoders and Decoders are safe for use by concurrent threads. Also 
> make it clear that NPE is thrown if any of the parameters are passed 
> as null (unless otherwise specified of course).
>
> I'm not sure that getUrlEncoder is the most suitable name to get a 
> base64url encoder. The reason is that the method name makes it sound 
> like it returns a URLEncoder or or at least an encoder for HTML forms. 
> While more verbose, getBase64UrlEncoder is clear that it returns a 
> base64url encoder.
>
> Do you think getEncoder(int,byte[]) will be used much? If not then 
> perhaps it should be left out for the first version (I guess part of 
> this is getting used to providing the line separate as a byte array).
>
> For the javadoc then Encoder and Decoder will need @since 1.8. They 
> should probably cross reference each other too.
>
> encode(byte[]) should be clearer that it encodes all bytes in the 
> given array. Also I think it needs to be clear that the returned byte 
> array is appropriately sized -- as currently worded it doesn't make it 
> clear that they can't be extra elements at the end (odd as it might be).
>
> Typo at line 215, "byter array" -> "byte array"
>
> Typo at line 246, "methold" -> "method".
>
> Typo at line 247, "arry" -> "array"
>
> Type at line 254, "encocde" -> "encode"
>
> Typo at line 277, "buffter" -> "buffer". Another one at line 702.
>
> Minor comment, but I assume you should move the 
> @SuppressWarnings("deprecation") on encodeToString to after the method 
> comment rather than before. I see the same thing in decode(String).
>
> I think encode(ByteBuffer) needs to be clear as to the 
> position/limit/capacity of the returned buffer.
>
> I'm not sure so about encode(ba, null) returning the required length, 
> it feels odd and a bit like some of the win32 APIs. If the intention 
> is that the caller allocates the byte[] and then calls encode again 
> then it would be easier to just encode(ba).
>
> For the decoder methods then IllegalArgumentException may be thrown 
> mid-flight, meaning that some bytes may have been written into output 
> buffer or array even though an exception is thrown. I think this needs 
> to be made clear in the spec. It also makes me wonder if this is the 
> right exception, it feels like a more specialized malformed input 
> exception.
>
> Another point about the decode methods is that they stop at the 
> padding bytes and so this allows for bytes after the padding. I'm 
> curious about this choice and whether you considered this as an error? 
> I see how this influences decode(ByteBuffer,ByteBuffer) to return a 
> boolean and I just wonder if there are other choices to consider.
>
> That's mostly it for now. I didn't check in the IDE but there are lot 
> of imports that are don't appear to be  used, perhaps left over from 
> previous iterations?
>
> -Alan



From mike.duigou at oracle.com  Wed Oct 24 03:50:17 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 23 Oct 2012 20:50:17 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <508758C7.5030703@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508695CC.1080408@oracle.com> <508758C7.5030703@oracle.com>
Message-ID: <0A803C59-1E5E-4A72-B910-4AAA03EAD5AE@oracle.com>

I'm eager to use this! 

Some comments:

- <tt>code</tt> is used in some places rather than {@code }

- The initial <ul> would perhaps be better as a <dl>. I don't know if definition lists are allowed in javadoc.

- public OutputStream wrap(OutputStream os) closing the underlying output stream precludes many potential uses. FilterOutputStreams do not consistently close the underlying stream.

- spelling error "methold"

- InputStream wrap() it might be nice if the return stream EOF when the padding character(s) are consumed but not close() or otherwise alter the source InputStream

- private static byte[] getBytes(ByteBuffer bb) should document, even though it's a private method, that the bytes returned should be not considered mutable since they might be shared.

- the "if (ret != dst.length) // TBD: not necessary" is worrisome as it will generate garbage.

- I'm still wishing String encode(byte[] buf) didn't use an intermediate byte array. :-)

- "stream after use, in which" -> "stream after use, during which"

On Oct 23 2012, at 19:56 , Xueming Shen wrote:

> Hi Alan,
> 
> Thanks for the review. I hope I addressed most of the comments in the
> updated webrev at
> 
> http://cr.openjdk.java.net/~sherman/4235519/webrev
> 
> mainly
> 
> (1) Pulled the base64 "terms" up to the class doc and then be referenced from various methods
> (2) Gave up the C style de/encode(byte[], null), just leave the invoker to have enough space. I
>     remember Paul once suggested to have a convenient method to return the estimated length
>     of the byte[] needed to en/decode a specified input byte array/buffer. I think we can do it
>     later when it is really desired. I agreed your argument that if people need to get the size and
>     prepare a "new" array, they bet off just call de/encode(byte[])
> (3) Gave up the "liberal" decoding design, tight the spec/impl to treat the input as "illegal base64"
>     if the padding character appears in the middle of input.
> (4) Some clarification of spec for thread safe, null exception and the pos/limit of input/output byte
>     buffer as suggested.
> (5) Fixed the typos
> 
> I still don't have a better name for method "getUrlEn/Decoder()", Base64.getBase64UrlEn/Decoder()
> does not feel good for me.
> 
> -Sherman
> 
> 
> On 10/23/12 6:04 AM, Alan Bateman wrote:
>> On 18/10/2012 03:10, Xueming Shen wrote:
>>> :
>>> 
>>> webrev:
>>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>> I took another pass over this, focusing on the API as that is what we have to get right. Performance is important too but I think the priority has to be the API first.
>> 
>> Overall I think it is quite nice and easy to use.
>> 
>> I wonder if the Base64 class description should try to establish the terms "base64" and "base64url" so that they can be referenced from the various methods? That would avoid needing to duplicate references to the RFC 4668 and RFC 2045 in so many places.
>> 
>> I think it would also be useful if the specification indicated whether Encoders and Decoders are safe for use by concurrent threads. Also make it clear that NPE is thrown if any of the parameters are passed as null (unless otherwise specified of course).
>> 
>> I'm not sure that getUrlEncoder is the most suitable name to get a base64url encoder. The reason is that the method name makes it sound like it returns a URLEncoder or or at least an encoder for HTML forms. While more verbose, getBase64UrlEncoder is clear that it returns a base64url encoder.
>> 
>> Do you think getEncoder(int,byte[]) will be used much? If not then perhaps it should be left out for the first version (I guess part of this is getting used to providing the line separate as a byte array).
>> 
>> For the javadoc then Encoder and Decoder will need @since 1.8. They should probably cross reference each other too.
>> 
>> encode(byte[]) should be clearer that it encodes all bytes in the given array. Also I think it needs to be clear that the returned byte array is appropriately sized -- as currently worded it doesn't make it clear that they can't be extra elements at the end (odd as it might be).
>> 
>> Typo at line 215, "byter array" -> "byte array"
>> 
>> Typo at line 246, "methold" -> "method".
>> 
>> Typo at line 247, "arry" -> "array"
>> 
>> Type at line 254, "encocde" -> "encode"
>> 
>> Typo at line 277, "buffter" -> "buffer". Another one at line 702.
>> 
>> Minor comment, but I assume you should move the @SuppressWarnings("deprecation") on encodeToString to after the method comment rather than before. I see the same thing in decode(String).
>> 
>> I think encode(ByteBuffer) needs to be clear as to the position/limit/capacity of the returned buffer.
>> 
>> I'm not sure so about encode(ba, null) returning the required length, it feels odd and a bit like some of the win32 APIs. If the intention is that the caller allocates the byte[] and then calls encode again then it would be easier to just encode(ba).
>> 
>> For the decoder methods then IllegalArgumentException may be thrown mid-flight, meaning that some bytes may have been written into output buffer or array even though an exception is thrown. I think this needs to be made clear in the spec. It also makes me wonder if this is the right exception, it feels like a more specialized malformed input exception.
>> 
>> Another point about the decode methods is that they stop at the padding bytes and so this allows for bytes after the padding. I'm curious about this choice and whether you considered this as an error? I see how this influences decode(ByteBuffer,ByteBuffer) to return a boolean and I just wonder if there are other choices to consider.
>> 
>> That's mostly it for now. I didn't check in the IDE but there are lot of imports that are don't appear to be  used, perhaps left over from previous iterations?
>> 
>> -Alan
> 



From xueming.shen at oracle.com  Wed Oct 24 05:12:25 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 23 Oct 2012 22:12:25 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <0A803C59-1E5E-4A72-B910-4AAA03EAD5AE@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508695CC.1080408@oracle.com> <508758C7.5030703@oracle.com>
	<0A803C59-1E5E-4A72-B910-4AAA03EAD5AE@oracle.com>
Message-ID: <508778B9.1070602@oracle.com>



On 10/23/2012 8:50 PM, Mike Duigou wrote:
> I'm eager to use this!
>
> Some comments:
>
> -<tt>code</tt>  is used in some places rather than {@code }
fixed
>
> - The initial<ul>  would perhaps be better as a<dl>. I don't know if definition lists are allowed in javadoc.
>
> - public OutputStream wrap(OutputStream os) closing the underlying output stream precludes many potential uses. FilterOutputStreams do not consistently close the underlying stream.
It has been an issue for a while. Obviously there are users that prefer 
the underlying stream not
get closed when the outer one is closed.  I think we have couple rfes 
that ask for a "close this
stream only but not the underlying one" close. But I don't think we can 
do this in the default
close(), otherwise, I'm sure we will gen another side of complain, the 
close() does not close the
underlying stream:-)
>
> - spelling error "methold"
fixed
>
> - InputStream wrap() it might be nice if the return stream EOF when the padding character(s) are consumed but not close() or otherwise alter the source InputStream
I need give it a little more time tomorrow.
>
> - private static byte[] getBytes(ByteBuffer bb) should document, even though it's a private method, that the bytes returned should be not considered mutable since they might be shared.
I have been thinking of rewriting the de/encode(ByteBuffer) to get rid 
of getBytes(...). Probably
need to move some piece around. If I end up keeping it I will put some 
comment int.
>
> - the "if (ret != dst.length) // TBD: not necessary" is worrisome as it will generate garbage.
while I'm pretty sure I don't need this for encode (it is definitely 
needed for
decode()), I just keep it for safe:-) I removed the "TBD" comment though.
>
> - I'm still wishing String encode(byte[] buf) didn't use an intermediate byte array. :-)
>
> - "stream after use, in which" ->  "stream after use, during which"
fixed.

Thanks for taking a look.

-Sherman
>
> On Oct 23 2012, at 19:56 , Xueming Shen wrote:
>
>> Hi Alan,
>>
>> Thanks for the review. I hope I addressed most of the comments in the
>> updated webrev at
>>
>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>
>> mainly
>>
>> (1) Pulled the base64 "terms" up to the class doc and then be referenced from various methods
>> (2) Gave up the C style de/encode(byte[], null), just leave the invoker to have enough space. I
>>      remember Paul once suggested to have a convenient method to return the estimated length
>>      of the byte[] needed to en/decode a specified input byte array/buffer. I think we can do it
>>      later when it is really desired. I agreed your argument that if people need to get the size and
>>      prepare a "new" array, they bet off just call de/encode(byte[])
>> (3) Gave up the "liberal" decoding design, tight the spec/impl to treat the input as "illegal base64"
>>      if the padding character appears in the middle of input.
>> (4) Some clarification of spec for thread safe, null exception and the pos/limit of input/output byte
>>      buffer as suggested.
>> (5) Fixed the typos
>>
>> I still don't have a better name for method "getUrlEn/Decoder()", Base64.getBase64UrlEn/Decoder()
>> does not feel good for me.
>>
>> -Sherman
>>
>>
>> On 10/23/12 6:04 AM, Alan Bateman wrote:
>>> On 18/10/2012 03:10, Xueming Shen wrote:
>>>> :
>>>>
>>>> webrev:
>>>> http://cr.openjdk.java.net/~sherman/4235519/webrev
>>> I took another pass over this, focusing on the API as that is what we have to get right. Performance is important too but I think the priority has to be the API first.
>>>
>>> Overall I think it is quite nice and easy to use.
>>>
>>> I wonder if the Base64 class description should try to establish the terms "base64" and "base64url" so that they can be referenced from the various methods? That would avoid needing to duplicate references to the RFC 4668 and RFC 2045 in so many places.
>>>
>>> I think it would also be useful if the specification indicated whether Encoders and Decoders are safe for use by concurrent threads. Also make it clear that NPE is thrown if any of the parameters are passed as null (unless otherwise specified of course).
>>>
>>> I'm not sure that getUrlEncoder is the most suitable name to get a base64url encoder. The reason is that the method name makes it sound like it returns a URLEncoder or or at least an encoder for HTML forms. While more verbose, getBase64UrlEncoder is clear that it returns a base64url encoder.
>>>
>>> Do you think getEncoder(int,byte[]) will be used much? If not then perhaps it should be left out for the first version (I guess part of this is getting used to providing the line separate as a byte array).
>>>
>>> For the javadoc then Encoder and Decoder will need @since 1.8. They should probably cross reference each other too.
>>>
>>> encode(byte[]) should be clearer that it encodes all bytes in the given array. Also I think it needs to be clear that the returned byte array is appropriately sized -- as currently worded it doesn't make it clear that they can't be extra elements at the end (odd as it might be).
>>>
>>> Typo at line 215, "byter array" ->  "byte array"
>>>
>>> Typo at line 246, "methold" ->  "method".
>>>
>>> Typo at line 247, "arry" ->  "array"
>>>
>>> Type at line 254, "encocde" ->  "encode"
>>>
>>> Typo at line 277, "buffter" ->  "buffer". Another one at line 702.
>>>
>>> Minor comment, but I assume you should move the @SuppressWarnings("deprecation") on encodeToString to after the method comment rather than before. I see the same thing in decode(String).
>>>
>>> I think encode(ByteBuffer) needs to be clear as to the position/limit/capacity of the returned buffer.
>>>
>>> I'm not sure so about encode(ba, null) returning the required length, it feels odd and a bit like some of the win32 APIs. If the intention is that the caller allocates the byte[] and then calls encode again then it would be easier to just encode(ba).
>>>
>>> For the decoder methods then IllegalArgumentException may be thrown mid-flight, meaning that some bytes may have been written into output buffer or array even though an exception is thrown. I think this needs to be made clear in the spec. It also makes me wonder if this is the right exception, it feels like a more specialized malformed input exception.
>>>
>>> Another point about the decode methods is that they stop at the padding bytes and so this allows for bytes after the padding. I'm curious about this choice and whether you considered this as an error? I see how this influences decode(ByteBuffer,ByteBuffer) to return a boolean and I just wonder if there are other choices to consider.
>>>
>>> That's mostly it for now. I didn't check in the IDE but there are lot of imports that are don't appear to be  used, perhaps left over from previous iterations?
>>>
>>> -Alan


From xuelei.fan at oracle.com  Wed Oct 24 15:26:28 2012
From: xuelei.fan at oracle.com (xuelei.fan at oracle.com)
Date: Wed, 24 Oct 2012 15:26:28 +0000
Subject: hg: jdk8/tl/jdk: 8001466: Nightly regression test failure of
	SSLSocketSNISensitive.java
Message-ID: <20121024152727.6057F474FE@hg.openjdk.java.net>

Changeset: e782f3c383fe
Author:    xuelei
Date:      2012-10-24 08:25 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e782f3c383fe

8001466: Nightly regression test failure of SSLSocketSNISensitive.java
Reviewed-by: weijun

! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java



From jim.gish at oracle.com  Wed Oct 24 19:31:13 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 24 Oct 2012 15:31:13 -0400
Subject: RFR: 7159567 - inconsistent configuration of MemoryHandler
In-Reply-To: <507F0B31.6030103@oracle.com>
References: <50637167.4060006@oracle.com> <5063BD8C.2010607@oracle.com>
	<50645D19.4050505@oracle.com> <5065F6DD.7010801@oracle.com>
	<5066176D.6040005@oracle.com> <50773C27.3050407@oracle.com>
	<507F0B31.6030103@oracle.com>
Message-ID: <50884201.4040806@oracle.com>

See updated webrev: 
http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler

Thanks,
     Jim

On 10/17/2012 03:46 PM, Mandy Chung wrote:
> Hi Jim,
>
> On 10/11/2012 2:37 PM, Jim Gish wrote:
>> Please review the updated changes at 
>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/
>>
>
> The spec change looks good.  As Alan points out, </li> is missing.  
> Although they were not there before, I would think it's a good clean 
> up while you are in these files if you agree.
Done
>
> The test looks better.   Is SimpleTargetHandler.numPublished intended 
> to be checked?  SimpleTargetHandler is set as the target for 
> java.util.logging.MemoryHandler.  I guess you want to create a logger 
> using the standard MemoryHandler.
>
> Nit: the test is named MemoryHandler and I guess the name conflict 
> causes the custom handler classes to extend 
> "java.util.logging.MemoryHandler" with a fully-qualified class name.  
> As the properties file is named MemoryHandlerTest.props, do you 
> consider renaming the test to MemoryHandlerTest to avoid the name 
> conflict?   I don't have strong opinion and just want to point that out.
I don't see this as a problem.  However, I've renamed MemoryHandler to 
MemoryHandlerTest for improved clarity.
>
> L62-64:  better not to rethrow a new RuntimeException as the exception 
> and stack trace will help diagnostics if it does go wrong.  You can 
> get rid of this try-catch block.
OK -- the reason I did this was to insert a readable message into the 
new RuntimeException to indicate the cause of the failure.  I think this 
is good practice and leads to easier diagnosis, but since you disagree, 
I'll take it out.
>
> L120: is it a leftover debug statement?  I think you meant to add test 
> case to exercise this target handler, right?
removed and a few tests added.

....Jim

>
>> I've changed as you've requested, added some additional tests, did 
>> some better error handling in the case of a MemoryHandler not 
>> specifying a target (now throws RuntimeException with an appropriate 
>> message instead of attempting to load a null class and throwing 
>> NPE).  I also corrected the copyrights, tested with JCK, all jdk_lang 
>> tests and have submitted a JPRT job with core tests.
>>
>
> Great.  Thanks for doing it.
>
> Mandy
>
>> I've forwarded a CCC request (separately) and will await its approval 
>> and further review of this change.
>>
>> Thanks,
>>     Jim
>>
>> On 09/28/2012 05:32 PM, Mandy Chung wrote:
>>> On 9/28/2012 12:13 PM, Jim Gish wrote:
>>>> I've re-spun the change with additional usage notes in the spec to 
>>>> reflect the long-standing actual behavior.  Note that it doesn't 
>>>> change the spec per se, as it was already stated in LogManager. 
>>>> This change simply replicates that language with an example in each 
>>>> *Handler class to make it easier to find.
>>>>
>>>
>>> Thanks for looking into it.  This statement in LogManager does
>>> specify the properties for handlers:
>>>
>>>   The properties for loggers and Handlers will have names starting
>>>   with the dot-separated name for the handler or logger.
>>>
>>> Replicating that statement with an example is one way to do it.
>>> Would it be clearer if the prefix of the properties referenced
>>> in the bullet list is replaced from "java.util.logging" to
>>> some kind of prefix - something like this:
>>>
>>>  *<b>Configuration:</b>
>>>  * By default each<tt>ConsoleHandler</tt>  is initialized using the 
>>> following
>>>  *<tt>LogManager</tt>  configuration properties. If properties are 
>>> not defined
>>>  * (or have invalid values) then the specified default values are used.
>>>  *<ul>
>>>  *<li> <handler's classname>.level
>>>  *        specifies the default level for the<tt>Handler</tt>
>>>  *        (defaults to<tt>Level.INFO</tt>).
>>>  ...<snip>
>>>  *</ul>
>>>  *
>>>  * For example, the properties for {@code ConsoleHandler} would be:
>>>  *     java.util.logging.ConsoleHandler.level=INFO
>>>  * 
>>> java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
>>>  *
>>>  * For a custom handler, e.g. com.foo.MyHandler, the properties 
>>> would be:
>>>  *     com.foo.MyHandler.level=INFO
>>>  * com.foo.MyHandler.formatter=java.util.logging.SimpleFormatter
>>>
>>> This might add some clarity to the spec.
>>>
>>> This is a spec bug fix that I would suggest to file a CCC to
>>> track for compatibility.  I would also suggest running the JCK
>>> tests to find out if there is any regression due to this fix.
>>>
>>>
>>>> The webrev, as posted at 
>>>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/ 
>>>>
>>>
>>> See my comment above w.r.t. the spec change.
>>>
>>> test/java/util/logging/MemoryHandler.java
>>>   L27: "via via" typo
>>>   L28: @run tag specifies the test name
>>>        So it should be @run main/othervm MemoryHandler
>>>
>>>   L43: jtreg runs the test in a different working directory
>>>   other than the test source.  So the test has to read
>>>   the system property ("test.src") to determine the location
>>>   of the properties file.  Typically, we will do this:
>>>     String src = System.getProperty("test.src", ".);
>>>     File   fname  = new File(src, LM_PROP_FNAME);
>>>
>>>   You don't need L44. You can reference LoggingDeadlock3.java test.
>>>
>>>   L51: this catch block to throw a RuntimeException doesn't seem
>>>   necessary.  If NPE is thrown, the test will fail anyway.
>>>
>>>   One suggestion to the test is to test both cases (one with
>>>   the specified target handler and one without).  You can
>>>   define a custom target handler so that the test can verify
>>>   if the expected one is used.  A simple handler to count
>>>   the number of log messages will do the work.
>>>
>>> test/java/util/logging/MemoryHandlerTest.props
>>>   I suggest to take out the comments and just keep the
>>>   properties the test needs to make it easier to tell
>>>   what's configured.
>>>   Perhaps you should also specify
>>>   java.util.logging.MemoryHandler.target to make sure
>>>   that the custom handler with no target handler specified
>>>   will not use j.u.l.MemoryHandler.target as the default.
>>>
>>> Mandy
>>>
>>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From alan.bateman at oracle.com  Wed Oct 24 19:43:53 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Wed, 24 Oct 2012 19:43:53 +0000
Subject: hg: jdk8/tl/jdk: 6976971: TEST:
	javax/management/remote/mandatory/URLTest.java should be re-integrated
Message-ID: <20121024194415.B51FD4750C@hg.openjdk.java.net>

Changeset: 8e8fcd44b963
Author:    jbachorik
Date:      2012-10-24 20:44 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e8fcd44b963

6976971: TEST: javax/management/remote/mandatory/URLTest.java should be re-integrated
Reviewed-by: alanb

! test/javax/management/remote/mandatory/URLTest.java



From chris.hegarty at oracle.com  Wed Oct 24 21:55:30 2012
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Wed, 24 Oct 2012 21:55:30 +0000
Subject: hg: jdk8/tl/jdk: 8000203: File descriptor leak in
	src/solaris/native/java/net/net_util_md.c
Message-ID: <20121024215551.B858247525@hg.openjdk.java.net>

Changeset: 909676adaefd
Author:    chegar
Date:      2012-10-24 21:20 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/909676adaefd

8000203: File descriptor leak in src/solaris/native/java/net/net_util_md.c
Reviewed-by: dsamersoff, khazra, chegar
Contributed-by: John Zavgren <john.zavgren at oracle.com>

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



From jim.gish at oracle.com  Wed Oct 24 23:13:39 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 24 Oct 2012 19:13:39 -0400
Subject: RFR: 7184195 - java.util.logging.Logger.getGlobal().info() doesn't
	log without configuration
Message-ID: <50887623.6000202@oracle.com>

Please review
http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-init-fix/ 
<http://cr.openjdk.java.net/%7Ejgish/Bug7184195-global-logger-init-fix/>

In JDK7, Logger.global was deprecated because of potential deadlock 
problems.  The method getGlobal() was introduced as a convenience method 
to get the global logger in lieu of this or calling 
Logger.getLogger(Logger.GLOBAL_LOGGER_NAME).  Unfortunately, this was 
broken out of the gate.  getGlobal() simply used the deprecated static 
variable global, but this had the result of returning the global logger 
without initializing the logging system.  As a result, simply calling 
Logger.getGlobal().INFO("msg") does nothing.  So much for the 
convenience of a simple global logger for devs to use ootb without any 
setup required.

This simple fix simply returns 
Logger.getLogger(Logger.GLOBAL_LOGGER_NAME) when getGlobal() is called 
and hence results in proper setup of the logging sytem /and /a working 
global logger  with no "assembly" required :-)

Thanks,
    Jim

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From mandy.chung at oracle.com  Thu Oct 25 00:40:51 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 24 Oct 2012 17:40:51 -0700
Subject: RFR: 7159567 - inconsistent configuration of MemoryHandler
In-Reply-To: <50884201.4040806@oracle.com>
References: <50637167.4060006@oracle.com> <5063BD8C.2010607@oracle.com>
	<50645D19.4050505@oracle.com> <5065F6DD.7010801@oracle.com>
	<5066176D.6040005@oracle.com> <50773C27.3050407@oracle.com>
	<507F0B31.6030103@oracle.com> <50884201.4040806@oracle.com>
Message-ID: <50888A93.1010705@oracle.com>

On 10/24/2012 12:31 PM, Jim Gish wrote:
> See updated webrev: 
> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler
>

Looks good.  Thanks for the update.

MemoryHandlerTest.java - thanks for renaming it but you forget to 
change  L28 @run tag.  jtreg should fail if you run this new test.  
L64-66 this try-catch block isn't necessary, as I mentioned in my 
previous comment, but no big deal if you want to leave it there.  The 
comment lines and some throw statements are really long and should be 
broken into multiple lines (I didn't notice the long lines in previous 
versions - sorry if I had missed them).   Hopefully it's just one-click 
reformat for you using IDE :)

Mandy

> Thanks,
>     Jim
>
> On 10/17/2012 03:46 PM, Mandy Chung wrote:
>> Hi Jim,
>>
>> On 10/11/2012 2:37 PM, Jim Gish wrote:
>>> Please review the updated changes at 
>>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/
>>>
>>
>> The spec change looks good.  As Alan points out, </li> is missing.  
>> Although they were not there before, I would think it's a good clean 
>> up while you are in these files if you agree.
> Done
>>
>> The test looks better.   Is SimpleTargetHandler.numPublished intended 
>> to be checked?  SimpleTargetHandler is set as the target for 
>> java.util.logging.MemoryHandler.  I guess you want to create a logger 
>> using the standard MemoryHandler.
>>
>> Nit: the test is named MemoryHandler and I guess the name conflict 
>> causes the custom handler classes to extend 
>> "java.util.logging.MemoryHandler" with a fully-qualified class name.  
>> As the properties file is named MemoryHandlerTest.props, do you 
>> consider renaming the test to MemoryHandlerTest to avoid the name 
>> conflict?   I don't have strong opinion and just want to point that out.
> I don't see this as a problem.  However, I've renamed MemoryHandler to 
> MemoryHandlerTest for improved clarity.
>>
>> L62-64:  better not to rethrow a new RuntimeException as the 
>> exception and stack trace will help diagnostics if it does go wrong.  
>> You can get rid of this try-catch block.
> OK -- the reason I did this was to insert a readable message into the 
> new RuntimeException to indicate the cause of the failure.  I think 
> this is good practice and leads to easier diagnosis, but since you 
> disagree, I'll take it out.
>>
>> L120: is it a leftover debug statement?  I think you meant to add 
>> test case to exercise this target handler, right?
> removed and a few tests added.
>
> ....Jim
>
>>
>>> I've changed as you've requested, added some additional tests, did 
>>> some better error handling in the case of a MemoryHandler not 
>>> specifying a target (now throws RuntimeException with an appropriate 
>>> message instead of attempting to load a null class and throwing 
>>> NPE).  I also corrected the copyrights, tested with JCK, all 
>>> jdk_lang tests and have submitted a JPRT job with core tests.
>>>
>>
>> Great.  Thanks for doing it.
>>
>> Mandy
>>
>>> I've forwarded a CCC request (separately) and will await its 
>>> approval and further review of this change.
>>>
>>> Thanks,
>>>     Jim
>>>
>>> On 09/28/2012 05:32 PM, Mandy Chung wrote:
>>>> On 9/28/2012 12:13 PM, Jim Gish wrote:
>>>>> I've re-spun the change with additional usage notes in the spec to 
>>>>> reflect the long-standing actual behavior.  Note that it doesn't 
>>>>> change the spec per se, as it was already stated in LogManager. 
>>>>> This change simply replicates that language with an example in 
>>>>> each *Handler class to make it easier to find.
>>>>>
>>>>
>>>> Thanks for looking into it.  This statement in LogManager does
>>>> specify the properties for handlers:
>>>>
>>>>   The properties for loggers and Handlers will have names starting
>>>>   with the dot-separated name for the handler or logger.
>>>>
>>>> Replicating that statement with an example is one way to do it.
>>>> Would it be clearer if the prefix of the properties referenced
>>>> in the bullet list is replaced from "java.util.logging" to
>>>> some kind of prefix - something like this:
>>>>
>>>>  *<b>Configuration:</b>
>>>>  * By default each<tt>ConsoleHandler</tt>  is initialized using the 
>>>> following
>>>>  *<tt>LogManager</tt>  configuration properties. If properties are 
>>>> not defined
>>>>  * (or have invalid values) then the specified default values are 
>>>> used.
>>>>  *<ul>
>>>>  *<li> <handler's classname>.level
>>>>  *        specifies the default level for the<tt>Handler</tt>
>>>>  *        (defaults to<tt>Level.INFO</tt>).
>>>>  ...<snip>
>>>>  *</ul>
>>>>  *
>>>>  * For example, the properties for {@code ConsoleHandler} would be:
>>>>  *     java.util.logging.ConsoleHandler.level=INFO
>>>>  * 
>>>> java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
>>>>  *
>>>>  * For a custom handler, e.g. com.foo.MyHandler, the properties 
>>>> would be:
>>>>  *     com.foo.MyHandler.level=INFO
>>>>  * com.foo.MyHandler.formatter=java.util.logging.SimpleFormatter
>>>>
>>>> This might add some clarity to the spec.
>>>>
>>>> This is a spec bug fix that I would suggest to file a CCC to
>>>> track for compatibility.  I would also suggest running the JCK
>>>> tests to find out if there is any regression due to this fix.
>>>>
>>>>
>>>>> The webrev, as posted at 
>>>>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/ 
>>>>>
>>>>
>>>> See my comment above w.r.t. the spec change.
>>>>
>>>> test/java/util/logging/MemoryHandler.java
>>>>   L27: "via via" typo
>>>>   L28: @run tag specifies the test name
>>>>        So it should be @run main/othervm MemoryHandler
>>>>
>>>>   L43: jtreg runs the test in a different working directory
>>>>   other than the test source.  So the test has to read
>>>>   the system property ("test.src") to determine the location
>>>>   of the properties file.  Typically, we will do this:
>>>>     String src = System.getProperty("test.src", ".);
>>>>     File   fname  = new File(src, LM_PROP_FNAME);
>>>>
>>>>   You don't need L44. You can reference LoggingDeadlock3.java test.
>>>>
>>>>   L51: this catch block to throw a RuntimeException doesn't seem
>>>>   necessary.  If NPE is thrown, the test will fail anyway.
>>>>
>>>>   One suggestion to the test is to test both cases (one with
>>>>   the specified target handler and one without).  You can
>>>>   define a custom target handler so that the test can verify
>>>>   if the expected one is used.  A simple handler to count
>>>>   the number of log messages will do the work.
>>>>
>>>> test/java/util/logging/MemoryHandlerTest.props
>>>>   I suggest to take out the comments and just keep the
>>>>   properties the test needs to make it easier to tell
>>>>   what's configured.
>>>>   Perhaps you should also specify
>>>>   java.util.logging.MemoryHandler.target to make sure
>>>>   that the custom handler with no target handler specified
>>>>   will not use j.u.l.MemoryHandler.target as the default.
>>>>
>>>> Mandy
>>>>
>>>
>


From mike.duigou at oracle.com  Thu Oct 25 04:07:45 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 24 Oct 2012 21:07:45 -0700
Subject: Request for review : 7088913 : 
Message-ID: <71D98C33-3311-4F07-A70C-764C8730FB2E@oracle.com>

A long, long time ago (2011) there was a review request[1] for 

CR#7088913 : Add compatible static hashCode(primitive) to primitive wrapper classes

The change was approved by the three cc:ed reviewers. At that time the webrev was co-mingled with another changeset that had more controversial changes. Neither changeset was committed and 7088913 got ignored and eventually forgotten. Until now. 

Since so much time has passed I am asking for review again so that the commit is not a surprise to anyone. The webrev incorporates Joe's suggestions from long ago and now including an expanded (though probably not complete) unit test.

http://cr.openjdk.java.net/~mduigou/7088913/1/webrev/

Mike

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-September/007733.html

From david.holmes at oracle.com  Thu Oct 25 04:18:26 2012
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 25 Oct 2012 14:18:26 +1000
Subject: Request for review : 7088913 :
In-Reply-To: <71D98C33-3311-4F07-A70C-764C8730FB2E@oracle.com>
References: <71D98C33-3311-4F07-A70C-764C8730FB2E@oracle.com>
Message-ID: <5088BD92.3080208@oracle.com>

Hi Mike,

Looks okay to me. I assume the ccc request will be resuscitated :)

David

On 25/10/2012 2:07 PM, Mike Duigou wrote:
> A long, long time ago (2011) there was a review request[1] for
>
> CR#7088913 : Add compatible static hashCode(primitive) to primitive wrapper classes
>
> The change was approved by the three cc:ed reviewers. At that time the webrev was co-mingled with another changeset that had more controversial changes. Neither changeset was committed and 7088913 got ignored and eventually forgotten. Until now.
>
> Since so much time has passed I am asking for review again so that the commit is not a surprise to anyone. The webrev incorporates Joe's suggestions from long ago and now including an expanded (though probably not complete) unit test.
>
> http://cr.openjdk.java.net/~mduigou/7088913/1/webrev/
>
> Mike
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-September/007733.html


From joe.darcy at oracle.com  Thu Oct 25 05:14:02 2012
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 24 Oct 2012 22:14:02 -0700
Subject: Request for review : 7088913 :
In-Reply-To: <71D98C33-3311-4F07-A70C-764C8730FB2E@oracle.com>
References: <71D98C33-3311-4F07-A70C-764C8730FB2E@oracle.com>
Message-ID: <5088CA9A.40608@oracle.com>

Hi Mike,

The code looks fine with one quibble in the test; the bugs should be 
listed on the same line.  Instead of

   * @bug 4245470
+ * @bug 7088913

use

     * @bug 4245470 7088913

Thanks,

-Joe

On 10/24/2012 9:07 PM, Mike Duigou wrote:
> A long, long time ago (2011) there was a review request[1] for
>
> CR#7088913 : Add compatible static hashCode(primitive) to primitive wrapper classes
>
> The change was approved by the three cc:ed reviewers. At that time the webrev was co-mingled with another changeset that had more controversial changes. Neither changeset was committed and 7088913 got ignored and eventually forgotten. Until now.
>
> Since so much time has passed I am asking for review again so that the commit is not a surprise to anyone. The webrev incorporates Joe's suggestions from long ago and now including an expanded (though probably not complete) unit test.
>
> http://cr.openjdk.java.net/~mduigou/7088913/1/webrev/
>
> Mike
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-September/007733.html



From chris.hegarty at oracle.com  Thu Oct 25 14:13:40 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 25 Oct 2012 15:13:40 +0100
Subject: Minor/sync/cleanup j.u.c with Dougs CVS - Oct 2012
Message-ID: <50894914.1010504@oracle.com>


In preparation to a re-sync of the java.util.concurrent classes with 
Doug's CVS, I've extracted most of the minor/small changes. This will 
reduce the noise when reviewing the remainder of the implementation 
changes. More specifically,

Cleanup:
   javadoc style/consistency
   javadoc example code style
   imports
   whitespace
   uniform serialization method javadoc
   typos

Minor/small impl changes:
   remove redundant null checks
   throw NPE when more efficient
   rework timeouts, lasttime -> deadline
   STPE, make drainTo methods more robust when add throws

To be clear, I'm not requested a review here. These are Doug's changes 
are I am already a reviewer, but please feel free ( be warned, nothing 
interesting here! )

http://cr.openjdk.java.net/~chegar/8001575/webrev.00/webrev/

-Chris.


From jim.gish at oracle.com  Thu Oct 25 17:25:34 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Thu, 25 Oct 2012 13:25:34 -0400
Subject: RFR: 7159567 - inconsistent configuration of MemoryHandler
In-Reply-To: <50888A93.1010705@oracle.com>
References: <50637167.4060006@oracle.com> <5063BD8C.2010607@oracle.com>
	<50645D19.4050505@oracle.com> <5065F6DD.7010801@oracle.com>
	<5066176D.6040005@oracle.com> <50773C27.3050407@oracle.com>
	<507F0B31.6030103@oracle.com> <50884201.4040806@oracle.com>
	<50888A93.1010705@oracle.com>
Message-ID: <5089760E.9070005@oracle.com>

OK.  One more time. 
http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler

I compromised with the RuntimeException.  I'm instead catching it, but 
throwing a new one this way:

   65             throw new RuntimeException(
   66                 "Test Failed: did not load java.util.logging.ConsoleHandler as expected",
   67                 rte);

That way, we retain the original, but have the advantage of having a clear indication of "Test Failed" and the reason.  Otherwise, diagnosing
the failure forces the reader to dig into the stack trace.

Thanks,
    Jim


On 10/24/2012 08:40 PM, Mandy Chung wrote:
> On 10/24/2012 12:31 PM, Jim Gish wrote:
>> See updated webrev: 
>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler
>>
>
> Looks good.  Thanks for the update.
>
> MemoryHandlerTest.java - thanks for renaming it but you forget to 
> change  L28 @run tag.  jtreg should fail if you run this new test.  
> L64-66 this try-catch block isn't necessary, as I mentioned in my 
> previous comment, but no big deal if you want to leave it there.  The 
> comment lines and some throw statements are really long and should be 
> broken into multiple lines (I didn't notice the long lines in previous 
> versions - sorry if I had missed them). Hopefully it's just one-click 
> reformat for you using IDE :)
>
> Mandy
>
>> Thanks,
>>     Jim
>>
>> On 10/17/2012 03:46 PM, Mandy Chung wrote:
>>> Hi Jim,
>>>
>>> On 10/11/2012 2:37 PM, Jim Gish wrote:
>>>> Please review the updated changes at 
>>>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/ 
>>>>
>>>>
>>>
>>> The spec change looks good.  As Alan points out, </li> is missing.  
>>> Although they were not there before, I would think it's a good clean 
>>> up while you are in these files if you agree.
>> Done
>>>
>>> The test looks better.   Is SimpleTargetHandler.numPublished 
>>> intended to be checked?  SimpleTargetHandler is set as the target 
>>> for java.util.logging.MemoryHandler.  I guess you want to create a 
>>> logger using the standard MemoryHandler.
>>>
>>> Nit: the test is named MemoryHandler and I guess the name conflict 
>>> causes the custom handler classes to extend 
>>> "java.util.logging.MemoryHandler" with a fully-qualified class 
>>> name.  As the properties file is named MemoryHandlerTest.props, do 
>>> you consider renaming the test to MemoryHandlerTest to avoid the 
>>> name conflict?   I don't have strong opinion and just want to point 
>>> that out.
>> I don't see this as a problem.  However, I've renamed MemoryHandler 
>> to MemoryHandlerTest for improved clarity.
>>>
>>> L62-64:  better not to rethrow a new RuntimeException as the 
>>> exception and stack trace will help diagnostics if it does go 
>>> wrong.  You can get rid of this try-catch block.
>> OK -- the reason I did this was to insert a readable message into the 
>> new RuntimeException to indicate the cause of the failure.  I think 
>> this is good practice and leads to easier diagnosis, but since you 
>> disagree, I'll take it out.
>>>
>>> L120: is it a leftover debug statement?  I think you meant to add 
>>> test case to exercise this target handler, right?
>> removed and a few tests added.
>>
>> ....Jim
>>
>>>
>>>> I've changed as you've requested, added some additional tests, did 
>>>> some better error handling in the case of a MemoryHandler not 
>>>> specifying a target (now throws RuntimeException with an 
>>>> appropriate message instead of attempting to load a null class and 
>>>> throwing NPE).  I also corrected the copyrights, tested with JCK, 
>>>> all jdk_lang tests and have submitted a JPRT job with core tests.
>>>>
>>>
>>> Great.  Thanks for doing it.
>>>
>>> Mandy
>>>
>>>> I've forwarded a CCC request (separately) and will await its 
>>>> approval and further review of this change.
>>>>
>>>> Thanks,
>>>>     Jim
>>>>
>>>> On 09/28/2012 05:32 PM, Mandy Chung wrote:
>>>>> On 9/28/2012 12:13 PM, Jim Gish wrote:
>>>>>> I've re-spun the change with additional usage notes in the spec 
>>>>>> to reflect the long-standing actual behavior.  Note that it 
>>>>>> doesn't change the spec per se, as it was already stated in 
>>>>>> LogManager. This change simply replicates that language with an 
>>>>>> example in each *Handler class to make it easier to find.
>>>>>>
>>>>>
>>>>> Thanks for looking into it.  This statement in LogManager does
>>>>> specify the properties for handlers:
>>>>>
>>>>>   The properties for loggers and Handlers will have names starting
>>>>>   with the dot-separated name for the handler or logger.
>>>>>
>>>>> Replicating that statement with an example is one way to do it.
>>>>> Would it be clearer if the prefix of the properties referenced
>>>>> in the bullet list is replaced from "java.util.logging" to
>>>>> some kind of prefix - something like this:
>>>>>
>>>>>  *<b>Configuration:</b>
>>>>>  * By default each<tt>ConsoleHandler</tt>  is initialized using 
>>>>> the following
>>>>>  *<tt>LogManager</tt>  configuration properties. If properties are 
>>>>> not defined
>>>>>  * (or have invalid values) then the specified default values are 
>>>>> used.
>>>>>  *<ul>
>>>>>  *<li> <handler's classname>.level
>>>>>  *        specifies the default level for the<tt>Handler</tt>
>>>>>  *        (defaults to<tt>Level.INFO</tt>).
>>>>>  ...<snip>
>>>>>  *</ul>
>>>>>  *
>>>>>  * For example, the properties for {@code ConsoleHandler} would be:
>>>>>  *     java.util.logging.ConsoleHandler.level=INFO
>>>>>  * 
>>>>> java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
>>>>>  *
>>>>>  * For a custom handler, e.g. com.foo.MyHandler, the properties 
>>>>> would be:
>>>>>  *     com.foo.MyHandler.level=INFO
>>>>>  * com.foo.MyHandler.formatter=java.util.logging.SimpleFormatter
>>>>>
>>>>> This might add some clarity to the spec.
>>>>>
>>>>> This is a spec bug fix that I would suggest to file a CCC to
>>>>> track for compatibility.  I would also suggest running the JCK
>>>>> tests to find out if there is any regression due to this fix.
>>>>>
>>>>>
>>>>>> The webrev, as posted at 
>>>>>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/ 
>>>>>>
>>>>>
>>>>> See my comment above w.r.t. the spec change.
>>>>>
>>>>> test/java/util/logging/MemoryHandler.java
>>>>>   L27: "via via" typo
>>>>>   L28: @run tag specifies the test name
>>>>>        So it should be @run main/othervm MemoryHandler
>>>>>
>>>>>   L43: jtreg runs the test in a different working directory
>>>>>   other than the test source.  So the test has to read
>>>>>   the system property ("test.src") to determine the location
>>>>>   of the properties file.  Typically, we will do this:
>>>>>     String src = System.getProperty("test.src", ".);
>>>>>     File   fname  = new File(src, LM_PROP_FNAME);
>>>>>
>>>>>   You don't need L44. You can reference LoggingDeadlock3.java test.
>>>>>
>>>>>   L51: this catch block to throw a RuntimeException doesn't seem
>>>>>   necessary.  If NPE is thrown, the test will fail anyway.
>>>>>
>>>>>   One suggestion to the test is to test both cases (one with
>>>>>   the specified target handler and one without).  You can
>>>>>   define a custom target handler so that the test can verify
>>>>>   if the expected one is used.  A simple handler to count
>>>>>   the number of log messages will do the work.
>>>>>
>>>>> test/java/util/logging/MemoryHandlerTest.props
>>>>>   I suggest to take out the comments and just keep the
>>>>>   properties the test needs to make it easier to tell
>>>>>   what's configured.
>>>>>   Perhaps you should also specify
>>>>>   java.util.logging.MemoryHandler.target to make sure
>>>>>   that the custom handler with no target handler specified
>>>>>   will not use j.u.l.MemoryHandler.target as the default.
>>>>>
>>>>> Mandy
>>>>>
>>>>
>>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From mandy.chung at oracle.com  Thu Oct 25 17:47:08 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 25 Oct 2012 10:47:08 -0700
Subject: RFR: 7159567 - inconsistent configuration of MemoryHandler
In-Reply-To: <5089760E.9070005@oracle.com>
References: <50637167.4060006@oracle.com> <5063BD8C.2010607@oracle.com>
	<50645D19.4050505@oracle.com> <5065F6DD.7010801@oracle.com>
	<5066176D.6040005@oracle.com> <50773C27.3050407@oracle.com>
	<507F0B31.6030103@oracle.com> <50884201.4040806@oracle.com>
	<50888A93.1010705@oracle.com> <5089760E.9070005@oracle.com>
Message-ID: <50897B1C.8050903@oracle.com>

On 10/25/2012 10:25 AM, Jim Gish wrote:
> OK.  One more time. 
> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler
>

Great, thanks! I'll push it for you.

> I compromised with the RuntimeException.  I'm instead catching it, but 
> throwing a new one this way:
>    65             throw new RuntimeException(
>    66                 "Test Failed: did not load java.util.logging.ConsoleHandler as expected",
>    67                 rte);
>
> That way, we retain the original, but have the advantage of having a clear indication of "Test Failed" and the reason.  Otherwise, diagnosing
> the failure forces the reader to dig into the stack trace.

I like a clear error message too.  If the test fails, you will need the 
original exception and the stack trace to diagnose the problem anyway 
and in some cases, the exception is clear enough.  Anyway, just to 
explain why I had the comment.  I'm okay with what you have.

Mandy

> Thanks,
>     Jim
>
>
> On 10/24/2012 08:40 PM, Mandy Chung wrote:
>> On 10/24/2012 12:31 PM, Jim Gish wrote:
>>> See updated webrev: 
>>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler
>>>
>>
>> Looks good.  Thanks for the update.
>>
>> MemoryHandlerTest.java - thanks for renaming it but you forget to 
>> change  L28 @run tag.  jtreg should fail if you run this new test.  
>> L64-66 this try-catch block isn't necessary, as I mentioned in my 
>> previous comment, but no big deal if you want to leave it there.  The 
>> comment lines and some throw statements are really long and should be 
>> broken into multiple lines (I didn't notice the long lines in 
>> previous versions - sorry if I had missed them).   Hopefully it's 
>> just one-click reformat for you using IDE :)
>>
>> Mandy
>>
>>> Thanks,
>>>     Jim
>>>
>>> On 10/17/2012 03:46 PM, Mandy Chung wrote:
>>>> Hi Jim,
>>>>
>>>> On 10/11/2012 2:37 PM, Jim Gish wrote:
>>>>> Please review the updated changes at 
>>>>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/ 
>>>>>
>>>>>
>>>>
>>>> The spec change looks good.  As Alan points out, </li> is missing.  
>>>> Although they were not there before, I would think it's a good 
>>>> clean up while you are in these files if you agree.
>>> Done
>>>>
>>>> The test looks better.   Is SimpleTargetHandler.numPublished 
>>>> intended to be checked?  SimpleTargetHandler is set as the target 
>>>> for java.util.logging.MemoryHandler.  I guess you want to create a 
>>>> logger using the standard MemoryHandler.
>>>>
>>>> Nit: the test is named MemoryHandler and I guess the name conflict 
>>>> causes the custom handler classes to extend 
>>>> "java.util.logging.MemoryHandler" with a fully-qualified class 
>>>> name.  As the properties file is named MemoryHandlerTest.props, do 
>>>> you consider renaming the test to MemoryHandlerTest to avoid the 
>>>> name conflict?   I don't have strong opinion and just want to point 
>>>> that out.
>>> I don't see this as a problem.  However, I've renamed MemoryHandler 
>>> to MemoryHandlerTest for improved clarity.
>>>>
>>>> L62-64:  better not to rethrow a new RuntimeException as the 
>>>> exception and stack trace will help diagnostics if it does go 
>>>> wrong.  You can get rid of this try-catch block.
>>> OK -- the reason I did this was to insert a readable message into 
>>> the new RuntimeException to indicate the cause of the failure.  I 
>>> think this is good practice and leads to easier diagnosis, but since 
>>> you disagree, I'll take it out.
>>>>
>>>> L120: is it a leftover debug statement?  I think you meant to add 
>>>> test case to exercise this target handler, right?
>>> removed and a few tests added.
>>>
>>> ....Jim
>>>
>>>>
>>>>> I've changed as you've requested, added some additional tests, did 
>>>>> some better error handling in the case of a MemoryHandler not 
>>>>> specifying a target (now throws RuntimeException with an 
>>>>> appropriate message instead of attempting to load a null class and 
>>>>> throwing NPE).  I also corrected the copyrights, tested with JCK, 
>>>>> all jdk_lang tests and have submitted a JPRT job with core tests.
>>>>>
>>>>
>>>> Great.  Thanks for doing it.
>>>>
>>>> Mandy
>>>>
>>>>> I've forwarded a CCC request (separately) and will await its 
>>>>> approval and further review of this change.
>>>>>
>>>>> Thanks,
>>>>>     Jim
>>>>>
>>>>> On 09/28/2012 05:32 PM, Mandy Chung wrote:
>>>>>> On 9/28/2012 12:13 PM, Jim Gish wrote:
>>>>>>> I've re-spun the change with additional usage notes in the spec 
>>>>>>> to reflect the long-standing actual behavior.  Note that it 
>>>>>>> doesn't change the spec per se, as it was already stated in 
>>>>>>> LogManager. This change simply replicates that language with an 
>>>>>>> example in each *Handler class to make it easier to find.
>>>>>>>
>>>>>>
>>>>>> Thanks for looking into it.  This statement in LogManager does
>>>>>> specify the properties for handlers:
>>>>>>
>>>>>>   The properties for loggers and Handlers will have names starting
>>>>>>   with the dot-separated name for the handler or logger.
>>>>>>
>>>>>> Replicating that statement with an example is one way to do it.
>>>>>> Would it be clearer if the prefix of the properties referenced
>>>>>> in the bullet list is replaced from "java.util.logging" to
>>>>>> some kind of prefix - something like this:
>>>>>>
>>>>>>  *<b>Configuration:</b>
>>>>>>  * By default each<tt>ConsoleHandler</tt>  is initialized using 
>>>>>> the following
>>>>>>  *<tt>LogManager</tt>  configuration properties. If properties 
>>>>>> are not defined
>>>>>>  * (or have invalid values) then the specified default values are 
>>>>>> used.
>>>>>>  *<ul>
>>>>>>  *<li> <handler's classname>.level
>>>>>>  *        specifies the default level for the<tt>Handler</tt>
>>>>>>  *        (defaults to<tt>Level.INFO</tt>).
>>>>>>  ...<snip>
>>>>>>  *</ul>
>>>>>>  *
>>>>>>  * For example, the properties for {@code ConsoleHandler} would be:
>>>>>>  *     java.util.logging.ConsoleHandler.level=INFO
>>>>>>  * 
>>>>>> java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
>>>>>>  *
>>>>>>  * For a custom handler, e.g. com.foo.MyHandler, the properties 
>>>>>> would be:
>>>>>>  *     com.foo.MyHandler.level=INFO
>>>>>>  * com.foo.MyHandler.formatter=java.util.logging.SimpleFormatter
>>>>>>
>>>>>> This might add some clarity to the spec.
>>>>>>
>>>>>> This is a spec bug fix that I would suggest to file a CCC to
>>>>>> track for compatibility.  I would also suggest running the JCK
>>>>>> tests to find out if there is any regression due to this fix.
>>>>>>
>>>>>>
>>>>>>> The webrev, as posted at 
>>>>>>> http://cr.openjdk.java.net/~jgish/Bug7159567-set-logging-MemoryHandler/ 
>>>>>>>
>>>>>>
>>>>>> See my comment above w.r.t. the spec change.
>>>>>>
>>>>>> test/java/util/logging/MemoryHandler.java
>>>>>>   L27: "via via" typo
>>>>>>   L28: @run tag specifies the test name
>>>>>>        So it should be @run main/othervm MemoryHandler
>>>>>>
>>>>>>   L43: jtreg runs the test in a different working directory
>>>>>>   other than the test source.  So the test has to read
>>>>>>   the system property ("test.src") to determine the location
>>>>>>   of the properties file.  Typically, we will do this:
>>>>>>     String src = System.getProperty("test.src", ".);
>>>>>>     File   fname  = new File(src, LM_PROP_FNAME);
>>>>>>
>>>>>>   You don't need L44. You can reference LoggingDeadlock3.java test.
>>>>>>
>>>>>>   L51: this catch block to throw a RuntimeException doesn't seem
>>>>>>   necessary.  If NPE is thrown, the test will fail anyway.
>>>>>>
>>>>>>   One suggestion to the test is to test both cases (one with
>>>>>>   the specified target handler and one without).  You can
>>>>>>   define a custom target handler so that the test can verify
>>>>>>   if the expected one is used.  A simple handler to count
>>>>>>   the number of log messages will do the work.
>>>>>>
>>>>>> test/java/util/logging/MemoryHandlerTest.props
>>>>>>   I suggest to take out the comments and just keep the
>>>>>>   properties the test needs to make it easier to tell
>>>>>>   what's configured.
>>>>>>   Perhaps you should also specify
>>>>>>   java.util.logging.MemoryHandler.target to make sure
>>>>>>   that the custom handler with no target handler specified
>>>>>>   will not use j.u.l.MemoryHandler.target as the default.
>>>>>>
>>>>>> Mandy
>>>>>>
>>>>>
>>>
>
> -- 
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.gish at oracle.com


From jonathan.gibbons at oracle.com  Thu Oct 25 18:10:26 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 25 Oct 2012 18:10:26 +0000
Subject: hg: jdk8/tl/langtools: 7200915: convert TypeTags from a series of
	small ints to an enum
Message-ID: <20121025181031.6274847544@hg.openjdk.java.net>

Changeset: c002fdee76fd
Author:    jjg
Date:      2012-10-25 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c002fdee76fd

7200915: convert TypeTags from a series of small ints to an enum
Reviewed-by: jjg, mcimadamore
Contributed-by: vicente.romero at oracle.com

! src/share/classes/com/sun/tools/javac/code/Attribute.java
! src/share/classes/com/sun/tools/javac/code/Kinds.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Symtab.java
! src/share/classes/com/sun/tools/javac/code/Type.java
+ src/share/classes/com/sun/tools/javac/code/TypeTag.java
- src/share/classes/com/sun/tools/javac/code/TypeTags.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java
! src/share/classes/com/sun/tools/javac/comp/Check.java
! src/share/classes/com/sun/tools/javac/comp/ConstFold.java
! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java
! src/share/classes/com/sun/tools/javac/comp/Enter.java
! src/share/classes/com/sun/tools/javac/comp/Flow.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/comp/Lower.java
! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/share/classes/com/sun/tools/javac/jvm/Code.java
! src/share/classes/com/sun/tools/javac/jvm/Gen.java
! src/share/classes/com/sun/tools/javac/jvm/UninitializedType.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/model/JavacElements.java
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/share/classes/com/sun/tools/javac/tree/Pretty.java
! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java
! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java
! src/share/classes/com/sun/tools/javac/util/Constants.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java
! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java
! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java
! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java
! src/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java
! src/share/classes/com/sun/tools/javadoc/TypeMaker.java
! test/tools/javac/6889255/T6889255.java
! test/tools/javac/tree/MakeLiteralTest.java



From jonathan.gibbons at oracle.com  Thu Oct 25 20:33:38 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Thu, 25 Oct 2012 20:33:38 +0000
Subject: hg: jdk8/tl/langtools: 6725230: Java Compilation with Jsr199 ignores
	Class-Path in manifest
Message-ID: <20121025203343.BC83B47548@hg.openjdk.java.net>

Changeset: ea2616a6bd01
Author:    jjg
Date:      2012-10-25 13:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ea2616a6bd01

6725230: Java Compilation with Jsr199 ignores Class-Path in manifest
Reviewed-by: jjg, mcimadamore
Contributed-by: vicente.romero at oracle.com

! src/share/classes/com/sun/tools/javac/file/Locations.java
+ test/tools/javac/Paths/TestCompileJARInClassPath.java



From dan.xu at oracle.com  Thu Oct 25 21:26:49 2012
From: dan.xu at oracle.com (Dan Xu)
Date: Thu, 25 Oct 2012 14:26:49 -0700
Subject: Review Request - JDK-4239752: FileSystem should be a platform-specific
	class to avoid native code
Message-ID: <5089AE99.8000300@oracle.com>

Hi,

Please review the code change to avoid native codes when creating the 
FileSystem object, http://cr.openjdk.java.net/~dxu/4239752/webrev/.

In the change, the native codes for windows and unix platforms are 
removed. Instead, corresponding Java codes are added for each platform. 
Thanks!

-Dan


From dan.xu at oracle.com  Thu Oct 25 21:45:32 2012
From: dan.xu at oracle.com (Dan Xu)
Date: Thu, 25 Oct 2012 14:45:32 -0700
Subject: Review Request: JDK-8001565, (fs) Typo Path.endsWith(String) javadoc
Message-ID: <5089B2FC.3070500@oracle.com>

Hi,

Please help review the javadoc typo fix at, 
http://cr.openjdk.java.net/~dxu/8001565/webrev/. Thanks!

-Dan



From Lance.Andersen at oracle.com  Thu Oct 25 21:47:48 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Thu, 25 Oct 2012 17:47:48 -0400
Subject: Review Request: JDK-8001565,
	(fs) Typo Path.endsWith(String) javadoc
In-Reply-To: <5089B2FC.3070500@oracle.com>
References: <5089B2FC.3070500@oracle.com>
Message-ID: <38B37E1F-9B66-42AB-AF8E-B87595F3AADF@oracle.com>

This fix is fine Dan

Best
Lance
On Oct 25, 2012, at 5:45 PM, Dan Xu wrote:

> Hi,
> 
> Please help review the javadoc typo fix at, http://cr.openjdk.java.net/~dxu/8001565/webrev/. Thanks!
> 
> -Dan
> 

-------------- next part --------------

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  Thu Oct 25 22:12:14 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 25 Oct 2012 15:12:14 -0700
Subject: Review Request: JDK-8001565, (fs) Typo Path.endsWith(String)
	javadoc
In-Reply-To: <5089B2FC.3070500@oracle.com>
References: <5089B2FC.3070500@oracle.com>
Message-ID: <5089B93E.6020609@oracle.com>

On 10/25/2012 2:45 PM, Dan Xu wrote:
> Hi,
>
> Please help review the javadoc typo fix at, 
> http://cr.openjdk.java.net/~dxu/8001565/webrev/. Thanks!
>

Looks good with me.  I can push this for you.

Mandy



From mandy.chung at oracle.com  Thu Oct 25 22:11:57 2012
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 25 Oct 2012 22:11:57 +0000
Subject: hg: jdk8/tl/jdk: 7159567: inconsistent configuration of MemoryHandler
Message-ID: <20121025221209.B2FA44754A@hg.openjdk.java.net>

Changeset: 37a4b4892e8e
Author:    jgish
Date:      2012-10-25 15:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37a4b4892e8e

7159567: inconsistent configuration of MemoryHandler
Reviewed-by: mchung, alanb

! src/share/classes/java/util/logging/ConsoleHandler.java
! src/share/classes/java/util/logging/FileHandler.java
! src/share/classes/java/util/logging/MemoryHandler.java
! src/share/classes/java/util/logging/SocketHandler.java
! src/share/classes/java/util/logging/StreamHandler.java
+ test/java/util/logging/MemoryHandlerTest.java
+ test/java/util/logging/MemoryHandlerTest.props



From jim.gish at oracle.com  Thu Oct 25 22:13:21 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Thu, 25 Oct 2012 18:13:21 -0400
Subject: Review Request - JDK-4239752: FileSystem should be a
	platform-specific class to avoid native code
In-Reply-To: <5089AE99.8000300@oracle.com>
References: <5089AE99.8000300@oracle.com>
Message-ID: <5089B981.7080805@oracle.com>

Looks good to me.

Jim

On 10/25/2012 05:26 PM, Dan Xu wrote:
> Hi,
>
> Please review the code change to avoid native codes when creating the 
> FileSystem object, http://cr.openjdk.java.net/~dxu/4239752/webrev/.
>
> In the change, the native codes for windows and unix platforms are 
> removed. Instead, corresponding Java codes are added for each 
> platform. Thanks!
>
> -Dan

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From jim.gish at oracle.com  Thu Oct 25 22:15:22 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Thu, 25 Oct 2012 18:15:22 -0400
Subject: Review Request: JDK-8001565, (fs) Typo Path.endsWith(String)
	javadoc
In-Reply-To: <5089B2FC.3070500@oracle.com>
References: <5089B2FC.3070500@oracle.com>
Message-ID: <5089B9FA.6060407@oracle.com>

Fine and "Dan"dy :-)

...Jim

On 10/25/2012 05:45 PM, Dan Xu wrote:
> Hi,
>
> Please help review the javadoc typo fix at, 
> http://cr.openjdk.java.net/~dxu/8001565/webrev/. Thanks!
>
> -Dan
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From dan.xu at oracle.com  Thu Oct 25 22:17:18 2012
From: dan.xu at oracle.com (Dan Xu)
Date: Thu, 25 Oct 2012 15:17:18 -0700
Subject: Review Request: JDK-8001565, (fs) Typo Path.endsWith(String)
	javadoc
In-Reply-To: <5089B93E.6020609@oracle.com>
References: <5089B2FC.3070500@oracle.com> <5089B93E.6020609@oracle.com>
Message-ID: <5089BA6E.5090101@oracle.com>

Thank you. Do you need me to generate the patch?

-Dan


On 10/25/2012 03:12 PM, Mandy Chung wrote:
> On 10/25/2012 2:45 PM, Dan Xu wrote:
>> Hi,
>>
>> Please help review the javadoc typo fix at, 
>> http://cr.openjdk.java.net/~dxu/8001565/webrev/. Thanks!
>>
>
> Looks good with me.  I can push this for you.
>
> Mandy
>



From mandy.chung at oracle.com  Thu Oct 25 22:40:58 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 25 Oct 2012 15:40:58 -0700
Subject: Review Request: JDK-8001565, (fs) Typo Path.endsWith(String)
	javadoc
In-Reply-To: <5089BA6E.5090101@oracle.com>
References: <5089B2FC.3070500@oracle.com> <5089B93E.6020609@oracle.com>
	<5089BA6E.5090101@oracle.com>
Message-ID: <5089BFFA.5050800@oracle.com>

I have your patch from the webrev.
Mandy

On 10/25/2012 3:17 PM, Dan Xu wrote:
> Thank you. Do you need me to generate the patch?
>
> -Dan
>
>
> On 10/25/2012 03:12 PM, Mandy Chung wrote:
>> On 10/25/2012 2:45 PM, Dan Xu wrote:
>>> Hi,
>>>
>>> Please help review the javadoc typo fix at, 
>>> http://cr.openjdk.java.net/~dxu/8001565/webrev/. Thanks!
>>>
>>
>> Looks good with me.  I can push this for you.
>>
>> Mandy
>>
>


From mandy.chung at oracle.com  Thu Oct 25 22:43:13 2012
From: mandy.chung at oracle.com (mandy.chung at oracle.com)
Date: Thu, 25 Oct 2012 22:43:13 +0000
Subject: hg: jdk8/tl/jdk: 8001565: (fs) Typo Path.endsWith(String) javadoc
Message-ID: <20121025224337.093FF47555@hg.openjdk.java.net>

Changeset: 27677928a937
Author:    dxu
Date:      2012-10-25 15:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27677928a937

8001565: (fs) Typo Path.endsWith(String) javadoc
Reviewed-by: mchung, jgish, lancea

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



From david.holmes at oracle.com  Fri Oct 26 02:06:49 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 26 Oct 2012 12:06:49 +1000
Subject: Minor/sync/cleanup j.u.c with Dougs CVS - Oct 2012
In-Reply-To: <50894914.1010504@oracle.com>
References: <50894914.1010504@oracle.com>
Message-ID: <5089F039.7020507@oracle.com>

Hi Chris,

You can count me as a reviewer anyway. :)

A couple of observations:

--- old/src/share/classes/java/util/concurrent/ExecutionException.java 
Thu Oct 25 14:14:15 2012
+++ new/src/share/classes/java/util/concurrent/ExecutionException.java 
Thu Oct 25 14:14:14 2012
@@ -79,11 +79,9 @@

      /**
       * Constructs an <tt>ExecutionException</tt> with the specified cause.
-     * The detail message is set to:
-     * <pre>
-     *  (cause == null ? null : cause.toString())</pre>
-     * (which typically contains the class and detail message of
-     * <tt>cause</tt>).
+     * The detail message is set to {@code (cause == null ? null :
+     * cause.toString())} (which typically contains the class and
+     * detail message of <tt>cause</tt>).

The last <tt>cause</tt> should be replaced by {@Code cause}.

There are a couple of places that refer to JLS (eg package-info, Locks.java)

+ * <a href="http://java.sun.com/docs/books/jls/"> The Java Language
+ * Specification, Third Edition (17.4 Memory Model)</a>:

which should, I believe, be updated to:

http://docs.oracle.com/javase/specs/jls/se7/html/index.html

Thanks,
David

On 26/10/2012 12:13 AM, Chris Hegarty wrote:
>
> In preparation to a re-sync of the java.util.concurrent classes with
> Doug's CVS, I've extracted most of the minor/small changes. This will
> reduce the noise when reviewing the remainder of the implementation
> changes. More specifically,
>
> Cleanup:
> javadoc style/consistency
> javadoc example code style
> imports
> whitespace
> uniform serialization method javadoc
> typos
>
> Minor/small impl changes:
> remove redundant null checks
> throw NPE when more efficient
> rework timeouts, lasttime -> deadline
> STPE, make drainTo methods more robust when add throws
>
> To be clear, I'm not requested a review here. These are Doug's changes
> are I am already a reviewer, but please feel free ( be warned, nothing
> interesting here! )
>
> http://cr.openjdk.java.net/~chegar/8001575/webrev.00/webrev/
>
> -Chris.


From david.holmes at oracle.com  Fri Oct 26 02:33:25 2012
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 26 Oct 2012 12:33:25 +1000
Subject: Review Request - JDK-4239752: FileSystem should be a
	platform-specific class to avoid native code
In-Reply-To: <5089AE99.8000300@oracle.com>
References: <5089AE99.8000300@oracle.com>
Message-ID: <5089F675.3040900@oracle.com>

Looks good to me.

I have to wonder why we ever used a native method to invoke a Java 
constructor though ???

David

On 26/10/2012 7:26 AM, Dan Xu wrote:
> Hi,
>
> Please review the code change to avoid native codes when creating the
> FileSystem object, http://cr.openjdk.java.net/~dxu/4239752/webrev/.
>
> In the change, the native codes for windows and unix platforms are
> removed. Instead, corresponding Java codes are added for each platform.
> Thanks!
>
> -Dan


From Alan.Bateman at oracle.com  Fri Oct 26 08:17:31 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 26 Oct 2012 09:17:31 +0100
Subject: Review Request - JDK-4239752: FileSystem should be a
	platform-specific class to avoid native code
In-Reply-To: <5089AE99.8000300@oracle.com>
References: <5089AE99.8000300@oracle.com>
Message-ID: <508A471B.4050506@oracle.com>

On 25/10/2012 22:26, Dan Xu wrote:
> Hi,
>
> Please review the code change to avoid native codes when creating the 
> FileSystem object, http://cr.openjdk.java.net/~dxu/4239752/webrev/.
>
> In the change, the native codes for windows and unix platforms are 
> removed. Instead, corresponding Java codes are added for each 
> platform. Thanks!
>
> -Dan
Thanks for taking this one, the changes looks good to me, and a good 
follow-up to 7186817 [1]. Also thank you for spending the time to make 
sure that it builds with both the old and the new build system. I'll 
push it for you today.

-Alan.

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


From alan.bateman at oracle.com  Fri Oct 26 10:22:46 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Fri, 26 Oct 2012 10:22:46 +0000
Subject: hg: jdk8/tl/jdk: 4239752: FileSystem should be a platform-specific
	class to avoid native code
Message-ID: <20121026102335.0C15F47585@hg.openjdk.java.net>

Changeset: 0b52c87c39da
Author:    dxu
Date:      2012-10-26 11:21 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b52c87c39da

4239752: FileSystem should be a platform-specific class to avoid native code
Reviewed-by: alanb, dholmes, erikj, jgish

! make/java/java/Exportedfiles.gmk
! make/java/java/FILES_c.gmk
! make/java/java/FILES_java.gmk
! make/java/java/mapfile-vers
! makefiles/CompileJavaClasses.gmk
! makefiles/mapfiles/libjava/mapfile-vers
! src/share/classes/java/io/File.java
! src/share/classes/java/io/FileSystem.java
+ src/solaris/classes/java/io/DefaultFileSystem.java
- src/solaris/native/java/io/FileSystem_md.c
+ src/windows/classes/java/io/DefaultFileSystem.java
- src/windows/native/java/io/FileSystem_md.c



From mandy.chung at oracle.com  Fri Oct 26 18:13:30 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 26 Oct 2012 11:13:30 -0700
Subject: Review Request - JDK-4239752: FileSystem should be a
	platform-specific class to avoid native code
In-Reply-To: <5089AE99.8000300@oracle.com>
References: <5089AE99.8000300@oracle.com>
Message-ID: <508AD2CA.4000605@oracle.com>

Looks good to me.   You also fixed the new build to include 
java.io.FileSystem - that's good.

Mandy

On 10/25/2012 2:26 PM, Dan Xu wrote:
> Hi,
>
> Please review the code change to avoid native codes when creating the 
> FileSystem object, http://cr.openjdk.java.net/~dxu/4239752/webrev/.
>
> In the change, the native codes for windows and unix platforms are 
> removed. Instead, corresponding Java codes are added for each 
> platform. Thanks!
>
> -Dan


From jonathan.gibbons at oracle.com  Fri Oct 26 20:11:00 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 26 Oct 2012 20:11:00 +0000
Subject: hg: jdk8/tl/langtools: 8001219: Clean up use of URLs in javadoc
	Extern class
Message-ID: <20121026201102.1FB584759E@hg.openjdk.java.net>

Changeset: 217c265158fe
Author:    jjg
Date:      2012-10-26 13:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/217c265158fe

8001219: Clean up use of URLs in javadoc Extern class
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java



From chris.hegarty at oracle.com  Fri Oct 26 20:40:49 2012
From: chris.hegarty at oracle.com (chris.hegarty at oracle.com)
Date: Fri, 26 Oct 2012 20:40:49 +0000
Subject: hg: jdk8/tl/jdk: 8001575: Minor/sync/cleanup j.u.c with Dougs CVS -
	Oct 2012
Message-ID: <20121026204109.391A54759F@hg.openjdk.java.net>

Changeset: 3fc5457cf779
Author:    dl
Date:      2012-10-26 21:34 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3fc5457cf779

8001575: Minor/sync/cleanup j.u.c with Dougs CVS - Oct 2012
Reviewed-by: chegar, dholmes

! src/share/classes/java/util/concurrent/AbstractExecutorService.java
! src/share/classes/java/util/concurrent/BlockingQueue.java
! src/share/classes/java/util/concurrent/BrokenBarrierException.java
! src/share/classes/java/util/concurrent/CompletionService.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentMap.java
! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/CountDownLatch.java
! src/share/classes/java/util/concurrent/CyclicBarrier.java
! src/share/classes/java/util/concurrent/Delayed.java
! src/share/classes/java/util/concurrent/ExecutionException.java
! src/share/classes/java/util/concurrent/Executor.java
! src/share/classes/java/util/concurrent/ExecutorService.java
! src/share/classes/java/util/concurrent/Executors.java
! src/share/classes/java/util/concurrent/Future.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/RecursiveAction.java
! src/share/classes/java/util/concurrent/RejectedExecutionException.java
! src/share/classes/java/util/concurrent/ScheduledExecutorService.java
! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
! src/share/classes/java/util/concurrent/Semaphore.java
! src/share/classes/java/util/concurrent/SynchronousQueue.java
! src/share/classes/java/util/concurrent/ThreadFactory.java
! src/share/classes/java/util/concurrent/TimeUnit.java
! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java
! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicLong.java
! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/AtomicReference.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java
! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
! src/share/classes/java/util/concurrent/atomic/package-info.java
! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
! src/share/classes/java/util/concurrent/locks/Condition.java
! src/share/classes/java/util/concurrent/locks/Lock.java
! src/share/classes/java/util/concurrent/locks/LockSupport.java
! src/share/classes/java/util/concurrent/locks/ReentrantLock.java
! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
! src/share/classes/java/util/concurrent/package-info.java



From chris.hegarty at oracle.com  Fri Oct 26 20:43:03 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 26 Oct 2012 21:43:03 +0100
Subject: Minor/sync/cleanup j.u.c with Dougs CVS - Oct 2012
In-Reply-To: <5089F039.7020507@oracle.com>
References: <50894914.1010504@oracle.com> <5089F039.7020507@oracle.com>
Message-ID: <508AF5D7.3060705@oracle.com>

Thanks David,

   java.sun.com... D'oh. Updated and pushed. The meat will come shortly!

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3fc5457cf779

-Chris.


On 10/26/2012 03:06 AM, David Holmes wrote:
> Hi Chris,
>
> You can count me as a reviewer anyway. :)
>
> A couple of observations:
>
> --- old/src/share/classes/java/util/concurrent/ExecutionException.java
> Thu Oct 25 14:14:15 2012
> +++ new/src/share/classes/java/util/concurrent/ExecutionException.java
> Thu Oct 25 14:14:14 2012
> @@ -79,11 +79,9 @@
>
>       /**
>        * Constructs an <tt>ExecutionException</tt> with the specified
> cause.
> -     * The detail message is set to:
> -     * <pre>
> -     *  (cause == null ? null : cause.toString())</pre>
> -     * (which typically contains the class and detail message of
> -     * <tt>cause</tt>).
> +     * The detail message is set to {@code (cause == null ? null :
> +     * cause.toString())} (which typically contains the class and
> +     * detail message of <tt>cause</tt>).
>
> The last <tt>cause</tt> should be replaced by {@Code cause}.
>
> There are a couple of places that refer to JLS (eg package-info,
> Locks.java)
>
> + * <a href="http://java.sun.com/docs/books/jls/"> The Java Language
> + * Specification, Third Edition (17.4 Memory Model)</a>:
>
> which should, I believe, be updated to:
>
> http://docs.oracle.com/javase/specs/jls/se7/html/index.html
>
> Thanks,
> David
>
> On 26/10/2012 12:13 AM, Chris Hegarty wrote:
>>
>> In preparation to a re-sync of the java.util.concurrent classes with
>> Doug's CVS, I've extracted most of the minor/small changes. This will
>> reduce the noise when reviewing the remainder of the implementation
>> changes. More specifically,
>>
>> Cleanup:
>> javadoc style/consistency
>> javadoc example code style
>> imports
>> whitespace
>> uniform serialization method javadoc
>> typos
>>
>> Minor/small impl changes:
>> remove redundant null checks
>> throw NPE when more efficient
>> rework timeouts, lasttime -> deadline
>> STPE, make drainTo methods more robust when add throws
>>
>> To be clear, I'm not requested a review here. These are Doug's changes
>> are I am already a reviewer, but please feel free ( be warned, nothing
>> interesting here! )
>>
>> http://cr.openjdk.java.net/~chegar/8001575/webrev.00/webrev/
>>
>> -Chris.


From jonathan.gibbons at oracle.com  Fri Oct 26 23:41:48 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Fri, 26 Oct 2012 23:41:48 +0000
Subject: hg: jdk8/tl/langtools: 8001229: refactor javac so that ct.sym is just
	used for javac, not all clients of JavacFileManager
Message-ID: <20121026234153.3B355475C2@hg.openjdk.java.net>

Changeset: e6cb81683ffe
Author:    jjg
Date:      2012-10-26 16:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e6cb81683ffe

8001229: refactor javac so that ct.sym is just used for javac, not all clients of JavacFileManager
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javah/JavahFileManager.java
! src/share/classes/com/sun/tools/javah/JavahTask.java
! src/share/classes/com/sun/tools/javap/JavapFileManager.java



From jonathan.gibbons at oracle.com  Sat Oct 27 00:18:06 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Sat, 27 Oct 2012 00:18:06 +0000
Subject: hg: jdk8/tl/langtools: 8001714: add missing tests for 7199925
Message-ID: <20121027001809.24D5A475C4@hg.openjdk.java.net>

Changeset: 64fce9f95b1d
Author:    jjg
Date:      2012-10-26 17:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/64fce9f95b1d

8001714: add missing tests for 7199925
Reviewed-by: darcy

+ test/tools/javac/annotations/repeatingAnnotations/ClassReaderDefault.java
+ test/tools/javac/annotations/repeatingAnnotations/SeparateCompile.java



From jonathan.gibbons at oracle.com  Sat Oct 27 01:40:48 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Sat, 27 Oct 2012 01:40:48 +0000
Subject: hg: jdk8/tl/langtools: 8001717: TypeTags cleanup breaks GenStubs
Message-ID: <20121027014050.4FBB6475CA@hg.openjdk.java.net>

Changeset: 384f7a4beae7
Author:    jjg
Date:      2012-10-26 18:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/384f7a4beae7

8001717: TypeTags cleanup breaks GenStubs
Reviewed-by: jjh

! make/tools/genstubs/GenStubs.java



From alan.bateman at oracle.com  Sat Oct 27 10:26:14 2012
From: alan.bateman at oracle.com (alan.bateman at oracle.com)
Date: Sat, 27 Oct 2012 10:26:14 +0000
Subject: hg: jdk8/tl/jdk: 7176225: Remove JDBC-ODBC Bridge
Message-ID: <20121027102657.1AC6847626@hg.openjdk.java.net>

Changeset: 615af31cfccc
Author:    alanb
Date:      2012-10-27 09:18 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/615af31cfccc

7176225: Remove JDBC-ODBC Bridge
Reviewed-by: lancea, ohair, tbell

! make/common/Sanity.gmk
! make/common/shared/Defs-solaris.gmk
! make/common/shared/Sanity.gmk
! make/sun/Makefile
- make/sun/jdbc/Makefile
! makefiles/CompileNativeLibraries.gmk
! makefiles/CopyIntoClasses.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcMisc.gmk



From weijun.wang at oracle.com  Mon Oct 29 06:15:10 2012
From: weijun.wang at oracle.com (weijun.wang at oracle.com)
Date: Mon, 29 Oct 2012 06:15:10 +0000
Subject: hg: jdk8/tl/jdk: 2 new changesets
Message-ID: <20121029061542.A54FA4763F@hg.openjdk.java.net>

Changeset: 33e29fbc3e5b
Author:    weijun
Date:      2012-10-29 14:14 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33e29fbc3e5b

7184246: Simplify Config.get() of krb5
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/Checksum.java
! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/KdcComm.java
! src/share/classes/sun/security/krb5/PrincipalName.java
! src/share/classes/sun/security/krb5/Realm.java
! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java
! src/share/classes/sun/security/krb5/internal/KDCOptions.java
! src/share/classes/sun/security/krb5/internal/KerberosTime.java
! src/share/classes/sun/security/krb5/internal/crypto/CksumType.java
! src/share/classes/sun/security/krb5/internal/crypto/EType.java
! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
! test/sun/security/krb5/ConfPlusProp.java
! test/sun/security/krb5/DnsFallback.java
! test/sun/security/krb5/ParseConfig.java
! test/sun/security/krb5/auto/BasicKrb5Test.java
! test/sun/security/krb5/auto/MaxRetries.java
+ test/sun/security/krb5/config/Duplicates.java
+ test/sun/security/krb5/config/SCDynamicConfigTest.java
+ test/sun/security/krb5/config/k1.conf

Changeset: cb70077c6370
Author:    weijun
Date:      2012-10-29 14:14 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb70077c6370

7195426: kdc_default_options not supported correctly
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/internal/KDCOptions.java
+ test/sun/security/krb5/config/KdcDefaultOptions.java
+ test/sun/security/krb5/config/kdc_default_options.conf



From youdwei at linux.vnet.ibm.com  Mon Oct 29 07:51:50 2012
From: youdwei at linux.vnet.ibm.com (Deven You)
Date: Mon, 29 Oct 2012 15:51:50 +0800
Subject: javax.sql.rowset.serial.SerialBlob doesn't support free and
	getBinaryStream
In-Reply-To: <505C2738.50206@oracle.com>
References: <4FE81ED6.7020909@linux.vnet.ibm.com>
	<4FF16425.9070308@linux.vnet.ibm.com>
	<40E34C07-424B-4569-8BCA-82AECEB865CB@oracle.com>
	<4FF533A4.80808@linux.vnet.ibm.com>
	<97CD7D6F-DEF1-43B0-A529-54628081EED6@oracle.com>
	<505BDD2A.40206@linux.vnet.ibm.com> <505C2738.50206@oracle.com>
Message-ID: <508E3596.3070705@linux.vnet.ibm.com>

Hi Alan,

The Java Spec does not mention the thread safe for JDBC API. But I see 
the other code in SerialBlob/SerialClob have not consider it.

I think use buff == null to replace isFree is a good idea because it 
also avoid the problem for the condition buf == null && isFree == false 
so we won't need create a readObject method.

Thanks for your suggestion for isFree, I will correct it later.

Lance: How about your suggestion? Since you mentioned you will develop 
the implementation yourself. I use my implementation mainly for the test 
cases. But you may also take a look my implementation.

Thanks a lot!

On 09/21/2012 04:37 PM, Alan Bateman wrote:
> On 21/09/2012 04:21, Deven You wrote:
>> Hi Lance,
>>
>> I am very busy with other work so I can't work with the 
>> SerialBlob/SerialClob item for long time. I am very happy to refine 
>> the current test case and create new tests for SerialClob.
>>
>> I have create a new webre[1] for this task, please review it.
>>
>> [1] http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eyoudwei/OJDK-576/webrev.01/>
>>
>> PS: If the isFree is not transient, I want to know how we add this 
>> field to the javadoc serialized form?
> I don't know very much about the rowset API and I can't see anything 
> to specify whether it is meant to be safe for use by concurrent 
> threads. There are clearly lots of issues here and implementing free 
> introduces a lot more, especially with the possibility of an 
> asynchronous free or more than one thread calling free at around the 
> same time.
>
> Have you considered "buf == null" to mean that the resources are 
> freed? That might avoid needing to change the serialized form. Also as 
> these types are serializable it means you have to consider the case 
> where you deserialize to buf == null && isFree == false for example. 
> On that point, it looks to me that this code needs a readObject anyway 
> (for several reasons).
>
> A small point is that "isFree" is a odd name for a method that doesn't 
> return a boolean. If the patch goes ahead then I think it needs a 
> better name, ensureNotFree or requireNotFree or something like that.
>
> -Alan.
>



From staffan.larsen at oracle.com  Mon Oct 29 08:24:57 2012
From: staffan.larsen at oracle.com (staffan.larsen at oracle.com)
Date: Mon, 29 Oct 2012 08:24:57 +0000
Subject: hg: jdk8/tl/jdk: 8001621: Update awk scripts that check output from
	jps/jcmd
Message-ID: <20121029082519.8411F47642@hg.openjdk.java.net>

Changeset: d1ffbdf7e3c6
Author:    sla
Date:      2012-10-29 09:23 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1ffbdf7e3c6

8001621: Update awk scripts that check output from jps/jcmd
Reviewed-by: alanb

! test/sun/tools/jcmd/jcmd_Output1.awk
! test/sun/tools/jps/jps-l_Output1.awk
! test/sun/tools/jps/jps_Output1.awk



From Lance.Andersen at oracle.com  Mon Oct 29 10:39:29 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Mon, 29 Oct 2012 06:39:29 -0400
Subject: javax.sql.rowset.serial.SerialBlob doesn't support free and
	getBinaryStream
In-Reply-To: <508E3596.3070705@linux.vnet.ibm.com>
References: <4FE81ED6.7020909@linux.vnet.ibm.com>
	<4FF16425.9070308@linux.vnet.ibm.com>
	<40E34C07-424B-4569-8BCA-82AECEB865CB@oracle.com>
	<4FF533A4.80808@linux.vnet.ibm.com>
	<97CD7D6F-DEF1-43B0-A529-54628081EED6@oracle.com>
	<505BDD2A.40206@linux.vnet.ibm.com> <505C2738.50206@oracle.com>
	<508E3596.3070705@linux.vnet.ibm.com>
Message-ID: <F7B1D533-BDB1-4FF8-A61F-0FBDC555B935@oracle.com>

Hi Deven,

I will address the needed updates a bit later.

Thank you for your input

Best
Lance
On Oct 29, 2012, at 3:51 AM, Deven You wrote:

> Hi Alan,
> 
> The Java Spec does not mention the thread safe for JDBC API. But I see the other code in SerialBlob/SerialClob have not consider it.
> 
> I think use buff == null to replace isFree is a good idea because it also avoid the problem for the condition buf == null && isFree == false so we won't need create a readObject method.
> 
> Thanks for your suggestion for isFree, I will correct it later.
> 
> Lance: How about your suggestion? Since you mentioned you will develop the implementation yourself. I use my implementation mainly for the test cases. But you may also take a look my implementation.
> 
> Thanks a lot!
> 
> On 09/21/2012 04:37 PM, Alan Bateman wrote:
>> On 21/09/2012 04:21, Deven You wrote:
>>> Hi Lance,
>>> 
>>> I am very busy with other work so I can't work with the SerialBlob/SerialClob item for long time. I am very happy to refine the current test case and create new tests for SerialClob.
>>> 
>>> I have create a new webre[1] for this task, please review it.
>>> 
>>> [1] http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ <http://cr.openjdk.java.net/%7Eyoudwei/OJDK-576/webrev.01/>
>>> 
>>> PS: If the isFree is not transient, I want to know how we add this field to the javadoc serialized form?
>> I don't know very much about the rowset API and I can't see anything to specify whether it is meant to be safe for use by concurrent threads. There are clearly lots of issues here and implementing free introduces a lot more, especially with the possibility of an asynchronous free or more than one thread calling free at around the same time.
>> 
>> Have you considered "buf == null" to mean that the resources are freed? That might avoid needing to change the serialized form. Also as these types are serializable it means you have to consider the case where you deserialize to buf == null && isFree == false for example. On that point, it looks to me that this code needs a readObject anyway (for several reasons).
>> 
>> A small point is that "isFree" is a odd name for a method that doesn't return a boolean. If the patch goes ahead then I think it needs a better name, ensureNotFree or requireNotFree or something like that.
>> 
>> -Alan.
>> 
> 

-------------- next part --------------

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 fredrik.ohrstrom at oracle.com  Mon Oct 29 13:24:10 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Mon, 29 Oct 2012 13:24:10 +0000
Subject: hg: jdk8/tl/corba: 8000970: break out auxiliary classes that will
	prevent multi-core compilation of the JDK.
Message-ID: <20121029132412.718A647644@hg.openjdk.java.net>

Changeset: 643e7612cf6d
Author:    ohrstrom
Date:      2012-10-29 14:10 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/643e7612cf6d

8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK.
Reviewed-by: alanb, wetmore

! src/share/classes/com/sun/corba/se/impl/util/IdentityHashtable.java
+ src/share/classes/com/sun/corba/se/impl/util/IdentityHashtableEntry.java



From fredrik.ohrstrom at oracle.com  Mon Oct 29 13:25:12 2012
From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com)
Date: Mon, 29 Oct 2012 13:25:12 +0000
Subject: hg: jdk8/tl/jdk: 8000970: break out auxiliary classes that will
	prevent multi-core compilation of the JDK
Message-ID: <20121029132537.2347B47645@hg.openjdk.java.net>

Changeset: 17384fc6b31f
Author:    ohrstrom
Date:      2012-10-29 14:12 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17384fc6b31f

8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK
Reviewed-by: alanb, wetmore

+ make/tools/src/build/tools/generatenimbus/AbstractGradient.java
+ make/tools/src/build/tools/generatenimbus/Border.java
+ make/tools/src/build/tools/generatenimbus/Canvas.java
+ make/tools/src/build/tools/generatenimbus/ComponentColor.java
+ make/tools/src/build/tools/generatenimbus/Dimension.java
+ make/tools/src/build/tools/generatenimbus/Ellipse.java
+ make/tools/src/build/tools/generatenimbus/Gradient.java
+ make/tools/src/build/tools/generatenimbus/GradientStop.java
+ make/tools/src/build/tools/generatenimbus/Insets.java
+ make/tools/src/build/tools/generatenimbus/Layer.java
+ make/tools/src/build/tools/generatenimbus/Matte.java
! make/tools/src/build/tools/generatenimbus/Paint.java
+ make/tools/src/build/tools/generatenimbus/Path.java
+ make/tools/src/build/tools/generatenimbus/Point.java
+ make/tools/src/build/tools/generatenimbus/RadialGradient.java
+ make/tools/src/build/tools/generatenimbus/Rectangle.java
! make/tools/src/build/tools/generatenimbus/Shape.java
! make/tools/src/build/tools/generatenimbus/SynthModel.java
+ make/tools/src/build/tools/generatenimbus/Typeface.java
+ make/tools/src/build/tools/generatenimbus/UIColor.java
+ make/tools/src/build/tools/generatenimbus/UIComponent.java
! make/tools/src/build/tools/generatenimbus/UIDefault.java
+ make/tools/src/build/tools/generatenimbus/UIFont.java
+ make/tools/src/build/tools/generatenimbus/UIIconRegion.java
+ make/tools/src/build/tools/generatenimbus/UIProperty.java
+ make/tools/src/build/tools/generatenimbus/UIRegion.java
+ make/tools/src/build/tools/generatenimbus/UIState.java
+ make/tools/src/build/tools/generatenimbus/UIStateType.java
! make/tools/src/build/tools/generatenimbus/UIStyle.java
! src/share/classes/javax/management/timer/Timer.java
+ src/share/classes/javax/management/timer/TimerAlarmClock.java
+ src/share/classes/sun/awt/im/ExecutableInputMethodManager.java
! src/share/classes/sun/awt/im/InputMethodManager.java
+ src/share/classes/sun/misc/FDBigInt.java
! src/share/classes/sun/misc/FloatingDecimal.java
! src/share/classes/sun/net/httpserver/Event.java
+ src/share/classes/sun/net/httpserver/WriteFinishedEvent.java
+ src/share/classes/sun/net/www/http/KeepAliveCleanerEntry.java
! src/share/classes/sun/net/www/http/KeepAliveStream.java
+ src/share/classes/sun/security/ssl/ExtensionType.java
+ src/share/classes/sun/security/ssl/HelloExtension.java
! src/share/classes/sun/security/ssl/HelloExtensions.java
+ src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java
+ src/share/classes/sun/security/ssl/ServerNameExtension.java
+ src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java
+ src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java
+ src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java
+ src/share/classes/sun/security/ssl/UnknownExtension.java
! src/solaris/classes/sun/awt/X11/XChoicePeer.java
+ src/solaris/classes/sun/awt/X11/XChoicePeerListener.java
+ src/solaris/classes/sun/font/DelegateStrike.java
! src/solaris/classes/sun/font/NativeStrike.java
! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java
+ src/solaris/classes/sun/java2d/jules/TileTrapContainer.java



From naoto.sato at oracle.com  Mon Oct 29 17:43:25 2012
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 29 Oct 2012 17:43:25 +0000
Subject: hg: jdk8/tl/jdk: 8000997: Multiple locale sensitive services cannot
	be loaded
Message-ID: <20121029174347.8406347650@hg.openjdk.java.net>

Changeset: 7fa45c455034
Author:    naoto
Date:      2012-10-29 10:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7fa45c455034

8000997: Multiple locale sensitive services cannot be loaded
Reviewed-by: okutsu

! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java
! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java
! test/java/util/PluggableLocale/CurrencyNameProviderTest.java
! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh
! test/java/util/PluggableLocale/GenericTest.java
! test/java/util/PluggableLocale/barprovider.jar
+ test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java
! test/java/util/PluggableLocale/providersrc/Makefile
! test/java/util/PluggableLocale/providersrc/java.util.spi.CurrencyNameProvider



From Ulf.Zibis at CoSoCo.de  Mon Oct 29 18:15:32 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Mon, 29 Oct 2012 19:15:32 +0100
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <5086B05E.1040505@CoSoCo.de>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508695CC.1080408@oracle.com> <5086B05E.1040505@CoSoCo.de>
Message-ID: <508EC7C4.6090902@CoSoCo.de>

Hi Sherman,

can you give me a short answer please?

-Ulf

Am 23.10.2012 16:57, schrieb Ulf Zibis:
> Am 23.10.2012 15:04, schrieb Alan Bateman:
>> I'm not sure that getUrlEncoder is the most suitable name to get a base64url encoder. The reason 
>> is that the method name makes it sound like it returns a URLEncoder or or at least an encoder for 
>> HTML forms. While more verbose, getBase64UrlEncoder is clear that it returns a base64url encoder.
>
> I'm wondering, why there are those get... methods at all.
>
> Alternatively you could make the appropriate constructors and predifined static variants public. 
> So one only should use:
> Base64.Encoder encoder = new Base64.Encoder(...);
> Base64.Encoder urlEncoder = Base64.Encoder.RFC4648_URLSAFE;
>
> No need for those looong method names.
>
> -Ulf
>
>



From jim.gish at oracle.com  Mon Oct 29 20:33:15 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Mon, 29 Oct 2012 16:33:15 -0400
Subject: RFR: 6594697 - varargs message and Throwable methods for
	java.util.Logger
Message-ID: <508EE80B.2050708@oracle.com>

Please review 
http://cr.openjdk.java.net/~jgish/Bug6594697-AddLogThrowable/ 
<http://cr.openjdk.java.net/%7Ejgish/Bug6594697-AddLogThrowable/>

This change adds three new methods to Logger that provide a Throwable 
along with a varags Object list as parameters to the log message.  In 
addition, it makes a small refactoring change to the existing log 
message to better enable sub-classing of Logger.

Thanks,
    Jim

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From mandy.chung at oracle.com  Mon Oct 29 22:05:50 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 29 Oct 2012 15:05:50 -0700
Subject: RFR: 7184195 - java.util.logging.Logger.getGlobal().info() doesn't
	log without configuration
In-Reply-To: <50887623.6000202@oracle.com>
References: <50887623.6000202@oracle.com>
Message-ID: <508EFDBE.8020702@oracle.com>

Jim,

The logging deadlock issue is subtle and complex.  Do we have a test 
case that verifies your fix that is  deadlock-free?

I can't tell for sure but looks like it smells the potential deadlock if 
Logger.getGlobal() triggers the LogManager class initialization but 
LogManager.<clinit> calls Logger.getLogger().setLogManager().

Maybe you already see this - 4994705 may give you some idea of the 
deadlock problem.

Hope this helps.
Mandy

On 10/24/2012 4:13 PM, Jim Gish wrote:
> Please review
> http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-init-fix/
>
> In JDK7, Logger.global was deprecated because of potential deadlock 
> problems.  The method getGlobal() was introduced as a convenience 
> method to get the global logger in lieu of this or calling 
> Logger.getLogger(Logger.GLOBAL_LOGGER_NAME).  Unfortunately, this was 
> broken out of the gate.  getGlobal() simply used the deprecated static 
> variable global, but this had the result of returning the global 
> logger without initializing the logging system.  As a result, simply 
> calling Logger.getGlobal().INFO("msg") does nothing.  So much for the 
> convenience of a simple global logger for devs to use ootb without any 
> setup required.
>
> This simple fix simply returns 
> Logger.getLogger(Logger.GLOBAL_LOGGER_NAME) when getGlobal() is called 
> and hence results in proper setup of the logging sytem /and /a working 
> global logger  with no "assembly" required :-)
>
> Thanks,
>    Jim
>


From jim.gish at oracle.com  Mon Oct 29 22:30:45 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Mon, 29 Oct 2012 18:30:45 -0400
Subject: RFR: 7184195 - java.util.logging.Logger.getGlobal().info() doesn't
	log without configuration
In-Reply-To: <508EFDBE.8020702@oracle.com>
References: <50887623.6000202@oracle.com> <508EFDBE.8020702@oracle.com>
Message-ID: <508F0395.6040609@oracle.com>

Hi Mandy,

I don't understand your second sentence.  Could you please clarify?


Thanks,
     Jim

On 10/29/2012 06:05 PM, Mandy Chung wrote:
> Jim,
>
> The logging deadlock issue is subtle and complex.  Do we have a test 
> case that verifies your fix that is  deadlock-free?
>
> I can't tell for sure but looks like it smells the potential deadlock 
> if Logger.getGlobal() triggers the LogManager class initialization but 
> LogManager.<clinit> calls Logger.getLogger().setLogManager().
>
> Maybe you already see this - 4994705 may give you some idea of the 
> deadlock problem.
>
> Hope this helps.
> Mandy
>
> On 10/24/2012 4:13 PM, Jim Gish wrote:
>> Please review
>> http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-init-fix/
>>
>> In JDK7, Logger.global was deprecated because of potential deadlock 
>> problems.  The method getGlobal() was introduced as a convenience 
>> method to get the global logger in lieu of this or calling 
>> Logger.getLogger(Logger.GLOBAL_LOGGER_NAME). Unfortunately, this was 
>> broken out of the gate.  getGlobal() simply used the deprecated 
>> static variable global, but this had the result of returning the 
>> global logger without initializing the logging system.  As a result, 
>> simply calling Logger.getGlobal().INFO("msg") does nothing.  So much 
>> for the convenience of a simple global logger for devs to use ootb 
>> without any setup required.
>>
>> This simple fix simply returns 
>> Logger.getLogger(Logger.GLOBAL_LOGGER_NAME) when getGlobal() is 
>> called and hence results in proper setup of the logging sytem /and /a 
>> working global logger  with no "assembly" required :-)
>>
>> Thanks,
>>    Jim
>>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From mike.duigou at oracle.com  Mon Oct 29 23:55:13 2012
From: mike.duigou at oracle.com (mike.duigou at oracle.com)
Date: Mon, 29 Oct 2012 23:55:13 +0000
Subject: hg: jdk8/tl/jdk: 6206780: (str) Forwarding append methods in
	String{Buffer, Builder} are inconsistent
Message-ID: <20121029235552.4F8934766E@hg.openjdk.java.net>

Changeset: e2f976a73afb
Author:    jgish
Date:      2012-10-29 16:51 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2f976a73afb

6206780: (str) Forwarding append methods in String{Buffer,Builder} are inconsistent
Summary: update StringBuilder & StringBuffer to consistently handle forwarding to AbstractStringBuilder. Some additional cleanup (removal of refs to sub-classes from AbstractStringBuilder)
Reviewed-by: chegar, alanb, mduigou

! src/share/classes/java/lang/AbstractStringBuilder.java
! src/share/classes/java/lang/StringBuffer.java
! src/share/classes/java/lang/StringBuilder.java
+ test/java/lang/StringBuffer/AppendStringBuilder.java
+ test/java/lang/StringBuffer/BufferForwarding.java
+ test/java/lang/StringBuffer/TestSynchronization.java
+ test/java/lang/StringBuilder/AppendStringBuffer.java
+ test/java/lang/StringBuilder/BuilderForwarding.java



From mandy.chung at oracle.com  Tue Oct 30 00:18:25 2012
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 29 Oct 2012 17:18:25 -0700
Subject: RFR: 7184195 - java.util.logging.Logger.getGlobal().info() doesn't
	log without configuration
In-Reply-To: <508F0395.6040609@oracle.com>
References: <50887623.6000202@oracle.com> <508EFDBE.8020702@oracle.com>
	<508F0395.6040609@oracle.com>
Message-ID: <508F1CD1.70104@oracle.com>

What I mean is when multiple threads are using j.u.logging and one calls 
Logger.getGlobal() but the LogManager class initialization is calling 
Logger.getGlobal(), what will happen?   similar to what the 
LoggingDeadlock.java test does [1].  This is the code in LogManager I'm 
referring to.

       // Adding the global Logger. Doing so in the Logger.<clinit>
       // would deadlock with the LogManager.<clinit>.
       Logger.getGlobal().setLogManager(manager);
       manager.addLogger(Logger.getGlobal());


Also, the logging initialization is fragile.  I would suggest to verify 
if logging using the global logger by multiple threads print all log 
messages correctly.

There are several test/java/util/logging/LoggingDeadlock* tests that you 
should check out if they adequately verify your fix.

Mandy

[1] 
http://hg.openjdk.java.net/jdk8/tl/jdk/file/00cd9dc3c2b5/test/java/util/logging/LoggingDeadlock.java

On 10/29/2012 3:30 PM, Jim Gish wrote:
> Hi Mandy,
>
> I don't understand your second sentence.  Could you please clarify?
>
>
> Thanks,
>     Jim
>
> On 10/29/2012 06:05 PM, Mandy Chung wrote:
>> Jim,
>>
>> The logging deadlock issue is subtle and complex.  Do we have a test 
>> case that verifies your fix that is  deadlock-free?
>>
>> I can't tell for sure but looks like it smells the potential deadlock 
>> if Logger.getGlobal() triggers the LogManager class initialization 
>> but LogManager.<clinit> calls Logger.getLogger().setLogManager().
>>
>> Maybe you already see this - 4994705 may give you some idea of the 
>> deadlock problem.
>>
>> Hope this helps.
>> Mandy
>>
>> On 10/24/2012 4:13 PM, Jim Gish wrote:
>>> Please review
>>> http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-init-fix/
>>>
>>> In JDK7, Logger.global was deprecated because of potential deadlock 
>>> problems.  The method getGlobal() was introduced as a convenience 
>>> method to get the global logger in lieu of this or calling 
>>> Logger.getLogger(Logger.GLOBAL_LOGGER_NAME). Unfortunately, this was 
>>> broken out of the gate.  getGlobal() simply used the deprecated 
>>> static variable global, but this had the result of returning the 
>>> global logger without initializing the logging system.  As a result, 
>>> simply calling Logger.getGlobal().INFO("msg") does nothing.  So much 
>>> for the convenience of a simple global logger for devs to use ootb 
>>> without any setup required.
>>>
>>> This simple fix simply returns 
>>> Logger.getLogger(Logger.GLOBAL_LOGGER_NAME) when getGlobal() is 
>>> called and hence results in proper setup of the logging sytem /and 
>>> /a working global logger  with no "assembly" required :-)
>>>
>>> Thanks,
>>>    Jim
>>>
>


From xueming.shen at oracle.com  Tue Oct 30 01:51:01 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 29 Oct 2012 18:51:01 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <508EC7C4.6090902@CoSoCo.de>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508695CC.1080408@oracle.com> <5086B05E.1040505@CoSoCo.de>
	<508EC7C4.6090902@CoSoCo.de>
Message-ID: <508F3285.50306@oracle.com>

Ulf, my apology. Some how I missed your email.

We tried various prototypes for this simple utility class. See
http://cr.openjdk.java.net/~sherman/base64/

The v4 might be close to the static constant approach you suggested. 
While It's hard
to draw a clear line on which one is better, we concluded that the 
proposed approach
provides the best balance among usability, readability and 
extensibility. For example,
the "get" approach allows us to hide the "singleton" choice to the 
implementation. It
provides a consistent interface "fixed" basic/url/mime type en/decoder 
and the configurable
floating length/linefeed encoder.

-Sherman

On 10/29/12 11:15 AM, Ulf Zibis wrote:
> Hi Sherman,
>
> can you give me a short answer please?
>
> -Ulf
>
> Am 23.10.2012 16:57, schrieb Ulf Zibis:
>> Am 23.10.2012 15:04, schrieb Alan Bateman:
>>> I'm not sure that getUrlEncoder is the most suitable name to get a 
>>> base64url encoder. The reason is that the method name makes it sound 
>>> like it returns a URLEncoder or or at least an encoder for HTML 
>>> forms. While more verbose, getBase64UrlEncoder is clear that it 
>>> returns a base64url encoder.
>>
>> I'm wondering, why there are those get... methods at all.
>>
>> Alternatively you could make the appropriate constructors and 
>> predifined static variants public. So one only should use:
>> Base64.Encoder encoder = new Base64.Encoder(...);
>> Base64.Encoder urlEncoder = Base64.Encoder.RFC4648_URLSAFE;
>>
>> No need for those looong method names.
>>
>> -Ulf
>>
>>
>



From jim.gish at oracle.com  Tue Oct 30 14:21:01 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Tue, 30 Oct 2012 10:21:01 -0400
Subject: RFR: 6594697 - varargs message and Throwable methods for
	java.util.Logger
In-Reply-To: <ad10c193-7a3f-40b5-8d9f-37123789679d@default>
References: <508EE80B.2050708@oracle.com>
	<ad10c193-7a3f-40b5-8d9f-37123789679d@default>
Message-ID: <508FE24D.30906@oracle.com>

I was one the fence with the parameter ordering and would like 
additional feedback on this point.  I started off as you suggested, but 
didn't like the fact that the params were separated from the msg by the 
Throwable.  I could go either way, but would like to hear from others on 
this point.

Thanks,
     Jim
On 10/30/2012 07:24 AM, Sandeep Shrivastava wrote:
>
> Jim,
>
> Thanks for using the isLoggable() method that will go a long way in 
> improving the code of existing sub classes of the Logger.
>
> I have a question about the argument list to the new log methods.
>
> *public void log(Level level, Throwable thrown, String msg, Object... 
> params) *
>
> Could we not have the signature as *public void log(Level level, 
> String msg, Throwable thrown, Object... params)*
>
> **
>
> We already have a method in which the Throwable is after the msg param 
> *public void log(Level level, String msg, Throwable thrown)*
>
> So this will keep it consistent.
>
> Thanks
>
> Sandeep
>
> *From:*Jim Gish
> *Sent:* Monday, October 29, 2012 4:33 PM
> *To:* core-libs-dev
> *Cc:* Rajendra Inamdar; Sandeep Shrivastava
> *Subject:* RFR: 6594697 - varargs message and Throwable methods for 
> java.util.Logger
>
> Please review 
> http://cr.openjdk.java.net/~jgish/Bug6594697-AddLogThrowable/ 
> <http://cr.openjdk.java.net/%7Ejgish/Bug6594697-AddLogThrowable/>
>
> This change adds three new methods to Logger that provide a Throwable 
> along with a varags Object list as parameters to the log message.  In 
> addition, it makes a small refactoring change to the existing log 
> message to better enable sub-classing of Logger.
>
> Thanks,
>    Jim
>
> -- 
> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
> Oracle Java Platform Group | Core Libraries Team
> 35 Network Drive
> Burlington, MA 01803
> jim.gish at oracle.com  <mailto:jim.gish at oracle.com>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From Ulf.Zibis at CoSoCo.de  Tue Oct 30 16:02:58 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 30 Oct 2012 17:02:58 +0100
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <508758C7.5030703@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508695CC.1080408@oracle.com> <508758C7.5030703@oracle.com>
Message-ID: <508FFA32.1090206@CoSoCo.de>

Am 24.10.2012 04:56, schrieb Xueming Shen:
> Thanks for the review. I hope I addressed most of the comments in the
> updated webrev at
>
> http://cr.openjdk.java.net/~sherman/4235519/webrev

Hi Sherman,

my additional comments:

I'm "confused" about the order of xxcode() and Xxcoder.
In other places e.g. charsets, we have de... before en..., which is also true alphabetical

1026     private Base64() {}
1027     private static final int MIMELINEMAX = 76;
1028     private static final byte[] crlf = new byte[] {'\r', '\n'};
- difficult to find, please move (more) to the beginning, at least not in between inner class 
definitions.
- I more would like CRLF than crlf

  118      * @param lineLength    the length of each output line (rounded down
  119      *                      to nearest multiple of 4).
This could be interpreted as: the parameter must be rounded before, so maybe better:
  118      * @param lineLength    the length of each output line (if not a multiple of 4,
  119      *                      it will be rounded down accordingly).


  126     public static Encoder getEncoder(int lineLength, byte[] lineSeparator) {
  127          Objects.requireNonNull(lineSeparator);
  128          return new Encoder(false, lineSeparator, lineLength / 4 * 4);
  129     }
- What (should) happen(s), if lineSeparator.length == 0 ?
- Isn't one of these little faster, or at least more clear? :
     lineLength -= lineLength % 4
     lineLength & 0xFFFFFFFC
     lineLength << 2 >> 2

Broken indentation (why at all, compared to lines 213..215?):
  208         private final byte[] newline;
  209         private final int    linemax;
  210         private final boolean isURL;

Unconventional indentation and even broken in lines 223..224 (maybe more?):
  247          * @param   src   the byte array to encode
  248          * @param   dst   the output byte array
  249          * @return        The number of bytes written to the output byte array
  250          *
  251          * @throws        IllegalArgumentException if {@code dst} does not have
  252          *                enough space for encoding all input bytes.

More conventional:
  247          * @param  src  the byte array to encode
  248          * @param  dst  the output byte array
  249          * @return The number of bytes written to the output byte array
  250          *
  251          * @throws IllegalArgumentException if {@code dst} does not have
  252          *         enough space for encoding all input bytes.

  603         static {
  604             Arrays.fill(fromBase64, -1);
  605             for (int i = 0; i < Encoder.toBase64.length; i++)
  606                 fromBase64[Encoder.toBase64[i]] = i;
  607             fromBase64['='] = -2;
  608         }
This causes the inner Encoder class to be loaded, even if not needed. So maybe move the toBase64 
table to the outer class.
Have you compared performance with fromBase64 as byte[] (including local 'b' in decode() as byte)?
Retrieving the bytes by b = base64[x] then could be done without address-shift and smaller/faster 
LoadB operations could be used by JIT. At least the footprint of the table would be smaller.

Missing spaces:
  805             return new DecInputStream(is, isURL?fromBase64URL:fromBase64, isMIME);
Why at all you repeat this code many times? Why not? :
  631             this.base64 = isURL ? fromBase64URL : fromBase64;
Also it would at least be helpful for readers to define final, e.g.:
  809             final int[] base64 = isURL ? fromBase64URL : fromBase64;

Why you mix the algorithms to check the padding? :
  824                         if (b == -2) {   // padding byte
  890                     if (b == '=') {


-Ulf



From Lance.Andersen at oracle.com  Tue Oct 30 16:25:02 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 30 Oct 2012 12:25:02 -0400
Subject: Review request for 8001536
Message-ID: <FBA7F5E1-12B9-4FE0-8DA3-4A86193646AD@oracle.com>

Hi,

This is a request for review of http://cr.openjdk.java.net/~lancea/8001536/webrev.00/.  This adds read/writeObject as well as clone methods to SerialXLob classes.

All SQE tests passed,  1 failure in the RowSet JCK/TCK tests due to a bug in the test that the TCK team is aware of and will address.  JDBC Unit tests all pass .


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 Ulf.Zibis at CoSoCo.de  Tue Oct 30 16:26:49 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 30 Oct 2012 17:26:49 +0100
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <508FFA32.1090206@CoSoCo.de>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508695CC.1080408@oracle.com> <508758C7.5030703@oracle.com>
	<508FFA32.1090206@CoSoCo.de>
Message-ID: <508FFFC9.7090403@CoSoCo.de>

Oops:
> lineLength << 2 >> 2
I meant::
     lineLength >> 2 << 2

-Ulf



From jonathan.gibbons at oracle.com  Tue Oct 30 17:15:55 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Tue, 30 Oct 2012 17:15:55 +0000
Subject: hg: jdk8/tl/langtools: 8001929: fix doclint errors in langtools doc
	comments
Message-ID: <20121030171600.95A7C47683@hg.openjdk.java.net>

Changeset: 23fe1a96bc0f
Author:    jjg
Date:      2012-10-30 10:15 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/23fe1a96bc0f

8001929: fix doclint errors in langtools doc comments
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! src/share/classes/com/sun/tools/javac/code/TypeTag.java
! src/share/classes/com/sun/tools/javac/comp/Attr.java



From forax at univ-mlv.fr  Tue Oct 30 18:05:39 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 30 Oct 2012 19:05:39 +0100
Subject: Review request for 8001536
In-Reply-To: <FBA7F5E1-12B9-4FE0-8DA3-4A86193646AD@oracle.com>
References: <FBA7F5E1-12B9-4FE0-8DA3-4A86193646AD@oracle.com>
Message-ID: <509016F3.2030509@univ-mlv.fr>

On 10/30/2012 05:25 PM, Lance Andersen - Oracle wrote:
> Hi,
>
> This is a request for review of http://cr.openjdk.java.net/~lancea/8001536/webrev.00/.  This adds read/writeObject as well as clone methods to SerialXLob classes.
>
> All SQE tests passed,  1 failure in the RowSet JCK/TCK tests due to a bug in the test that the TCK team is aware of and will address.  JDBC Unit tests all pass .

Hi Lance.
In SerialBlob and in SerialClob
test (obj == null) is not necessary in equals, null instanceof X is 
always false.

in hashCode, Objects.hash() allocate an array to pass arguments to 
Arrays.hashCode() and box primitive values to Object.
while this method is really convenient to use, each calls will allocate 
an array and box the two values,
the overhead seems to high here.
This code should be equivalent:
     return ((31 +Arrays.hashCode(buf)) * 31 +len) * 31 + origLen;

in clone, sb should not be initialized to null and the catch should be: 
throw new InternalError(e),
this is the standard code you can see in clone.

in readObject, the test (buf.length != len) can be done before decoding 
the blob.

in writeObject, you set "blob" twice, which is weird, also I think that 
if blob is not Serializable,
the code should throw an exception, so you should not use instanceof and 
let s.writeFields()
to throw NotSerializable exception.

cheers,
R?mi

>
>
> 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 Ulf.Zibis at CoSoCo.de  Tue Oct 30 18:18:10 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 30 Oct 2012 19:18:10 +0100
Subject: Review request for 8001536
In-Reply-To: <FBA7F5E1-12B9-4FE0-8DA3-4A86193646AD@oracle.com>
References: <FBA7F5E1-12B9-4FE0-8DA3-4A86193646AD@oracle.com>
Message-ID: <509019E2.3050105@CoSoCo.de>

Hi all,

please add the bug summary to the subject line.
Bug  8001536 is not publicly visible :-(

-Ulf

Am 30.10.2012 17:25, schrieb Lance Andersen - Oracle:
> Hi,
>
> This is a request for review of http://cr.openjdk.java.net/~lancea/8001536/webrev.00/.  This adds read/writeObject as well as clone methods to SerialXLob classes.
>
> All SQE tests passed,  1 failure in the RowSet JCK/TCK tests due to a bug in the test that the TCK team is aware of and will address.  JDBC Unit tests all pass .
>
>
> 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 Oct 30 18:28:16 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 30 Oct 2012 14:28:16 -0400
Subject: Review request for 8001536
In-Reply-To: <509019E2.3050105@CoSoCo.de>
References: <FBA7F5E1-12B9-4FE0-8DA3-4A86193646AD@oracle.com>
	<509019E2.3050105@CoSoCo.de>
Message-ID: <42C61B8D-C6D9-408B-B28D-9537A7FF5019@oracle.com>

Hi Ulf,

The bug is described below, it is just adding the read/writeObject and clone methods.

Best
Lance
On Oct 30, 2012, at 2:18 PM, Ulf Zibis wrote:

> Hi all,
> 
> please add the bug summary to the subject line.
> Bug  8001536 is not publicly visible :-(
> 
> -Ulf
> 
> Am 30.10.2012 17:25, schrieb Lance Andersen - Oracle:
>> Hi,
>> 
>> This is a request for review of http://cr.openjdk.java.net/~lancea/8001536/webrev.00/.  This adds read/writeObject as well as clone methods to SerialXLob classes.
>> 
>> All SQE tests passed,  1 failure in the RowSet JCK/TCK tests due to a bug in the test that the TCK team is aware of and will address.  JDBC Unit tests all pass .
>> 
>> 
>> 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
>> 
>> 
> 

-------------- next part --------------

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 Alan.Bateman at oracle.com  Tue Oct 30 18:30:45 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Oct 2012 18:30:45 +0000
Subject: RFR: 6594697 - varargs message and Throwable methods for
	java.util.Logger
In-Reply-To: <508FE24D.30906@oracle.com>
References: <508EE80B.2050708@oracle.com>
	<ad10c193-7a3f-40b5-8d9f-37123789679d@default>
	<508FE24D.30906@oracle.com>
Message-ID: <50901CD5.1080309@oracle.com>

On 30/10/2012 14:21, Jim Gish wrote:
> I was one the fence with the parameter ordering and would like 
> additional feedback on this point.  I started off as you suggested, 
> but didn't like the fact that the params were separated from the msg 
> by the Throwable.  I could go either way, but would like to hear from 
> others on this point.
>
> Thanks,
>     Jim
I think it make sense to keep the message and its parameters together, 
and since the parameters have to be at the end then it does mean the 
Throwable comes before the message. It does mean that there is a bit of 
inconsistency in the ordering but it might be a bit odd to put the 
Throwable between the message and its parameters.

I think the changes to use isLoggable should be separated out into their 
own issue.

-Alan


From Ulf.Zibis at CoSoCo.de  Tue Oct 30 18:44:23 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 30 Oct 2012 19:44:23 +0100
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <508F3285.50306@oracle.com>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508695CC.1080408@oracle.com> <5086B05E.1040505@CoSoCo.de>
	<508EC7C4.6090902@CoSoCo.de> <508F3285.50306@oracle.com>
Message-ID: <50902007.6050603@CoSoCo.de>

Hi Sherman,

thanks for your details.
Has this discussion been on the list, and I have missed it?

I see a problem with hiding the "singleton" choice:
Developers might tend to repetitively invoke
     public static Encoder getEncoder(int lineLength, byte[] lineSeparator)
instead reusing the the same instance.
(Note: It should not harm, to move the
      Objects.requireNonNull(lineSeparator);
to the general private constructor.)
In case of a public constant
     Encoder.RFC4648
... developer would be aware about the re-usability of the encoder.

IMHO, the get...() methods are just waste of source lines and bytecode footprint.

But in contrast to the v4 I like the inner class approach: Base64.De/Encoder.

Little nit: In lines 89,100,127,128,138,149,159 the indentation is 5 instead 4.

-Ulf



Am 30.10.2012 02:51, schrieb Xueming Shen:
> Ulf, my apology. Some how I missed your email.
>
> We tried various prototypes for this simple utility class. See
> http://cr.openjdk.java.net/~sherman/base64/
>
> The v4 might be close to the static constant approach you suggested. While It's hard
> to draw a clear line on which one is better, we concluded that the proposed approach
> provides the best balance among usability, readability and extensibility. For example,
> the "get" approach allows us to hide the "singleton" choice to the implementation. It
> provides a consistent interface "fixed" basic/url/mime type en/decoder and the configurable
> floating length/linefeed encoder.
>
> -Sherman
>
> On 10/29/12 11:15 AM, Ulf Zibis wrote:
>> Hi Sherman,
>>
>> can you give me a short answer please?
>>
>> -Ulf
>>
>> Am 23.10.2012 16:57, schrieb Ulf Zibis:
>>> Am 23.10.2012 15:04, schrieb Alan Bateman:
>>>> I'm not sure that getUrlEncoder is the most suitable name to get a base64url encoder. The 
>>>> reason is that the method name makes it sound like it returns a URLEncoder or or at least an 
>>>> encoder for HTML forms. While more verbose, getBase64UrlEncoder is clear that it returns a 
>>>> base64url encoder.
>>>
>>> I'm wondering, why there are those get... methods at all.
>>>
>>> Alternatively you could make the appropriate constructors and predifined static variants public. 
>>> So one only should use:
>>> Base64.Encoder encoder = new Base64.Encoder(...);
>>> Base64.Encoder urlEncoder = Base64.Encoder.RFC4648_URLSAFE;
>>>
>>> No need for those looong method names.
>>>
>>> -Ulf
>>>
>>>
>>
>
>



From Ulf.Zibis at CoSoCo.de  Tue Oct 30 18:50:10 2012
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 30 Oct 2012 19:50:10 +0100
Subject: Review request for 8001536
In-Reply-To: <42C61B8D-C6D9-408B-B28D-9537A7FF5019@oracle.com>
References: <FBA7F5E1-12B9-4FE0-8DA3-4A86193646AD@oracle.com>
	<509019E2.3050105@CoSoCo.de>
	<42C61B8D-C6D9-408B-B28D-9537A7FF5019@oracle.com>
Message-ID: <50902162.3090405@CoSoCo.de>

Thanks Lance.

But having the subject of the request in clear text in the list view of the email client would be a 
great help.

-Ulf


Am 30.10.2012 19:28, schrieb Lance Andersen - Oracle:
> Hi Ulf,
>
> The bug is described below, it is just adding the read/writeObject and clone methods.
>
> Best
> Lance
> On Oct 30, 2012, at 2:18 PM, Ulf Zibis wrote:
>
>> Hi all,
>>
>> please add the bug summary to the subject line.
>> Bug  8001536 is not publicly visible :-(
>>
>> -Ulf
>>
>> Am 30.10.2012 17:25, schrieb Lance Andersen - Oracle:
>>> Hi,
>>>
>>> This is a request for review of http://cr.openjdk.java.net/~lancea/8001536/webrev.00/.  This adds read/writeObject as well as clone methods to SerialXLob classes.
>>>
>>> All SQE tests passed,  1 failure in the RowSet JCK/TCK tests due to a bug in the test that the TCK team is aware of and will address.  JDBC Unit tests all pass .
>>>
>>>
>>> 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 Lance.Andersen at oracle.com  Tue Oct 30 18:53:57 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 30 Oct 2012 14:53:57 -0400
Subject: Review request for 8001536
In-Reply-To: <509016F3.2030509@univ-mlv.fr>
References: <FBA7F5E1-12B9-4FE0-8DA3-4A86193646AD@oracle.com>
	<509016F3.2030509@univ-mlv.fr>
Message-ID: <E223B2D4-B6AD-4CA2-99EA-8B0CB2E180E3@oracle.com>

Hi Remi,


Thank you for the feedback

On Oct 30, 2012, at 2:05 PM, Remi Forax wrote:

> On 10/30/2012 05:25 PM, Lance Andersen - Oracle wrote:
>> Hi,
>> 
>> This is a request for review of http://cr.openjdk.java.net/~lancea/8001536/webrev.00/.  This adds read/writeObject as well as clone methods to SerialXLob classes.
>> 
>> All SQE tests passed,  1 failure in the RowSet JCK/TCK tests due to a bug in the test that the TCK team is aware of and will address.  JDBC Unit tests all pass .
> 
> Hi Lance.
> In SerialBlob and in SerialClob
> test (obj == null) is not necessary in equals, null instanceof X is always false.

OK, thanks for the suggestion, I will make this change
> 
> in hashCode, Objects.hash() allocate an array to pass arguments to Arrays.hashCode() and box primitive values to Object.
> while this method is really convenient to use, each calls will allocate an array and box the two values,
> the overhead seems to high here.
> This code should be equivalent:
>    return ((31 +Arrays.hashCode(buf)) * 31 +len) * 31 + origLen;
I can simplify hashCode to the what you have above, I liked the convenience method which is why I was using it. But happy to change it
> 
> in clone, sb should not be initialized to null

I think it is OK as I have it as  HashMap does it similar to what I have done vs ArrayList which follows your suggestion.  Do we have a preferred practice or is this just a style choice?
> and the catch should be: throw new InternalError(e),

Given I am providing clone(), I did not see a reason to provide InternalError().  I have no strong preference but some java classes do and others do not (HashMap for example), so what is our preferred standard?
> this is the standard code you can see in clone.
> 
> in readObject, the test (buf.length != len) can be done before decoding the blob.

True, I can move it up.
> 
> in writeObject, you set "blob" twice, which is weird,

my bad, I forgot to remove that.
> also I think that if blob is not Serializable,
> the code should throw an exception, so you should not use instanceof and let s.writeFields()
> to throw NotSerializable exception.

This is intentional.  A Blob or Clob will not be serializable as its properties are unique to the database and it is created from an active Connection object.  

In the event someone actually tried to serialize this, I do not want it to fail just because someone passed in a LOB to instantiate this beast (note these methods should never have been created this way but this is way before my time).

In the unlikely event someone created their own wrapped Blob/Clob (which I cannot see why anyone would do), I am allowing for both for backwards compatibility.

Best
Lance
> 
> cheers,
> R?mi
> 
>> 
>> 
>> 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
>> 
> 

-------------- next part --------------

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 Oct 30 18:56:23 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Tue, 30 Oct 2012 14:56:23 -0400
Subject: Review request for 8001536
In-Reply-To: <50902162.3090405@CoSoCo.de>
References: <FBA7F5E1-12B9-4FE0-8DA3-4A86193646AD@oracle.com>
	<509019E2.3050105@CoSoCo.de>
	<42C61B8D-C6D9-408B-B28D-9537A7FF5019@oracle.com>
	<50902162.3090405@CoSoCo.de>
Message-ID: <9A914C31-8063-4A9A-AE61-1055C20B7798@oracle.com>

Point taken Ulf, thank you for the feedback and will follow your suggestion going forward , which I typically do, but I think I am still feeling the effects of being offline due to hurricane sandy :-(

Best
Lance


On Oct 30, 2012, at 2:50 PM, Ulf Zibis wrote:

> Thanks Lance.
> 
> But having the subject of the request in clear text in the list view of the email client would be a great help.
> 
> -Ulf
> 
> 
> Am 30.10.2012 19:28, schrieb Lance Andersen - Oracle:
>> Hi Ulf,
>> 
>> The bug is described below, it is just adding the read/writeObject and clone methods.
>> 
>> Best
>> Lance
>> On Oct 30, 2012, at 2:18 PM, Ulf Zibis wrote:
>> 
>>> Hi all,
>>> 
>>> please add the bug summary to the subject line.
>>> Bug  8001536 is not publicly visible :-(
>>> 
>>> -Ulf
>>> 
>>> Am 30.10.2012 17:25, schrieb Lance Andersen - Oracle:
>>>> Hi,
>>>> 
>>>> This is a request for review of http://cr.openjdk.java.net/~lancea/8001536/webrev.00/.  This adds read/writeObject as well as clone methods to SerialXLob classes.
>>>> 
>>>> All SQE tests passed,  1 failure in the RowSet JCK/TCK tests due to a bug in the test that the TCK team is aware of and will address.  JDBC Unit tests all pass .
>>>> 
>>>> 
>>>> 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
>> 
> 

-------------- next part --------------

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 Alan.Bateman at oracle.com  Tue Oct 30 19:24:34 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Oct 2012 19:24:34 +0000
Subject: Review request for 8001536
In-Reply-To: <509016F3.2030509@univ-mlv.fr>
References: <FBA7F5E1-12B9-4FE0-8DA3-4A86193646AD@oracle.com>
	<509016F3.2030509@univ-mlv.fr>
Message-ID: <50902972.90508@oracle.com>

On 30/10/2012 18:05, Remi Forax wrote:
>
> in writeObject, you set "blob" twice, which is weird, also I think 
> that if blob is not Serializable,
> the code should throw an exception, so you should not use instanceof 
> and let s.writeFields()
> to throw NotSerializable exception.
Yes, that is odd. I think the issue here is that serialized form should 
never have included the blob in the first place.

-Alan


From jim.gish at oracle.com  Tue Oct 30 20:31:51 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Tue, 30 Oct 2012 16:31:51 -0400
Subject: RFR: 6594697 - varargs message and Throwable methods for
	java.util.Logger
In-Reply-To: <50901CD5.1080309@oracle.com>
References: <508EE80B.2050708@oracle.com>
	<ad10c193-7a3f-40b5-8d9f-37123789679d@default>
	<508FE24D.30906@oracle.com> <50901CD5.1080309@oracle.com>
Message-ID: <50903937.9020206@oracle.com>

I've prepared a new webrev retaining the parameter ordering, but 
removing the isLoggable() refactoring for now.

http://cr.openjdk.java.net/~jgish/Bug6594697-AddLogThrowable/ 
<http://cr.openjdk.java.net/%7Ejgish/Bug6594697-AddLogThrowable/>

Thanks,
     Jim

If this looks o.k. I'll submit to CCC for approval.

On 10/30/2012 02:30 PM, Alan Bateman wrote:
> On 30/10/2012 14:21, Jim Gish wrote:
>> I was one the fence with the parameter ordering and would like 
>> additional feedback on this point.  I started off as you suggested, 
>> but didn't like the fact that the params were separated from the msg 
>> by the Throwable.  I could go either way, but would like to hear from 
>> others on this point.
>>
>> Thanks,
>>     Jim
> I think it make sense to keep the message and its parameters together, 
> and since the parameters have to be at the end then it does mean the 
> Throwable comes before the message. It does mean that there is a bit 
> of inconsistency in the ordering but it might be a bit odd to put the 
> Throwable between the message and its parameters.
>
> I think the changes to use isLoggable should be separated out into 
> their own issue.
>
> -Alan

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From xueming.shen at oracle.com  Tue Oct 30 22:40:42 2012
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 30 Oct 2012 15:40:42 -0700
Subject: Review/comment needed for the new public java.util.Base64 class
In-Reply-To: <508FFA32.1090206@CoSoCo.de>
References: <5075B65D.1020709@oracle.com>
	<CACzrW9D1acFu_dKEXH-AeyLM6q=LtVF3=qctC09gL0AAHj2uMw@mail.gmail.com>
	<5076F68A.3020501@oracle.com>
	<1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com>
	<5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com>
	<508695CC.1080408@oracle.com> <508758C7.5030703@oracle.com>
	<508FFA32.1090206@CoSoCo.de>
Message-ID: <5090576A.4080709@oracle.com>

Hi Ulf, thanks for the comments.

Webrev has been updated to address most of your comments.

http://cr.openjdk.java.net/~sherman/4235519/webrev

(1) all @param and @return tags have been "normalized".
(2) private constructor BAse64() {} has been moved up.
(3) MIMELINEMAX and CRLF have been moved into encoder.
(4) -> lineLength >>2<<2;

Your questions:


>
> I'm "confused" about the order of xxcode() and Xxcoder.
> In other places e.g. charsets, we have de... before en..., which is 
> also true alphabetical
>
should not be an issue. javadoc output should be in alphabetic order. If 
it is really
concerns you, I can do a copy/paste:-)


>
>
> - What (should) happen(s), if lineSeparator.length == 0 ?
do nothing. expected?



> - Isn't one of these little faster, or at least more clear? :
>     lineLength -= lineLength % 4
>     lineLength & 0xFFFFFFFC
>     lineLength << 2 >> 2
>
>
>  603         static {
>  604             Arrays.fill(fromBase64, -1);
>  605             for (int i = 0; i < Encoder.toBase64.length; i++)
>  606                 fromBase64[Encoder.toBase64[i]] = i;
>  607             fromBase64['='] = -2;
>  608         }
> This causes the inner Encoder class to be loaded, even if not needed. 
> So maybe move the toBase64 table to the outer class.
> Have you compared performance with fromBase64 as byte[] (including 
> local 'b' in decode() as byte)?

understood. but it appears the hotspot likes it the constant/fixed 
length lookup
table is inside encoder. Same as you suggestion in your previous email 
to use
String in source and expand it during runtime. It saves about 500 bytes 
but slows
the server vm. Those repeating lines of "isURL? ...." is also supposed 
to be a
performance tweak to eliminate the array boundary check in loop.

>
>
> Why you mix the algorithms to check the padding? :
>  824                         if (b == -2) {   // padding byte
>  890                     if (b == '=') {
>
It is supposed reduce one "if" check for normal base64 character inside the
loop. I'm not that sure it really helps though.

-Sherman



From forax at univ-mlv.fr  Wed Oct 31 11:15:16 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 31 Oct 2012 12:15:16 +0100
Subject: Review request for 8001536
In-Reply-To: <E223B2D4-B6AD-4CA2-99EA-8B0CB2E180E3@oracle.com>
References: <FBA7F5E1-12B9-4FE0-8DA3-4A86193646AD@oracle.com>
	<509016F3.2030509@univ-mlv.fr>
	<E223B2D4-B6AD-4CA2-99EA-8B0CB2E180E3@oracle.com>
Message-ID: <50910844.60502@univ-mlv.fr>

On 10/30/2012 07:53 PM, Lance Andersen - Oracle wrote:
> Hi Remi,
>
>
> Thank you for the feedback
>
> On Oct 30, 2012, at 2:05 PM, Remi Forax wrote:
>
>> On 10/30/2012 05:25 PM, Lance Andersen - Oracle wrote:
>>> Hi,
>>>
>>> This is a request for review of http://cr.openjdk.java.net/~lancea/8001536/webrev.00/.  This adds read/writeObject as well as clone methods to SerialXLob classes.
>>>
>>> All SQE tests passed,  1 failure in the RowSet JCK/TCK tests due to a bug in the test that the TCK team is aware of and will address.  JDBC Unit tests all pass .
>> Hi Lance.
>> In SerialBlob and in SerialClob
>> test (obj == null) is not necessary in equals, null instanceof X is always false.
> OK, thanks for the suggestion, I will make this change
>> in hashCode, Objects.hash() allocate an array to pass arguments to Arrays.hashCode() and box primitive values to Object.
>> while this method is really convenient to use, each calls will allocate an array and box the two values,
>> the overhead seems to high here.
>> This code should be equivalent:
>>     return ((31 +Arrays.hashCode(buf)) * 31 +len) * 31 + origLen;
> I can simplify hashCode to the what you have above, I liked the convenience method which is why I was using it. But happy to change it

In fact, thinking a little more about that, Objects.hash() even don't 
provide the semantics you want
because it calls Arrays.hashCode() and not Arrays.deepEquals() so 
Objects.hash(buf, ..., ....) calls
buf.hashCode() and not Arrays.hashCode(buf).

>> in clone, sb should not be initialized to null
> I think it is OK as I have it as  HashMap does it similar to what I have done vs ArrayList which follows your suggestion.  Do we have a preferred practice or is this just a style choice?
>> and the catch should be: throw new InternalError(e),
> Given I am providing clone(), I did not see a reason to provide InternalError().  I have no strong preference but some java classes do and others do not (HashMap for example), so what is our preferred standard?

I don't think it's a good idea to let the catch empty and I don't like 
to have to initialize a variable
in the code for something that never occurs.
Maybe something like:

A a;
try {
   a = clone();
} catch(CloneNotSupportedException e) {
   throw null;  // should never be executed
}
...

throw null will not produce a big bytecode unlike new InternalError(e)
and because it's a throw, the compiler will not require to initialize 'a'.

And this pattern should be enforced in the whole JDK.

>> this is the standard code you can see in clone.
>>
>> in readObject, the test (buf.length != len) can be done before decoding the blob.
> True, I can move it up.
>> in writeObject, you set "blob" twice, which is weird,
> my bad, I forgot to remove that.
>> also I think that if blob is not Serializable,
>> the code should throw an exception, so you should not use instanceof and let s.writeFields()
>> to throw NotSerializable exception.
> This is intentional.  A Blob or Clob will not be serializable as its properties are unique to the database and it is created from an active Connection object.
>
> In the event someone actually tried to serialize this, I do not want it to fail just because someone passed in a LOB to instantiate this beast (note these methods should never have been created this way but this is way before my time).
>
> In the unlikely event someone created their own wrapped Blob/Clob (which I cannot see why anyone would do), I am allowing for both for backwards compatibility.

Ok, maybe you should add a comment.

>
> Best
> Lance

kind regards,
R?mi



From Lance.Andersen at oracle.com  Wed Oct 31 15:08:00 2012
From: Lance.Andersen at oracle.com (Lance Andersen - Oracle)
Date: Wed, 31 Oct 2012 11:08:00 -0400
Subject: Review request for 8001536 updated
In-Reply-To: <509016F3.2030509@univ-mlv.fr>
References: <FBA7F5E1-12B9-4FE0-8DA3-4A86193646AD@oracle.com>
	<509016F3.2030509@univ-mlv.fr>
Message-ID: <175719F7-CE8C-455E-9E5C-2F2AB5B8A1FB@oracle.com>

Here is revised webrev taking into account Remi's suggestions http://cr.openjdk.java.net/~lancea/8001536/webrev.01/


Best,
Lance


On Oct 30, 2012, at 2:05 PM, Remi Forax wrote:

> On 10/30/2012 05:25 PM, Lance Andersen - Oracle wrote:
>> Hi,
>> 
>> This is a request for review of http://cr.openjdk.java.net/~lancea/8001536/webrev.00/.  This adds read/writeObject as well as clone methods to SerialXLob classes.
>> 
>> All SQE tests passed,  1 failure in the RowSet JCK/TCK tests due to a bug in the test that the TCK team is aware of and will address.  JDBC Unit tests all pass .
> 
> Hi Lance.
> In SerialBlob and in SerialClob
> test (obj == null) is not necessary in equals, null instanceof X is always false.
> 
> in hashCode, Objects.hash() allocate an array to pass arguments to Arrays.hashCode() and box primitive values to Object.
> while this method is really convenient to use, each calls will allocate an array and box the two values,
> the overhead seems to high here.
> This code should be equivalent:
>    return ((31 +Arrays.hashCode(buf)) * 31 +len) * 31 + origLen;
> 
> in clone, sb should not be initialized to null and the catch should be: throw new InternalError(e),
> this is the standard code you can see in clone.
> 
> in readObject, the test (buf.length != len) can be done before decoding the blob.
> 
> in writeObject, you set "blob" twice, which is weird, also I think that if blob is not Serializable,
> the code should throw an exception, so you should not use instanceof and let s.writeFields()
> to throw NotSerializable exception.
> 
> cheers,
> R?mi
> 
>> 
>> 
>> 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
>> 
> 

-------------- next part --------------

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 lana.steuck at oracle.com  Wed Oct 31 16:51:03 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 31 Oct 2012 16:51:03 +0000
Subject: hg: jdk8/tl: 6 new changesets
Message-ID: <20121031165104.977CE476B0@hg.openjdk.java.net>

Changeset: 8343ccdd63f1
Author:    katleman
Date:      2012-10-18 11:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/8343ccdd63f1

Added tag jdk8-b61 for changeset 20ff117b5090

! .hgtags

Changeset: c12e759ac4e8
Author:    tbell
Date:      2012-10-23 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/c12e759ac4e8

7152336: Enable builds on Windows with MinGW/MSYS
Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7
Reviewed-by: ohair, tbell
Contributed-by: volker.simonis at gmail.com

! README-builds.html
+ make/scripts/fixpath.pl
! make/scripts/vsvars.sh

Changeset: 8a3fe0ae06a8
Author:    katleman
Date:      2012-10-24 13:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/8a3fe0ae06a8

Merge


Changeset: 4e984be114bd
Author:    katleman
Date:      2012-10-25 09:52 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/4e984be114bd

Added tag jdk8-b62 for changeset 8a3fe0ae06a8

! .hgtags

Changeset: 744e165aaf33
Author:    lana
Date:      2012-10-23 09:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/744e165aaf33

Merge


Changeset: ce212cd7ea69
Author:    lana
Date:      2012-10-25 20:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/rev/ce212cd7ea69

Merge




From lana.steuck at oracle.com  Wed Oct 31 16:51:03 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 31 Oct 2012 16:51:03 +0000
Subject: hg: jdk8/tl/corba: 7 new changesets
Message-ID: <20121031165111.69EB9476B1@hg.openjdk.java.net>

Changeset: 2394155f9f9e
Author:    katleman
Date:      2012-10-18 11:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/2394155f9f9e

Added tag jdk8-b61 for changeset 0e08ba7648fb

! .hgtags

Changeset: 0a5931be9176
Author:    tbell
Date:      2012-10-23 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/0a5931be9176

7152336: Enable builds on Windows with MinGW/MSYS
Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7
Reviewed-by: ohair, tbell
Contributed-by: volker.simonis at gmail.com

! make/common/shared/Defs-utils.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Platform.gmk

Changeset: 08afb9c6f44f
Author:    katleman
Date:      2012-10-24 13:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/08afb9c6f44f

Merge


Changeset: bbaef650c3d2
Author:    katleman
Date:      2012-10-25 09:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/bbaef650c3d2

Added tag jdk8-b62 for changeset 08afb9c6f44f

! .hgtags

Changeset: 23e0226a31ac
Author:    lana
Date:      2012-10-23 09:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/23e0226a31ac

Merge


Changeset: 9094cd4a614f
Author:    lana
Date:      2012-10-25 20:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/9094cd4a614f

Merge

! make/common/shared/Defs-utils.gmk

Changeset: aac74d377a03
Author:    lana
Date:      2012-10-30 23:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/corba/rev/aac74d377a03

Merge




From lana.steuck at oracle.com  Wed Oct 31 16:51:07 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 31 Oct 2012 16:51:07 +0000
Subject: hg: jdk8/tl/jaxws: 2 new changesets
Message-ID: <20121031165118.90B9A476B2@hg.openjdk.java.net>

Changeset: d265b9b4c0f5
Author:    katleman
Date:      2012-10-18 11:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d265b9b4c0f5

Added tag jdk8-b61 for changeset 97e5e74e2a34

! .hgtags

Changeset: c27ea8d489e8
Author:    katleman
Date:      2012-10-25 09:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c27ea8d489e8

Added tag jdk8-b62 for changeset d265b9b4c0f5

! .hgtags



From lana.steuck at oracle.com  Wed Oct 31 16:51:08 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 31 Oct 2012 16:51:08 +0000
Subject: hg: jdk8/tl/jaxp: 4 new changesets
Message-ID: <20121031165128.3123A476B4@hg.openjdk.java.net>

Changeset: 5d0fa0108d02
Author:    katleman
Date:      2012-10-18 11:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5d0fa0108d02

Added tag jdk8-b61 for changeset 6b1db0b41d2f

! .hgtags

Changeset: a96e34e038f5
Author:    katleman
Date:      2012-10-25 09:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a96e34e038f5

Added tag jdk8-b62 for changeset 5d0fa0108d02

! .hgtags

Changeset: 23e1d537224b
Author:    lana
Date:      2012-10-23 09:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/23e1d537224b

Merge


Changeset: fc589819b335
Author:    lana
Date:      2012-10-25 20:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/fc589819b335

Merge




From lana.steuck at oracle.com  Wed Oct 31 16:51:26 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 31 Oct 2012 16:51:26 +0000
Subject: hg: jdk8/tl/langtools: 5 new changesets
Message-ID: <20121031165139.4864B476B5@hg.openjdk.java.net>

Changeset: b47bb81ba962
Author:    katleman
Date:      2012-10-18 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b47bb81ba962

Added tag jdk8-b61 for changeset 26020b247ad3

! .hgtags

Changeset: 16498acd21b5
Author:    katleman
Date:      2012-10-25 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/16498acd21b5

Added tag jdk8-b62 for changeset b47bb81ba962

! .hgtags

Changeset: 5dde04b8bbb3
Author:    lana
Date:      2012-10-23 09:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5dde04b8bbb3

Merge


Changeset: 669468143a5e
Author:    lana
Date:      2012-10-25 20:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/669468143a5e

Merge


Changeset: 27f7952eea3c
Author:    lana
Date:      2012-10-31 08:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/27f7952eea3c

Merge




From lana.steuck at oracle.com  Wed Oct 31 16:52:52 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 31 Oct 2012 16:52:52 +0000
Subject: hg: jdk8/tl/hotspot: 84 new changesets
Message-ID: <20121031165614.973FC476B6@hg.openjdk.java.net>

Changeset: 81e878c53615
Author:    amurillo
Date:      2012-10-05 13:37 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/81e878c53615

8000498: new hotspot build - hs25-b05
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: d8ce2825b193
Author:    coleenp
Date:      2012-09-29 06:40 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d8ce2825b193

8000213: NPG: Should have renamed arrayKlass and typeArrayKlass
Summary: Capitalize these metadata types (and objArrayKlass)
Reviewed-by: stefank, twisti, kvn

! agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java
! agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlass.java
! agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlass.java
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/stubGenerator_sparc.cpp
! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/cpu/x86/vm/x86_32.ad
! src/share/vm/c1/c1_Runtime1.cpp
! src/share/vm/ci/ciArrayKlass.cpp
! src/share/vm/ci/ciArrayKlass.hpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciKlass.hpp
! src/share/vm/ci/ciObjArrayKlass.cpp
! src/share/vm/ci/ciObjArrayKlass.hpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/ci/ciTypeArrayKlass.cpp
! src/share/vm/ci/ciTypeArrayKlass.hpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp
! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp
! src/share/vm/gc_implementation/shared/markSweep.cpp
! src/share/vm/interpreter/bytecodeInterpreter.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/memory/oopFactory.cpp
! src/share/vm/memory/oopFactory.hpp
! src/share/vm/memory/specialized_oop_closures.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/arrayKlass.cpp
! src/share/vm/oops/arrayKlass.hpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/oops/klassVtable.cpp
! src/share/vm/oops/klassVtable.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/objArrayKlass.hpp
! src/share/vm/oops/objArrayKlass.inline.hpp
! src/share/vm/oops/objArrayOop.cpp
! src/share/vm/oops/objArrayOop.hpp
! src/share/vm/oops/oop.pcgc.inline.hpp
! src/share/vm/oops/oop.psgc.inline.hpp
! src/share/vm/oops/oopsHierarchy.hpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.hpp
! src/share/vm/oops/typeArrayOop.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/parseHelper.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jniCheck.cpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/jvmtiRedefineClasses.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/prims/unsafe.cpp
! src/share/vm/runtime/advancedThresholdPolicy.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/reflection.cpp
! src/share/vm/runtime/sharedRuntime.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/heapDumper.cpp
! src/share/vm/services/management.cpp
! src/share/vm/services/threadService.cpp
! src/share/vm/shark/sharkRuntime.cpp

Changeset: fab6fbf427d2
Author:    kevinw
Date:      2012-09-30 23:24 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fab6fbf427d2

7200145: runtime/7196045/Test7196045.java fails with No class provided for `main'
Reviewed-by: dholmes, dsamersoff

! test/runtime/7196045/Test7196045.java

Changeset: ba8fd2fe198b
Author:    coleenp
Date:      2012-10-04 08:38 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ba8fd2fe198b

7198519: Broken build, hotspot-rt win USE_PRECOMPILED_HEADER=0
Summary: Uncommented out include for sys/stat.h and deleted include statements that were commented out.
Reviewed-by: coleenp, acorn, dholmes
Contributed-by: harold.seigel at oracle.com

! src/os/windows/vm/jvm_windows.h

Changeset: bacdc1d5c21c
Author:    coleenp
Date:      2012-10-04 08:43 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bacdc1d5c21c

6884973: java -XX:Atomics=2 crashes
Summary: Remove buggy experimental option
Reviewed-by: acorn, coleenp
Contributed-by: harold.seigel at oracle.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 48087f745a86
Author:    dholmes
Date:      2012-10-04 19:52 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/48087f745a86

7199186: runtime/7194254/Test7194254.java fails - wrong test name on @run
Reviewed-by: kvn, twisti

! test/runtime/7194254/Test7194254.java

Changeset: f2eb2d4488db
Author:    dholmes
Date:      2012-10-04 20:09 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f2eb2d4488db

Merge


Changeset: 75982791ddb6
Author:    coleenp
Date:      2012-10-08 09:18 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/75982791ddb6

7170638: Use DTRACE_PROBE[N] in JNI Set and SetStatic Field.
Summary: Don't use HS_DTRACE_PROBE_CDECL_N and HS_DTRACE_PROBE_N directly.
Reviewed-by: coleenp, kamg, dholmes, sspitsyn
Contributed-by: Mark Wielaard <mjw at redhat.com>

! make/bsd/makefiles/buildtree.make
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/dtrace.make
! make/linux/makefiles/vm.make
! make/solaris/makefiles/buildtree.make
! src/share/vm/prims/jni.cpp
! src/share/vm/utilities/dtrace.hpp

Changeset: 7a40901e0d5c
Author:    minqi
Date:      2012-10-08 16:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7a40901e0d5c

8000332: SA ClassDump throws exception after permgen removal
Summary: In ClassWrite.writeFields(), fields count was mistakenly set to fields length which overflow the array index. Also removed a file which is leftover from 6879063 changeset.
Reviewed-by: coleenp, sspitsyn
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java
! agent/src/share/native/sadis.c

Changeset: 0e8ca886e4e1
Author:    minqi
Date:      2012-10-08 16:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0e8ca886e4e1

Merge


Changeset: 6e5a59a8e4a7
Author:    rbackman
Date:      2012-10-09 07:41 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e5a59a8e4a7

Merge

! src/cpu/sparc/vm/templateTable_sparc.cpp
! src/cpu/x86/vm/templateTable_x86_32.cpp
! src/cpu/x86/vm/templateTable_x86_64.cpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/interpreter/interpreterRuntime.cpp
! src/share/vm/oops/constantPool.cpp
! src/share/vm/oops/constantPool.hpp
! src/share/vm/oops/objArrayKlass.cpp
! src/share/vm/oops/typeArrayKlass.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 26351ce8c4b0
Author:    coleenp
Date:      2012-10-09 02:42 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/26351ce8c4b0

8000622: Forgot to hg add and check in test for JDK-7170638
Summary: add the test
Reviewed-by: coleenp, kamg
Contributed-by: Mark Wielaard <mjw at redhat.com>

+ test/serviceability/7170638/SDTProbesGNULinuxTest.sh

Changeset: b9a9ed0f8eeb
Author:    mikael
Date:      2012-10-09 10:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9a9ed0f8eeb

7197424: update copyright year to match last edit in jdk8 hotspot repository
Summary: Update copyright year to 2012 for relevant files
Reviewed-by: dholmes, coleenp

! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java
! agent/src/share/classes/sun/jvm/hotspot/oops/BranchData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/CounterData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/JumpData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/MultiBranchData.java
! agent/src/share/classes/sun/jvm/hotspot/oops/VirtualCallData.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtable.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/BasicHashtableEntry.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableBucket.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java
! make/bsd/Makefile
! make/bsd/makefiles/adlc.make
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/dtrace.make
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/jvmg.make
! make/bsd/makefiles/launcher.make
! make/bsd/makefiles/product.make
! make/bsd/makefiles/rules.make
! make/bsd/makefiles/sparcWorks.make
! make/bsd/makefiles/top.make
! make/linux/makefiles/launcher.make
! make/linux/makefiles/ppc.make
! make/linux/makefiles/product.make
! make/linux/makefiles/rules.make
! make/linux/makefiles/sparcWorks.make
! make/linux/makefiles/top.make
! make/solaris/makefiles/adlc.make
! make/solaris/makefiles/gcc.make
! make/solaris/makefiles/jvmg.make
! make/solaris/makefiles/optimized.make
! make/solaris/makefiles/rules.make
! make/solaris/makefiles/top.make
! make/windows/build.bat
! make/windows/build_vm_def.sh
! make/windows/get_msc_ver.sh
! make/windows/makefiles/adlc.make
! make/windows/makefiles/launcher.make
! make/windows/makefiles/projectcreator.make
! make/windows/makefiles/rules.make
! make/windows/makefiles/sanity.make
! make/windows/makefiles/shared.make
! make/windows/makefiles/vm.make
! make/windows/projectfiles/common/Makefile
! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp
! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.hpp
! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp
! src/cpu/sparc/vm/interpreterGenerator_sparc.hpp
! src/cpu/x86/vm/c1_FrameMap_x86.cpp
! src/cpu/x86/vm/c1_FrameMap_x86.hpp
! src/cpu/x86/vm/c1_LinearScan_x86.cpp
! src/cpu/x86/vm/interpreterGenerator_x86.hpp
! src/cpu/x86/vm/stubRoutines_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_64.hpp
! src/cpu/x86/vm/templateTable_x86_32.hpp
! src/cpu/x86/vm/templateTable_x86_64.hpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/cpu/zero/vm/interpreterGenerator_zero.hpp
! src/cpu/zero/vm/methodHandles_zero.hpp
! src/os/bsd/vm/decoder_machO.cpp
! src/os/bsd/vm/os_bsd.inline.hpp
! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/decoder_linux.cpp
! src/os/linux/vm/os_linux.inline.hpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/posix/launcher/java_md.c
! src/os/posix/launcher/launcher.script
! src/os/posix/vm/os_posix.cpp
! src/os/posix/vm/os_posix.hpp
! src/os/solaris/dtrace/hs_private.d
! src/os/solaris/vm/attachListener_solaris.cpp
! src/os/solaris/vm/decoder_solaris.cpp
! src/os/solaris/vm/os_solaris.hpp
! src/os/solaris/vm/os_solaris.inline.hpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/os/windows/vm/decoder_windows.cpp
! src/os/windows/vm/decoder_windows.hpp
! src/os/windows/vm/os_windows.hpp
! src/os/windows/vm/perfMemory_windows.cpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.hpp
! src/os_cpu/bsd_x86/vm/os_bsd_x86.inline.hpp
! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp
! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.cpp
! src/os_cpu/linux_x86/vm/os_linux_x86.hpp
! src/os_cpu/linux_x86/vm/os_linux_x86.inline.hpp
! src/os_cpu/linux_zero/vm/os_linux_zero.cpp
! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp
! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp
! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
! 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.cpp
! src/os_cpu/windows_x86/vm/os_windows_x86.hpp
! src/os_cpu/windows_x86/vm/os_windows_x86.inline.hpp
! src/share/tools/ProjectCreator/ProjectCreator.java
! src/share/tools/ProjectCreator/Util.java
! src/share/tools/ProjectCreator/WinGammaPlatform.java
! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java
! src/share/vm/asm/assembler.cpp
! src/share/vm/asm/assembler.hpp
! src/share/vm/asm/register.hpp
! src/share/vm/c1/c1_CFGPrinter.cpp
! src/share/vm/c1/c1_Canonicalizer.cpp
! src/share/vm/c1/c1_Canonicalizer.hpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_Compiler.cpp
! src/share/vm/c1/c1_FrameMap.cpp
! src/share/vm/c1/c1_FrameMap.hpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_IR.cpp
! src/share/vm/c1/c1_IR.hpp
! src/share/vm/c1/c1_InstructionPrinter.hpp
! src/share/vm/c1/c1_LinearScan.cpp
! src/share/vm/c1/c1_LinearScan.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/c1/c1_ValueMap.cpp
! src/share/vm/c1/c1_ValueMap.hpp
! src/share/vm/c1/c1_ValueStack.cpp
! src/share/vm/c1/c1_ValueStack.hpp
! src/share/vm/ci/ciMethodHandle.hpp
! src/share/vm/ci/ciSignature.hpp
! src/share/vm/ci/ciSymbol.cpp
! src/share/vm/ci/ciTypeFlow.hpp
! src/share/vm/classfile/classLoader.hpp
! src/share/vm/classfile/javaAssertions.hpp
! src/share/vm/code/stubs.cpp
! src/share/vm/code/stubs.hpp
! src/share/vm/code/vmreg.hpp
! src/share/vm/compiler/abstractCompiler.hpp
! src/share/vm/compiler/oopMap.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp
! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp
! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp
! src/share/vm/gc_implementation/g1/ptrQueue.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.hpp
! src/share/vm/gc_implementation/g1/survRateGroup.hpp
! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.hpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.cpp
! src/share/vm/gc_implementation/parallelScavenge/gcTaskThread.hpp
! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp
! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp
! src/share/vm/gc_implementation/parallelScavenge/psGenerationCounters.cpp
! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp
! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp
! src/share/vm/gc_implementation/shared/adaptiveSizePolicy.hpp
! src/share/vm/gc_implementation/shared/allocationStats.hpp
! src/share/vm/gc_implementation/shared/collectorCounters.cpp
! src/share/vm/gc_implementation/shared/collectorCounters.hpp
! src/share/vm/gc_implementation/shared/gSpaceCounters.cpp
! src/share/vm/gc_implementation/shared/gSpaceCounters.hpp
! src/share/vm/gc_implementation/shared/gcPolicyCounters.hpp
! src/share/vm/gc_implementation/shared/gcStats.hpp
! src/share/vm/gc_implementation/shared/gcUtil.cpp
! src/share/vm/gc_implementation/shared/gcUtil.hpp
! src/share/vm/gc_implementation/shared/generationCounters.cpp
! src/share/vm/gc_implementation/shared/generationCounters.hpp
! src/share/vm/gc_implementation/shared/hSpaceCounters.cpp
! src/share/vm/gc_implementation/shared/hSpaceCounters.hpp
! src/share/vm/gc_implementation/shared/spaceCounters.cpp
! src/share/vm/gc_implementation/shared/spaceCounters.hpp
! src/share/vm/gc_implementation/shared/spaceDecorator.hpp
! src/share/vm/interpreter/interpreter.hpp
! src/share/vm/libadt/set.cpp
! src/share/vm/libadt/vectset.cpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/cardTableModRefBS.cpp
! src/share/vm/memory/freeBlockDictionary.cpp
! src/share/vm/memory/freeList.cpp
! src/share/vm/memory/freeList.hpp
! src/share/vm/memory/heap.cpp
! src/share/vm/memory/heap.hpp
! src/share/vm/memory/referencePolicy.hpp
! src/share/vm/memory/space.inline.hpp
! src/share/vm/memory/threadLocalAllocBuffer.hpp
! src/share/vm/oops/objArrayOop.hpp
! src/share/vm/opto/addnode.cpp
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/divnode.cpp
! src/share/vm/opto/domgraph.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/generateOptoStub.cpp
! src/share/vm/opto/idealKit.cpp
! src/share/vm/opto/idealKit.hpp
! src/share/vm/opto/ifnode.cpp
! src/share/vm/opto/locknode.cpp
! src/share/vm/opto/locknode.hpp
! src/share/vm/opto/loopPredicate.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopUnswitch.cpp
! src/share/vm/opto/loopnode.hpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/macro.hpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/mulnode.cpp
! src/share/vm/opto/parse.hpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/phaseX.hpp
! src/share/vm/opto/split_if.cpp
! src/share/vm/opto/subnode.hpp
! src/share/vm/prims/jniExport.hpp
! src/share/vm/prims/jvmtiCodeBlobEvents.cpp
! src/share/vm/prims/jvmtiExtensions.cpp
! src/share/vm/prims/jvmtiRawMonitor.cpp
! src/share/vm/prims/jvmtiTagMap.hpp
! src/share/vm/prims/jvmtiUtil.cpp
! src/share/vm/runtime/arguments.hpp
! src/share/vm/runtime/dtraceJSDT.hpp
! src/share/vm/runtime/interfaceSupport.hpp
! src/share/vm/runtime/java.hpp
! src/share/vm/runtime/monitorChunk.cpp
! src/share/vm/runtime/monitorChunk.hpp
! src/share/vm/runtime/mutex.hpp
! src/share/vm/runtime/park.cpp
! src/share/vm/runtime/perfMemory.cpp
! src/share/vm/runtime/stubCodeGenerator.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/task.hpp
! src/share/vm/runtime/timer.cpp
! src/share/vm/runtime/vmThread.hpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/runtime/vm_version.hpp
! src/share/vm/services/attachListener.hpp
! src/share/vm/services/g1MemoryPool.cpp
! src/share/vm/services/g1MemoryPool.hpp
! src/share/vm/services/lowMemoryDetector.hpp
! src/share/vm/services/memoryManager.hpp
! src/share/vm/trace/tracing.hpp
! src/share/vm/utilities/array.cpp
! src/share/vm/utilities/decoder.cpp
! src/share/vm/utilities/decoder_elf.cpp
! 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/globalDefinitions_visCPP.hpp
! src/share/vm/utilities/growableArray.cpp
! src/share/vm/utilities/histogram.cpp
! src/share/vm/utilities/histogram.hpp
! src/share/vm/utilities/intHisto.cpp
! src/share/vm/utilities/intHisto.hpp
! src/share/vm/utilities/preserveException.cpp
! src/share/vm/utilities/stack.hpp
! src/share/vm/utilities/stack.inline.hpp
! src/share/vm/utilities/taskqueue.hpp
! src/share/vm/utilities/vmError.hpp
! src/share/vm/utilities/workgroup.cpp
! src/share/vm/utilities/workgroup.hpp
! test/compiler/6859338/Test6859338.java
! test/compiler/7116216/StackOverflow.java

Changeset: c3e799c37717
Author:    vlivanov
Date:      2012-10-05 18:57 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c3e799c37717

7177003: C1: LogCompilation support
Summary: add LogCompilation support in C1 - both client and tiered mode.
Reviewed-by: twisti, kvn

! src/os/linux/vm/vmError_linux.cpp
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_GraphBuilder.cpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/compiler/compileBroker.cpp
! src/share/vm/compiler/compileLog.cpp
! src/share/vm/compiler/compileLog.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/parse1.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/utilities/ostream.cpp

Changeset: 9a9b6e05ffb4
Author:    vlivanov
Date:      2012-10-05 19:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9a9b6e05ffb4

8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64
Summary: Move decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) anymore.
Reviewed-by: twisti, kvn

! src/share/vm/code/dependencies.cpp

Changeset: 9024b6b53ec2
Author:    vlivanov
Date:      2012-10-05 19:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9024b6b53ec2

8000485: Hotspot build fails in Solaris Studio IDE when building dtrace
Summary: Prepend '.' to the existing native library path
Reviewed-by: kvn, sspitsyn

! make/bsd/makefiles/dtrace.make
! make/solaris/makefiles/dtrace.make

Changeset: 377508648226
Author:    vlivanov
Date:      2012-10-08 13:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/377508648226

8000313: C2 should use jlong for 64bit values
Summary: Replace all occurrences of long with jlong in C2 code.
Reviewed-by: kvn, twisti

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/phaseX.hpp

Changeset: 65d07d9ee446
Author:    twisti
Date:      2012-10-08 17:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65d07d9ee446

8000263: JSR 292: signature types may appear to be unloaded
Reviewed-by: kvn, jrose

! src/cpu/sparc/vm/methodHandles_sparc.cpp
! src/cpu/sparc/vm/methodHandles_sparc.hpp
! src/cpu/x86/vm/methodHandles_x86.cpp
! src/cpu/x86/vm/methodHandles_x86.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/classfile/vmSymbols.cpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/prims/methodHandles.hpp
! src/share/vm/runtime/globals.hpp

Changeset: 8e47bac5643a
Author:    roland
Date:      2012-10-09 10:11 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8e47bac5643a

7054512: Compress class pointers after perm gen removal
Summary: support of compress class pointers in the compilers.
Reviewed-by: kvn, twisti

! agent/src/share/classes/sun/jvm/hotspot/debugger/Address.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/Debugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/JVMDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/dummy/DummyAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgAddress.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java
! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java
! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Array.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java
! agent/src/share/classes/sun/jvm/hotspot/oops/MetadataField.java
+ agent/src/share/classes/sun/jvm/hotspot/oops/NarrowKlassField.java
! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java
! agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/RobustOopDeterminator.java
! src/cpu/sparc/vm/assembler_sparc.cpp
! src/cpu/sparc/vm/assembler_sparc.hpp
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp
! src/cpu/sparc/vm/relocInfo_sparc.cpp
! src/cpu/sparc/vm/sparc.ad
! src/cpu/sparc/vm/vm_version_sparc.cpp
! src/cpu/sparc/vm/vtableStubs_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/c1_FrameMap_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp
! src/cpu/x86/vm/vtableStubs_x86_64.cpp
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/os/bsd/dtrace/generateJvmOffsets.cpp
! src/os/bsd/dtrace/jhelper.d
! src/os/solaris/dtrace/generateJvmOffsets.cpp
! src/os/solaris/dtrace/jhelper.d
! src/share/vm/adlc/archDesc.cpp
! src/share/vm/adlc/forms.cpp
! src/share/vm/adlc/forms.hpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/oops/instanceOop.hpp
! src/share/vm/oops/oop.inline.hpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/connode.cpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/live.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/machnode.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/matcher.hpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/node.hpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/subnode.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/utilities/globalDefinitions.cpp
! src/share/vm/utilities/globalDefinitions.hpp

Changeset: f6badecb7ea7
Author:    vlivanov
Date:      2012-10-09 12:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f6badecb7ea7

7199654: Remove LoadUI2LNode
Summary: Removed LoadUI2L node from Ideal nodes, use match rule in .ad files instead.
Reviewed-by: 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/forms.cpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/opto/classes.hpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/mulnode.cpp
! src/share/vm/opto/superword.cpp

Changeset: d336b3173277
Author:    kvn
Date:      2012-10-09 16:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d336b3173277

8000592: Improve adlc usability
Summary: several changes to adlc to improve its usability
Reviewed-by: kvn
Contributed-by: goetz.lindenmaier at sap.com

! src/share/vm/adlc/adlparse.cpp
! src/share/vm/adlc/archDesc.cpp
! src/share/vm/adlc/archDesc.hpp
! src/share/vm/adlc/dict2.cpp
! src/share/vm/adlc/filebuff.hpp
! src/share/vm/adlc/forms.hpp
! src/share/vm/adlc/formssel.cpp
! src/share/vm/adlc/formssel.hpp
! src/share/vm/adlc/main.cpp
! src/share/vm/adlc/output_c.cpp
! src/share/vm/adlc/output_h.cpp

Changeset: 94e9408dbf50
Author:    roland
Date:      2012-10-11 18:21 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/94e9408dbf50

8000753: compiler/6912517 crashes on 64bit sparc with compressed oops off
Summary: code generated by c1 for getClass intrinsic broken when klass field is loaded on 64bit with compressed klass off.
Reviewed-by: kvn

! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp

Changeset: 19eb999cb72c
Author:    twisti
Date:      2012-10-11 14:46 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/19eb999cb72c

8000740: remove LinkWellKnownClasses
Reviewed-by: kvn, jrose

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/classfile/systemDictionary.hpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/runtime/globals.hpp

Changeset: d804e148cff8
Author:    kvn
Date:      2012-10-12 09:22 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d804e148cff8

Merge

! make/bsd/makefiles/dtrace.make
! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp
! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/c1_FrameMap_x86.hpp
! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
! src/cpu/x86/vm/x86_32.ad
! src/share/vm/c1/c1_Compilation.cpp
! src/share/vm/c1/c1_Compilation.hpp
! src/share/vm/c1/c1_GraphBuilder.hpp
! src/share/vm/c1/c1_Optimizer.cpp
! src/share/vm/ci/ciEnv.cpp
! src/share/vm/ci/ciObjectFactory.cpp
! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/classfile/classFileParser.hpp
! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/method.cpp
! src/share/vm/opto/bytecodeInfo.cpp
! src/share/vm/opto/connode.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/memnode.hpp
! src/share/vm/opto/mulnode.cpp
! src/share/vm/opto/phaseX.hpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: fb19af007ffc
Author:    jprovino
Date:      2012-10-10 14:35 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fb19af007ffc

7189254: Change makefiles for more flexibility to override defaults
Summary: Change makefiles so that targets and parameters can be overridden by alternate makefiles.
Reviewed-by: dholmes, coleenp

! make/Makefile
! make/bsd/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/defs.make
! make/bsd/makefiles/gcc.make
! make/bsd/makefiles/ia64.make
+ make/bsd/makefiles/minimal1.make
! make/bsd/makefiles/vm.make
! make/defs.make
+ make/excludeSrc.make
! make/linux/Makefile
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/defs.make
! make/linux/makefiles/gcc.make
! make/linux/makefiles/ia64.make
+ make/linux/makefiles/minimal1.make
! make/linux/makefiles/vm.make
! make/windows/makefiles/defs.make
! src/os/solaris/vm/os_solaris.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/heapInspection.hpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/metaspaceShared.hpp
! src/share/vm/memory/universe.cpp
! src/share/vm/prims/forte.hpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiEnter.xsl
! src/share/vm/prims/jvmtiEnvBase.hpp
! src/share/vm/prims/jvmtiExport.hpp
! src/share/vm/prims/jvmtiImpl.hpp
! src/share/vm/prims/jvmtiRedefineClasses.hpp
! src/share/vm/prims/jvmtiTagMap.hpp
! src/share/vm/prims/jvmtiThreadState.hpp
! src/share/vm/prims/nativeLookup.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/fprofiler.hpp
! src/share/vm/runtime/globals_extension.hpp
! src/share/vm/runtime/init.cpp
! src/share/vm/runtime/perfData.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/services/attachListener.hpp
! src/share/vm/services/classLoadingService.cpp
! src/share/vm/services/classLoadingService.hpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/diagnosticCommand.hpp
! src/share/vm/services/heapDumper.hpp
! src/share/vm/services/management.cpp
! src/share/vm/services/management.hpp
! src/share/vm/services/memReporter.hpp
! src/share/vm/services/memTracker.hpp
! src/share/vm/services/runtimeService.cpp
! src/share/vm/services/runtimeService.hpp
! src/share/vm/utilities/macros.hpp

Changeset: bbeecede56dd
Author:    jiangli
Date:      2012-10-11 14:36 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bbeecede56dd

8000459: assert(java_lang_String::is_instance(entry)) failure with various mlvm tests.
Summary: Remove unneeded assert.
Reviewed-by: sspitsyn, coleenp

! src/share/vm/prims/jvmtiTagMap.cpp

Changeset: 9855b7e559ae
Author:    collins
Date:      2012-10-12 10:49 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9855b7e559ae

Merge

! make/bsd/Makefile
! make/bsd/makefiles/buildtree.make
! make/bsd/makefiles/gcc.make
! make/linux/makefiles/buildtree.make
! make/linux/makefiles/vm.make
! src/share/vm/memory/universe.cpp
! src/share/vm/prims/jni.cpp
! src/share/vm/prims/jvmtiTagMap.cpp
! src/share/vm/prims/jvmtiTagMap.hpp
! src/share/vm/runtime/vmStructs.cpp
! src/share/vm/runtime/vm_version.cpp
! src/share/vm/services/attachListener.hpp
! src/share/vm/services/diagnosticCommand.cpp
! src/share/vm/services/management.cpp

Changeset: 5876f980ea19
Author:    collins
Date:      2012-10-12 11:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5876f980ea19

Merge

! src/share/vm/memory/universe.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: b261523fe66c
Author:    amurillo
Date:      2012-10-12 13:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b261523fe66c

Merge


Changeset: 4547dc71db76
Author:    amurillo
Date:      2012-10-12 13:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4547dc71db76

Added tag hs25-b05 for changeset b261523fe66c

! .hgtags

Changeset: fcbdaeb69946
Author:    katleman
Date:      2012-10-18 11:08 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fcbdaeb69946

Added tag jdk8-b61 for changeset 4547dc71db76

! .hgtags

Changeset: 58fbf2da3c16
Author:    amurillo
Date:      2012-10-12 14:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/58fbf2da3c16

8000834: new hotspot build - hs25-b06
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 8a5ea0a9ccc4
Author:    johnc
Date:      2012-10-06 01:17 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8a5ea0a9ccc4

7127708: G1: change task num types from int to uint in concurrent mark
Summary: Change the type of various task num fields, parameters etc to unsigned and rename them to be more consistent with the other collectors. Code changes were also reviewed by Vitaly Davidovich.
Reviewed-by: johnc
Contributed-by: Kaushik Srenevasan <kaushik at twitter.com>

! 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/g1OopClosures.inline.hpp

Changeset: 04155d9c8c76
Author:    johnc
Date:      2012-10-08 09:12 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/04155d9c8c76

8000358: G1: metaspace information not printed in PrintHeapAtGC output nor in hs_err file
Summary: Missing call to MetaspaceAux::print_on() in G1CollectedHeap::print_on().
Reviewed-by: azeemj, jmasa
Contributed-by: Mikael Gerdin <mikael.gerdin at oracle.com>

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp

Changeset: dd2b66d09ccd
Author:    stefank
Date:      2012-10-09 22:12 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dd2b66d09ccd

8000659: NPG: ClassCastExceptions are unexpectedly thrown when testing nashorn
Summary: Treat the oops in invoke_method_table() as strong roots when ClassUnloading is enabled.
Reviewed-by: kamg, coleenp

! src/share/vm/classfile/systemDictionary.cpp

Changeset: 4202510ee0fe
Author:    johnc
Date:      2012-10-15 10:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4202510ee0fe

8000831: Heap verification output incorrect/incomplete
Summary: Restore non-silent output of heap verification.
Reviewed-by: ysr, brutisso, jmasa

! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp
! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp
! src/share/vm/memory/genCollectedHeap.cpp
! src/share/vm/memory/universe.hpp
! src/share/vm/utilities/debug.cpp

Changeset: 633ba56cb013
Author:    jmasa
Date:      2012-10-17 13:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/633ba56cb013

Merge

! src/share/vm/classfile/systemDictionary.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp
! src/share/vm/memory/universe.hpp

Changeset: bdb5f8c9978b
Author:    coleenp
Date:      2012-10-10 17:04 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bdb5f8c9978b

7199068: NPG: SharedSkipVerify is meaningless
Summary: Remove the SharedSkipVerify flag
Reviewed-by: kamg, sspitsyn, coleenp
Contributed-by: harold.seigel at oracle.com

! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/oops/klass.cpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/handles.hpp

Changeset: 48a75d2640a5
Author:    kamg
Date:      2012-10-11 14:27 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/48a75d2640a5

7054345: Support version 52.0 class file in HotSpot
Summary: Accept classfiles with major version 52
Reviewed-by: coleenp, acorn

! src/share/vm/classfile/classFileParser.cpp

Changeset: e0ea0e94c23c
Author:    kevinw
Date:      2012-10-15 16:48 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0ea0e94c23c

7195151: Multiplatform tescase for 6929067
Reviewed-by: kamg, kvn

! test/runtime/6929067/Test6929067.sh

Changeset: e52361627b65
Author:    coleenp
Date:      2012-10-15 22:33 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e52361627b65

Merge

! src/share/vm/classfile/classFileParser.cpp
! src/share/vm/memory/universe.cpp
! src/share/vm/runtime/globals.hpp

Changeset: 045cb62046a7
Author:    rbackman
Date:      2012-08-28 15:15 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/045cb62046a7

7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives
Reviewed-by: dholmes, dcubed

! src/share/vm/prims/jvmtiTagMap.cpp

Changeset: 7b5885dadbdc
Author:    nloodin
Date:      2012-10-17 17:36 +0200
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b5885dadbdc

8000617: It should be possible to allocate memory without the VM dying.
Reviewed-by: coleenp, kamg

! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/allocation.inline.hpp
! src/share/vm/memory/resourceArea.cpp
! src/share/vm/memory/resourceArea.hpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp

Changeset: e8c79c2ba3f3
Author:    coleenp
Date:      2012-10-18 12:29 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e8c79c2ba3f3

Merge


Changeset: d0337c31c8be
Author:    amurillo
Date:      2012-10-19 11:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d0337c31c8be

Merge


Changeset: dccd40de8db1
Author:    amurillo
Date:      2012-10-19 11:03 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dccd40de8db1

Added tag hs25-b06 for changeset d0337c31c8be

! .hgtags

Changeset: 556dd9e475c6
Author:    katleman
Date:      2012-10-25 09:53 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/556dd9e475c6

Added tag jdk8-b62 for changeset dccd40de8db1

! .hgtags

Changeset: d0e7716b179e
Author:    amurillo
Date:      2012-10-19 11:26 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d0e7716b179e

8001176: new hotspot build - hs25-b07
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: 85916677fc22
Author:    coleenp
Date:      2012-10-18 13:08 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/85916677fc22

7188233: UseVMInterruptibleIO flag deprecate for JDK8
Summary: The -XX:+UseVMInterruptibleIO flag is deprecated for JDK8.  The flag will still enable Interruptible IO on Solaris, but users will get a warning.
Reviewed-by: dholmes, acorn, alanb
Contributed-by: harold.seigel at oracle.com

! src/share/vm/runtime/arguments.cpp

Changeset: 8ebcedb7604d
Author:    coleenp
Date:      2012-10-18 13:09 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8ebcedb7604d

7053130: hs_err file does not record specified CLASSPATH
Summary: Added code to write the value of the java.class.path property to the hs_err file.
Reviewed-by: kmo, dholmes, kvn
Contributed-by: harold.seigel at oracle.com

! src/share/vm/runtime/arguments.cpp

Changeset: c7957b458bf8
Author:    minqi
Date:      2012-10-19 08:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c7957b458bf8

8000818: SA constant pool need to reference to reference map after permgen removal
Summary: After permgen removal, constant pool changed to put _ldc and _ldc_w (fast_ldc and fast_ldcw) index to reference map, no longer calculated via constant pool cache.
Reviewed-by: coleenp, sspitsyn, dholmes
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java
! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java

Changeset: 8eeffbc22f10
Author:    minqi
Date:      2012-10-19 08:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8eeffbc22f10

8001055: Bytes.swap should follow big endian
Summary: This is a mistake change in 6879063 about Bytes.swap. Java byte code order always follows big endian, but in that change, assume they follow native platform order that is not right.
Reviewed-by: coleenp, sspitsyn, dholmes
Contributed-by: yumin.qi at oracle.com

! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java

Changeset: 716c64bda5ba
Author:    zgu
Date:      2012-10-19 21:40 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/716c64bda5ba

7199092: NMT: NMT needs to deal overlapped virtual memory ranges
Summary: Enhanced virtual memory tracking to track committed regions as well as reserved regions, so NMT now can generate virtual memory map.
Reviewed-by: acorn, coleenp

! src/os/bsd/vm/perfMemory_bsd.cpp
! src/os/linux/vm/perfMemory_linux.cpp
! src/os/solaris/vm/os_solaris.cpp
! src/os/solaris/vm/perfMemory_solaris.cpp
! src/os/windows/vm/perfMemory_windows.cpp
! src/share/vm/memory/allocation.cpp
! src/share/vm/memory/allocation.hpp
! src/share/vm/memory/filemap.cpp
! src/share/vm/memory/filemap.hpp
! src/share/vm/memory/metaspaceShared.cpp
! src/share/vm/memory/resourceArea.hpp
! src/share/vm/runtime/handles.cpp
! src/share/vm/runtime/handles.hpp
! src/share/vm/runtime/handles.inline.hpp
! src/share/vm/runtime/os.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/services/attachListener.cpp
! src/share/vm/services/memBaseline.cpp
! src/share/vm/services/memBaseline.hpp
! src/share/vm/services/memPtr.cpp
! src/share/vm/services/memPtr.hpp
! src/share/vm/services/memRecorder.cpp
! src/share/vm/services/memRecorder.hpp
! src/share/vm/services/memReporter.cpp
! src/share/vm/services/memReporter.hpp
! src/share/vm/services/memSnapshot.cpp
! src/share/vm/services/memSnapshot.hpp
! src/share/vm/services/memTracker.cpp
! src/share/vm/services/memTracker.hpp

Changeset: b988bff99b38
Author:    zgu
Date:      2012-10-19 18:55 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b988bff99b38

Merge


Changeset: 80f44792c0c9
Author:    coleenp
Date:      2012-10-22 12:01 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/80f44792c0c9

Merge


Changeset: 685df3c6f84b
Author:    jmasa
Date:      2012-09-18 23:35 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/685df3c6f84b

7045397: NPG: Add freelists to class loader arenas.
Reviewed-by: coleenp, stefank, jprovino, ohair

! make/excludeSrc.make
+ src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp
+ src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp
! 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/concurrentMarkSweep/freeChunk.hpp
! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp
! src/share/vm/gc_implementation/shared/vmGCOperations.hpp
! src/share/vm/memory/binaryTreeDictionary.cpp
! src/share/vm/memory/binaryTreeDictionary.hpp
! src/share/vm/memory/freeBlockDictionary.cpp
! src/share/vm/memory/freeBlockDictionary.hpp
! src/share/vm/memory/freeList.cpp
! src/share/vm/memory/freeList.hpp
+ src/share/vm/memory/metablock.hpp
+ src/share/vm/memory/metachunk.hpp
! src/share/vm/memory/metaspace.cpp
! src/share/vm/memory/metaspace.hpp
! src/share/vm/runtime/vmStructs.cpp

Changeset: 476718ea6759
Author:    jmasa
Date:      2012-10-25 12:59 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/476718ea6759

8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk()
Reviewed-by: johnc, tamao

! src/share/vm/memory/binaryTreeDictionary.hpp

Changeset: b58313cf9afd
Author:    jcoomes
Date:      2012-10-26 08:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b58313cf9afd

Merge


Changeset: cfe522e6461c
Author:    kvn
Date:      2012-10-17 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cfe522e6461c

8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space
Summary: Fix type of method pointer load from vtable.
Reviewed-by: twisti, johnc, roland

! src/share/vm/opto/compile.cpp
! src/share/vm/opto/compile.hpp
! src/share/vm/opto/library_call.cpp

Changeset: e81a8af10cd9
Author:    kvn
Date:      2012-10-18 07:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e81a8af10cd9

8001071: Add simple range check into VM implemenation of Unsafe access methods
Summary: Add simple check in debug version of VM.
Reviewed-by: twisti, johnc

! src/share/vm/prims/unsafe.cpp

Changeset: aaeb9add1ab3
Author:    dlong
Date:      2012-10-19 14:21 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aaeb9add1ab3

8001101: C2: more general vector rule subsetting
Summary: Allow which vector rules are supported to be decided at runtime. Also a small change to allow vector types in Type::_type_info[] to apply to more platforms.
Reviewed-by: kvn, twisti
Contributed-by: dean.long at oracle.com

! src/share/vm/opto/type.cpp
! src/share/vm/opto/vectornode.cpp

Changeset: 67f4c477c9ab
Author:    vlivanov
Date:      2012-10-22 11:44 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/67f4c477c9ab

8000805: JMM issue: short loads are non-atomic
Summary: perform transforms during IGVN phase when Load has a single user.
Reviewed-by: jrose, kvn, twisti

! src/share/vm/opto/mulnode.cpp
+ test/compiler/8000805/Test8000805.java

Changeset: fd1d564dd460
Author:    twisti
Date:      2012-10-22 16:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd1d564dd460

8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920)
Reviewed-by: kvn

! src/share/vm/c1/c1_GraphBuilder.cpp

Changeset: b2c669fd8114
Author:    kvn
Date:      2012-10-23 13:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b2c669fd8114

8001183: incorrect results of char vectors right shift operaiton
Summary: do vector right shift operation for small int types only after loads
Reviewed-by: jrose, dlong

! src/cpu/x86/vm/x86.ad
! src/share/vm/opto/superword.cpp
! src/share/vm/opto/vectornode.cpp
! test/compiler/6340864/TestByteVect.java
! test/compiler/6340864/TestIntVect.java
! test/compiler/6340864/TestLongVect.java
! test/compiler/6340864/TestShortVect.java
+ test/compiler/8001183/TestCharVect.java

Changeset: a3ecd773a7b9
Author:    kvn
Date:      2012-10-24 14:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a3ecd773a7b9

7184394: add intrinsics to use AES instructions
Summary: Use new x86 AES instructions for AESCrypt.
Reviewed-by: twisti, kvn, roland
Contributed-by: tom.deneau at amd.com

! src/cpu/x86/vm/assembler_x86.cpp
! src/cpu/x86/vm/assembler_x86.hpp
! src/cpu/x86/vm/stubGenerator_x86_32.cpp
! src/cpu/x86/vm/stubGenerator_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_32.cpp
! src/cpu/x86/vm/stubRoutines_x86_32.hpp
! src/cpu/x86/vm/stubRoutines_x86_64.cpp
! src/cpu/x86/vm/stubRoutines_x86_64.hpp
! src/cpu/x86/vm/vm_version_x86.cpp
! src/cpu/x86/vm/vm_version_x86.hpp
! src/share/vm/classfile/vmSymbols.hpp
! src/share/vm/oops/method.cpp
! src/share/vm/opto/callGenerator.cpp
! src/share/vm/opto/callGenerator.hpp
! src/share/vm/opto/doCall.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/runtime.cpp
! src/share/vm/opto/runtime.hpp
! src/share/vm/runtime/globals.hpp
! src/share/vm/runtime/stubRoutines.cpp
! src/share/vm/runtime/stubRoutines.hpp
+ test/compiler/7184394/TestAESBase.java
+ test/compiler/7184394/TestAESDecode.java
+ test/compiler/7184394/TestAESEncode.java
+ test/compiler/7184394/TestAESMain.java

Changeset: 006174cfe979
Author:    kvn
Date:      2012-10-25 17:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/006174cfe979

7163534: VM could crashes assert(false) failed: infinite EA connection graph build
Summary: In case of time or iterations limit reached C2 stops EA and continue compilation without EA as it does in product VM already.
Reviewed-by: twisti

! src/share/vm/opto/c2_globals.hpp
! src/share/vm/opto/escape.cpp

Changeset: 410afdc6a07c
Author:    kvn
Date:      2012-10-26 11:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/410afdc6a07c

8001635: assert(in_bb(n)) failed: must be
Summary: Added missed check that Load node is in processed loop block.
Reviewed-by: twisti

! src/share/vm/opto/superword.cpp

Changeset: 588f08ed16cf
Author:    kvn
Date:      2012-10-26 12:06 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/588f08ed16cf

Merge

! src/share/vm/runtime/globals.hpp

Changeset: dc16fe422c53
Author:    amurillo
Date:      2012-10-26 14:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dc16fe422c53

Merge


Changeset: 57c61f87a1fd
Author:    amurillo
Date:      2012-10-26 14:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/57c61f87a1fd

Added tag hs25-b07 for changeset dc16fe422c53

! .hgtags

Changeset: bf14ed159fb0
Author:    kvn
Date:      2012-05-23 12:11 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf14ed159fb0

7158801: Improve VM CompileOnly option
Summary: Fixed buffer overflow during parsing flags -XX:CompileCommand=, -XX:CompileOnly= and command lines in .hotspot_compiler file.
Reviewed-by: never

! src/share/vm/compiler/compilerOracle.cpp

Changeset: fe4a4ea5bed9
Author:    kamg
Date:      2012-06-08 12:49 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe4a4ea5bed9

7158804: Improve config file parsing
Summary: Check buffer length when reading
Reviewed-by: dholmes, dcubed

! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/runtime/arguments.cpp
+ test/runtime/7158804/Test7158804.sh

Changeset: 6b5a3d18fe0e
Author:    asaha
Date:      2012-08-02 14:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6b5a3d18fe0e

Merge

! src/share/vm/compiler/compilerOracle.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 000352e00389
Author:    asaha
Date:      2012-08-02 22:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/000352e00389

Merge


Changeset: defeb6dad7d5
Author:    asaha
Date:      2012-08-10 10:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/defeb6dad7d5

Merge


Changeset: e4d10261499c
Author:    asaha
Date:      2012-09-07 18:18 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e4d10261499c

Merge

- agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java
- src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp
- src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp
- src/share/vm/prims/methodHandleWalk.cpp
- src/share/vm/prims/methodHandleWalk.hpp
! src/share/vm/runtime/arguments.cpp

Changeset: 521c82b9cbf8
Author:    kvn
Date:      2012-09-19 13:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/521c82b9cbf8

7198606: Improve VM optimization
Summary: Remove incorrect code in OptimizeFill optimization.
Reviewed-by: roland, twisti

! src/share/vm/opto/loopTransform.cpp

Changeset: 849cf0480cb9
Author:    asaha
Date:      2012-09-25 11:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/849cf0480cb9

Merge


Changeset: 5a3a6dac85e2
Author:    asaha
Date:      2012-09-26 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a3a6dac85e2

7199488: [TEST] runtime/7158800/InternTest.java failed due to false-positive on PID match.
Reviewed-by: coleenp

- test/runtime/7158800/BadUtf8.java
- test/runtime/7158800/InternTest.java
- test/runtime/7158800/Test7158800.sh
- test/runtime/7158800/badstrings.txt

Changeset: 218a94758fe7
Author:    asaha
Date:      2012-10-10 14:28 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/218a94758fe7

Merge

- agent/make/ClosureFinder.java
- agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java
- agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Address.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java
- agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java
- agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java
- agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java
- agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java
- agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java
- make/solaris/makefiles/reorder_COMPILER1_amd64
- make/solaris/makefiles/reorder_COMPILER1_i486
- make/solaris/makefiles/reorder_COMPILER1_sparc
- make/solaris/makefiles/reorder_COMPILER1_sparcv9
- make/solaris/makefiles/reorder_COMPILER2_amd64
- make/solaris/makefiles/reorder_COMPILER2_i486
- make/solaris/makefiles/reorder_COMPILER2_sparc
- make/solaris/makefiles/reorder_COMPILER2_sparcv9
- make/solaris/makefiles/reorder_CORE_i486
- make/solaris/makefiles/reorder_CORE_sparc
- make/solaris/makefiles/reorder_CORE_sparcv9
- make/solaris/makefiles/reorder_TIERED_amd64
- make/solaris/makefiles/reorder_TIERED_i486
- make/solaris/makefiles/reorder_TIERED_sparc
- make/solaris/makefiles/reorder_TIERED_sparcv9
- make/solaris/reorder.sh
- src/cpu/sparc/vm/dump_sparc.cpp
- src/cpu/x86/vm/dump_x86_32.cpp
- src/cpu/x86/vm/dump_x86_64.cpp
- src/cpu/zero/vm/dump_zero.cpp
- src/share/tools/ProjectCreator/DirectoryTree.java
- src/share/tools/ProjectCreator/DirectoryTreeNode.java
- src/share/tools/ProjectCreator/FileFormatException.java
- src/share/tools/ProjectCreator/WinGammaPlatformVC6.java
- src/share/vm/ci/ciArrayKlassKlass.hpp
- src/share/vm/ci/ciCPCache.cpp
- src/share/vm/ci/ciCPCache.hpp
- src/share/vm/ci/ciInstanceKlassKlass.cpp
- src/share/vm/ci/ciInstanceKlassKlass.hpp
- src/share/vm/ci/ciKlassKlass.cpp
- src/share/vm/ci/ciKlassKlass.hpp
- src/share/vm/ci/ciMethodKlass.cpp
- src/share/vm/ci/ciMethodKlass.hpp
- src/share/vm/ci/ciObjArrayKlassKlass.cpp
- src/share/vm/ci/ciObjArrayKlassKlass.hpp
- src/share/vm/ci/ciTypeArrayKlassKlass.cpp
- src/share/vm/ci/ciTypeArrayKlassKlass.hpp
! src/share/vm/compiler/compilerOracle.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp
- src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp
- src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp
- src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp
- src/share/vm/memory/classify.cpp
- src/share/vm/memory/classify.hpp
- src/share/vm/memory/compactPermGen.hpp
- src/share/vm/memory/compactingPermGenGen.cpp
- src/share/vm/memory/compactingPermGenGen.hpp
- src/share/vm/memory/dump.cpp
- src/share/vm/memory/permGen.cpp
- src/share/vm/memory/permGen.hpp
- src/share/vm/memory/restore.cpp
- src/share/vm/memory/serialize.cpp
- src/share/vm/oops/arrayKlassKlass.cpp
- src/share/vm/oops/arrayKlassKlass.hpp
- src/share/vm/oops/compiledICHolderKlass.cpp
- src/share/vm/oops/compiledICHolderKlass.hpp
- src/share/vm/oops/compiledICHolderOop.cpp
- src/share/vm/oops/compiledICHolderOop.hpp
- src/share/vm/oops/constMethodKlass.cpp
- src/share/vm/oops/constMethodKlass.hpp
- src/share/vm/oops/constMethodOop.cpp
- src/share/vm/oops/constMethodOop.hpp
- src/share/vm/oops/constantPoolKlass.cpp
- src/share/vm/oops/constantPoolKlass.hpp
- src/share/vm/oops/constantPoolOop.cpp
- src/share/vm/oops/constantPoolOop.hpp
- src/share/vm/oops/cpCacheKlass.cpp
- src/share/vm/oops/cpCacheKlass.hpp
- src/share/vm/oops/cpCacheOop.cpp
- src/share/vm/oops/cpCacheOop.hpp
- src/share/vm/oops/instanceKlassKlass.cpp
- src/share/vm/oops/instanceKlassKlass.hpp
- src/share/vm/oops/klassKlass.cpp
- src/share/vm/oops/klassKlass.hpp
- src/share/vm/oops/klassOop.cpp
- src/share/vm/oops/klassOop.hpp
- src/share/vm/oops/methodDataKlass.cpp
- src/share/vm/oops/methodDataKlass.hpp
- src/share/vm/oops/methodDataOop.cpp
- src/share/vm/oops/methodDataOop.hpp
- src/share/vm/oops/methodKlass.cpp
- src/share/vm/oops/methodKlass.hpp
- src/share/vm/oops/methodOop.cpp
- src/share/vm/oops/methodOop.hpp
- src/share/vm/oops/objArrayKlassKlass.cpp
- src/share/vm/oops/objArrayKlassKlass.hpp
- src/share/vm/oops/typeArrayKlassKlass.cpp
- src/share/vm/oops/typeArrayKlassKlass.hpp
! src/share/vm/opto/loopTransform.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 6ba00f89fbe1
Author:    asaha
Date:      2012-10-11 15:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6ba00f89fbe1

Merge

! src/share/vm/runtime/arguments.cpp

Changeset: d2582a08fa5d
Author:    asaha
Date:      2012-10-18 21:58 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d2582a08fa5d

Merge

! src/share/vm/opto/loopTransform.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: cb829aa4c98e
Author:    lana
Date:      2012-10-25 20:07 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cb829aa4c98e

Merge

- test/runtime/7158800/BadUtf8.java
- test/runtime/7158800/InternTest.java
- test/runtime/7158800/Test7158800.sh
- test/runtime/7158800/badstrings.txt

Changeset: acabb5c282f5
Author:    lana
Date:      2012-10-30 13:56 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/acabb5c282f5

Merge

! src/share/vm/runtime/arguments.cpp



From lana.steuck at oracle.com  Wed Oct 31 16:53:10 2012
From: lana.steuck at oracle.com (lana.steuck at oracle.com)
Date: Wed, 31 Oct 2012 16:53:10 +0000
Subject: hg: jdk8/tl/jdk: 49 new changesets
Message-ID: <20121031170517.78356476BA@hg.openjdk.java.net>

Changeset: 1ae6420126af
Author:    katleman
Date:      2012-10-18 11:09 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ae6420126af

Added tag jdk8-b61 for changeset 61ddb3fd000a

! .hgtags

Changeset: 61af38b8d4ff
Author:    twisti
Date:      2012-10-19 17:04 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/61af38b8d4ff

8000989: smaller code changes to make future JSR 292 backports easier
Reviewed-by: jrose

! src/share/classes/java/lang/invoke/BoundMethodHandle.java
! src/share/classes/java/lang/invoke/CallSite.java
! src/share/classes/java/lang/invoke/DirectMethodHandle.java
! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/share/classes/java/lang/invoke/Invokers.java
! src/share/classes/java/lang/invoke/LambdaForm.java
! src/share/classes/java/lang/invoke/MemberName.java
! src/share/classes/java/lang/invoke/MethodHandle.java
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleStatics.java
! src/share/classes/sun/invoke/util/ValueConversions.java
! test/java/lang/invoke/BigArityTest.java
! test/java/lang/invoke/PrivateInvokeTest.java

Changeset: 7a7e49acadec
Author:    kamg
Date:      2012-10-22 20:12 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a7e49acadec

8001225: Disable jdk regression test java/lang/System/Versions.java until jdk's classfile version code is updated
Summary: Exclude java/lang/System/Versions.java test
Reviewed-by: sspitsyn, coleenp

! test/ProblemList.txt

Changeset: a0a2b186ae28
Author:    tbell
Date:      2012-10-23 10:10 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a0a2b186ae28

7152336: Enable builds on Windows with MinGW/MSYS
Summary: Minimal makefile changes to enable building OpenJDK using MSYS on Windows7
Reviewed-by: ohair, tbell
Contributed-by: volker.simonis at gmail.com

! make/com/sun/java/pack/Makefile
! make/common/Defs-windows.gmk
! make/common/Demo.gmk
! make/common/Library.gmk
! make/common/Program.gmk
! make/common/Release.gmk
! make/common/shared/Defs-utils.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Platform.gmk
! make/common/shared/Sanity-Settings.gmk
! make/common/shared/Sanity.gmk
! make/jdk_generic_profile.sh
! make/tools/freetypecheck/Makefile
+ make/tools/msys_build_scripts/dospath.sh
+ make/tools/msys_build_scripts/dospath.vbs

Changeset: 50b8b17449d2
Author:    katleman
Date:      2012-10-24 13:14 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50b8b17449d2

Merge


Changeset: 65d2c6726487
Author:    katleman
Date:      2012-10-25 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/65d2c6726487

Added tag jdk8-b62 for changeset 50b8b17449d2

! .hgtags

Changeset: 117eed515e42
Author:    bae
Date:      2012-10-23 13:10 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/117eed515e42

7051394: NullPointerException when running regression tests LoadProfileTest by using openjdk-7-b144
Reviewed-by: jgodinez, prr

! src/share/native/sun/java2d/cmm/lcms/LCMS.c

Changeset: aeb96dec1c6b
Author:    lana
Date:      2012-10-23 09:38 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aeb96dec1c6b

Merge


Changeset: 93e2669f1ac2
Author:    leonidr
Date:      2012-10-09 18:00 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93e2669f1ac2

7185280: Jre7cert: focusgained does not get called for all focus req when do alt + tab
Reviewed-by: anthony

! src/windows/native/sun/windows/awt_Window.cpp

Changeset: 527f8eeb8e8d
Author:    leonidr
Date:      2012-10-09 20:59 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/527f8eeb8e8d

7124321: [macosx] TrayIcon MouseListener is never triggered
Reviewed-by: anthony

! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java
! src/macosx/native/sun/awt/CTrayIcon.h
! src/macosx/native/sun/awt/CTrayIcon.m

Changeset: d4d0327e36e2
Author:    kshefov
Date:      2012-10-12 18:46 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d4d0327e36e2

7184326: TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo
Reviewed-by: anthony

! test/java/awt/Frame/7024749/bug7024749.java

Changeset: 34d502d14a61
Author:    lana
Date:      2012-10-12 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34d502d14a61

Merge

- src/share/classes/sun/util/xml/XMLUtils.java
- src/share/test/pack200/pack.conf

Changeset: f42d178f0452
Author:    anthony
Date:      2012-10-16 20:11 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f42d178f0452

6818083: When DISPLAY is bad, InternalError thrown, not AWTError
Summary: Throw AWTError instead of InternalError if the DISPLAY is bad
Reviewed-by: anthony, serb
Contributed-by: Mikhail Cherkasov <mikhail.cherkasov at oracle.com>

! src/solaris/native/sun/awt/awt_GraphicsEnv.c
+ test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.java
+ test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.sh

Changeset: 47cdc463b4b0
Author:    kizune
Date:      2012-10-17 14:32 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/47cdc463b4b0

7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test
Reviewed-by: serb, leonidr

! src/macosx/classes/sun/awt/CGraphicsDevice.java

Changeset: e6a8ee65d248
Author:    alexsch
Date:      2012-10-17 17:33 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6a8ee65d248

8000969: [macosx] Directories are not deselected when JFileChooser has FILES_ONLY selection mode
Reviewed-by: rupashka

! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java

Changeset: 29b7bd890d3a
Author:    alexsch
Date:      2012-10-17 10:16 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29b7bd890d3a

8000626: Implement dead key detection for KeyEvent on Linux
Reviewed-by: kizune

! src/solaris/classes/sun/awt/X11/XKeysym.java
! src/solaris/classes/sun/awt/X11/XWindow.java
! src/solaris/classes/sun/awt/X11/keysym2ucs.h

Changeset: 9c6f60a4e996
Author:    alexsch
Date:      2012-10-18 17:50 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c6f60a4e996

7199708: FileChooser crashs when opening large folder
Reviewed-by: bagiras

! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java

Changeset: 8bbc6a5f1e92
Author:    alexsch
Date:      2012-10-18 18:28 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8bbc6a5f1e92

7175707: [macosx] PIT: 8 b43 Not running on AppKit thread issue again
Reviewed-by: serb, anthony

! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/macosx/native/sun/awt/AWTWindow.m

Changeset: 6b16f6fc41c5
Author:    serb
Date:      2012-10-19 15:23 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b16f6fc41c5

7124520: [macosx] re:6373505 Toolkit.getScreenResolution() != GraphicsConfiguration.getNormalizingTransform()
Reviewed-by: anthony, kizune

! src/macosx/classes/sun/awt/CGraphicsDevice.java
! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
+ test/java/awt/GraphicsConfiguration/NormalizingTransformTest/NormalizingTransformTest.java

Changeset: e0f91b40b8dd
Author:    alexsch
Date:      2012-10-23 14:30 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0f91b40b8dd

6624200: Regression test fails: test/closed/javax/swing/JMenuItem/4654927/bug4654927.java
Reviewed-by: rupashka

+ test/javax/swing/JMenuItem/4654927/bug4654927.java
! test/javax/swing/regtesthelpers/Util.java

Changeset: 37a6ead4a357
Author:    lana
Date:      2012-10-23 09:40 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37a6ead4a357

Merge


Changeset: cdc7f9be3707
Author:    lana
Date:      2012-10-23 09:41 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdc7f9be3707

Merge

- src/share/classes/sun/security/tools/CertAndKeyGen.java
- src/share/classes/sun/security/tools/JarSigner.java
- src/share/classes/sun/security/tools/JarSignerResources.java
- src/share/classes/sun/security/tools/JarSignerResources_ja.java
- src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java
- src/share/classes/sun/security/tools/KeyTool.java
- src/share/classes/sun/security/tools/TimestampedSigner.java
- src/windows/classes/java/io/Win32FileSystem.java
- src/windows/native/java/io/Win32FileSystem_md.c
- test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java
- test/com/sun/jndi/ldap/ReadTimeoutTest.java

Changeset: 0582dc4674c9
Author:    wetmore
Date:      2012-05-21 15:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0582dc4674c9

7167656: Multiple Seeders are being created
Reviewed-by: smarks, mduigou, ahgross

! src/share/classes/sun/security/provider/SecureRandom.java

Changeset: b4f35876d9b5
Author:    mullan
Date:      2012-06-08 11:02 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4f35876d9b5

7163198: Tightened package accessibility
7169887: Tightened package accessibility
Reviewed-by: vinnie, hawtin

! src/share/lib/security/java.security
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 89a0551b98d8
Author:    weijun
Date:      2012-06-15 09:51 +0800
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89a0551b98d8

6631398: FilePermission improved path checking
Reviewed-by: mullan, skoivu, jdn

! src/share/classes/java/io/FilePermission.java

Changeset: 7439e8007e09
Author:    mullan
Date:      2012-06-18 10:00 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7439e8007e09

7172522: Improve DomainCombiner checking
Reviewed-by: vinnie, ahgross

! src/share/classes/java/security/AccessController.java

Changeset: 2a98c51549a8
Author:    smarks
Date:      2012-06-21 00:20 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a98c51549a8

7093490: adjust package access in rmiregistry
Reviewed-by: ahgross, coffeys, dmocek

! src/share/classes/sun/rmi/registry/RegistryImpl.java

Changeset: 263f15439f4b
Author:    dsamersoff
Date:      2012-06-22 16:22 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/263f15439f4b

7158796: Tighten properties checking in EnvHelp
Summary: Move getProperty call out of computeBooleanFromString
Reviewed-by: skoivu, sla

! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java
! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java
! src/share/classes/javax/management/remote/rmi/RMIConnector.java
! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java

Changeset: 3a825f6cbc71
Author:    dsamersoff
Date:      2012-06-22 18:19 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a825f6cbc71

7169888: Narrowing resource definitions in JMX RMI connector
Summary: CPU bug, we can't put offending calls outside doPrivileged, but narrow granted permissions.
Reviewed-by: ahgross, fparain

! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java

Changeset: 90498c1cc87c
Author:    xuelei
Date:      2012-07-28 19:42 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90498c1cc87c

7186286: TLS implementation to better adhere to RFC
Summary: also reviewed by Alexander Fomin <Alexander.Fomin at Oracle.COM>, Andrew Gross<Andrew.Gross at Oracle.COM>, Sean Coffey<Sean.Coffey at Oracle.COM>
Reviewed-by: valeriep, wetmore

! src/share/classes/sun/security/ssl/HandshakeInStream.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java

Changeset: 983c17aecdac
Author:    mullan
Date:      2012-08-15 15:31 -0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/983c17aecdac

7189490: More improvements to DomainCombiner checking
Reviewed-by: ahgross, jdn, vinnie

! src/share/classes/java/security/AccessController.java

Changeset: 6cc28cc213b6
Author:    chegar
Date:      2012-08-16 15:02 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cc28cc213b6

7189103: Executors needs to maintain state
Reviewed-by: dholmes, hawtin

! src/share/classes/java/util/concurrent/Executors.java

Changeset: a09b9ebb61b6
Author:    chegar
Date:      2012-08-29 14:05 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a09b9ebb61b6

7189567: java net obselete protocol
Reviewed-by: alanb, ahgross

! make/sun/net/FILES_java.gmk
- src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
- src/share/classes/sun/net/www/protocol/gopher/Handler.java
! test/java/net/URL/Test.java

Changeset: 2ac636f46c5b
Author:    alanb
Date:      2012-09-08 20:31 +0100
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ac636f46c5b

7169884: LogManager checks do not work correctly for sub-types
Reviewed-by: mchung, ahgross

! src/share/classes/java/util/logging/FileHandler.java
! src/share/classes/java/util/logging/Handler.java
! src/share/classes/java/util/logging/LogManager.java
! src/share/classes/java/util/logging/Logger.java
! src/share/classes/java/util/logging/MemoryHandler.java
! src/share/classes/java/util/logging/StreamHandler.java

Changeset: 4488ea026532
Author:    asaha
Date:      2012-09-08 22:23 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4488ea026532

Merge


Changeset: e869a8513cb7
Author:    smarks
Date:      2012-09-10 16:05 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e869a8513cb7

7195919: (sl) ServiceLoader can throw CCE without needing to create instance
Reviewed-by: ahgross, alanb, dmeetry

! src/share/classes/java/util/ServiceLoader.java
! src/share/classes/sun/misc/Service.java

Changeset: 9a7e2fa3c9c5
Author:    malenkov
Date:      2012-09-11 12:57 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a7e2fa3c9c5

7195549: Better bean object persistence
Reviewed-by: art, ahgross

! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java

Changeset: 1d1fcf0c1ce8
Author:    rupashka
Date:      2012-09-11 15:59 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d1fcf0c1ce8

7195194: Better data validation for Swing
Reviewed-by: art, ahgross

! src/share/classes/javax/swing/text/DefaultFormatter.java

Changeset: 3b49bd3c392b
Author:    malenkov
Date:      2012-09-19 21:42 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b49bd3c392b

7195917: XMLDecoder parsing at close-time should be improved
Reviewed-by: art, ahgross

! src/share/classes/com/sun/beans/decoder/DocumentHandler.java
! src/share/classes/java/beans/XMLDecoder.java

Changeset: 762eee5e6e16
Author:    jrose
Date:      2012-09-20 14:02 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/762eee5e6e16

7196190: Improve method of handling MethodHandles
Summary: Bind callers to caller-sensitive methods.
Reviewed-by: twisti, jjh, vlivanov, ahgross

! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleNatives.java
! src/share/classes/java/lang/invoke/MethodHandleStatics.java
! src/share/classes/java/lang/invoke/MethodHandles.java
! src/share/classes/sun/invoke/anon/AnonymousClassLoader.java
! src/share/classes/sun/invoke/util/ValueConversions.java
+ test/java/lang/invoke/7196190/ClassForNameTest.java
+ test/java/lang/invoke/7196190/GetUnsafeTest.java
+ test/java/lang/invoke/7196190/MHProxyTest.java
+ test/java/lang/invoke/7196190/jtreg.security.policy

Changeset: e113ffde452a
Author:    dsamersoff
Date:      2012-09-24 16:15 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e113ffde452a

7198296: Problem with classloader in JMX
Summary: wb classes have to be available for hotspot tests
Reviewed-by: ahgross, asaha
Contributed-by: frederic.parain at oracle.com, daniel.fuchs at oracle.com, jean-francois.denise at oracle.com

! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java

Changeset: ca79b33a0731
Author:    dsamersoff
Date:      2012-09-24 17:00 +0400
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca79b33a0731

7192975: Issue with JMX reflection
Summary: Make security check unconditional
Reviewed-by: ahgross, asaha
Contributed-by: jaroslav.bachorik at oracle.com

! src/share/classes/javax/management/modelmbean/DescriptorSupport.java

Changeset: 74eec13c464e
Author:    asaha
Date:      2012-09-25 11:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/74eec13c464e

Merge

- make/common/Defs-embedded.gmk
- make/common/Release-embedded.gmk

Changeset: e4ce54b79bb4
Author:    asaha
Date:      2012-10-10 14:31 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e4ce54b79bb4

Merge

- src/macosx/classes/sun/awt/SunToolkitSubclass.java
! src/share/classes/java/io/FilePermission.java
- src/share/classes/sun/management/LockDataConverter.java
- src/share/classes/sun/management/LockDataConverterMXBean.java
- src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java
- src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java
- test/sun/misc/URLClassPath/ClassnameCharTest.sh
- test/sun/net/www/httptest/HttpServer.java
- test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java

Changeset: 28fe37b50e3c
Author:    asaha
Date:      2012-10-11 15:30 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/28fe37b50e3c

Merge


Changeset: d3b3fea7d1d7
Author:    asaha
Date:      2012-10-18 22:01 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3b3fea7d1d7

Merge

! src/share/classes/java/io/FilePermission.java
! src/share/classes/java/util/ServiceLoader.java
- src/share/classes/sun/util/xml/XMLUtils.java
- src/share/test/pack200/pack.conf

Changeset: e6fbbb2c610d
Author:    lana
Date:      2012-10-23 11:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6fbbb2c610d

Merge

! src/share/classes/java/util/ServiceLoader.java
! src/share/classes/java/util/logging/LogManager.java
- src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
- src/share/classes/sun/net/www/protocol/gopher/Handler.java
! src/share/classes/sun/security/ssl/HandshakeInStream.java
! src/share/classes/sun/security/ssl/Handshaker.java
! src/share/lib/security/java.security
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: dfd509da3da6
Author:    lana
Date:      2012-10-25 20:32 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfd509da3da6

Merge

! make/common/Release.gmk
! src/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/share/classes/java/lang/invoke/MethodHandleStatics.java
! src/share/classes/sun/invoke/util/ValueConversions.java
- src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
- src/share/classes/sun/net/www/protocol/gopher/Handler.java
- src/share/classes/sun/security/tools/CertAndKeyGen.java
- src/share/classes/sun/security/tools/JarSigner.java
- src/share/classes/sun/security/tools/JarSignerResources.java
- src/share/classes/sun/security/tools/JarSignerResources_ja.java
- src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java
- src/share/classes/sun/security/tools/KeyTool.java
- src/share/classes/sun/security/tools/TimestampedSigner.java
- src/windows/classes/java/io/Win32FileSystem.java
- src/windows/native/java/io/Win32FileSystem_md.c
! test/ProblemList.txt
- test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java
- test/com/sun/jndi/ldap/ReadTimeoutTest.java

Changeset: ac97b1cfc0ea
Author:    lana
Date:      2012-10-31 08:29 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac97b1cfc0ea

Merge

! make/common/shared/Sanity.gmk
! src/share/classes/java/util/concurrent/Executors.java
! src/share/classes/java/util/logging/FileHandler.java
! src/share/classes/java/util/logging/MemoryHandler.java
! src/share/classes/java/util/logging/StreamHandler.java
- src/share/classes/sun/net/www/protocol/gopher/GopherClient.java
- src/share/classes/sun/net/www/protocol/gopher/Handler.java



From kumar.x.srinivasan at oracle.COM  Wed Oct 31 17:43:54 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Wed, 31 Oct 2012 10:43:54 -0700
Subject: RFR: JDK-8001191:  use -source 8 -target 8 when compiling the JDK
Message-ID: <5091635A.3010000@oracle.COM>

Hello,

Please review changes to rev up the default -source and -target for jdk 
compilation,
thus producing v52.0 class files.

Bug is here:
https://jbs.oracle.com/bugs/browse/JDK-8001191

Webrev is here:
http://cr.openjdk.java.net/~ksrini/8001191/webrev.0/

Note: this webrev is generated against the master repository but changes 
will be
pushed via tl  after the tl-master sync is completed.

Thanks
Kumar



From mike.duigou at oracle.com  Wed Oct 31 18:08:23 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 31 Oct 2012 11:08:23 -0700
Subject: RFR: JDK-8001191: use -source 8 -target 8 when compiling the JDK
In-Reply-To: <5091635A.3010000@oracle.COM>
References: <5091635A.3010000@oracle.COM>
Message-ID: <CB85E652-8D9A-4B43-A8DA-A2A9CE6BB61E@oracle.com>

Looks good.

make/java/invoke/Makefile:
 I have had good success in the lambda repo with just removing the version directives from this file. They date from early days of 292 and are no longer relevant. The package compiles just fine using the global default now.

On Oct 31 2012, at 10:43 , Kumar Srinivasan wrote:

> Hello,
> 
> Please review changes to rev up the default -source and -target for jdk compilation,
> thus producing v52.0 class files.
> 
> Bug is here:
> https://jbs.oracle.com/bugs/browse/JDK-8001191
> 
> Webrev is here:
> http://cr.openjdk.java.net/~ksrini/8001191/webrev.0/
> 
> Note: this webrev is generated against the master repository but changes will be
> pushed via tl  after the tl-master sync is completed.
> 
> Thanks
> Kumar
> 



From jim.gish at oracle.com  Wed Oct 31 18:08:20 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 31 Oct 2012 14:08:20 -0400
Subject: RFR: JDK-8001191:  use -source 8 -target 8 when compiling the JDK
In-Reply-To: <5091635A.3010000@oracle.COM>
References: <5091635A.3010000@oracle.COM>
Message-ID: <50916914.2050004@oracle.com>

Looks good to me.

Thanks,
    Jim
On 10/31/2012 01:43 PM, Kumar Srinivasan wrote:
> Hello,
>
> Please review changes to rev up the default -source and -target for 
> jdk compilation,
> thus producing v52.0 class files.
>
> Bug is here:
> https://jbs.oracle.com/bugs/browse/JDK-8001191
>
> Webrev is here:
> http://cr.openjdk.java.net/~ksrini/8001191/webrev.0/
>
> Note: this webrev is generated against the master repository but 
> changes will be
> pushed via tl  after the tl-master sync is completed.
>
> Thanks
> Kumar
>

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From kumar.x.srinivasan at oracle.COM  Wed Oct 31 18:15:10 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Wed, 31 Oct 2012 11:15:10 -0700
Subject: RFR: 7050936: (pack200) Support version 52.0 class files
Message-ID: <50916AAE.8080105@oracle.COM>

Hi,

Please review change which allows pack200 to recognize the class
file v52.0.

Bug is here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7050936

Webrev is here:
http://cr.openjdk.java.net/~ksrini/7050936/webrev.0/

Thanks
Kumar





From forax at univ-mlv.fr  Wed Oct 31 18:16:51 2012
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 31 Oct 2012 19:16:51 +0100
Subject: Review request for 8001536 updated
In-Reply-To: <175719F7-CE8C-455E-9E5C-2F2AB5B8A1FB@oracle.com>
References: <FBA7F5E1-12B9-4FE0-8DA3-4A86193646AD@oracle.com>
	<509016F3.2030509@univ-mlv.fr>
	<175719F7-CE8C-455E-9E5C-2F2AB5B8A1FB@oracle.com>
Message-ID: <50916B13.6060108@univ-mlv.fr>

On 10/31/2012 04:08 PM, Lance Andersen - Oracle wrote:
> Here is revised webrev taking into account Remi's suggestions http://cr.openjdk.java.net/~lancea/8001536/webrev.01/

looks good :)

> Best,
> Lance

R?mi

>
> On Oct 30, 2012, at 2:05 PM, Remi Forax wrote:
>
>> On 10/30/2012 05:25 PM, Lance Andersen - Oracle wrote:
>>> Hi,
>>>
>>> This is a request for review of http://cr.openjdk.java.net/~lancea/8001536/webrev.00/.  This adds read/writeObject as well as clone methods to SerialXLob classes.
>>>
>>> All SQE tests passed,  1 failure in the RowSet JCK/TCK tests due to a bug in the test that the TCK team is aware of and will address.  JDBC Unit tests all pass .
>> Hi Lance.
>> In SerialBlob and in SerialClob
>> test (obj == null) is not necessary in equals, null instanceof X is always false.
>>
>> in hashCode, Objects.hash() allocate an array to pass arguments to Arrays.hashCode() and box primitive values to Object.
>> while this method is really convenient to use, each calls will allocate an array and box the two values,
>> the overhead seems to high here.
>> This code should be equivalent:
>>     return ((31 +Arrays.hashCode(buf)) * 31 +len) * 31 + origLen;
>>
>> in clone, sb should not be initialized to null and the catch should be: throw new InternalError(e),
>> this is the standard code you can see in clone.
>>
>> in readObject, the test (buf.length != len) can be done before decoding the blob.
>>
>> in writeObject, you set "blob" twice, which is weird, also I think that if blob is not Serializable,
>> the code should throw an exception, so you should not use instanceof and let s.writeFields()
>> to throw NotSerializable exception.
>>
>> cheers,
>> R?mi
>>
>>>
>>> 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 kumar.x.srinivasan at oracle.COM  Wed Oct 31 18:18:42 2012
From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan)
Date: Wed, 31 Oct 2012 11:18:42 -0700
Subject: RFR: JDK-8001191:  use -source 8 -target 8 when compiling the JDK
In-Reply-To: <CB85E652-8D9A-4B43-A8DA-A2A9CE6BB61E@oracle.com>
References: <5091635A.3010000@oracle.COM>
	<CB85E652-8D9A-4B43-A8DA-A2A9CE6BB61E@oracle.com>
Message-ID: <50916B82.6060601@oracle.COM>


> Looks good.
>
> make/java/invoke/Makefile:
>   I have had good success in the lambda repo with just removing the version directives from this file. They date from early days of 292 and are no longer relevant. The package compiles just fine using the global default now.

Lets address this as separate issue when we start the lambda merges.

Kumar

>
> On Oct 31 2012, at 10:43 , Kumar Srinivasan wrote:
>
>> Hello,
>>
>> Please review changes to rev up the default -source and -target for jdk compilation,
>> thus producing v52.0 class files.
>>
>> Bug is here:
>> https://jbs.oracle.com/bugs/browse/JDK-8001191
>>
>> Webrev is here:
>> http://cr.openjdk.java.net/~ksrini/8001191/webrev.0/
>>
>> Note: this webrev is generated against the master repository but changes will be
>> pushed via tl  after the tl-master sync is completed.
>>
>> Thanks
>> Kumar
>>



From naoto.sato at oracle.com  Wed Oct 31 18:36:13 2012
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 31 Oct 2012 18:36:13 +0000
Subject: hg: jdk8/tl/jdk: 8001231: Move locale data out of rt.jar (except the
	US locale)
Message-ID: <20121031183648.E343F476CB@hg.openjdk.java.net>

Changeset: 178618fb4300
Author:    naoto
Date:      2012-10-31 11:33 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/178618fb4300

8001231: Move locale data out of rt.jar (except the US locale)
Reviewed-by: alanb, erikj

! make/java/java/genlocales.gmk
! make/java/java/localegen.sh
! make/java/text/base/FILES_java.gmk
! make/java/util/FILES_java.gmk
! make/java/util/FILES_properties.gmk
! make/sun/text/FILES_java.gmk
! make/sun/text/FILES_properties.gmk
! makefiles/CreateJars.gmk
! makefiles/GensrcLocaleDataMetaInfo.gmk
! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java
! src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template



From jim.gish at oracle.com  Wed Oct 31 19:08:42 2012
From: jim.gish at oracle.com (Jim Gish)
Date: Wed, 31 Oct 2012 15:08:42 -0400
Subject: about JavaOne2012 Finding and Solving Java Deadlocks
In-Reply-To: <CF148525-7ECE-40EF-98D5-8237AC14DB43@oracle.com>
References: <CAE=739u=NjFmOpdQyxPhsFAUhp5kt4+Pz1Z+e7PD4dyXqtKC0g@mail.gmail.com>
	<CF148525-7ECE-40EF-98D5-8237AC14DB43@oracle.com>
Message-ID: <5091773A.4060804@oracle.com>

I'd be very interested in this too, and would also like to see the slides.

Thanks,
    Jim

On 10/15/2012 05:50 PM, Mike Duigou wrote:
> The session was a hands on lab so was not recorded that I can tell.
>
> Here's the official session page:
>
> https://oracleus.activeevents.com/connect/search.ww?event=javaone#loadSearch-event=javaone&searchPhrase=&searchType=session&tc=0&sortBy=&p=&i%2811424%29=18653&i%2810050%29=&i%2810090%29=&i%2810092%29=&i%2811842%29=&i%2810086%29=
>
> Some of the presenters are subscribers to this list. If they don't respond with the slides perhaps you can contact them.
>
> Mike
>
> On Oct 13 2012, at 03:44 , fuyou wrote:
>
>> hi all
>>
>> I  am very interested in session of  HOL6500 - Finding and Solving Java
>> Deadlocks(JavaOne 2012) .how can i watch video or download  slides.
>>
>> Thanks!
>>
>> -- 
>>    =============================================
>>
>>   fuyou001
>> Best Regards

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com



From mike.duigou at oracle.com  Wed Oct 31 20:16:24 2012
From: mike.duigou at oracle.com (Mike Duigou)
Date: Wed, 31 Oct 2012 13:16:24 -0700
Subject: Review Request: CR#8001634 : Initial set of lambda functional
	interfaces
Message-ID: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com>

There's a large set of library changes that will be coming with Lambda. We're getting near the end of the runway and there's lots left to do so we want to start the process of getting some of the more stable pieces put back to the JDK8 repositories.  We've spent a some time slicing things into manageable chunks. This is the first bunch. We'd like to time-box this review at one week, since there are many more pieces to follow.

The first chunk is the basic set of functional interface types.  While this set is not complete, it is enough to be able to proceed on some other pieces.  This set contains no extension methods (we'll do those separately) and does not contain all the specializations we may eventually need.

The specification is limited; most of the interesting restrictions (side-effect-freedom, idempotency, stability) would really be imposed not by the SAM itself by by how the SAM is used in a calculation. However, some common doc for "how to write good SAMs" that we can stick in the package doc would be helpful. Suggestions welcome.

Elements of this naming scheme include:
- Each SAM type has a unique (arity, method name) pair.  This allows SAMs to implement other SAMs without collision.
- The argument lists are structured so that specializations act on the first argument(s), so IntMapper<T> is a specialization of Mapper<R,T>, and IntBinaryOperator is a specialization of BinaryOperator<T>.

In order to get the most useful feedback out of this review, we'd like to ask you follow the following guidelines for the review:

- We are time-boxed at one week. (until Nov. 7th)

- Please review the whole bunch in a single message if possible, rather than in bits and pieces.  It is far easier to extract useful feedback from one complete review than from a dozen partial ones.

- Please wait a few days before replying to other people's reviews! We want to keep the discussion on-topic to maximize the useful review content.  It is far too easy for the discussion to spiral off into minutia and lose sight of the goal -- which is to provide useful feedback on the API we're asking for feedback on.

http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/


From chris.hegarty at oracle.com  Wed Oct 31 20:45:29 2012
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 31 Oct 2012 20:45:29 +0000
Subject: RFR: JDK-8001191: use -source 8 -target 8 when compiling the JDK
In-Reply-To: <5091635A.3010000@oracle.COM>
References: <5091635A.3010000@oracle.COM>
Message-ID: <FF142217-3BBC-490F-BF23-704DB8113742@oracle.com>

Looks fine Kumar.

-Chris

On 31 Oct 2012, at 17:43, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:

> Hello,
> 
> Please review changes to rev up the default -source and -target for jdk compilation,
> thus producing v52.0 class files.
> 
> Bug is here:
> https://jbs.oracle.com/bugs/browse/JDK-8001191
> 
> Webrev is here:
> http://cr.openjdk.java.net/~ksrini/8001191/webrev.0/
> 
> Note: this webrev is generated against the master repository but changes will be
> pushed via tl  after the tl-master sync is completed.
> 
> Thanks
> Kumar
> 


From jonathan.gibbons at oracle.com  Wed Oct 31 20:49:00 2012
From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com)
Date: Wed, 31 Oct 2012 20:49:00 +0000
Subject: hg: jdk8/tl/langtools: 8001664: refactor javadoc to use abstraction
	to handle files
Message-ID: <20121031204905.65366476CF@hg.openjdk.java.net>

Changeset: b980e8e6aabf
Author:    jjg
Date:      2012-10-31 13:48 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b980e8e6aabf

8001664: refactor javadoc to use abstraction to handle files
Reviewed-by: darcy

! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java
! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java
! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java
! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java
+ src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java
- src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java
! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java
! test/com/sun/javadoc/testDocFileDir/TestDocFileDir.java



From robert.field at oracle.com  Fri Oct 26 00:35:09 2012
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Fri, 26 Oct 2012 00:35:09 -0000
Subject: hg: jdk8/tl/jdk: 8000806: Implement runtime lambda metafactory
Message-ID: <20121026003504.1750D4755C@hg.openjdk.java.net>

Changeset: 6302932b7380
Author:    rfield
Date:      2012-10-25 17:34 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6302932b7380

8000806: Implement runtime lambda metafactory
Summary: Implement lambda invokedynamic bootstrap by generating at runtime an inner class that implements the functional interface
Reviewed-by: twisti

+ src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
+ src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
+ src/share/classes/java/lang/invoke/LambdaConversionException.java
+ src/share/classes/java/lang/invoke/LambdaMetafactory.java
+ src/share/classes/java/lang/invoke/MagicLambdaImpl.java
+ src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java



From tomlu235 at gmail.com  Fri Oct 26 09:02:42 2012
From: tomlu235 at gmail.com (Thomas L)
Date: Fri, 26 Oct 2012 09:02:42 -0000
Subject: What happened to System/Process.getPid() ?
Message-ID: <CAMjZ7tjyFq+YFKGkswW_JcbVzZJyYtRU8qzHdvjF1pLsze0R3Q@mail.gmail.com>

I'm sorry if I missed this, but I can't seem to find any information about
what happened to the RFE "provide process ID" [1]. This umbrella bug
report/RFE is marked as 'fixed', but I can't see that the "getPid" part is
included in the current build of JDK8 (build 62).

The "process destroy/getPid" RFE was previously listed under JDK8 features,
but now it's gone.[2]

And I can't find any information about "getPid()" being dropped from JDK8
either.

In his review request for the "System.killProcess" part of this RFE, Rob
McKenna wrote:

"As per the bug report the toString/pid work has been left to be
completed separately."[3]

What happened to "System/Process.getPid()" ? Is anyone actively working on
adding this to JDK8 ?

[1]. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4244896
[2]. http://openjdk.java.net/projects/jdk8/features
[3].
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/009816.html

Thanks
Thomas


From robert.field at oracle.com  Mon Oct 29 17:40:32 2012
From: robert.field at oracle.com (robert.field at oracle.com)
Date: Mon, 29 Oct 2012 17:40:32 -0000
Subject: hg: jdk8/tl/langtools: 8000694: Add generation of lambda
	implementation code: invokedynamic call, lambda method,
	adaptor methods
Message-ID: <20121029174026.863944764F@hg.openjdk.java.net>

Changeset: a65971893c50
Author:    rfield
Date:      2012-10-29 10:39 -0700
URL:       http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a65971893c50

8000694: Add generation of lambda implementation code: invokedynamic call, lambda method, adaptor methods
Summary: Add lambda implementation code with calling/supporting code elsewhere in the compiler
Reviewed-by: mcimadamore, jjg

! src/share/classes/com/sun/tools/javac/code/Symtab.java
+ src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/share/classes/com/sun/tools/javac/util/Names.java