From amaembo at gmail.com Sat Aug 1 04:36:05 2015 From: amaembo at gmail.com (Tagir Valeev) Date: Sat, 1 Aug 2015 10:36:05 +0600 Subject: RFR(s): 8132800: clarify stream package documentation regarding sequential vs parallel modes In-Reply-To: <55BBE66D.2060009@oracle.com> References: <55BBE66D.2060009@oracle.com> Message-ID: Hello! Probably additional clarifications should be added about Stream.concat method (and primitive analogs). Currently it's unclear that the resulting stream is actually the new pipeline, which do not propagate parallel status to the concatenated streams. See also my StackOverflow question: http://stackoverflow.com/q/30464397/4856258 Also things become more complex in JDK9 with the introduction of takeWhile/dropWhile. For JDK Stream implementation these two are normal intermediate operations, but if it happens that user has his own stream implementation or delegate to JDK stream, then the default takeWhile/dropWhile implementation is used which is actually starts new pipeline at given point, so further changes of parallel/sequential mode are not propagated to the initial pipeline. In my StreamEx library I call such operations as "quasi-intermediate", and explicitly clarify this point. See the JavaDoc: http://amaembo.github.io/streamex/javadoc/javax/util/streamex/package-summary.html#StreamOps Probably some clarification should be added to @implSpec section of takeWhile/dropWhile. With best regards, Tagir Valeev. On Sat, Aug 1, 2015 at 3:19 AM, Stuart Marks wrote: > Hi all, > > The sequential() and parallel() methods on a stream set the execution mode > for the entire pipeline. Unfortunately this isn't particularly clear from > the documentation. This has been a recurring question. Please review this > change to the java.util.stream package documentation to help clarify this > point. > > I've also added a couple anchor tags that were missing from various > sections. > > This is intended to be a purely editorial change, not a specification > change. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8132800 > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8132800/webrev.0/ > > Thanks, > > s'marks > From aph at redhat.com Sat Aug 1 08:57:22 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 01 Aug 2015 09:57:22 +0100 Subject: Replacement for sun.misc.Unsafe.allocateInstance(Class) ? In-Reply-To: References: Message-ID: <55BC89F2.8080904@redhat.com> On 31/07/15 18:33, J?rg Schaible wrote: > there's a lot of talk about making sun.misc.Unsafe unaccessible in JDK 9 ... > however, there seems no replacement for the allocateInstance method. > > XStream is relying heavily on this functionality and without it the library > will no longer be able to deserialize a lot of objects from XML. What are > the long-term options? In the long term we're going to need a more official way for non-core serialization to create uninitialized objects. I suspect it's more likely to look like sun.reflect.ReflectionFactory than Unsafe.allocateInstance. However, the security problems are great. I haven't heard any suggestion about how to expose this feature to user-created libraries without breaking Java security, and I suspect there may be none. Andrew. From fweimer at redhat.com Sat Aug 1 22:38:33 2015 From: fweimer at redhat.com (Florian Weimer) Date: Sun, 2 Aug 2015 00:38:33 +0200 Subject: Replacement for sun.misc.Unsafe.allocateInstance(Class) ? In-Reply-To: <55BC89F2.8080904@redhat.com> References: <55BC89F2.8080904@redhat.com> Message-ID: <55BD4A69.6080900@redhat.com> On 08/01/2015 10:57 AM, Andrew Haley wrote: > However, the security problems are great. I haven't heard any > suggestion about how to expose this feature to user-created libraries > without breaking Java security, and I suspect there may be none. Are the problems greater than those of general reflection after setAccessible(true)? I don't think so. I think the main objection would be philosophical (against adding yet more trapdoors). I respect that?but at the same time, there does not seem to be a core technical requirement why a suitable API with a proper permission check could not be added to the JDK. -- Florian Weimer / Red Hat Product Security From david.holmes at oracle.com Sun Aug 2 02:16:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Sun, 2 Aug 2015 12:16:23 +1000 Subject: Replacement for sun.misc.Unsafe.allocateInstance(Class) ? In-Reply-To: References: Message-ID: <55BD7D77.1090309@oracle.com> On 1/08/2015 3:33 AM, J?rg Schaible wrote: > Hello guys, > > there's a lot of talk about making sun.misc.Unsafe unaccessible in JDK 9 ... > however, there seems no replacement for the allocateInstance method. > > XStream is relying heavily on this functionality and without it the library > will no longer be able to deserialize a lot of objects from XML. What are > the long-term options? See: http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002342.html for existing discussion. David > Cheers, > j?rg > From aph at redhat.com Sun Aug 2 10:20:48 2015 From: aph at redhat.com (Andrew Haley) Date: Sun, 02 Aug 2015 11:20:48 +0100 Subject: Replacement for sun.misc.Unsafe.allocateInstance(Class) ? In-Reply-To: <55BD4A69.6080900@redhat.com> References: <55BC89F2.8080904@redhat.com> <55BD4A69.6080900@redhat.com> Message-ID: <55BDEF00.4030106@redhat.com> On 01/08/15 23:38, Florian Weimer wrote: > On 08/01/2015 10:57 AM, Andrew Haley wrote: > >> However, the security problems are great. I haven't heard any >> suggestion about how to expose this feature to user-created libraries >> without breaking Java security, and I suspect there may be none. > > Are the problems greater than those of general reflection after > setAccessible(true)? No. Either blows a huge hole on the usual guarantees. > I don't think so. I think the main objection would be philosophical > (against adding yet more trapdoors). "philosophical" doesn't mean "unimportant" or "fussy", though: it goes to the very core of the way that Java is used and is intended to be used. > I respect that?but at the same > time, there does not seem to be a core technical requirement why a > suitable API with a proper permission check could not be added to > the JDK. We have ReflectionFactory already, and I suppose as long as there are security checks there's no strong security-related reason not to move that class into, say, java.lang.reflect. Having said that, there are real problems where parts of the VM "know" something about the structure of an object. For example, String instances always have a char[] attached, and HotSpot makes use of that fact. Violating such invariants may cause the VM to crash. I don't know that a list of such invariants exists. Perhaps that's not exactly a security worry, but it's surely a problem. Andrew. From michael.haupt at oracle.com Sun Aug 2 14:31:04 2015 From: michael.haupt at oracle.com (Michael Haupt) Date: Sun, 2 Aug 2015 16:31:04 +0200 Subject: [9] RFR: 8060717: [TESTBUG] Improve test coverage of MethodHandles.explicitCastArguments() In-Reply-To: <55BBA449.1030603@oracle.com> References: <55BBA449.1030603@oracle.com> Message-ID: <0B7B1F71-0BE3-400E-A6C2-5FD01E13777A@oracle.com> Hi Konstantin, > Am 31.07.2015 um 18:37 schrieb Konstantin Shefov : > Please review a test improvement. Covered more cases for MethodHandles.explicitCastArguments(). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8060717 > Webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.00/ note that mine is a lower-case review and does not count, but: thumbs up. The level of detail at which the API is tested improves significantly with these changes. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment From joe.darcy at oracle.com Mon Aug 3 03:19:57 2015 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 2 Aug 2015 20:19:57 -0700 Subject: JDK 9 RFR of JDK-8132854: Adjust tier 1 and 2 definitions for nio-related intrinsics Message-ID: <55BEDDDD.6040104@oracle.com> Hello, With the fix for JDK-8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics the sources for the libraries clearly indicate which methods might have intrinsic support in HotSpot, that is, which methods might have their Java source implementation replaced by some other code sequence maintained in HotSpot, such as a special-purpose processor-specific instruction. To ease testing, it would be help if all the intrinsified methods were included in the tier 1 test group. Most of the intrinics are in java.lang, java.math, and java.util, packages whose tests are already in tier 1. Two nio-related classes are marked with @HotSpotIntrinsicCandidate: ./java.base/share/classes/sun/nio/cs/ISO_8859_1.java # implEncodeISOArray marked ./java.base/share/classes/java/nio/Buffer.java # index check Therefore, I propose moving the tests that directly cover those areas to tier 1: --- a/test/TEST.groups Mon Aug 03 09:25:02 2015 +0800 +++ b/test/TEST.groups Sun Aug 02 20:16:00 2015 -0700 @@ -28,11 +28,15 @@ tier1 = \ :jdk_lang \ :jdk_util \ + sun/nio/cs/ISO8859x.java \ + java/nio/Buffer \ :jdk_math tier2 = \ :jdk_io \ :jdk_nio \ + -sun/nio/cs/ISO8859x.java \ + -java/nio/Buffer \ :jdk_net \ :jdk_time \ :jdk_security \ Full webrev at http://cr.openjdk.java.net/~darcy/8132854.0/ Thanks, -Joe From alexander.v.stepanov at oracle.com Mon Aug 3 09:31:07 2015 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Mon, 03 Aug 2015 12:31:07 +0300 Subject: RFR [9] 8132468: docs: replace tags (obsolete in html5) for java.io, java.lang, java.math Message-ID: <55BF34DB.8090106@oracle.com> Hello, Could you please review the following fix: http://cr.openjdk.java.net/~avstepan/8132468/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8132468 Just some cleanup for docs (replacing obsolete ""). Thanks, Alexander From alexander.v.stepanov at oracle.com Mon Aug 3 09:43:10 2015 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Mon, 03 Aug 2015 12:43:10 +0300 Subject: RFR [9] 8132877: docs: replace tags (obsolete in html5) for java.naming Message-ID: <55BF37AE.4080107@oracle.com> Hello, Could you please review the following fix: http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8132877 Just some cleanup for docs (replacing obsolete ""). Thanks, Alexander From daniel.fuchs at oracle.com Mon Aug 3 12:17:27 2015 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 03 Aug 2015 14:17:27 +0200 Subject: RFR [9] 8132468: docs: replace tags (obsolete in html5) for java.io, java.lang, java.math In-Reply-To: <55BF34DB.8090106@oracle.com> References: <55BF34DB.8090106@oracle.com> Message-ID: <55BF5BD7.30101@oracle.com> On 03/08/15 11:31, Alexander Stepanov wrote: > Hello, > > Could you please review the following fix: > http://cr.openjdk.java.net/~avstepan/8132468/webrev.00/ > for > https://bugs.openjdk.java.net/browse/JDK-8132468 > > Just some cleanup for docs (replacing obsolete ""). > > Thanks, > Alexander Hi Alexander, mostly looks good to me - with afew remarks though. In some files, such as src/java.base/share/classes/java/io/Console.java and src/java.base/share/classes/java/lang/ClassLoader.java (possibly others) - you're using formatting like: + * {@link #readLine}. The is not needed around {@link } - as that should be the default formatting for {@link } (we use {@linkplain } when we don't want the code formatting for @link). src/java.base/share/classes/java/io/File.java + *
+ * new File( f.{@link + * #toURI() toURI}()).equals( f.{@link + * #getAbsoluteFile() getAbsoluteFile}()) + *
Would that be easier to read as: *
{@code new File(f.}{@link * #toURI() toURI()}{@code .equals(f.}{@link * #getAbsoluteFile() getAbsoluteFile()}{@code )} *
(not sure why the original text has hard spaces   - as we usually don't put any space after an open parenthesis) Same remark for this a few lines below: + *
+ * new {@link #File(java.net.URI) File}( f{@code + * .toURI()).equals(} f.{@link #getAbsoluteFile() getAbsoluteFile}()) + *
I mean - I don't particularly object but if the goal is to replace and everywhere - then why not go the full way down? The other question is whether 
 would be a better fit than

.


Otherwise looks good!

-- daniel


From alexander.v.stepanov at oracle.com  Mon Aug  3 12:40:25 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Mon, 03 Aug 2015 15:40:25 +0300
Subject: RFR [9] 8132468: docs: replace  tags (obsolete in html5)
	for java.io, java.lang, java.math
In-Reply-To: <55BF5BD7.30101@oracle.com>
References: <55BF34DB.8090106@oracle.com> <55BF5BD7.30101@oracle.com>
Message-ID: <55BF6139.9020805@oracle.com>

Hello Daniel,

Thank you for the notes;

 > The  is not needed around {@link } - as that should be 
the default formatting for {@link }
Sorry, didn't know; I have to fix that.

 > Would that be easier to read as:
Yes, probably that's better. Some old-style  tags were 
saved just because of some extra code formatting (like italic letters, 
 or  tags etc.) inside of them (which should be displayed 
literally in case of {@code })

 > if the goal is to replace  and  everywhere
Sorry, I didn't replace *all* of , just some of them. The 
main intention was to replace just  (as the tag is deprecated 
for HTML5, in contrast to the ). So the touched packages (and even 
files) still have a lot of  tags.

Thanks,
Alexander

On 8/3/2015 3:17 PM, Daniel Fuchs wrote:
> On 03/08/15 11:31, Alexander Stepanov wrote:
>> Hello,
>>
>> Could you please review the following fix:
>> http://cr.openjdk.java.net/~avstepan/8132468/webrev.00/
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8132468
>>
>> Just some cleanup for docs (replacing obsolete "").
>>
>> Thanks,
>> Alexander
>
> Hi Alexander,
>
> mostly looks good to me - with afew remarks though.
>
> In some files, such as
> src/java.base/share/classes/java/io/Console.java and
> src/java.base/share/classes/java/lang/ClassLoader.java
> (possibly others) - you're using formatting like:
>
> +    * {@link #readLine}.
>
> The  is not needed around {@link } - as that should be
> the default formatting for {@link } (we use {@linkplain } when we
> don't want the code formatting for @link).
>
>
> src/java.base/share/classes/java/io/File.java
>
> +     * 

> +     * new File( f.{@link
> +     * #toURI() toURI}()).equals( f.{@link
> +     * #getAbsoluteFile() getAbsoluteFile}())
> +     * 

>
> Would that be easier to read as:
>
>      * 
{@code new File(f.}{@link
>      * #toURI() toURI()}{@code .equals(f.}{@link
>      * #getAbsoluteFile() getAbsoluteFile()}{@code )}
>      * 

>
> (not sure why the original text has hard spaces   - as
>  we usually don't put any space after an open parenthesis)
>
> Same remark for this a few lines below:
>
> +     * 

> +     * new {@link #File(java.net.URI) File}( f{@code
> +     * .toURI()).equals(} f.{@link 
> #getAbsoluteFile() getAbsoluteFile}())
> +     * 

>
> I mean - I don't particularly object but if the goal is to replace
>  and  everywhere - then why not go the full
> way down?
>
> The other question is whether 
 would be a better fit than
> 
.
>
>
> Otherwise looks good!
>
> -- daniel



From lance.andersen at oracle.com  Mon Aug  3 12:53:03 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 3 Aug 2015 08:53:03 -0400
Subject: RFR [9] 8132877: docs: replace  tags (obsolete in html5) for
	java.naming
In-Reply-To: <55BF37AE.4080107@oracle.com>
References: <55BF37AE.4080107@oracle.com>
Message-ID: <02F25F91-0789-4C12-A132-D58B0B12201F@oracle.com>

I think this looks ok also. 

I agree with Daniel that we have additional clean-up opportunities  throughout we can do to the javadocs, but keeping each change set  more narrow helps reduce the chance of  introducing additional errors

Best
Lance
On Aug 3, 2015, at 5:43 AM, Alexander Stepanov  wrote:

> http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/



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 alexander.v.stepanov at oracle.com  Mon Aug  3 12:57:55 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Mon, 03 Aug 2015 15:57:55 +0300
Subject: RFR [9] 8132877: docs: replace  tags (obsolete in html5)
	for java.naming
In-Reply-To: <02F25F91-0789-4C12-A132-D58B0B12201F@oracle.com>
References: <55BF37AE.4080107@oracle.com>
	<02F25F91-0789-4C12-A132-D58B0B12201F@oracle.com>
Message-ID: <55BF6553.3070905@oracle.com>

Thanks!

On 8/3/2015 3:53 PM, Lance Andersen wrote:
> I think this looks ok also.
>
> I agree with Daniel that we have additional clean-up opportunities 
>  throughout we can do to the javadocs, but keeping each change set 
>  more narrow helps reduce the chance of  introducing additional errors
>
> Best
> Lance
> On Aug 3, 2015, at 5:43 AM, Alexander Stepanov 
>  > wrote:
>
>> http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/ 
>> 
>
> 
> 
> 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 alexander.v.stepanov at oracle.com  Mon Aug  3 13:01:47 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Mon, 03 Aug 2015 16:01:47 +0300
Subject: RFR [9] 8132877: docs: replace  tags (obsolete in html5)
	for java.naming
In-Reply-To: <55BF6553.3070905@oracle.com>
References: <55BF37AE.4080107@oracle.com>
	<02F25F91-0789-4C12-A132-D58B0B12201F@oracle.com>
	<55BF6553.3070905@oracle.com>
Message-ID: <55BF663B.4090503@oracle.com>

P.S. I have also to replace {@link ...} with just {@link 
...} in a couple of places here (as in the previous RFR 8132468...)

Regards,
Alexander

On 8/3/2015 3:57 PM, Alexander Stepanov wrote:
> Thanks!
>
> On 8/3/2015 3:53 PM, Lance Andersen wrote:
>> I think this looks ok also.
>>
>> I agree with Daniel that we have additional clean-up opportunities 
>>  throughout we can do to the javadocs, but keeping each change set 
>>  more narrow helps reduce the chance of  introducing additional errors
>>
>> Best
>> Lance
>> On Aug 3, 2015, at 5:43 AM, Alexander Stepanov 
>> > > wrote:
>>
>>> http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/ 
>>> 
>>
>> 
>> 
>> 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 alexander.v.stepanov at oracle.com  Mon Aug  3 15:07:02 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Mon, 03 Aug 2015 18:07:02 +0300
Subject: RFR [9] 8132468: docs: replace  tags (obsolete in html5)
	for java.io, java.lang, java.math
In-Reply-To: <55BF6139.9020805@oracle.com>
References: <55BF34DB.8090106@oracle.com> <55BF5BD7.30101@oracle.com>
	<55BF6139.9020805@oracle.com>
Message-ID: <55BF8396.4090109@oracle.com>

Please see the updated webrev:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/

removed wrapping  around the links (mostly 
PrintStream.java, PrintWriter.java, File.java), plus other changes in 
File.java

Thanks,
Alexander

On 8/3/2015 3:40 PM, Alexander Stepanov wrote:
> Hello Daniel,
>
> Thank you for the notes;
>
> > The  is not needed around {@link } - as that should be 
> the default formatting for {@link }
> Sorry, didn't know; I have to fix that.
>
> > Would that be easier to read as:
> Yes, probably that's better. Some old-style  tags were 
> saved just because of some extra code formatting (like italic letters, 
>  or  tags etc.) inside of them (which should be displayed 
> literally in case of {@code })
>
> > if the goal is to replace  and  everywhere
> Sorry, I didn't replace *all* of , just some of them. The 
> main intention was to replace just  (as the tag is deprecated 
> for HTML5, in contrast to the ). So the touched packages (and 
> even files) still have a lot of  tags.
>
> Thanks,
> Alexander
>
> On 8/3/2015 3:17 PM, Daniel Fuchs wrote:
>> On 03/08/15 11:31, Alexander Stepanov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix:
>>> http://cr.openjdk.java.net/~avstepan/8132468/webrev.00/
>>> for
>>> https://bugs.openjdk.java.net/browse/JDK-8132468
>>>
>>> Just some cleanup for docs (replacing obsolete "").
>>>
>>> Thanks,
>>> Alexander
>>
>> Hi Alexander,
>>
>> mostly looks good to me - with afew remarks though.
>>
>> In some files, such as
>> src/java.base/share/classes/java/io/Console.java and
>> src/java.base/share/classes/java/lang/ClassLoader.java
>> (possibly others) - you're using formatting like:
>>
>> +    * {@link #readLine}.
>>
>> The  is not needed around {@link } - as that should be
>> the default formatting for {@link } (we use {@linkplain } when we
>> don't want the code formatting for @link).
>>
>>
>> src/java.base/share/classes/java/io/File.java
>>
>> +     * 

>> +     * new File( f.{@link
>> +     * #toURI() toURI}()).equals( f.{@link
>> +     * #getAbsoluteFile() getAbsoluteFile}())
>> +     * 

>>
>> Would that be easier to read as:
>>
>>      * 
{@code new File(f.}{@link
>>      * #toURI() toURI()}{@code .equals(f.}{@link
>>      * #getAbsoluteFile() getAbsoluteFile()}{@code )}
>>      * 

>>
>> (not sure why the original text has hard spaces   - as
>>  we usually don't put any space after an open parenthesis)
>>
>> Same remark for this a few lines below:
>>
>> +     * 

>> +     * new {@link #File(java.net.URI) File}( f{@code
>> +     * .toURI()).equals(} f.{@link 
>> #getAbsoluteFile() getAbsoluteFile}())
>> +     * 

>>
>> I mean - I don't particularly object but if the goal is to replace
>>  and  everywhere - then why not go the full
>> way down?
>>
>> The other question is whether 
 would be a better fit than
>> 
.
>>
>>
>> Otherwise looks good!
>>
>> -- daniel
>



From konstantin.shefov at oracle.com  Mon Aug  3 15:06:53 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Mon, 03 Aug 2015 18:06:53 +0300
Subject: [9] RFR: 8060717: [TESTBUG] Improve test coverage of
	MethodHandles.explicitCastArguments()
In-Reply-To: <0B7B1F71-0BE3-400E-A6C2-5FD01E13777A@oracle.com>
References: <55BBA449.1030603@oracle.com>
	<0B7B1F71-0BE3-400E-A6C2-5FD01E13777A@oracle.com>
Message-ID: <55BF838D.7080202@oracle.com>

Michael, thanks for reviewing!

Vladimir, could you take a look, please?

-Konstantin

On 08/02/2015 05:31 PM, Michael Haupt wrote:
> Hi Konstantin,
>
>> Am 31.07.2015 um 18:37 schrieb Konstantin Shefov 
>> >:
>> Please review a test improvement. Covered more cases for 
>> MethodHandles.explicitCastArguments().
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060717
>> Webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.00/ 
>> 
>
> note that mine is a lower-case review and does not count, but: thumbs 
> up. The level of detail at which the API is tested improves 
> significantly with these changes.
>
> Best,
>
> Michael
>
> -- 
>
> Oracle 
> Dr. Michael Haupt | Principal Member of Technical Staff
> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
> OracleJava Platform Group | LangTools Team | Nashorn
> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, 
> Germany
> Green Oracle  	Oracle is committed 
> to developing practices and products that help protect the environment
>
>



From pavel.rappo at oracle.com  Mon Aug  3 15:33:45 2015
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 3 Aug 2015 16:33:45 +0100
Subject: RFR [9] 8132468: docs: replace  tags (obsolete in html5) for
	java.io, java.lang, java.math
In-Reply-To: <55BF8396.4090109@oracle.com>
References: <55BF34DB.8090106@oracle.com> <55BF5BD7.30101@oracle.com>
	<55BF6139.9020805@oracle.com> <55BF8396.4090109@oracle.com>
Message-ID: <84C4434E-679A-48C4-B507-AC266BEC64F4@oracle.com>

> 
> On 3 Aug 2015, at 16:07, Alexander Stepanov  wrote:
> 
> Please see the updated webrev:
> http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/
> 
> removed wrapping  around the links (mostly PrintStream.java, PrintWriter.java, File.java), plus other changes in File.java
> 
> Thanks,
> Alexander

Hi Alexander, if I were you I would run specdiff against the changes and
upload it along with the RFR.

P.S. "I've tried it once, it was awful." [1] It's very easy to go the all the
way and lose oneself in there :)

------------------------------------------------------------------------------
[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030262.html

-Pavel



From alexander.v.stepanov at oracle.com  Mon Aug  3 15:39:38 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Mon, 03 Aug 2015 18:39:38 +0300
Subject: RFR [9] 8132877: docs: replace  tags (obsolete in html5)
	for java.naming
In-Reply-To: <55BF663B.4090503@oracle.com>
References: <55BF37AE.4080107@oracle.com>	<02F25F91-0789-4C12-A132-D58B0B12201F@oracle.com>	<55BF6553.3070905@oracle.com>
	<55BF663B.4090503@oracle.com>
Message-ID: <55BF8B3A.6010505@oracle.com>

just in case, the updated webrev: 
http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html

On 8/3/2015 4:01 PM, Alexander Stepanov wrote:
> P.S. I have also to replace {@link ...} with just {@link 
> ...} in a couple of places here (as in the previous RFR 8132468...)
>
> Regards,
> Alexander
>
> On 8/3/2015 3:57 PM, Alexander Stepanov wrote:
>> Thanks!
>>
>> On 8/3/2015 3:53 PM, Lance Andersen wrote:
>>> I think this looks ok also.
>>>
>>> I agree with Daniel that we have additional clean-up opportunities 
>>>  throughout we can do to the javadocs, but keeping each change set 
>>>  more narrow helps reduce the chance of  introducing additional errors
>>>
>>> Best
>>> Lance
>>> On Aug 3, 2015, at 5:43 AM, Alexander Stepanov 
>>> >> > wrote:
>>>
>>>> http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/ 
>>>> 
>>>
>>> 
>>>  
>>>
>>> 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 alexander.v.stepanov at oracle.com  Mon Aug  3 16:03:42 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Mon, 03 Aug 2015 19:03:42 +0300
Subject: RFR [9] 8132468: docs: replace  tags (obsolete in html5)
	for java.io, java.lang, java.math
In-Reply-To: <84C4434E-679A-48C4-B507-AC266BEC64F4@oracle.com>
References: <55BF34DB.8090106@oracle.com> <55BF5BD7.30101@oracle.com>
	<55BF6139.9020805@oracle.com> <55BF8396.4090109@oracle.com>
	<84C4434E-679A-48C4-B507-AC266BEC64F4@oracle.com>
Message-ID: <55BF90DE.1000202@oracle.com>

Hello Pavel

 > Hi Alexander, if I were you I would run specdiff
Thanks; but sorry, I'm afraid I haven't enough time for the extra 
experiments just now...

 > It's very easy to go the all the way and lose oneself in there :)
please accept my condolences :)

Regards,
Alexander

On 8/3/2015 6:33 PM, Pavel Rappo wrote:
>> On 3 Aug 2015, at 16:07, Alexander Stepanov  wrote:
>>
>> Please see the updated webrev:
>> http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/
>>
>> removed wrapping  around the links (mostly PrintStream.java, PrintWriter.java, File.java), plus other changes in File.java
>>
>> Thanks,
>> Alexander
> Hi Alexander, if I were you I would run specdiff against the changes and
> upload it along with the RFR.
>
> P.S. "I've tried it once, it was awful." [1] It's very easy to go the all the
> way and lose oneself in there :)
>
> ------------------------------------------------------------------------------
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030262.html
>
> -Pavel
>



From martinrb at google.com  Mon Aug  3 17:02:03 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 3 Aug 2015 10:02:03 -0700
Subject: RFR [9] 8132877: docs: replace  tags (obsolete in html5) for
	java.naming
In-Reply-To: <55BF37AE.4080107@oracle.com>
References: <55BF37AE.4080107@oracle.com>
Message-ID: 

I'm surprised  is going away.  Do you have a reference that explains
the new jdk9 javadoc standards?

On Mon, Aug 3, 2015 at 2:43 AM, Alexander Stepanov <
alexander.v.stepanov at oracle.com> wrote:

> Hello,
>
> Could you please review the following fix:
> http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/
> for
> https://bugs.openjdk.java.net/browse/JDK-8132877
>
> Just some cleanup for docs (replacing obsolete "").
>
> Thanks,
> Alexander
>


From alexander.v.stepanov at oracle.com  Mon Aug  3 17:21:28 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Mon, 03 Aug 2015 20:21:28 +0300
Subject: RFR [9] 8132877: docs: replace  tags (obsolete in html5)
	for java.naming
In-Reply-To: 
References: <55BF37AE.4080107@oracle.com>
	
Message-ID: <55BFA318.10009@oracle.com>

Sorry, at the moment I can say only that   is deprecated in HTML5:
http://www.html-5.com/changes/deprecated/

"Here is a list of deprecated HTML tags to avoid using" - that's was the 
main motivation.

As I know, in future(?) the documentation should be HTML5-compliant: 
http://openjdk.java.net/jeps/224 (but it is outside of my competence, 
sorry).

Regards,
Alexander

On 8/3/2015 8:02 PM, Martin Buchholz wrote:
> I'm surprised  is going away.  Do you have a reference that 
> explains the new jdk9 javadoc standards?
>
> On Mon, Aug 3, 2015 at 2:43 AM, Alexander Stepanov 
>  > wrote:
>
>     Hello,
>
>     Could you please review the following fix:
>     http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/
>     
>     for
>     https://bugs.openjdk.java.net/browse/JDK-8132877
>
>     Just some cleanup for docs (replacing obsolete "").
>
>     Thanks,
>     Alexander
>
>



From martinrb at google.com  Mon Aug  3 18:26:02 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 3 Aug 2015 11:26:02 -0700
Subject: RFR [9] 8132877: docs: replace  tags (obsolete in html5) for
	java.naming
In-Reply-To: <55BFA318.10009@oracle.com>
References: <55BF37AE.4080107@oracle.com>
	
	<55BFA318.10009@oracle.com>
Message-ID: 

Bhavesh, it would be good if jep 224 said what to do with the many legacy
 tags.  Best practice seems to be to convert to {@code ...} if possible
and appropriate, else to , , or , as given by
http://www.w3schools.com/tags/tag_code.asp

On Mon, Aug 3, 2015 at 10:21 AM, Alexander Stepanov <
alexander.v.stepanov at oracle.com> wrote:

> Sorry, at the moment I can say only that   is deprecated in HTML5:
> http://www.html-5.com/changes/deprecated/
>
> "Here is a list of deprecated HTML tags to avoid using" - that's was the
> main motivation.
>
> As I know, in future(?) the documentation should be HTML5-compliant:
> http://openjdk.java.net/jeps/224 (but it is outside of my competence,
> sorry).
>


From brent.christian at oracle.com  Mon Aug  3 19:24:40 2015
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 03 Aug 2015 12:24:40 -0700
Subject: RFR: JDK-8062849 -- Optimize EnumMap.equals
In-Reply-To: <4DCE139D-0D61-4A88-AED8-F26C18B9A6D3@oracle.com>
References: <4DCE139D-0D61-4A88-AED8-F26C18B9A6D3@oracle.com>
Message-ID: <55BFBFF8.9060005@oracle.com>

Looks reasonable to me.
-Brent

On 7/28/15 9:14 AM, Steve Drach wrote:
> Please review the following simple fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8062849 .
>
> -----------------
> # HG changeset patch
> # User sdrach
> # Date 1437777193 25200
> #      Fri Jul 24 15:33:13 2015 -0700
> # Node ID e57b1569a65ec4dc8c749dedd3345abe5d493054
> # Parent  4dd09cb5f7c2a2a23a9958ea7a602dd74d5709b2
> 8062849: Optimize EnumMap.equals
> Summary: In the equals method, if the two EnumMaps are a different size return false since they can't be equal.
> Reviewed-by: brent.christian at oracle.com, paul.sandoz at oracle.com
> Contributed-by: steve.drach at oracle.com
>
> diff --git a/src/java.base/share/classes/java/util/EnumMap.java b/src/java.base/share/classes/java/util/EnumMap.java
> --- a/src/java.base/share/classes/java/util/EnumMap.java
> +++ b/src/java.base/share/classes/java/util/EnumMap.java
> @@ -681,8 +681,11 @@
>       }
>
>       private boolean equals(EnumMap em) {
> +        if (size != em.size)
> +            return false;
> +
>           if (em.keyType != keyType)
> -            return size == 0 && em.size == 0;
> +            return size == 0;
>
>           // Key types match, compare each value
>           for (int i = 0; i < keyUniverse.length; i++) {
>


From mark.reinhold at oracle.com  Mon Aug  3 19:27:45 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Mon,  3 Aug 2015 12:27:45 -0700 (PDT)
Subject: JEP 259: Stack-Walking API
Message-ID: <20150803192745.D98196CCD8@eggemoggin.niobe.net>

New JEP Candidate: http://openjdk.java.net/jeps/259

- Mark


From kim.barrett at oracle.com  Mon Aug  3 20:49:43 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 3 Aug 2015 16:49:43 -0400
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55BB76EE.2070306@gmail.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com> <55B9EA8A.1080102@oracle.com>
	<55B9FA54.5040902@gmail.com> <55B9FB50.8050907@oracle.com>
	<55B9FF5F.2020706@gmail.com> <55BA0E2B.9050101@oracle.com>
	<55BA110F.2010101@gmail.com> <55BA13E8.1050606@oracle.com>
	
	<55BA9830.8030308@oracle.com>
	
	<55BB76EE.2070306@gmail.com>
Message-ID: <92395C30-A636-437B-8D60-98A133C63768@oracle.com>

On Jul 31, 2015, at 9:23 AM, Peter Levart  wrote:
> 
> This looks good now. Thanks for taking both of the issues together. I wonder if a similar racy test could be devised for the 2nd race. I doubt the ReferenceEnqueue test was meant to catch invalid races specifically. It was more a coincidence that it failed.
> 
> I tried to create a reproducer for 2nd race, but it is not reliable and sometimes needs several minutes to fail.

I would expect it to be hard to reproduce without patching in a sleep to expand the window of vulnerability, as I did to test for the first race.




From kim.barrett at oracle.com  Mon Aug  3 20:59:58 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 3 Aug 2015 16:59:58 -0400
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: <55BADBFE.2000808@oracle.com>
References: 
	<55B88FAB.4080302@oracle.com>
	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>
	<55B9E293.80102@gmail.com> <55B9EA8A.1080102@oracle.com>
	<55B9FA54.5040902@gmail.com> <55B9FB50.8050907@oracle.com>
	<55B9FF5F.2020706@gmail.com> <55BA0E2B.9050101@oracle.com>
	<55BA110F.2010101@gmail.com> <55BA13E8.1050606@oracle.com>
	
	<55BA9830.8030308@oracle.com>
	
	<55BADBFE.2000808@oracle.com>
Message-ID: <71B8E573-0BA0-4AAB-A069-AD0B4556CFF3@oracle.com>

On Jul 30, 2015, at 10:22 PM, David Holmes  wrote:
> 
> Looks good!

On Jul 31, 2015, at 5:10 AM, Daniel Fuchs  wrote:
> Thanks for taking care of this one!
> 
> PS: you might want to add @bug 8132306 to
>    jdk/test/java/lang/ref/ReferenceEnqueue.java

Done.

On Jul 31, 2015, at 9:23 AM, Peter Levart  wrote:
> This looks good now. Thanks for taking both of the issues together.

Thanks for your reviews and all the discussion.

There might be a delay in pushing though; further testing produced an unexpected (and not (easily) reproducible) failure, which I?m studying to determine whether it might have anything to do with this change set.  I don?t think it does, and we?ve had some flaky infrastructure problems in the last few days, but I?m following due diligence.  I?ll either push or come back for more discussion.




From stuart.marks at oracle.com  Mon Aug  3 21:47:19 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 3 Aug 2015 14:47:19 -0700
Subject: RFR [9] 8132468: docs: replace  tags (obsolete in html5) for
	java.io, java.lang, java.math
In-Reply-To: <55BF90DE.1000202@oracle.com>
References: <55BF34DB.8090106@oracle.com> <55BF5BD7.30101@oracle.com>
	<55BF6139.9020805@oracle.com> <55BF8396.4090109@oracle.com>
	<84C4434E-679A-48C4-B507-AC266BEC64F4@oracle.com>
	<55BF90DE.1000202@oracle.com>
Message-ID: <55BFE167.6030606@oracle.com>

Hi Alexander,

I think Pavel's advice to run specdiff is useful. It's not too difficult to run 
and in this case it provides a useful cross-check for making a large number of 
markup changes. Contact me directly if you need help with specdiff. I've run 
specdiff over your webrev.01 and I've posted the results here:

http://cr.openjdk.java.net/~smarks/reviews/8132468/specdiff.01/overview-summary.html

They show that of all the changes you made, only four are considered significant 
from specdiff's point of view. Of these, two appear to be merely whitespace 
issues, but there are two changes that do appear significant:

     File(URI)     // constructor
     File.toURI()

In both cases the italic 'f' is intended to be a metasyntactic variable, not an 
actual variable that's part of the code. The italic 'f' should be restored. In 
the case of File.toURI() it appears that the resulting code is now malformed, so 
there's clearly an error here.

You and Daniel Fuchs had an exchange about this a bit earlier. I suspect the 
reason for the   that appears between the opening parenthesis and the 
italic 'f' is so that the tail of the 'f' doesn't crash into parenthesis. In 
other words, the   is there merely for typographical purposes. I suspect 
that after you restore the italic 'f' it'll look bad, so you'll want to restore 
the   as well.

s'marks

On 8/3/15 9:03 AM, Alexander Stepanov wrote:
> Hello Pavel
>
>  > Hi Alexander, if I were you I would run specdiff
> Thanks; but sorry, I'm afraid I haven't enough time for the extra experiments
> just now...
>
>  > It's very easy to go the all the way and lose oneself in there :)
> please accept my condolences :)
>
> Regards,
> Alexander
>
> On 8/3/2015 6:33 PM, Pavel Rappo wrote:
>>> On 3 Aug 2015, at 16:07, Alexander Stepanov 
>>> wrote:
>>>
>>> Please see the updated webrev:
>>> http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/
>>>
>>> removed wrapping  around the links (mostly PrintStream.java,
>>> PrintWriter.java, File.java), plus other changes in File.java
>>>
>>> Thanks,
>>> Alexander
>> Hi Alexander, if I were you I would run specdiff against the changes and
>> upload it along with the RFR.
>>
>> P.S. "I've tried it once, it was awful." [1] It's very easy to go the all the
>> way and lose oneself in there :)
>>
>> ------------------------------------------------------------------------------
>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030262.html
>>
>> -Pavel
>>
>


From joe.darcy at oracle.com  Mon Aug  3 22:43:17 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 03 Aug 2015 15:43:17 -0700
Subject: Chair voting to approve 8041565: JMX ObjectName could be refactored
	to save memory 
Message-ID: <55BFEE85.9090202@oracle.com>




From stuart.marks at oracle.com  Mon Aug  3 23:09:04 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 3 Aug 2015 16:09:04 -0700
Subject: RFR(s): 8132800: clarify stream package documentation regarding
	sequential vs parallel modes
In-Reply-To: 
References: <55BBE66D.2060009@oracle.com>
	
Message-ID: <55BFF490.4060009@oracle.com>

Hi Tagir,

Interesting issues.

Regarding Stream.concat, it may be that, today, changes to the 
sequential/parallel execution mode aren't propagated to the streams being 
concatenated. But is that something inherent to the specification of 
concatenation, or is it something that might change in the future? It's 
currently unspecified, so adding a clarification really sounds more like 
changing the specification to reflect the current implementation, which I'd 
prefer not to do.

Regarding the default implementations of takeWhile/dropWhile, again, today, they 
don't propagate the execution mode upstream. But is this just a bug? Granted the 
API for doing so isn't obvious, but isn't this something that could just be fixed?

s'marks

On 7/31/15 9:36 PM, Tagir Valeev wrote:
> Hello!
>
> Probably additional clarifications should be added about Stream.concat method 
> (and primitive analogs). Currently it's unclear that the resulting stream is 
> actually the new pipeline, which do not propagate parallel status to the 
> concatenated streams. See also my StackOverflow question:
> http://stackoverflow.com/q/30464397/4856258
>
> Also things become more complex in JDK9 with the introduction of 
> takeWhile/dropWhile. For JDK Stream implementation these two are normal 
> intermediate operations, but if it happens that user has his own stream 
> implementation or delegate to JDK stream, then the default takeWhile/dropWhile 
> implementation is used which is actually starts new pipeline at given point, 
> so further changes of parallel/sequential mode are not propagated to the 
> initial pipeline. In my StreamEx library I call such operations as 
> "quasi-intermediate", and explicitly clarify this point. See the JavaDoc:
> http://amaembo.github.io/streamex/javadoc/javax/util/streamex/package-summary.html#StreamOps
> Probably some clarification should be added to @implSpec section of 
> takeWhile/dropWhile.
>
> With best regards,
> Tagir Valeev.
>
> On Sat, Aug 1, 2015 at 3:19 AM, Stuart Marks  > wrote:
>
>     Hi all,
>
>     The sequential() and parallel() methods on a stream set the execution mode
>     for the entire pipeline. Unfortunately this isn't particularly clear from
>     the documentation. This has been a recurring question. Please review this
>     change to the java.util.stream package documentation to help clarify this
>     point.
>
>     I've also added a couple anchor tags that were missing from various sections.
>
>     This is intended to be a purely editorial change, not a specification change.
>
>     Bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-8132800
>
>     Webrev:
>
>     http://cr.openjdk.java.net/~smarks/reviews/8132800/webrev.0/
>     
>
>     Thanks,
>
>     s'marks
>
>



From amaembo at gmail.com  Tue Aug  4 04:37:14 2015
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 4 Aug 2015 10:37:14 +0600
Subject: RFR(s): 8132800: clarify stream package documentation regarding
	sequential vs parallel modes
In-Reply-To: <55BFF490.4060009@oracle.com>
References: <55BBE66D.2060009@oracle.com>
	
	<55BFF490.4060009@oracle.com>
Message-ID: 

Hello, Stuart!

On Tue, Aug 4, 2015 at 5:09 AM, Stuart Marks 
wrote:

> Regarding Stream.concat, it may be that, today, changes to the
> sequential/parallel execution mode aren't propagated to the streams being
> concatenated. But is that something inherent to the specification of
> concatenation, or is it something that might change in the future? It's
> currently unspecified, so adding a clarification really sounds more like
> changing the specification to reflect the current implementation, which I'd
> prefer not to do.
>

That's fine. In this case it's probably should be explicitly mentioned
something like "note that further change of the stream mode from parallel
to sequential and vice versa is *not guaranteed* to propagate to the source
streams". It would still be better than not speaking about this at all.


Regarding the default implementations of takeWhile/dropWhile, again, today,
> they don't propagate the execution mode upstream. But is this just a bug?
> Granted the API for doing so isn't obvious, but isn't this something that
> could just be fixed?
>

It would be nice if it can be fixed, but given the current API I see no
easy way to do this. Probably Paul can comment on this.

With best regards,
Tagir Valeev.


>
> s'marks
>
>
> On 7/31/15 9:36 PM, Tagir Valeev wrote:
>
> Hello!
>
> Probably additional clarifications should be added about Stream.concat
> method (and primitive analogs). Currently it's unclear that the resulting
> stream is actually the new pipeline, which do not propagate parallel status
> to the concatenated streams. See also my StackOverflow question:
> http://stackoverflow.com/q/30464397/4856258
>
> Also things become more complex in JDK9 with the introduction of
> takeWhile/dropWhile. For JDK Stream implementation these two are normal
> intermediate operations, but if it happens that user has his own stream
> implementation or delegate to JDK stream, then the default
> takeWhile/dropWhile implementation is used which is actually starts new
> pipeline at given point, so further changes of parallel/sequential mode are
> not propagated to the initial pipeline. In my StreamEx library I call such
> operations as "quasi-intermediate", and explicitly clarify this point. See
> the JavaDoc:
>
> http://amaembo.github.io/streamex/javadoc/javax/util/streamex/package-summary.html#StreamOps
> Probably some clarification should be added to @implSpec section of
> takeWhile/dropWhile.
>
> With best regards,
> Tagir Valeev.
>
> On Sat, Aug 1, 2015 at 3:19 AM, Stuart Marks 
> wrote:
>
>> Hi all,
>>
>> The sequential() and parallel() methods on a stream set the execution
>> mode for the entire pipeline. Unfortunately this isn't particularly clear
>> from the documentation. This has been a recurring question. Please review
>> this change to the java.util.stream package documentation to help clarify
>> this point.
>>
>> I've also added a couple anchor tags that were missing from various
>> sections.
>>
>> This is intended to be a purely editorial change, not a specification
>> change.
>>
>> Bug:
>>
>>         https://bugs.openjdk.java.net/browse/JDK-8132800
>>
>> Webrev:
>>
>>         http://cr.openjdk.java.net/~smarks/reviews/8132800/webrev.0/
>>
>> Thanks,
>>
>> s'marks
>>
>
>
>


From amaembo at gmail.com  Tue Aug  4 04:47:38 2015
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 4 Aug 2015 10:47:38 +0600
Subject: Spliterator documentation on Priority(Blocking)Queue
Message-ID: 

Hello!

The PriorityQueue class iterator() returns elements in no particular order.
This is explicitly stated in JavaDoc for iterator() method [1] as well as
in class description [2]. However it's not mentioned mentioned that
spliterator() method also traverses the queue in no particular order. Well,
the user might guess that the order is not specified, because the
spliterator does not have ORDERED characteristic, but it's not so obvious
for any user. Probably it's would be good to add an explicit note like it's
done for iterator. The same thing is for PriorityBlockingQueue. What do you
think?

With best regards,
Tagir Valeev.

[1]
http://hg.openjdk.java.net/jdk9/dev/jdk/file/022d45d94d0a/src/java.base/share/classes/java/util/PriorityQueue.java#l477
[2]
http://hg.openjdk.java.net/jdk9/dev/jdk/file/022d45d94d0a/src/java.base/share/classes/java/util/PriorityQueue.java#l54


From frank.yuan at oracle.com  Tue Aug  4 06:51:44 2015
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 4 Aug 2015 14:51:44 +0800
Subject: Review request for JDK-8132660: Change jaxp unit test package name to
	be different with jaxp api
Message-ID: <02d901d0ce82$08329f30$1897dd90$@oracle.com>

Hi, Joe and all

 

Would you like to have a review for bug
https://bugs.openjdk.java.net/browse/JDK-8132660?

 

This is already on our plan for a while, but I have to finish it now because
these unit tests failed with latest Jigsaw build. However I made the changes
based on 9-dev repo, I tested them with both Jigsaw build and 9-dev build.
The JPRT successful mail is enclosed in the bug.

 

The webrev is at: http://cr.openjdk.java.net/~fyuan/8132660/webrev.00/. It
seems to be a big change but actually there are only some directories
changed. 

 

 

Thanks,

 

Frank

 



From paul.sandoz at oracle.com  Tue Aug  4 07:20:12 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 4 Aug 2015 09:20:12 +0200
Subject: RFR(s): 8132800: clarify stream package documentation regarding
	sequential vs parallel modes
In-Reply-To: <55BFF490.4060009@oracle.com>
References: <55BBE66D.2060009@oracle.com>
	
	<55BFF490.4060009@oracle.com>
Message-ID: <27303ED2-9ACB-4533-BF15-72286FE2EDBD@oracle.com>


On 4 Aug 2015, at 01:09, Stuart Marks  wrote:

> Hi Tagir,
> 
> Interesting issues.
> 
> Regarding Stream.concat, it may be that, today, changes to the sequential/parallel execution mode aren't propagated to the streams being concatenated.

The execution mode is propagated if either stream to concat is parallel i.e. isParallel()

The issue here is that Stream.spltierator() is a form of terminal operation that will result in pipeline evaluation if there are non-lazy stateful operations present.

What we don?t currently do is propagate the parallelism back to a sequential stream when the other is a parallel stream. We could easily do that as a bug fix. I agree with Stuart it does not require any specification e.g.:

public static  Stream concat(Stream a, Stream b) {
    Objects.requireNonNull(a);
    Objects.requireNonNull(b);

    boolean isPar = a.isParallel() || b.isParallel();
    @SuppressWarnings("unchecked")
    Spliterator split = new Streams.ConcatSpliterator.OfRef<>(
            (Spliterator) (isPar ? a.parallel() : a).spliterator(),
            (Spliterator) (isPar ? b.parallel() : b).spliterator());
    Stream stream = StreamSupport.stream(split, isPar);
    return stream.onClose(Streams.composedClose(a, b));
}


> But is that something inherent to the specification of concatenation, or is it something that might change in the future? It's currently unspecified, so adding a clarification really sounds more like changing the specification to reflect the current implementation, which I'd prefer not to do.
> 
> Regarding the default implementations of takeWhile/dropWhile, again, today, they don't propagate the execution mode upstream. But is this just a bug? Granted the API for doing so isn't obvious, but isn't this something that could just be fixed?
> 

The default implementations are specified to propagate the execution mode in terms of correctly reporting isParallel() but may choose not to split:

* the wrapped spliterator.  The returned stream preserves the execution
* characteristics of this stream (namely parallel or sequential execution
* as per {@link #isParallel()}) but the wrapped spliterator may choose to
* not support splitting.  When the returned stream is closed, the close
* handlers for both the returned and this stream are invoked.

So this is a little different from the Stream.concat case.

The only way a default implementation can be implemented is to derive functionality from the upstream spliterator(). Rather than choosing to add yet more code to support this (and most likely poorly too) i opted for not splitting and reuse some existing code (the unordered spliterators that are configured not to split). Nor did i want to wrap the non-splitting spliterator around one which copies a prefix, which introduces a different set of poorly splitting characteristics (and would also penalise sequential operation). This is a tradeoff, and seems to me a reasonable compromise for a default.

Paul.



From paul.sandoz at oracle.com  Tue Aug  4 07:22:59 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 4 Aug 2015 09:22:59 +0200
Subject: RFR(s): 8132800: clarify stream package documentation regarding
	sequential vs parallel modes
In-Reply-To: <55BBE66D.2060009@oracle.com>
References: <55BBE66D.2060009@oracle.com>
Message-ID: <471C0B5E-3367-4B3E-8922-79E5117BE223@oracle.com>


On 31 Jul 2015, at 23:19, Stuart Marks  wrote:

> Hi all,
> 
> The sequential() and parallel() methods on a stream set the execution mode for the entire pipeline. Unfortunately this isn't particularly clear from the documentation. This has been a recurring question. Please review this change to the java.util.stream package documentation to help clarify this point.
> 
> I've also added a couple anchor tags that were missing from various sections.
> 

Looks ok.

Paul.

> This is intended to be a purely editorial change, not a specification change.
> 
> Bug:
> 
> 	https://bugs.openjdk.java.net/browse/JDK-8132800
> 
> Webrev:
> 
> 	http://cr.openjdk.java.net/~smarks/reviews/8132800/webrev.0/
> 
> Thanks,
> 
> s'marks



From paul.sandoz at oracle.com  Tue Aug  4 07:51:47 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 4 Aug 2015 09:51:47 +0200
Subject: RFR(s): 8132800: clarify stream package documentation regarding
	sequential vs parallel modes
In-Reply-To: <27303ED2-9ACB-4533-BF15-72286FE2EDBD@oracle.com>
References: <55BBE66D.2060009@oracle.com>
	
	<55BFF490.4060009@oracle.com>
	<27303ED2-9ACB-4533-BF15-72286FE2EDBD@oracle.com>
Message-ID: 


On 4 Aug 2015, at 09:20, Paul Sandoz  wrote:

> 
> On 4 Aug 2015, at 01:09, Stuart Marks  wrote:
> 
>> Hi Tagir,
>> 
>> Interesting issues.
>> 
>> Regarding Stream.concat, it may be that, today, changes to the sequential/parallel execution mode aren't propagated to the streams being concatenated.
> 
> The execution mode is propagated if either stream to concat is parallel i.e. isParallel()
> 
> The issue here is that Stream.spltierator() is a form of terminal operation that will result in pipeline evaluation if there are non-lazy stateful operations present.
> 
> What we don?t currently do is propagate the parallelism back to a sequential stream when the other is a parallel stream. We could easily do that as a bug fix. I agree with Stuart it does not require any specification e.g.:
> 
> public static  Stream concat(Stream a, Stream b) {
>    Objects.requireNonNull(a);
>    Objects.requireNonNull(b);
> 
>    boolean isPar = a.isParallel() || b.isParallel();
>    @SuppressWarnings("unchecked")
>    Spliterator split = new Streams.ConcatSpliterator.OfRef<>(
>            (Spliterator) (isPar ? a.parallel() : a).spliterator(),
>            (Spliterator) (isPar ? b.parallel() : b).spliterator());
>    Stream stream = StreamSupport.stream(split, isPar);
>    return stream.onClose(Streams.composedClose(a, b));
> }
> 

And on reflection this may not always be the right thing to do, there are surprises either way. I am leaning towards not doing this and Stream.concat should obey the mode of the stream that is passed to it in terms of each evaluation. Thereby it is explicit as per what the caller declared.

It?s probably too late to specify that, but we could and something to the @implNote stating the current implementation behaviour and add an @apiNote on guaranteeing parallel execution of the two streams to concat.

Paul.


From paul.sandoz at oracle.com  Tue Aug  4 07:56:38 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 4 Aug 2015 09:56:38 +0200
Subject: Spliterator documentation on Priority(Blocking)Queue
In-Reply-To: 
References: 
Message-ID: 

Hi Tagir,

Can you log an issue?

Thanks,
Paul.

On 4 Aug 2015, at 06:47, Tagir Valeev  wrote:

> Hello!
> 
> The PriorityQueue class iterator() returns elements in no particular order.
> This is explicitly stated in JavaDoc for iterator() method [1] as well as
> in class description [2]. However it's not mentioned mentioned that
> spliterator() method also traverses the queue in no particular order. Well,
> the user might guess that the order is not specified, because the
> spliterator does not have ORDERED characteristic, but it's not so obvious
> for any user. Probably it's would be good to add an explicit note like it's
> done for iterator. The same thing is for PriorityBlockingQueue. What do you
> think?
> 
> With best regards,
> Tagir Valeev.
> 
> [1]
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/022d45d94d0a/src/java.base/share/classes/java/util/PriorityQueue.java#l477
> [2]
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/022d45d94d0a/src/java.base/share/classes/java/util/PriorityQueue.java#l54



From daniel.fuchs at oracle.com  Tue Aug  4 08:56:24 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 04 Aug 2015 10:56:24 +0200
Subject: RFR [9] 8132877: docs: replace  tags (obsolete in html5)
	for java.naming
In-Reply-To: <55BF8B3A.6010505@oracle.com>
References: <55BF37AE.4080107@oracle.com>	<02F25F91-0789-4C12-A132-D58B0B12201F@oracle.com>	<55BF6553.3070905@oracle.com>	<55BF663B.4090503@oracle.com>
	<55BF8B3A.6010505@oracle.com>
Message-ID: <55C07E38.70502@oracle.com>

Hi Alexander,

I had a look at 
http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/jdk.patch, and 
there's nothing that caught my eye.

However - it would be good if you could generate a specdiff so that
we could verify that no mistake has crept in.

best regards,

-- daniel

On 03/08/15 17:39, Alexander Stepanov wrote:
> just in case, the updated webrev:
> http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html
>
> On 8/3/2015 4:01 PM, Alexander Stepanov wrote:
>> P.S. I have also to replace {@link ...} with just {@link
>> ...} in a couple of places here (as in the previous RFR 8132468...)
>>
>> Regards,
>> Alexander
>>
>> On 8/3/2015 3:57 PM, Alexander Stepanov wrote:
>>> Thanks!
>>>
>>> On 8/3/2015 3:53 PM, Lance Andersen wrote:
>>>> I think this looks ok also.
>>>>
>>>> I agree with Daniel that we have additional clean-up opportunities
>>>>  throughout we can do to the javadocs, but keeping each change set
>>>>  more narrow helps reduce the chance of  introducing additional errors
>>>>
>>>> Best
>>>> Lance
>>>> On Aug 3, 2015, at 5:43 AM, Alexander Stepanov
>>>> >>> > wrote:
>>>>
>>>>> http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/
>>>>> 
>>>>
>>>> 
>>>> 
>>>>
>>>> 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 amaembo at gmail.com  Tue Aug  4 09:18:12 2015
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 4 Aug 2015 15:18:12 +0600
Subject: Spliterator documentation on Priority(Blocking)Queue
In-Reply-To: 
References: 
	
Message-ID: 

Hello, Paul.

I think I have no access rights to do it. Should I have to sign an OCA for
this? I submitted the signed OCA to oracle-ca_us at oracle.com last week (as
you suggested in ConstantSpliterator discussion), but still got no
response. Probably I did something wrong.

With best regards,
Tagir Valeev.

On Tue, Aug 4, 2015 at 1:56 PM, Paul Sandoz  wrote:

> Hi Tagir,
>
> Can you log an issue?
>
> Thanks,
> Paul.
>
> On 4 Aug 2015, at 06:47, Tagir Valeev  wrote:
>
> > Hello!
> >
> > The PriorityQueue class iterator() returns elements in no particular
> order.
> > This is explicitly stated in JavaDoc for iterator() method [1] as well as
> > in class description [2]. However it's not mentioned mentioned that
> > spliterator() method also traverses the queue in no particular order.
> Well,
> > the user might guess that the order is not specified, because the
> > spliterator does not have ORDERED characteristic, but it's not so obvious
> > for any user. Probably it's would be good to add an explicit note like
> it's
> > done for iterator. The same thing is for PriorityBlockingQueue. What do
> you
> > think?
> >
> > With best regards,
> > Tagir Valeev.
> >
> > [1]
> >
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/022d45d94d0a/src/java.base/share/classes/java/util/PriorityQueue.java#l477
> > [2]
> >
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/022d45d94d0a/src/java.base/share/classes/java/util/PriorityQueue.java#l54
>
>


From daniel.fuchs at oracle.com  Tue Aug  4 09:19:39 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 04 Aug 2015 11:19:39 +0200
Subject: RFR [9] 8132468: docs: replace  tags (obsolete in html5)
	for java.io, java.lang, java.math
In-Reply-To: <55BF34DB.8090106@oracle.com>
References: <55BF34DB.8090106@oracle.com>
Message-ID: <55C083AB.6020300@oracle.com>

Hi Alexander,

src/java.base/share/classes/java/io/File.java

1.

-     * 

-     * new File( f.{@link #toURI() 
toURI}()).equals( f.{@link #getAbsoluteFile() 
getAbsoluteFile}())
-     * 

+     * 

+     * {@code new File(f.}{@link
+     * #toURI() toURI}{@code ()).equals(f.}{@link
+     * #getAbsoluteFile() getAbsoluteFile}{@code ())}
+     * 


Sorry I missed the  in my previous suggestion - so
wrapping the whole thing with  is probably the better idea,
something like:

     * 

     * new File( f.{@link
     * #toURI() toURI()}.equals( f.{@link
     * #getAbsoluteFile() getAbsoluteFile()}
     * 


Whatever you chose to do - please do verify how the new javadoc
looks when changing such complex formatted statements.

2.

-     * 

-     * new {@link #File(java.net.URI) 
File}( f.toURI()).equals( f.{@link 
#getAbsoluteFile() getAbsoluteFile}())
-     * 

+     * 

+     * {@code new }{@link #File(java.net.URI) File}{@code 
.toURI()).equals(f.}
+     * {@link #getAbsoluteFile() getAbsoluteFile}{@code ())}
+     * 



As Stuart noted this second change is wrong - it's missing
(f.
I also believe we should keep the original italics
around 'f'.

Can you please generate a specdiff so that we can verify that
there's nothing wrong with the new javadoc?
It is very easy to miss something with such changes...

best regards,

-- daniel



On 03/08/15 11:31, Alexander Stepanov wrote:
> Hello,
>
> Could you please review the following fix:
> http://cr.openjdk.java.net/~avstepan/8132468/webrev.00/
> for
> https://bugs.openjdk.java.net/browse/JDK-8132468
>
> Just some cleanup for docs (replacing obsolete "").
>
> Thanks,
> Alexander



From chris.hegarty at oracle.com  Tue Aug  4 10:29:49 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 04 Aug 2015 11:29:49 +0100
Subject: Review request: JDK-8080108: [TEST_BUG] ERROR: No IPv6 address
	returned from platform
In-Reply-To: <55B8C031.6010802@oracle.com>
References: <55B8C031.6010802@oracle.com>
Message-ID: <55C0941D.8070806@oracle.com>

Alexander,

Wow, that's a lot of boiler plate for a manual test. Surely a 
README.txt, or similar would be sufficient?

I noticed that with your changes, now this test has a dependency on the 
jdk.desktop module ( imports from java.awt.* ). Is it really necessary 
to have a dialog window pop-up?

-Chris.

On 29/07/15 12:59, Alexander Fomin wrote:
> Hello,
>
> Please review the test bug fix
> https://bugs.openjdk.java.net/browse/JDK-8080108
>
> See webrev here
> http://cr.openjdk.java.net/~kshefov/8080108/webrev.00/
>
> The original test
> (com/sun/jndi/dns/IPv6NameserverPlatformParsingTest.java @bug 6991580)
> fails automatically if /etc/resolv.conf file doesn't contain IPv6
> nameserver entries.
> It's needed to edit /etc/resolv.conf manually before the test run, so
> this is a manual regression test.
> The test is intended to be run on non-Windows systems.
>
> Fix:
> - provided standard test machinery for regression manual tests with
> instructions for a user;
> - the test excluded for Windows.
>
> Tested on Linux and Windows(to make sure it's excluded).
>
> Thanks,
> Alexander


From paul.sandoz at oracle.com  Tue Aug  4 10:57:29 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 4 Aug 2015 12:57:29 +0200
Subject: Spliterator documentation on Priority(Blocking)Queue
In-Reply-To: 
References: 
	
	
Message-ID: <876895DB-CFE2-4A7B-9645-6AEB60D646D5@oracle.com>


On 4 Aug 2015, at 11:18, Tagir Valeev  wrote:

> Hello, Paul.
> 
> I think I have no access rights to do it.

You can do it here:

  http://bugreport.java.com/

(Write access to the Java Bug System requires OpenJDK author status.)


> Should I have to sign an OCA for this?

No.


> I submitted the signed OCA to oracle-ca_us at oracle.com last week (as you suggested in ConstantSpliterator discussion), but still got no response. Probably I did something wrong.
> 

It?s probably because people are busy. If you have it can you forward me (personally) the email you sent and i will try and ping people.

Thanks,
Paul.



From amaembo at gmail.com  Tue Aug  4 11:42:57 2015
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 4 Aug 2015 17:42:57 +0600
Subject: Spliterator documentation on Priority(Blocking)Queue
In-Reply-To: <876895DB-CFE2-4A7B-9645-6AEB60D646D5@oracle.com>
References: 
	
	
	<876895DB-CFE2-4A7B-9645-6AEB60D646D5@oracle.com>
Message-ID: 

Hello!

You can do it here:
>
>   http://bugreport.java.com/
>
> (Write access to the Java Bug System requires OpenJDK author status.)
>

Thank you for the clarification. I filed the issue with Review ID:
JI-9023040.


> It?s probably because people are busy. If you have it can you forward me
> (personally) the email you sent and i will try and ping people.
>

I forwarded that mail to you. Thank you in advance,

With best regards,
Tagir Valeev.


From paul.sandoz at oracle.com  Tue Aug  4 11:47:28 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 4 Aug 2015 13:47:28 +0200
Subject: Spliterator documentation on Priority(Blocking)Queue
In-Reply-To: 
References: 
	
	
	<876895DB-CFE2-4A7B-9645-6AEB60D646D5@oracle.com>
	
Message-ID: <7F5A17D1-0789-40D1-9274-87FE1C203F9F@oracle.com>


On 4 Aug 2015, at 13:42, Tagir Valeev  wrote:

> Hello!
> 
> You can do it here:
> 
>   http://bugreport.java.com/
> 
> (Write access to the Java Bug System requires OpenJDK author status.)
> 
> Thank you for the clarification. I filed the issue with Review ID: JI-9023040.
> 

Thanks, and here it is migrated:

  https://bugs.openjdk.java.net/browse/JDK-8132964

Paul.


From alexander.fomin at oracle.com  Tue Aug  4 12:53:04 2015
From: alexander.fomin at oracle.com (Alexander Fomin)
Date: Tue, 04 Aug 2015 15:53:04 +0300
Subject: Review request: JDK-8080108: [TEST_BUG] ERROR: No IPv6 address
	returned from platform
In-Reply-To: <55C0941D.8070806@oracle.com>
References: <55B8C031.6010802@oracle.com> <55C0941D.8070806@oracle.com>
Message-ID: <55C0B5B0.5010900@oracle.com>

Hi Chris

On 04.08.2015 13:29, Chris Hegarty wrote:
> Alexander,
>
> Wow, that's a lot of boiler plate for a manual test. Surely a 
> README.txt, or similar would be sufficient?
>
> I noticed that with your changes, now this test has a dependency on 
> the jdk.desktop module ( imports from java.awt.* ). Is it really 
> necessary to have a dialog window pop-up?

     With the current process manual tests without a dialog window with 
instruction and PASS/FAIL buttons will be, actually, skipped.
     The manual tests aren't run one by one. The regression manual 
testing is started with the command like:

..\bin\jtreg -v -m -ignore:quiet -jdk: -r: -w:

that run all manual test. So, nobody will read all README.txt files for 
all tests before run, right?

     With the command above, if we have some manual test with the only 
README.txt and without dialog window, the test will be run by jtreg 
automatically. In the result the instruction in README.txt will be 
skipped and the test will PASS or FAIL automatically (it depends on how 
the test is written).   If a such test passed, it doesn't mean that 
something has been ever tested. It may pass just because some resources 
or properties, required for the test, were absent. If the test FAIL, 
well, we may at least do one more iteration to rerun all failed manual 
tests one by one following to the instruction in the corresponding 
README.txt. But it's too expensive. Usually the failures just reported 
by SQE engineers as test bugs.

     BYW, the original test has a readme.txt with instruction. But it 
was never run properly.  At least for JDK 9 it was never pass (even on 
non Windows systems) because nobody read the README.txt before test 
execution, I guess.

     What is the problem with dependency on the jdk.desktop module?
     If we should avoid the dependency and we still wish the tests 
without standard dialog windows with test's instructions and PASS/FAIL 
buttons were run regularly, we, probably, need to fix jtreg. Currently 
jtreg doesn't take into account readme.txt files or provide any 
mechanism for manual test run execution. But this jtreg enhancement is 
out of scope for the bug I'm trying to fix.

Thanks,
Alexander

>
> -Chris.
>
> On 29/07/15 12:59, Alexander Fomin wrote:
>> Hello,
>>
>> Please review the test bug fix
>> https://bugs.openjdk.java.net/browse/JDK-8080108
>>
>> See webrev here
>> http://cr.openjdk.java.net/~kshefov/8080108/webrev.00/
>>
>> The original test
>> (com/sun/jndi/dns/IPv6NameserverPlatformParsingTest.java @bug 6991580)
>> fails automatically if /etc/resolv.conf file doesn't contain IPv6
>> nameserver entries.
>> It's needed to edit /etc/resolv.conf manually before the test run, so
>> this is a manual regression test.
>> The test is intended to be run on non-Windows systems.
>>
>> Fix:
>> - provided standard test machinery for regression manual tests with
>> instructions for a user;
>> - the test excluded for Windows.
>>
>> Tested on Linux and Windows(to make sure it's excluded).
>>
>> Thanks,
>> Alexander



From mark.reinhold at oracle.com  Tue Aug  4 14:56:04 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 04 Aug 2015 07:56:04 -0700
Subject: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.)
Message-ID: <20150804075604.598755@eggemoggin.niobe.net>

FYI:

  http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-August/004433.html

(Please reply on jigsaw-dev rather than on jdk9-dev or core-libs-dev.)

- Mark


From alexander.v.stepanov at oracle.com  Tue Aug  4 17:34:57 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Tue, 04 Aug 2015 20:34:57 +0300
Subject: RFR [9] 8132877: docs: replace  tags (obsolete in html5)
	for java.naming
In-Reply-To: <55C07E38.70502@oracle.com>
References: <55BF37AE.4080107@oracle.com>	<02F25F91-0789-4C12-A132-D58B0B12201F@oracle.com>	<55BF6553.3070905@oracle.com>	<55BF663B.4090503@oracle.com>
	<55BF8B3A.6010505@oracle.com> <55C07E38.70502@oracle.com>
Message-ID: <55C0F7C1.7040505@oracle.com>

Hello Daniel,

The review was re-uploaded as specdiff indeed discovered a couple of 
unwanted changes (in 'InitialContext' and 'ReferralException'), so your 
and Pavel's recommendations were very useful, thanks.

webrev (please update the web-page):
http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html
sdiff out (0 changes at the moment):
http://cr.openjdk.java.net/~avstepan/8132877/specdiff.01/overview-summary.html

Regards,
Alexander

On 8/4/2015 11:56 AM, Daniel Fuchs wrote:
> Hi Alexander,
>
> I had a look at 
> http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/jdk.patch, and 
> there's nothing that caught my eye.
>
> However - it would be good if you could generate a specdiff so that
> we could verify that no mistake has crept in.
>
> best regards,
>
> -- daniel
>
> On 03/08/15 17:39, Alexander Stepanov wrote:
>> just in case, the updated webrev:
>> http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html
>>
>> On 8/3/2015 4:01 PM, Alexander Stepanov wrote:
>>> P.S. I have also to replace {@link ...} with just {@link
>>> ...} in a couple of places here (as in the previous RFR 8132468...)
>>>
>>> Regards,
>>> Alexander
>>>
>>> On 8/3/2015 3:57 PM, Alexander Stepanov wrote:
>>>> Thanks!
>>>>
>>>> On 8/3/2015 3:53 PM, Lance Andersen wrote:
>>>>> I think this looks ok also.
>>>>>
>>>>> I agree with Daniel that we have additional clean-up opportunities
>>>>>  throughout we can do to the javadocs, but keeping each change set
>>>>>  more narrow helps reduce the chance of  introducing additional 
>>>>> errors
>>>>>
>>>>> Best
>>>>> Lance
>>>>> On Aug 3, 2015, at 5:43 AM, Alexander Stepanov
>>>>> >>>> > wrote:
>>>>>
>>>>>> http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/
>>>>>> 
>>>>>
>>>>> 
>>>>>  
>>>>>
>>>>>
>>>>> 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 paul.sandoz at oracle.com  Tue Aug  4 17:52:47 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 4 Aug 2015 19:52:47 +0200
Subject: JDK 9 RFR of JDK-8132854: Adjust tier 1 and 2 definitions for
	nio-related intrinsics
In-Reply-To: <55BEDDDD.6040104@oracle.com>
References: <55BEDDDD.6040104@oracle.com>
Message-ID: 

+1

Paul.

On 3 Aug 2015, at 05:19, joe darcy  wrote:

> Hello,
> 
> With the fix for
> 
>        JDK-8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics
> 
> the sources for the libraries clearly indicate which methods might have intrinsic support in HotSpot, that is, which methods might have their Java source implementation replaced by some other code sequence maintained in HotSpot, such as a special-purpose processor-specific instruction.
> 
> To ease testing, it would be help if all the intrinsified methods were included in the tier 1 test group. Most of the intrinics are in java.lang, java.math, and java.util, packages whose tests are already in tier 1. Two nio-related classes are marked with @HotSpotIntrinsicCandidate:
> 
>    ./java.base/share/classes/sun/nio/cs/ISO_8859_1.java # implEncodeISOArray marked
>    ./java.base/share/classes/java/nio/Buffer.java # index check
> 
> Therefore, I propose moving the tests that directly cover those areas to tier 1:
> 
> --- a/test/TEST.groups    Mon Aug 03 09:25:02 2015 +0800
> +++ b/test/TEST.groups    Sun Aug 02 20:16:00 2015 -0700
> @@ -28,11 +28,15 @@
> tier1 = \
>     :jdk_lang \
>     :jdk_util \
> +    sun/nio/cs/ISO8859x.java \
> +    java/nio/Buffer \
>     :jdk_math
> 
> tier2 = \
>     :jdk_io \
>     :jdk_nio \
> +    -sun/nio/cs/ISO8859x.java \
> +    -java/nio/Buffer \
>     :jdk_net \
>     :jdk_time \
>     :jdk_security \
> 
> Full webrev at
> 
>    http://cr.openjdk.java.net/~darcy/8132854.0/
> 
> Thanks,
> 
> -Joe



From huizhe.wang at oracle.com  Tue Aug  4 18:26:14 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 04 Aug 2015 11:26:14 -0700
Subject: Review request for JDK-8132660: Change jaxp unit test package
	name to be different with jaxp api
In-Reply-To: <02d901d0ce82$08329f30$1897dd90$@oracle.com>
References: <02d901d0ce82$08329f30$1897dd90$@oracle.com>
Message-ID: <55C103C6.2020702@oracle.com>

Hi Frank,

That looks fine. However, instead of appending an additional directory 
"utests", you could make the paths shorter by removing "javax/xml" and 
"org/w3c" or "org/xml". The short names are good enough to represent the 
API names, test/javax/xml/jaxp/unittest/parsers for example, is easily 
recognizable as a package that holds the tests for javax/xml/parsers. 
JAXP tests currently in the jdk test repositories are named using this 
approach.

Thanks,
Joe

On 8/3/2015 11:51 PM, Frank Yuan wrote:
>
> Hi, Joe and all
>
> Would you like to have a review for bug 
> https://bugs.openjdk.java.net/browse/JDK-8132660?
>
> This is already on our plan for a while, but I have to finish it now 
> because these unit tests failed with latest Jigsaw build. However I 
> made the changes based on 9-dev repo, I tested them with both Jigsaw 
> build and 9-dev build. The JPRT successful mail is enclosed in the bug.
>
> The webrev is at: http://cr.openjdk.java.net/~fyuan/8132660/webrev.00/ 
> . It seems to 
> be a big change but actually there are only some directories changed.
>
> Thanks,
>
> Frank
>



From stuart.marks at oracle.com  Tue Aug  4 21:19:29 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 4 Aug 2015 14:19:29 -0700
Subject: RFR(m): 8072722: add stream support to Scanner
Message-ID: <55C12C61.1050100@oracle.com>

Hi all,

Please review this API enhancement that adds streams support to java.util.Scanner.

Scanner is essentially a regular expression matcher that matches over arbitrary 
input (e.g., from a file) instead of a fixed string like Matcher. Scanner will 
read and buffer additional input as necessary when looking for matches.

This change proposes to add two streams methods:

1. tokens(), which returns a stream of tokens delimited by the Scanner's 
delimiter. Scanner's default delimiter is whitespace, so the following will 
collect a list of whitespace-separated words from a file:

     try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
         List words = sc.tokens().collect(toList());
     }

2. findAll(pattern), which returns a stream of match results generated by 
searching the input for the given pattern (either a Pattern or a String). For 
example, the following will extract from a file all words that are surrounded by 
"_" characters, such as _foo_ :

     try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
         return sc.findAll("_([\\w]+)_")
                  .map(mr -> mr.group(1))
                  .collect(toList());
     }

Implementation notes. A Scanner is essentially already an iterator of tokens, so 
tokens() pretty much just wraps "this" into a stream. The findAll() methods are 
a wrapper around repeated calls to findWithinHorizon(pattern, 0) with a bit of 
refactoring to avoid converting the MatchResult to a String prematurely.

The tests are pretty straightforward, with some additional cleanups, such as 
using try-with-resources.

Bug:

	https://bugs.openjdk.java.net/browse/JDK-8072722

Webrev:

	http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.0/

Specdiff:

	http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.0/overview-summary.html

Thanks,

s'marks



From stuart.marks at oracle.com  Tue Aug  4 21:53:13 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 4 Aug 2015 14:53:13 -0700
Subject: RFR(s): 8132800: clarify stream package documentation regarding
	sequential vs parallel modes
In-Reply-To: <27303ED2-9ACB-4533-BF15-72286FE2EDBD@oracle.com>
References: <55BBE66D.2060009@oracle.com>
	
	<55BFF490.4060009@oracle.com>
	<27303ED2-9ACB-4533-BF15-72286FE2EDBD@oracle.com>
Message-ID: <55C13449.6080301@oracle.com>

I've gone ahead and added this to the implementation note section of Stream.concat

+     * 
Subsequent changes to the sequential/parallel execution mode of the
+     * returned stream are not guaranteed to be propagated to the input streams.
+     *

and I've pushed the change.

The situation with Stream.takeWhile/dropWhile seems a bit sticky. On the one 
hand, the default implementations seem to make a reasonable set of compromises. 
On the other hand, I can't think of anything useful to add to the description 
that's already there. If somebody can think of something useful to add, by all 
means propose it, but I can't think of anything that usefully clarifies the 
situation without diving into a bunch of implementation details.

s'marks


On 8/4/15 12:20 AM, Paul Sandoz wrote:
>
> On 4 Aug 2015, at 01:09, Stuart Marks  wrote:
>
>> Hi Tagir,
>>
>> Interesting issues.
>>
>> Regarding Stream.concat, it may be that, today, changes to the sequential/parallel execution mode aren't propagated to the streams being concatenated.
>
> The execution mode is propagated if either stream to concat is parallel i.e. isParallel()
>
> The issue here is that Stream.spltierator() is a form of terminal operation that will result in pipeline evaluation if there are non-lazy stateful operations present.
>
> What we don?t currently do is propagate the parallelism back to a sequential stream when the other is a parallel stream. We could easily do that as a bug fix. I agree with Stuart it does not require any specification e.g.:
>
> public static  Stream concat(Stream a, Stream b) {
>      Objects.requireNonNull(a);
>      Objects.requireNonNull(b);
>
>      boolean isPar = a.isParallel() || b.isParallel();
>      @SuppressWarnings("unchecked")
>      Spliterator split = new Streams.ConcatSpliterator.OfRef<>(
>              (Spliterator) (isPar ? a.parallel() : a).spliterator(),
>              (Spliterator) (isPar ? b.parallel() : b).spliterator());
>      Stream stream = StreamSupport.stream(split, isPar);
>      return stream.onClose(Streams.composedClose(a, b));
> }
>
>
>> But is that something inherent to the specification of concatenation, or is it something that might change in the future? It's currently unspecified, so adding a clarification really sounds more like changing the specification to reflect the current implementation, which I'd prefer not to do.
>>
>> Regarding the default implementations of takeWhile/dropWhile, again, today, they don't propagate the execution mode upstream. But is this just a bug? Granted the API for doing so isn't obvious, but isn't this something that could just be fixed?
>>
>
> The default implementations are specified to propagate the execution mode in terms of correctly reporting isParallel() but may choose not to split:
>
> * the wrapped spliterator.  The returned stream preserves the execution
> * characteristics of this stream (namely parallel or sequential execution
> * as per {@link #isParallel()}) but the wrapped spliterator may choose to
> * not support splitting.  When the returned stream is closed, the close
> * handlers for both the returned and this stream are invoked.
>
> So this is a little different from the Stream.concat case.
>
> The only way a default implementation can be implemented is to derive functionality from the upstream spliterator(). Rather than choosing to add yet more code to support this (and most likely poorly too) i opted for not splitting and reuse some existing code (the unordered spliterators that are configured not to split). Nor did i want to wrap the non-splitting spliterator around one which copies a prefix, which introduces a different set of poorly splitting characteristics (and would also penalise sequential operation). This is a tradeoff, and seems to me a reasonable compromise for a default.
>
> Paul.
>


From amaembo at gmail.com  Wed Aug  5 04:30:38 2015
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 5 Aug 2015 10:30:38 +0600
Subject: RFR(s): 8132800: clarify stream package documentation regarding
	sequential vs parallel modes
In-Reply-To: <55C13449.6080301@oracle.com>
References: <55BBE66D.2060009@oracle.com>
	
	<55BFF490.4060009@oracle.com>
	<27303ED2-9ACB-4533-BF15-72286FE2EDBD@oracle.com>
	<55C13449.6080301@oracle.com>
Message-ID: 

Hello!

On Wed, Aug 5, 2015 at 3:53 AM, Stuart Marks 
wrote:

> I've gone ahead and added this to the implementation note section of
> Stream.concat
>
> +     * 
Subsequent changes to the sequential/parallel execution mode of
> the
> +     * returned stream are not guaranteed to be propagated to the input
> streams.
> +     *
>
> and I've pushed the change.
>
> The situation with Stream.takeWhile/dropWhile seems a bit sticky. On the
> one hand, the default implementations seem to make a reasonable set of
> compromises. On the other hand, I can't think of anything useful to add to
> the description that's already there. If somebody can think of something
> useful to add, by all means propose it, but I can't think of anything that
> usefully clarifies the situation without diving into a bunch of
> implementation details.
>
>
Agreed. Thanks.

Tagir Valeev.


> s'marks
>
>
>
> On 8/4/15 12:20 AM, Paul Sandoz wrote:
>
>>
>> On 4 Aug 2015, at 01:09, Stuart Marks  wrote:
>>
>> Hi Tagir,
>>>
>>> Interesting issues.
>>>
>>> Regarding Stream.concat, it may be that, today, changes to the
>>> sequential/parallel execution mode aren't propagated to the streams being
>>> concatenated.
>>>
>>
>> The execution mode is propagated if either stream to concat is parallel
>> i.e. isParallel()
>>
>> The issue here is that Stream.spltierator() is a form of terminal
>> operation that will result in pipeline evaluation if there are non-lazy
>> stateful operations present.
>>
>> What we don?t currently do is propagate the parallelism back to a
>> sequential stream when the other is a parallel stream. We could easily do
>> that as a bug fix. I agree with Stuart it does not require any
>> specification e.g.:
>>
>> public static  Stream concat(Stream a, Stream> extends T> b) {
>>      Objects.requireNonNull(a);
>>      Objects.requireNonNull(b);
>>
>>      boolean isPar = a.isParallel() || b.isParallel();
>>      @SuppressWarnings("unchecked")
>>      Spliterator split = new Streams.ConcatSpliterator.OfRef<>(
>>              (Spliterator) (isPar ? a.parallel() : a).spliterator(),
>>              (Spliterator) (isPar ? b.parallel() : b).spliterator());
>>      Stream stream = StreamSupport.stream(split, isPar);
>>      return stream.onClose(Streams.composedClose(a, b));
>> }
>>
>>
>> But is that something inherent to the specification of concatenation, or
>>> is it something that might change in the future? It's currently
>>> unspecified, so adding a clarification really sounds more like changing the
>>> specification to reflect the current implementation, which I'd prefer not
>>> to do.
>>>
>>> Regarding the default implementations of takeWhile/dropWhile, again,
>>> today, they don't propagate the execution mode upstream. But is this just a
>>> bug? Granted the API for doing so isn't obvious, but isn't this something
>>> that could just be fixed?
>>>
>>>
>> The default implementations are specified to propagate the execution mode
>> in terms of correctly reporting isParallel() but may choose not to split:
>>
>> * the wrapped spliterator.  The returned stream preserves the execution
>> * characteristics of this stream (namely parallel or sequential execution
>> * as per {@link #isParallel()}) but the wrapped spliterator may choose to
>> * not support splitting.  When the returned stream is closed, the close
>> * handlers for both the returned and this stream are invoked.
>>
>> So this is a little different from the Stream.concat case.
>>
>> The only way a default implementation can be implemented is to derive
>> functionality from the upstream spliterator(). Rather than choosing to add
>> yet more code to support this (and most likely poorly too) i opted for not
>> splitting and reuse some existing code (the unordered spliterators that are
>> configured not to split). Nor did i want to wrap the non-splitting
>> spliterator around one which copies a prefix, which introduces a different
>> set of poorly splitting characteristics (and would also penalise sequential
>> operation). This is a tradeoff, and seems to me a reasonable compromise for
>> a default.
>>
>> Paul.
>>
>>


From daniel.fuchs at oracle.com  Wed Aug  5 08:14:56 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 05 Aug 2015 10:14:56 +0200
Subject: RFR [9] 8132877: docs: replace  tags (obsolete in html5)
	for java.naming
In-Reply-To: <55C0F7C1.7040505@oracle.com>
References: <55BF37AE.4080107@oracle.com>	<02F25F91-0789-4C12-A132-D58B0B12201F@oracle.com>	<55BF6553.3070905@oracle.com>	<55BF663B.4090503@oracle.com>
	<55BF8B3A.6010505@oracle.com> <55C07E38.70502@oracle.com>
	<55C0F7C1.7040505@oracle.com>
Message-ID: <55C1C600.1080508@oracle.com>

Hi Alexander,

On 04/08/15 19:34, Alexander Stepanov wrote:
> Hello Daniel,
>
> The review was re-uploaded as specdiff indeed discovered a couple of
> unwanted changes (in 'InitialContext' and 'ReferralException'), so your
> and Pavel's recommendations were very useful, thanks.
>
> webrev (please update the web-page):
> http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html
> sdiff out (0 changes at the moment):
> http://cr.openjdk.java.net/~avstepan/8132877/specdiff.01/overview-summary.html

Looks good for me then.

best regards,

-- daniel

>
>
> Regards,
> Alexander
>
> On 8/4/2015 11:56 AM, Daniel Fuchs wrote:
>> Hi Alexander,
>>
>> I had a look at
>> http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/jdk.patch, and
>> there's nothing that caught my eye.
>>
>> However - it would be good if you could generate a specdiff so that
>> we could verify that no mistake has crept in.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 03/08/15 17:39, Alexander Stepanov wrote:
>>> just in case, the updated webrev:
>>> http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html
>>>
>>> On 8/3/2015 4:01 PM, Alexander Stepanov wrote:
>>>> P.S. I have also to replace {@link ...} with just {@link
>>>> ...} in a couple of places here (as in the previous RFR 8132468...)
>>>>
>>>> Regards,
>>>> Alexander
>>>>
>>>> On 8/3/2015 3:57 PM, Alexander Stepanov wrote:
>>>>> Thanks!
>>>>>
>>>>> On 8/3/2015 3:53 PM, Lance Andersen wrote:
>>>>>> I think this looks ok also.
>>>>>>
>>>>>> I agree with Daniel that we have additional clean-up opportunities
>>>>>>  throughout we can do to the javadocs, but keeping each change set
>>>>>>  more narrow helps reduce the chance of  introducing additional
>>>>>> errors
>>>>>>
>>>>>> Best
>>>>>> Lance
>>>>>> On Aug 3, 2015, at 5:43 AM, Alexander Stepanov
>>>>>> >>>>> > wrote:
>>>>>>
>>>>>>> http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/
>>>>>>> 
>>>>>>
>>>>>> 
>>>>>> 
>>>>>>
>>>>>>
>>>>>> 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 frank.yuan at oracle.com  Wed Aug  5 10:04:33 2015
From: frank.yuan at oracle.com (Frank Yuan)
Date: Wed, 5 Aug 2015 18:04:33 +0800
Subject: Review request for JDK-8132660: Change jaxp unit test package
	name to be different with jaxp api
In-Reply-To: <55C103C6.2020702@oracle.com>
References: <02d901d0ce82$08329f30$1897dd90$@oracle.com>
	<55C103C6.2020702@oracle.com>
Message-ID: <014201d0cf66$22baddb0$68309910$@oracle.com>

Hi Joe

 

Thank you very much! Really good advice! I have adjusted as it, please
re-check at:

http://cr.openjdk.java.net/~fyuan/8132660/webrev.01/

 

Btw, I only applied this practice on unit test, not for functional test
because Tristan still has a functional suite pending, I would unify the
functional part sometime after that suite is finished.

 

Best Regards

Frank

 

 

From: huizhe wang [mailto:huizhe.wang at oracle.com] 
Sent: Wednesday, August 05, 2015 2:26 AM
To: Frank Yuan 
Cc: 'core-libs-dev' ; 'Alan Bateman'
; 'Jan Lahoda' 
Subject: Re: Review request for JDK-8132660: Change jaxp unit test package
name to be different with jaxp api

 

Hi Frank,

That looks fine. However, instead of appending an additional directory
"utests", you could make the paths shorter by removing "javax/xml" and
"org/w3c" or "org/xml". The short names are good enough to represent the API
names, test/javax/xml/jaxp/unittest/parsers for example, is easily
recognizable as a package that holds the tests for javax/xml/parsers. JAXP
tests currently in the jdk test repositories are named using this approach.

Thanks,
Joe

On 8/3/2015 11:51 PM, Frank Yuan wrote:

Hi, Joe and all

 

Would you like to have a review for bug
https://bugs.openjdk.java.net/browse/JDK-8132660?

 

This is already on our plan for a while, but I have to finish it now because
these unit tests failed with latest Jigsaw build. However I made the changes
based on 9-dev repo, I tested them with both Jigsaw build and 9-dev build.
The JPRT successful mail is enclosed in the bug.

 

The webrev is at: http://cr.openjdk.java.net/~fyuan/8132660/webrev.00/
 . It seems to be a
big change but actually there are only some directories changed. 

 

 

Thanks,

 

Frank

 

 



From alexander.v.stepanov at oracle.com  Wed Aug  5 10:20:27 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Wed, 05 Aug 2015 13:20:27 +0300
Subject: RFR [9] 8132877: docs: replace  tags (obsolete in html5)
	for java.naming
In-Reply-To: <55C1C600.1080508@oracle.com>
References: <55BF37AE.4080107@oracle.com>	<02F25F91-0789-4C12-A132-D58B0B12201F@oracle.com>	<55BF6553.3070905@oracle.com>	<55BF663B.4090503@oracle.com>
	<55BF8B3A.6010505@oracle.com> <55C07E38.70502@oracle.com>
	<55C0F7C1.7040505@oracle.com> <55C1C600.1080508@oracle.com>
Message-ID: <55C1E36B.4030205@oracle.com>

Thanks!

On 8/5/2015 11:14 AM, Daniel Fuchs wrote:
> Hi Alexander,
>
> On 04/08/15 19:34, Alexander Stepanov wrote:
>> Hello Daniel,
>>
>> The review was re-uploaded as specdiff indeed discovered a couple of
>> unwanted changes (in 'InitialContext' and 'ReferralException'), so your
>> and Pavel's recommendations were very useful, thanks.
>>
>> webrev (please update the web-page):
>> http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html
>> sdiff out (0 changes at the moment):
>> http://cr.openjdk.java.net/~avstepan/8132877/specdiff.01/overview-summary.html 
>>
>
> Looks good for me then.
>
> best regards,
>
> -- daniel
>
>>
>>
>> Regards,
>> Alexander
>>
>> On 8/4/2015 11:56 AM, Daniel Fuchs wrote:
>>> Hi Alexander,
>>>
>>> I had a look at
>>> http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/jdk.patch, and
>>> there's nothing that caught my eye.
>>>
>>> However - it would be good if you could generate a specdiff so that
>>> we could verify that no mistake has crept in.
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 03/08/15 17:39, Alexander Stepanov wrote:
>>>> just in case, the updated webrev:
>>>> http://cr.openjdk.java.net/~avstepan/8132877/webrev.01/index.html
>>>>
>>>> On 8/3/2015 4:01 PM, Alexander Stepanov wrote:
>>>>> P.S. I have also to replace {@link ...} with just {@link
>>>>> ...} in a couple of places here (as in the previous RFR 8132468...)
>>>>>
>>>>> Regards,
>>>>> Alexander
>>>>>
>>>>> On 8/3/2015 3:57 PM, Alexander Stepanov wrote:
>>>>>> Thanks!
>>>>>>
>>>>>> On 8/3/2015 3:53 PM, Lance Andersen wrote:
>>>>>>> I think this looks ok also.
>>>>>>>
>>>>>>> I agree with Daniel that we have additional clean-up opportunities
>>>>>>>  throughout we can do to the javadocs, but keeping each change set
>>>>>>>  more narrow helps reduce the chance of  introducing additional
>>>>>>> errors
>>>>>>>
>>>>>>> Best
>>>>>>> Lance
>>>>>>> On Aug 3, 2015, at 5:43 AM, Alexander Stepanov
>>>>>>> >>>>>> > wrote:
>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/
>>>>>>>> 
>>>>>>>
>>>>>>> 
>>>>>>>  
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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 alexander.v.stepanov at oracle.com  Wed Aug  5 12:01:14 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Wed, 05 Aug 2015 15:01:14 +0300
Subject: RFR [9] 8132468: docs: replace  tags (obsolete in html5)
	for java.io, java.lang, java.math
In-Reply-To: <55BFE167.6030606@oracle.com>
References: <55BF34DB.8090106@oracle.com> <55BF5BD7.30101@oracle.com>
	<55BF6139.9020805@oracle.com> <55BF8396.4090109@oracle.com>
	<84C4434E-679A-48C4-B507-AC266BEC64F4@oracle.com>
	<55BF90DE.1000202@oracle.com> <55BFE167.6030606@oracle.com>
Message-ID: <55C1FB0A.9070204@oracle.com>

Hello Stuart,

Please see the final version of File.java (please update the page) - 
just replacing  with  in the mentioned places:
http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/src/java.base/share/classes/java/io/File.java.udiff.html
The specdiff reports for lang and io:
http://cr.openjdk.java.net/~avstepan/8132468/specdiff.io/overview-summary.html
http://cr.openjdk.java.net/~avstepan/8132468/specdiff.lang/overview-summary.html

Regards,
Alexander

On 8/4/2015 12:47 AM, Stuart Marks wrote:
> Hi Alexander,
>
> I think Pavel's advice to run specdiff is useful. It's not too 
> difficult to run and in this case it provides a useful cross-check for 
> making a large number of markup changes. Contact me directly if you 
> need help with specdiff. I've run specdiff over your webrev.01 and 
> I've posted the results here:
>
> http://cr.openjdk.java.net/~smarks/reviews/8132468/specdiff.01/overview-summary.html 
>
>
> They show that of all the changes you made, only four are considered 
> significant from specdiff's point of view. Of these, two appear to be 
> merely whitespace issues, but there are two changes that do appear 
> significant:
>
>     File(URI)     // constructor
>     File.toURI()
>
> In both cases the italic 'f' is intended to be a metasyntactic 
> variable, not an actual variable that's part of the code. The italic 
> 'f' should be restored. In the case of File.toURI() it appears that 
> the resulting code is now malformed, so there's clearly an error here.
>
> You and Daniel Fuchs had an exchange about this a bit earlier. I 
> suspect the reason for the   that appears between the opening 
> parenthesis and the italic 'f' is so that the tail of the 'f' doesn't 
> crash into parenthesis. In other words, the   is there merely for 
> typographical purposes. I suspect that after you restore the italic 
> 'f' it'll look bad, so you'll want to restore the   as well.
>
> s'marks
>
> On 8/3/15 9:03 AM, Alexander Stepanov wrote:
>> Hello Pavel
>>
>>  > Hi Alexander, if I were you I would run specdiff
>> Thanks; but sorry, I'm afraid I haven't enough time for the extra 
>> experiments
>> just now...
>>
>>  > It's very easy to go the all the way and lose oneself in there :)
>> please accept my condolences :)
>>
>> Regards,
>> Alexander
>>
>> On 8/3/2015 6:33 PM, Pavel Rappo wrote:
>>>> On 3 Aug 2015, at 16:07, Alexander Stepanov 
>>>> 
>>>> wrote:
>>>>
>>>> Please see the updated webrev:
>>>> http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/
>>>>
>>>> removed wrapping  around the links (mostly 
>>>> PrintStream.java,
>>>> PrintWriter.java, File.java), plus other changes in File.java
>>>>
>>>> Thanks,
>>>> Alexander
>>> Hi Alexander, if I were you I would run specdiff against the changes 
>>> and
>>> upload it along with the RFR.
>>>
>>> P.S. "I've tried it once, it was awful." [1] It's very easy to go 
>>> the all the
>>> way and lose oneself in there :)
>>>
>>> ------------------------------------------------------------------------------ 
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030262.html 
>>>
>>>
>>> -Pavel
>>>
>>



From chris.hegarty at oracle.com  Wed Aug  5 14:54:03 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 05 Aug 2015 15:54:03 +0100
Subject: Review request: JDK-8080108: [TEST_BUG] ERROR: No IPv6 address
	returned from platform
In-Reply-To: <55C0B5B0.5010900@oracle.com>
References: <55B8C031.6010802@oracle.com> <55C0941D.8070806@oracle.com>
	<55C0B5B0.5010900@oracle.com>
Message-ID: <55C2238B.6000303@oracle.com>

On 04/08/15 13:53, Alexander Fomin wrote:
> Hi Chris
>
> On 04.08.2015 13:29, Chris Hegarty wrote:
>> Alexander,
>>
>> Wow, that's a lot of boiler plate for a manual test. Surely a
>> README.txt, or similar would be sufficient?
>>
>> I noticed that with your changes, now this test has a dependency on
>> the jdk.desktop module ( imports from java.awt.* ). Is it really
>> necessary to have a dialog window pop-up?
>
>      With the current process manual tests without a dialog window with
> instruction and PASS/FAIL buttons will be, actually, skipped.
>      The manual tests aren't run one by one. The regression manual
> testing is started with the command like:
>
> ..\bin\jtreg -v -m -ignore:quiet -jdk: -r: dir> -w:
>
> that run all manual test. So, nobody will read all README.txt files for
> all tests before run, right?
>
>      With the command above, if we have some manual test with the only
> README.txt and without dialog window, the test will be run by jtreg
> automatically. In the result the instruction in README.txt will be
> skipped and the test will PASS or FAIL automatically (it depends on how
> the test is written).   If a such test passed, it doesn't mean that
> something has been ever tested. It may pass just because some resources
> or properties, required for the test, were absent. If the test FAIL,
> well, we may at least do one more iteration to rerun all failed manual
> tests one by one following to the instruction in the corresponding
> README.txt. But it's too expensive. Usually the failures just reported
> by SQE engineers as test bugs.

Ok. If this is already established process.

>      BYW, the original test has a readme.txt with instruction. But it
> was never run properly.  At least for JDK 9 it was never pass (even on
> non Windows systems) because nobody read the README.txt before test
> execution, I guess.
>
>      What is the problem with dependency on the jdk.desktop module?

The problem is that you must have a java runtime image with the 
java.desktop module installed, to be able to run a core networking test 
that has got nothing to do with graphics. Also it cannot be run on a 
headless system?

That said, I would prefer that this test was run by someone, at some 
point in time. If these changes facilitate that, then I support them, 
once I run jtreg with '-a' ( automatic only) and it is ignored.

>      If we should avoid the dependency and we still wish the tests
> without standard dialog windows with test's instructions and PASS/FAIL
> buttons were run regularly, we, probably, need to fix jtreg. Currently
> jtreg doesn't take into account readme.txt files or provide any
> mechanism for manual test run execution. But this jtreg enhancement is
> out of scope for the bug I'm trying to fix.

Right.

-Chris.

> Thanks,
> Alexander
>
>>
>> -Chris.
>>
>> On 29/07/15 12:59, Alexander Fomin wrote:
>>> Hello,
>>>
>>> Please review the test bug fix
>>> https://bugs.openjdk.java.net/browse/JDK-8080108
>>>
>>> See webrev here
>>> http://cr.openjdk.java.net/~kshefov/8080108/webrev.00/
>>>
>>> The original test
>>> (com/sun/jndi/dns/IPv6NameserverPlatformParsingTest.java @bug 6991580)
>>> fails automatically if /etc/resolv.conf file doesn't contain IPv6
>>> nameserver entries.
>>> It's needed to edit /etc/resolv.conf manually before the test run, so
>>> this is a manual regression test.
>>> The test is intended to be run on non-Windows systems.
>>>
>>> Fix:
>>> - provided standard test machinery for regression manual tests with
>>> instructions for a user;
>>> - the test excluded for Windows.
>>>
>>> Tested on Linux and Windows(to make sure it's excluded).
>>>
>>> Thanks,
>>> Alexander
>


From alexander.v.stepanov at oracle.com  Wed Aug  5 17:22:30 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Wed, 05 Aug 2015 20:22:30 +0300
Subject: RFR [9] 8133040: docs: replace  tags (obsolete in html5) for
	java.management
Message-ID: <55C24656.5090108@oracle.com>

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133040/webrev.00
for
https://bugs.openjdk.java.net/browse/JDK-8133040

specdiffs:
java.lang.management - no changes detected:
http://cr.openjdk.java.net/~avstepan/8133040/java.lang.management/overview-summary.html
javax.management - one (expected) change in TabularDataSupport:
http://cr.openjdk.java.net/~avstepan/8133040/javax.management/openmbean/package-summary.html

Regards,
Alexander


From alexander.v.stepanov at oracle.com  Wed Aug  5 17:37:52 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Wed, 05 Aug 2015 20:37:52 +0300
Subject: RFR [9] 8133040: docs: replace  tags (obsolete in html5)
	for java.management
In-Reply-To: <55C24656.5090108@oracle.com>
References: <55C24656.5090108@oracle.com>
Message-ID: <55C249F0.5080501@oracle.com>

 > javax.management - one (expected) change in TabularDataSupport:
(full package diff: 
http://cr.openjdk.java.net/~avstepan/8133040/javax.management/overview-summary.html)

On 8/5/2015 8:22 PM, Alexander Stepanov wrote:
> Hello,
>
> Could you please review the following fix:
> http://cr.openjdk.java.net/~avstepan/8133040/webrev.00
> for
> https://bugs.openjdk.java.net/browse/JDK-8133040
>
> specdiffs:
> java.lang.management - no changes detected:
> http://cr.openjdk.java.net/~avstepan/8133040/java.lang.management/overview-summary.html 
>
> javax.management - one (expected) change in TabularDataSupport:
> http://cr.openjdk.java.net/~avstepan/8133040/javax.management/openmbean/package-summary.html 
>
>
> Regards,
> Alexander



From alexander.fomin at oracle.com  Wed Aug  5 18:00:23 2015
From: alexander.fomin at oracle.com (Alexander Fomin)
Date: Wed, 05 Aug 2015 21:00:23 +0300
Subject: Review request: JDK-8080108: [TEST_BUG] ERROR: No IPv6 address
	returned from platform
In-Reply-To: <55C2238B.6000303@oracle.com>
References: <55B8C031.6010802@oracle.com> <55C0941D.8070806@oracle.com>
	<55C0B5B0.5010900@oracle.com> <55C2238B.6000303@oracle.com>
Message-ID: <55C24F37.70402@oracle.com>

Hi Crhis

On 05.08.2015 17:54, Chris Hegarty wrote:
>>      What is the problem with dependency on the jdk.desktop module?
>
> The problem is that you must have a java runtime image with the 
> java.desktop module installed, to be able to run a core networking 
> test that has got nothing to do with graphics. Also it cannot be run 
> on a headless system?
>
> That said, I would prefer that this test was run by someone, at some 
> point in time. If these changes facilitate that, then I support them, 
> once I run jtreg with '-a' ( automatic only) and it is ignored. 

Sure. These test will be run only during regression manual testing 
(jtreg with '-m'). The manual testing is doing regularly by dedicate 
persons.
These tests are ignored during automatic regression testing. So, with 
jtreg '-a' the test will be skipped. So, no dependences on java.desktop 
module.

Thanks,
Alexander


From xueming.shen at oracle.com  Wed Aug  5 19:04:50 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 05 Aug 2015 12:04:50 -0700
Subject: RFR JDK-8022224: Intermittent test failures in
	sun/nio/cs/FindDecoderBugs.java, , 
Message-ID: <55C25E52.3010703@oracle.com>

Hi,

Would you please help review the proposed change for  JDK-8022224.

issue: https://bugs.openjdk.java.net/browse/JDK-8022224
webrev: http://cr.openjdk.java.net/~sherman/8022224/

The fix for this particular problem is at ln#135-#137. The rest is the
clean to remove unused the code (was for the sun.nio.cs impl, which
had been completely removed since jdk7).

Thanks,
-Sherman


From chris.hegarty at oracle.com  Wed Aug  5 19:29:36 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 5 Aug 2015 20:29:36 +0100
Subject: RFR JDK-8022224: Intermittent test failures in
	sun/nio/cs/FindDecoderBugs.java, , 
In-Reply-To: <55C25E52.3010703@oracle.com>
References: <55C25E52.3010703@oracle.com>
Message-ID: <921713F5-73B0-4F16-B89C-F997B1C60E8F@oracle.com>

The change looks ok to me Sherman.

Should the bug synopsis be updated? It looks like a test bug rather than a product one.

-Chris

> On 5 Aug 2015, at 20:04, Xueming Shen  wrote:
> 
> Hi,
> 
> Would you please help review the proposed change for  JDK-8022224.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8022224
> webrev: http://cr.openjdk.java.net/~sherman/8022224/
> 
> The fix for this particular problem is at ln#135-#137. The rest is the
> clean to remove unused the code (was for the sun.nio.cs impl, which
> had been completely removed since jdk7).
> 
> Thanks,
> -Sherman


From stuart.marks at oracle.com  Wed Aug  5 19:46:51 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 5 Aug 2015 12:46:51 -0700
Subject: RFR [9] 8132468: docs: replace  tags (obsolete in html5) for
	java.io, java.lang, java.math
In-Reply-To: <55C1FB0A.9070204@oracle.com>
References: <55BF34DB.8090106@oracle.com> <55BF5BD7.30101@oracle.com>
	<55BF6139.9020805@oracle.com> <55BF8396.4090109@oracle.com>
	<84C4434E-679A-48C4-B507-AC266BEC64F4@oracle.com>
	<55BF90DE.1000202@oracle.com> <55BFE167.6030606@oracle.com>
	<55C1FB0A.9070204@oracle.com>
Message-ID: <55C2682B.6030106@oracle.com>

Hi Alexander,

The changes to File.java look good. Thanks for doing the specdiffs as well; it's 
a good way to verify that even with all these markup changes, specdiff didn't 
detect any changes to java.io.File at all.

(I didn't look at other files; I'm presuming that others have.)

s'marks

On 8/5/15 5:01 AM, Alexander Stepanov wrote:
> Hello Stuart,
>
> Please see the final version of File.java (please update the page) - just
> replacing  with  in the mentioned places:
> http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/src/java.base/share/classes/java/io/File.java.udiff.html
>
> The specdiff reports for lang and io:
> http://cr.openjdk.java.net/~avstepan/8132468/specdiff.io/overview-summary.html
> http://cr.openjdk.java.net/~avstepan/8132468/specdiff.lang/overview-summary.html
>
> Regards,
> Alexander
>
> On 8/4/2015 12:47 AM, Stuart Marks wrote:
>> Hi Alexander,
>>
>> I think Pavel's advice to run specdiff is useful. It's not too difficult to
>> run and in this case it provides a useful cross-check for making a large
>> number of markup changes. Contact me directly if you need help with specdiff.
>> I've run specdiff over your webrev.01 and I've posted the results here:
>>
>> http://cr.openjdk.java.net/~smarks/reviews/8132468/specdiff.01/overview-summary.html
>>
>>
>> They show that of all the changes you made, only four are considered
>> significant from specdiff's point of view. Of these, two appear to be merely
>> whitespace issues, but there are two changes that do appear significant:
>>
>>     File(URI)     // constructor
>>     File.toURI()
>>
>> In both cases the italic 'f' is intended to be a metasyntactic variable, not
>> an actual variable that's part of the code. The italic 'f' should be restored.
>> In the case of File.toURI() it appears that the resulting code is now
>> malformed, so there's clearly an error here.
>>
>> You and Daniel Fuchs had an exchange about this a bit earlier. I suspect the
>> reason for the   that appears between the opening parenthesis and the
>> italic 'f' is so that the tail of the 'f' doesn't crash into parenthesis. In
>> other words, the   is there merely for typographical purposes. I suspect
>> that after you restore the italic 'f' it'll look bad, so you'll want to
>> restore the   as well.
>>
>> s'marks
>>
>> On 8/3/15 9:03 AM, Alexander Stepanov wrote:
>>> Hello Pavel
>>>
>>>  > Hi Alexander, if I were you I would run specdiff
>>> Thanks; but sorry, I'm afraid I haven't enough time for the extra experiments
>>> just now...
>>>
>>>  > It's very easy to go the all the way and lose oneself in there :)
>>> please accept my condolences :)
>>>
>>> Regards,
>>> Alexander
>>>
>>> On 8/3/2015 6:33 PM, Pavel Rappo wrote:
>>>>> On 3 Aug 2015, at 16:07, Alexander Stepanov 
>>>>> wrote:
>>>>>
>>>>> Please see the updated webrev:
>>>>> http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/
>>>>>
>>>>> removed wrapping  around the links (mostly PrintStream.java,
>>>>> PrintWriter.java, File.java), plus other changes in File.java
>>>>>
>>>>> Thanks,
>>>>> Alexander
>>>> Hi Alexander, if I were you I would run specdiff against the changes and
>>>> upload it along with the RFR.
>>>>
>>>> P.S. "I've tried it once, it was awful." [1] It's very easy to go the all the
>>>> way and lose oneself in there :)
>>>>
>>>> ------------------------------------------------------------------------------
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030262.html
>>>>
>>>> -Pavel
>>>>
>>>
>


From volker.simonis at gmail.com  Wed Aug  5 19:56:22 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 5 Aug 2015 21:56:22 +0200
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: <55BBE261.4060902@oracle.com>
References: <55B6938E.2010806@Oracle.com> <55B6940D.90701@Oracle.com>
	
	<55BAC679.7010108@oracle.com>
	
	<55BBA878.3090509@Oracle.com> <55BBE261.4060902@oracle.com>
Message-ID: 

Hi,

so here's the webrev which implements the new Info.commandLine()
method (I chose 'commandLine() ' instead of 'cmdline()' or
'commandline()' because the other getters are camel case as well):

http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v4/

>From the JavaDoc of the new method:

* If {@code command()} and  {@code arguments()} return non-null
* optionals, this is simply a convenience method which concatenates
* the values of the two functions. Otherwise it will return a
* best-effort, platform dependent representation of the command line.

This didn't change anything on MacOS X where there is no additional
effort to get the command line.

On Solaris and AIX, Info.commandLine() will always return the contents
of psinfo.pr_psargs because there's no other method to get the exact
arguments (i.e. Info.arguments() always returns NULL. I could
therefore remove the extra handling of AIX/Solaris in the InfoTest
from my initial change.

On Linux, things are a little more complicated:

- the initial implementation for Linux used arg[0] as 'command' if
/proc/pid/exe wasn't readable. This was true for all the processes we
don't own (except if we are running as root). But this information may
be incomplete, because arg[0] may only contain the command without its
full path. One example is 'sendmail' for which Info.command() reported
"sendmail: accepting connections" but Info.arguments() was empty. This
is wrong, because 'sendmail' changes its argv[] array. I have
therefore disabled this behavior now that we have the 'commandLine()'
method.

- /proc/pid/cmdline is limited to PAGE_SIZE (normally 4096) characters
on Linux. So strictly speaking, this isn't 'exact' information as well
(there are plenty of complains that especially for Java programs this
is not enough) and should go to 'commandLine()' instead to 'arguments'
if /proc/pid/cmdline is truncated. I do check for this now.

- the information in /proc/pid/cmdline can also be changed to
something other than the original arguments if a program changes
argv[] (which is not forbidden) but there's probably not much we can
do to detect this. I've added a corresponding @implNote comment to
JavaDoc of Info.arguments().

- the initial implementation did not check for incomplete reads of
/proc/pid/cmdline. This may be a problem on systems with PAGE_SIZE >
4096 (on Linux/ppc64 a page size of 65536 is not unusual). I'm now
always reading the complete contents of /proc/pid/cmdline.

- as far as I understand the current implementation, 'arguments()'
returns the arguments array WITHOUT 'arg[0]' (which is the program
name) but may
be we should specify that more clearly in the JavaDoc of 'arguments()'.

That's it. Hope you like it :)

Regards,
Volker

On Fri, Jul 31, 2015 at 11:02 PM, Stuart Marks  wrote:
> Hi Roger, Volker,
>
> Glad to see you guys are receptive to this and that it can move forward. Let
> me know if you'd like me to help out, for example with reviews or something.
>
> s'marks
>
>
> On 7/31/15 9:55 AM, Roger Riggs wrote:
>>
>> Hi Volker,
>>
>> I agree that adding an Info.commandline() method would be a good way
>> to make the command line available and be able to describe that it is
>> OS dependent and may be truncated.
>> And having it assemble the command and arguments when they are available
>> makes
>> sense.
>> As an API addition it will need a clear spec and I can run it through CCC
>> so it
>> gets
>> another review and compatibility tests.
>>
>> Thanks, Roger
>>
>>
>>
>>
>> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>>>
>>> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks 
>>> wrote:
>>>>
>>>>
>>>> On 7/29/15 11:36 AM, Volker Simonis wrote:
>>>>>>
>>>>>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>>>>>> truncated or incomplete
>>>>>> values for the executable or arguments.
>>>>>> Can anyone be a tie-breaker  (with a good rational and suggestion for
>>>>>> how
>>>>>> an
>>>>>> application can use the data).
>>>>>
>>>>>
>>>>> As I wrote, I agree to hear other opinions here.
>>>>>
>>>>> All I want to say that this truncated data is actually what 'ps' is
>>>>> reporting on Solaris since decades and people seem to be happy with
>>>>> it. As use case I can imagine logging or monitoring (something like
>>>>> 'top' in Java) where this data will be just good enough.
>>>>>
>>>>> We could specially mark possibly incomplete data by extending the Info
>>>>> object with functions like commandIsExact() or argumentsIsPrecise().
>>>>> But notice that we can not statically preset these values per
>>>>> platform. For example on Solaris, the 'command()' would return a
>>>>> precise value for processes with the same uid like the VM but only
>>>>> inaccurate values for all other processes. The "arguments()" would be
>>>>> always inaccurate on Solaris/AIX.
>>>>
>>>>
>>>> It seems like there are cases where either exact or only approximate
>>>> information is available. And as you observed, you might get one or the
>>>> other on the same platform, depending on the UID. It also might depend
>>>> on
>>>> process state; I believe that some information becomes inaccessible when
>>>> the
>>>> process enters the zombie state.
>>>>
>>>> I don't think we should simply ignore one case or the other, but I also
>>>> don't think we should try to cram the different information into the
>>>> same
>>>> API.
>>>>
>>>> The current ProcessHandle.Info api has
>>>>
>>>>      Optional command()
>>>>      Optional arguments()
>>>>
>>>> It sounds to me like Roger wants these to contain only exact
>>>> information.
>>>> That seems reasonable, and this probably needs to be specified more
>>>> clearly
>>>> to contrast with what's below.
>>>>
>>>> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
>>>> single string which appears to be the concatenation of the arguments
>>>> (maybe
>>>> including the command name). It's also truncated to fit PRARGSZ. It
>>>> doesn't
>>>> make sense to me to try to return this as a String[], as the zeroth
>>>> element
>>>> of that array, and certainly not parsed out into "words". So maybe
>>>> instead
>>>> we should have a different API that returns an imprecise command line as
>>>> a
>>>> single string:
>>>>
>>>>      Optional cmdline()
>>>>
>>>> (Naming bikeshed TBS). The semantics would be that this is the process'
>>>> command and arguments concatenated into a single string (thus
>>>> potentially
>>>> losing argument boundaries) and also possibly truncated based on
>>>> platform
>>>> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out
>>>> in a
>>>> ps, top, or Activity Monitor style application, for informational
>>>> purposes.
>>>>
>>>> If this were implemented, then on Solaris, command() and arguments()
>>>> would
>>>> always return empty optionals.
>>>>
>>>> I'm not sure what this should be if the exact information is available.
>>>> It
>>>> would be inconvenient if something that just wanted to print out an
>>>> approximate command line had to check several different APIs to get the
>>>> information. Maybe cmdline() could assemble the information from exact
>>>> data
>>>> if it's is available, by concatenating the Strings from command() and
>>>> arguments(), as a convenience to the caller. But I could go either way
>>>> on
>>>> this.
>>>>
>>>> Not sure this counts as a tie-breaker, but it might be a reasonable way
>>>> forward.
>>>>
>>>> s'marks
>>>>
>>> Hi Stuart,
>>>
>>> thanks a lot for your comments - I like your proposal. For me this
>>> sounds like a good compromise.
>>>
>>> @Roger: should I go and add a new field commandLine and the
>>> corresponding getter to the Info class? As Stuart proposed, the getter
>>> could check if 'command' and 'arguments' are available and assemble
>>> the command line from them. Otherwise it could use the content of the
>>> commandLine field if that is available.
>>>
>>> Regards,
>>> Volker
>>
>>
>


From martinrb at google.com  Wed Aug  5 23:28:27 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 5 Aug 2015 16:28:27 -0700
Subject: RFR JDK-8022224: Intermittent test failures in
	sun/nio/cs/FindDecoderBugs.java, ,
In-Reply-To: <921713F5-73B0-4F16-B89C-F997B1C60E8F@oracle.com>
References: <55C25E52.3010703@oracle.com>
	<921713F5-73B0-4F16-B89C-F997B1C60E8F@oracle.com>
Message-ID: 

On Wed, Aug 5, 2015 at 12:29 PM, Chris Hegarty 
wrote:

> The change looks ok to me Sherman.
>
> Should the bug synopsis be updated? It looks like a test bug rather than a
> product one.
>

Why do you say that?  The JISAutoDetect charset is being fixed here, no?

Sherman: Thanks for fixing this.  I've observed this in the wild a couple
of times myself.

(Although flaky tests are annoying, finding actual bugs makes it so worth
it!)


From huizhe.wang at oracle.com  Thu Aug  6 00:13:29 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 05 Aug 2015 17:13:29 -0700
Subject: Review request for JDK-8132660: Change jaxp unit test package
	name to be different with jaxp api
In-Reply-To: <014201d0cf66$22baddb0$68309910$@oracle.com>
References: <02d901d0ce82$08329f30$1897dd90$@oracle.com>
	<55C103C6.2020702@oracle.com>
	<014201d0cf66$22baddb0$68309910$@oracle.com>
Message-ID: <55C2A6A9.1090800@oracle.com>

Hi Frank,

This looks good to me.

Best,
Joe

On 8/5/2015 3:04 AM, Frank Yuan wrote:
>
> Hi Joe
>
> Thank you very much! Really good advice! I have adjusted as it, please 
> re-check at:
>
> http://cr.openjdk.java.net/~fyuan/8132660/webrev.01/ 
> 
>
> Btw, I only applied this practice on unit test, not for functional 
> test because Tristan still has a functional suite pending, I would 
> unify the functional part sometime after that suite is finished.
>
> Best Regards
>
> Frank
>
> *From:*huizhe wang [mailto:huizhe.wang at oracle.com]
> *Sent:* Wednesday, August 05, 2015 2:26 AM
> *To:* Frank Yuan 
> *Cc:* 'core-libs-dev' ; 'Alan Bateman' 
> ; 'Jan Lahoda' 
> *Subject:* Re: Review request for JDK-8132660: Change jaxp unit test 
> package name to be different with jaxp api
>
> Hi Frank,
>
> That looks fine. However, instead of appending an additional directory 
> "utests", you could make the paths shorter by removing "javax/xml" and 
> "org/w3c" or "org/xml". The short names are good enough to represent 
> the API names, test/javax/xml/jaxp/unittest/parsers for example, is 
> easily recognizable as a package that holds the tests for 
> javax/xml/parsers. JAXP tests currently in the jdk test repositories 
> are named using this approach.
>
> Thanks,
> Joe
>
> On 8/3/2015 11:51 PM, Frank Yuan wrote:
>
>     Hi, Joe and all
>
>     Would you like to have a review for bug
>     https://bugs.openjdk.java.net/browse/JDK-8132660?
>
>     This is already on our plan for a while, but I have to finish it
>     now because these unit tests failed with latest Jigsaw build.
>     However I made the changes based on 9-dev repo, I tested them with
>     both Jigsaw build and 9-dev build. The JPRT successful mail is
>     enclosed in the bug.
>
>     The webrev is at:
>     http://cr.openjdk.java.net/~fyuan/8132660/webrev.00/
>     . It seems
>     to be a big change but actually there are only some directories
>     changed.
>
>     Thanks,
>
>     Frank
>



From Kirk.Shoop at microsoft.com  Thu Aug  6 02:45:09 2015
From: Kirk.Shoop at microsoft.com (Kirk Shoop)
Date: Thu, 6 Aug 2015 02:45:09 +0000
Subject: RFR 8124977 cmdline encoding challenges on Windows
In-Reply-To: <55AD42ED.3040102@oracle.com>
References: 
	
	<558C017A.2020708@oracle.com>
	
	<55A16577.8050302@oracle.com>
	
	<55AD42ED.3040102@oracle.com>
Message-ID: 

> -----Original Message-----
> From: Xueming Shen [mailto:xueming.shen at oracle.com]
> Sent: Monday, July 20, 2015 11:50 AM
> 
> On 07/20/2015 10:22 AM, Kirk Shoop wrote:
> > So when default system locale differs from the active one, we have
> different behavior on Linux and Windows. The new options allow a windows
> user to select the same behavior that one would expect on unix. The
> switches can certainly be removed, if the compatibility impact is acceptable.
> 
> Kirk, on Windows file.encoding is from the user locale and the
> sun.jnu.encoding is from the system locale setting. sun.jnu.encoding is
> purely for those text encoding sensitive jnu functiond to communicate with
> the underlying windows system api, when the system locale and the user
> locale are set to different value. On unix/linux/osx, these two are always set
> to the same value. Yes, they might be input/output issue if the encoding
> used by the console (oem codepage) is not compatible with the encoding
> used by the "user locale"
> and you are trying to use System.in/out/err for the input/output to the
> console.
> 
> Here is the original CCC request regarding the sun.jnu.encoding, which might
> provide some background info.
> 
> http://cr.openjdk.java.net/~sherman/4958170.html
> 
> If you/we are NOT going to change the encoding used by the underlying
> console, I don't think we need/should change the "encoding" used by the
> java.io.Console. As I suggested in my previously email, the
> Java_java_io_Console_encoding() implementation probably need to update
> to return utf8 if the cp == 65001 (that was 10 years ago, I'm not sure if the
> 65001 was really used back then when we wrote this code).  My
> understanding of the issue here is that if you continue to use the "A" version
> of the API to parse/get the arguments, and try to solve the possible issue
> triggered by the "incompatibility" of the oem encoding used by the console
> and the user locale encoding used by the System.in/ out/err, it's fine to
> define a new system property to specify a preferred encoding for the
> launcher to use, but this "preferred" encoding should not be used by
> java.io.Console.
> But isn't it more reasonable to simply always use the "W" version for this
> purpose in launcher?
> 
> -Sherman
> 

Thank you for the valuable feedback. We have vastly simplified the original patch. 
The new webrev is here:
  http://cr.openjdk.java.net/~kshoop/8124977/webrev.02/ 

This webrev uses GetCommandLineW on windows to retrieve the UCS16 commandline and also supports the 65001(UTF-8) codepage (set by chcp 65001) so that when -Dsun.jnu.encoding="UTF-8" is supplied the console output (stdout & stderr) will be in UTF8.

There are no new commandline switches.

Please let us know if there is anything else that needs improvement.

Thanks!
Kirk and Valery



From daniel.fuchs at oracle.com  Thu Aug  6 07:18:19 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 6 Aug 2015 09:18:19 +0200
Subject: RFR [9] 8132468: docs: replace  tags (obsolete in html5) for
	java.io, java.lang, java.math
In-Reply-To: <55C1FB0A.9070204@oracle.com>
References: <55BF34DB.8090106@oracle.com> <55BF5BD7.30101@oracle.com>
	<55BF6139.9020805@oracle.com> <55BF8396.4090109@oracle.com>
	<84C4434E-679A-48C4-B507-AC266BEC64F4@oracle.com>
	<55BF90DE.1000202@oracle.com> <55BFE167.6030606@oracle.com>
	<55C1FB0A.9070204@oracle.com>
Message-ID: <55C30A3B.5040004@oracle.com>

Hi Alexander,

On 8/5/15 2:01 PM, Alexander Stepanov wrote:
> Hello Stuart,
>
> Please see the final version of File.java (please update the page) - 
> just replacing  with  in the mentioned places:
> http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/src/java.base/share/classes/java/io/File.java.udiff.html 
>
> The specdiff reports for lang and io:
> http://cr.openjdk.java.net/~avstepan/8132468/specdiff.io/overview-summary.html 
>
> http://cr.openjdk.java.net/~avstepan/8132468/specdiff.lang/overview-summary.html 
>

This looks good to me as well.

best regards,

-- daniel
>
> Regards,
> Alexander
>
> On 8/4/2015 12:47 AM, Stuart Marks wrote:
>> Hi Alexander,
>>
>> I think Pavel's advice to run specdiff is useful. It's not too 
>> difficult to run and in this case it provides a useful cross-check 
>> for making a large number of markup changes. Contact me directly if 
>> you need help with specdiff. I've run specdiff over your webrev.01 
>> and I've posted the results here:
>>
>> http://cr.openjdk.java.net/~smarks/reviews/8132468/specdiff.01/overview-summary.html 
>>
>>
>> They show that of all the changes you made, only four are considered 
>> significant from specdiff's point of view. Of these, two appear to be 
>> merely whitespace issues, but there are two changes that do appear 
>> significant:
>>
>>     File(URI)     // constructor
>>     File.toURI()
>>
>> In both cases the italic 'f' is intended to be a metasyntactic 
>> variable, not an actual variable that's part of the code. The italic 
>> 'f' should be restored. In the case of File.toURI() it appears that 
>> the resulting code is now malformed, so there's clearly an error here.
>>
>> You and Daniel Fuchs had an exchange about this a bit earlier. I 
>> suspect the reason for the   that appears between the opening 
>> parenthesis and the italic 'f' is so that the tail of the 'f' doesn't 
>> crash into parenthesis. In other words, the   is there merely 
>> for typographical purposes. I suspect that after you restore the 
>> italic 'f' it'll look bad, so you'll want to restore the   as well.
>>
>> s'marks
>>
>> On 8/3/15 9:03 AM, Alexander Stepanov wrote:
>>> Hello Pavel
>>>
>>>  > Hi Alexander, if I were you I would run specdiff
>>> Thanks; but sorry, I'm afraid I haven't enough time for the extra 
>>> experiments
>>> just now...
>>>
>>>  > It's very easy to go the all the way and lose oneself in there :)
>>> please accept my condolences :)
>>>
>>> Regards,
>>> Alexander
>>>
>>> On 8/3/2015 6:33 PM, Pavel Rappo wrote:
>>>>> On 3 Aug 2015, at 16:07, Alexander Stepanov 
>>>>> 
>>>>> wrote:
>>>>>
>>>>> Please see the updated webrev:
>>>>> http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/
>>>>>
>>>>> removed wrapping  around the links (mostly 
>>>>> PrintStream.java,
>>>>> PrintWriter.java, File.java), plus other changes in File.java
>>>>>
>>>>> Thanks,
>>>>> Alexander
>>>> Hi Alexander, if I were you I would run specdiff against the 
>>>> changes and
>>>> upload it along with the RFR.
>>>>
>>>> P.S. "I've tried it once, it was awful." [1] It's very easy to go 
>>>> the all the
>>>> way and lose oneself in there :)
>>>>
>>>> ------------------------------------------------------------------------------ 
>>>>
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030262.html 
>>>>
>>>>
>>>> -Pavel
>>>>
>>>
>



From chris.hegarty at oracle.com  Thu Aug  6 07:52:27 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 6 Aug 2015 08:52:27 +0100
Subject: RFR JDK-8022224: Intermittent test failures in
	sun/nio/cs/FindDecoderBugs.java, , 
In-Reply-To: 
References: <55C25E52.3010703@oracle.com>
	<921713F5-73B0-4F16-B89C-F997B1C60E8F@oracle.com>
	
Message-ID: <9C0CCB2B-AD57-4709-8C26-C18586A38CA6@oracle.com>


On 6 Aug 2015, at 00:28, Martin Buchholz  wrote:
> 
> On Wed, Aug 5, 2015 at 12:29 PM, Chris Hegarty  wrote:
> The change looks ok to me Sherman.
> 
> Should the bug synopsis be updated? It looks like a test bug rather than a product one.
> 
> Why do you say that?  The JISAutoDetect charset is being fixed here, no?

When I first looked at this I expected it to be a test only bug. I was just initially surprised to see that it was actually a product bug.  I guess I think the synopsis should read something like ?Fix JISAutoDetect charset?, or something, rather than specifically mentioning a jdk regression test.  Given both Sherman?s and your comments, this is not worth debating.

> Sherman: Thanks for fixing this.  I've observed this in the wild a couple of times myself. 
> 
> (Although flaky tests are annoying, finding actual bugs makes it so worth it!)

Right.

-Chris.



From konstantin.shefov at oracle.com  Thu Aug  6 09:52:19 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Thu, 06 Aug 2015 12:52:19 +0300
Subject: [9] RFR: 8060717: [TESTBUG] Improve test coverage of
	MethodHandles.explicitCastArguments()
In-Reply-To: <55BF838D.7080202@oracle.com>
References: <55BBA449.1030603@oracle.com>
	<0B7B1F71-0BE3-400E-A6C2-5FD01E13777A@oracle.com>
	<55BF838D.7080202@oracle.com>
Message-ID: <55C32E53.1050704@oracle.com>

Kindly reminder

On 08/03/2015 06:06 PM, Konstantin Shefov wrote:
> Michael, thanks for reviewing!
>
> Vladimir, could you take a look, please?
>
> -Konstantin
>
> On 08/02/2015 05:31 PM, Michael Haupt wrote:
>> Hi Konstantin,
>>
>>> Am 31.07.2015 um 18:37 schrieb Konstantin Shefov 
>>> >:
>>> Please review a test improvement. Covered more cases for 
>>> MethodHandles.explicitCastArguments().
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060717
>>> Webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.00/ 
>>> 
>>
>> note that mine is a lower-case review and does not count, but: thumbs 
>> up. The level of detail at which the API is tested improves 
>> significantly with these changes.
>>
>> Best,
>>
>> Michael
>>
>> -- 
>>
>> Oracle 
>> Dr. Michael Haupt | Principal Member of Technical Staff
>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>> OracleJava Platform Group | LangTools Team | Nashorn
>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 
>> Potsdam, Germany
>> Green Oracle  	Oracle is committed 
>> to developing practices and products that help protect the environment
>>
>>
>



From vladimir.x.ivanov at oracle.com  Thu Aug  6 10:02:57 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 06 Aug 2015 13:02:57 +0300
Subject: [9] RFR: 8060717: [TESTBUG] Improve test coverage of
	MethodHandles.explicitCastArguments()
In-Reply-To: <55BF838D.7080202@oracle.com>
References: <55BBA449.1030603@oracle.com>
	<0B7B1F71-0BE3-400E-A6C2-5FD01E13777A@oracle.com>
	<55BF838D.7080202@oracle.com>
Message-ID: <55C330D1.80307@oracle.com>

Konstantin,

Overall, looks good.

Why do you create a new ClassLoader here and not simply reference them 
directly (they are loaded by application class loader)?
+    public static void testNonBCPRef2Ref() throws Throwable {
+        String testClassPath = System.getProperty("test.classes",".");
+        URL[] classpath = {(new File(testClassPath)).getCanonicalFile()
+            .toURI().toURL()};
+        URLClassLoader ucl = URLClassLoader.newInstance(classpath);
+        Class testInterface = ucl.loadClass(THIS_CLASS.getSimpleName()
+                + "$TestInterface");
+        Class testSuperClass = ucl.loadClass(THIS_CLASS.getSimpleName()
+                + "$TestSuperClass");
+        Class testSubClass1 = ucl.loadClass(THIS_CLASS.getSimpleName()
+                + "$TestSubClass1");

I see BCP-to-BCP & non-BCP-to-non-BCP ref-to-ref cases covered. What 
about BCP-to-non-BCP & non-BCP-to-BCP cases?

Best regards,
Vladimir Ivanov

On 8/3/15 6:06 PM, Konstantin Shefov wrote:
> Michael, thanks for reviewing!
>
> Vladimir, could you take a look, please?
>
> -Konstantin
>
> On 08/02/2015 05:31 PM, Michael Haupt wrote:
>> Hi Konstantin,
>>
>>> Am 31.07.2015 um 18:37 schrieb Konstantin Shefov
>>> >:
>>> Please review a test improvement. Covered more cases for
>>> MethodHandles.explicitCastArguments().
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060717
>>> Webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.00/
>>> 
>>
>> note that mine is a lower-case review and does not count, but: thumbs
>> up. The level of detail at which the API is tested improves
>> significantly with these changes.
>>
>> Best,
>>
>> Michael
>>
>> --
>>
>> Oracle 
>> Dr. Michael Haupt | Principal Member of Technical Staff
>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>> OracleJava Platform Group | LangTools Team | Nashorn
>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam,
>> Germany
>> Green Oracle  	Oracle is committed
>> to developing practices and products that help protect the environment
>>
>>
>


From alexander.v.stepanov at oracle.com  Thu Aug  6 10:06:05 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Thu, 06 Aug 2015 13:06:05 +0300
Subject: RFR [9] 8132468: docs: replace  tags (obsolete in html5)
	for java.io, java.lang, java.math
In-Reply-To: <55C2682B.6030106@oracle.com>
References: <55BF34DB.8090106@oracle.com> <55BF5BD7.30101@oracle.com>
	<55BF6139.9020805@oracle.com> <55BF8396.4090109@oracle.com>
	<84C4434E-679A-48C4-B507-AC266BEC64F4@oracle.com>
	<55BF90DE.1000202@oracle.com> <55BFE167.6030606@oracle.com>
	<55C1FB0A.9070204@oracle.com> <55C2682B.6030106@oracle.com>
Message-ID: <55C3318D.3000509@oracle.com>

Thanks!

On 8/5/2015 10:46 PM, Stuart Marks wrote:
> Hi Alexander,
>
> The changes to File.java look good. Thanks for doing the specdiffs as 
> well; it's a good way to verify that even with all these markup 
> changes, specdiff didn't detect any changes to java.io.File at all.
>
> (I didn't look at other files; I'm presuming that others have.)
>
> s'marks
>
> On 8/5/15 5:01 AM, Alexander Stepanov wrote:
>> Hello Stuart,
>>
>> Please see the final version of File.java (please update the page) - 
>> just
>> replacing  with  in the mentioned places:
>> http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/src/java.base/share/classes/java/io/File.java.udiff.html 
>>
>>
>> The specdiff reports for lang and io:
>> http://cr.openjdk.java.net/~avstepan/8132468/specdiff.io/overview-summary.html 
>>
>> http://cr.openjdk.java.net/~avstepan/8132468/specdiff.lang/overview-summary.html 
>>
>>
>> Regards,
>> Alexander
>>
>> On 8/4/2015 12:47 AM, Stuart Marks wrote:
>>> Hi Alexander,
>>>
>>> I think Pavel's advice to run specdiff is useful. It's not too 
>>> difficult to
>>> run and in this case it provides a useful cross-check for making a 
>>> large
>>> number of markup changes. Contact me directly if you need help with 
>>> specdiff.
>>> I've run specdiff over your webrev.01 and I've posted the results here:
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/8132468/specdiff.01/overview-summary.html 
>>>
>>>
>>>
>>> They show that of all the changes you made, only four are considered
>>> significant from specdiff's point of view. Of these, two appear to 
>>> be merely
>>> whitespace issues, but there are two changes that do appear 
>>> significant:
>>>
>>>     File(URI)     // constructor
>>>     File.toURI()
>>>
>>> In both cases the italic 'f' is intended to be a metasyntactic 
>>> variable, not
>>> an actual variable that's part of the code. The italic 'f' should be 
>>> restored.
>>> In the case of File.toURI() it appears that the resulting code is now
>>> malformed, so there's clearly an error here.
>>>
>>> You and Daniel Fuchs had an exchange about this a bit earlier. I 
>>> suspect the
>>> reason for the   that appears between the opening parenthesis 
>>> and the
>>> italic 'f' is so that the tail of the 'f' doesn't crash into 
>>> parenthesis. In
>>> other words, the   is there merely for typographical purposes. 
>>> I suspect
>>> that after you restore the italic 'f' it'll look bad, so you'll want to
>>> restore the   as well.
>>>
>>> s'marks
>>>
>>> On 8/3/15 9:03 AM, Alexander Stepanov wrote:
>>>> Hello Pavel
>>>>
>>>>  > Hi Alexander, if I were you I would run specdiff
>>>> Thanks; but sorry, I'm afraid I haven't enough time for the extra 
>>>> experiments
>>>> just now...
>>>>
>>>>  > It's very easy to go the all the way and lose oneself in there :)
>>>> please accept my condolences :)
>>>>
>>>> Regards,
>>>> Alexander
>>>>
>>>> On 8/3/2015 6:33 PM, Pavel Rappo wrote:
>>>>>> On 3 Aug 2015, at 16:07, Alexander Stepanov 
>>>>>> 
>>>>>> wrote:
>>>>>>
>>>>>> Please see the updated webrev:
>>>>>> http://cr.openjdk.java.net/~avstepan/8132468/webrev.01/
>>>>>>
>>>>>> removed wrapping  around the links (mostly 
>>>>>> PrintStream.java,
>>>>>> PrintWriter.java, File.java), plus other changes in File.java
>>>>>>
>>>>>> Thanks,
>>>>>> Alexander
>>>>> Hi Alexander, if I were you I would run specdiff against the 
>>>>> changes and
>>>>> upload it along with the RFR.
>>>>>
>>>>> P.S. "I've tried it once, it was awful." [1] It's very easy to go 
>>>>> the all the
>>>>> way and lose oneself in there :)
>>>>>
>>>>> ------------------------------------------------------------------------------ 
>>>>>
>>>>> [1]
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030262.html 
>>>>>
>>>>>
>>>>> -Pavel
>>>>>
>>>>
>>



From daniel.fuchs at oracle.com  Thu Aug  6 10:14:50 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 06 Aug 2015 12:14:50 +0200
Subject: RFR [9] 8133040: docs: replace  tags (obsolete in html5)
	for java.management
In-Reply-To: <55C249F0.5080501@oracle.com>
References: <55C24656.5090108@oracle.com> <55C249F0.5080501@oracle.com>
Message-ID: <55C3339A.6080200@oracle.com>

Hi Alexander,

Cursory inspection of the patch file has not revealed anything wrong.
Specdiff looks OK, so that's good for me.

best regards,

-- daniel

On 05/08/15 19:37, Alexander Stepanov wrote:
>  > javax.management - one (expected) change in TabularDataSupport:
> (full package diff:
> http://cr.openjdk.java.net/~avstepan/8133040/javax.management/overview-summary.html)
>
>
> On 8/5/2015 8:22 PM, Alexander Stepanov wrote:
>> Hello,
>>
>> Could you please review the following fix:
>> http://cr.openjdk.java.net/~avstepan/8133040/webrev.00
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8133040
>>
>> specdiffs:
>> java.lang.management - no changes detected:
>> http://cr.openjdk.java.net/~avstepan/8133040/java.lang.management/overview-summary.html
>>
>> javax.management - one (expected) change in TabularDataSupport:
>> http://cr.openjdk.java.net/~avstepan/8133040/javax.management/openmbean/package-summary.html
>>
>>
>> Regards,
>> Alexander
>



From alexander.v.stepanov at oracle.com  Thu Aug  6 10:25:09 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Thu, 06 Aug 2015 13:25:09 +0300
Subject: RFR [9] 8133040: docs: replace  tags (obsolete in html5)
	for java.management
In-Reply-To: <55C3339A.6080200@oracle.com>
References: <55C24656.5090108@oracle.com> <55C249F0.5080501@oracle.com>
	<55C3339A.6080200@oracle.com>
Message-ID: <55C33605.7080907@oracle.com>

Hello Daniel,

Thanks!

Regards,
Alexander

On 8/6/2015 1:14 PM, Daniel Fuchs wrote:
> Hi Alexander,
>
> Cursory inspection of the patch file has not revealed anything wrong.
> Specdiff looks OK, so that's good for me.
>
> best regards,
>
> -- daniel
>
> On 05/08/15 19:37, Alexander Stepanov wrote:
>>  > javax.management - one (expected) change in TabularDataSupport:
>> (full package diff:
>> http://cr.openjdk.java.net/~avstepan/8133040/javax.management/overview-summary.html) 
>>
>>
>>
>> On 8/5/2015 8:22 PM, Alexander Stepanov wrote:
>>> Hello,
>>>
>>> Could you please review the following fix:
>>> http://cr.openjdk.java.net/~avstepan/8133040/webrev.00
>>> for
>>> https://bugs.openjdk.java.net/browse/JDK-8133040
>>>
>>> specdiffs:
>>> java.lang.management - no changes detected:
>>> http://cr.openjdk.java.net/~avstepan/8133040/java.lang.management/overview-summary.html 
>>>
>>>
>>> javax.management - one (expected) change in TabularDataSupport:
>>> http://cr.openjdk.java.net/~avstepan/8133040/javax.management/openmbean/package-summary.html 
>>>
>>>
>>>
>>> Regards,
>>> Alexander
>>
>



From konstantin.shefov at oracle.com  Thu Aug  6 11:06:25 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Thu, 06 Aug 2015 14:06:25 +0300
Subject: [9] RFR: 8060717: [TESTBUG] Improve test coverage of
	MethodHandles.explicitCastArguments()
In-Reply-To: <55C330D1.80307@oracle.com>
References: <55BBA449.1030603@oracle.com>
	<0B7B1F71-0BE3-400E-A6C2-5FD01E13777A@oracle.com>
	<55BF838D.7080202@oracle.com> <55C330D1.80307@oracle.com>
Message-ID: <55C33FB1.5000708@oracle.com>

Hi Vladimir

Thanks for reviewing


On 08/06/2015 01:02 PM, Vladimir Ivanov wrote:
> Konstantin,
>
> Overall, looks good.
>
> Why do you create a new ClassLoader here and not simply reference them 
> directly (they are loaded by application class loader)?
You a right. Because of class loader hierarchy, all "Test*" classes in 
this case are loaded by app class loader as an ancestor of url class 
loader, so it is the same as just reference them directly.
To make the "Test*" classes loaded by ucl, they need to be outside of 
classpath, which will produce extra folders and ".java" files in test 
workspace.

I think non-bcp to bcp test will play just the same role (work with 
classes loaded by different class loaders).

So I will correct the code. I will add BCP-to-non-BCP & non-BCP-to-BCP 
cases and remove url classloader.

-Konstantin
> + public static void testNonBCPRef2Ref() throws Throwable {
> +        String testClassPath = System.getProperty("test.classes",".");
> +        URL[] classpath = {(new File(testClassPath)).getCanonicalFile()
> +            .toURI().toURL()};
> +        URLClassLoader ucl = URLClassLoader.newInstance(classpath);
> +        Class testInterface = ucl.loadClass(THIS_CLASS.getSimpleName()
> +                + "$TestInterface");
> +        Class testSuperClass = ucl.loadClass(THIS_CLASS.getSimpleName()
> +                + "$TestSuperClass");
> +        Class testSubClass1 = ucl.loadClass(THIS_CLASS.getSimpleName()
> +                + "$TestSubClass1");
>
> I see BCP-to-BCP & non-BCP-to-non-BCP ref-to-ref cases covered. What 
> about BCP-to-non-BCP & non-BCP-to-BCP cases?
>
> Best regards,
> Vladimir Ivanov
>
> On 8/3/15 6:06 PM, Konstantin Shefov wrote:
>> Michael, thanks for reviewing!
>>
>> Vladimir, could you take a look, please?
>>
>> -Konstantin
>>
>> On 08/02/2015 05:31 PM, Michael Haupt wrote:
>>> Hi Konstantin,
>>>
>>>> Am 31.07.2015 um 18:37 schrieb Konstantin Shefov
>>>> >:
>>>> Please review a test improvement. Covered more cases for
>>>> MethodHandles.explicitCastArguments().
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060717
>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.00/
>>>> 
>>>
>>> note that mine is a lower-case review and does not count, but: thumbs
>>> up. The level of detail at which the API is tested improves
>>> significantly with these changes.
>>>
>>> Best,
>>>
>>> Michael
>>>
>>> -- 
>>>
>>> Oracle 
>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>> OracleJava Platform Group | LangTools Team | Nashorn
>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam,
>>> Germany
>>> Green Oracle  Oracle is committed
>>> to developing practices and products that help protect the environment
>>>
>>>
>>



From amy.lu at oracle.com  Thu Aug  6 14:06:09 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 06 Aug 2015 22:06:09 +0800
Subject: JDK 9 RFR of JDK-8079769: tools/pack200/PackTestZip64.java may timeout
	at preparing the large test file
Message-ID: <55C369D1.7040906@oracle.com>

Please review the fix for test issue: tools/pack200/PackTestZip64.java 
may timeout at preparing the large test file

This test tries to create a big jar file for testing by adding a large 
number (Short.MAX_VALUE * 2 + 2) of small files to the golden jar 
(golden.jar). This prepare work is i/o sensitive and may take long thus 
may timeout (depending on the run timeout settings), especially when 
many tests run in concurrency.

To make the test more stable, without losing test coverage, this fix makes:
* PackTestZip64.java tests on the golden.jar only
* PackTestZip64Manual.java still tests on the big jar

bug: https://bugs.openjdk.java.net/browse/JDK-8079769
webrev: http://cr.openjdk.java.net/~amlu/8079769/webrev.00/

Thanks,
Amy


From konstantin.shefov at oracle.com  Thu Aug  6 14:49:46 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Thu, 06 Aug 2015 17:49:46 +0300
Subject: [9] RFR: 8060717: [TESTBUG] Improve test coverage of
	MethodHandles.explicitCastArguments()
In-Reply-To: <55C33FB1.5000708@oracle.com>
References: <55BBA449.1030603@oracle.com>	<0B7B1F71-0BE3-400E-A6C2-5FD01E13777A@oracle.com>	<55BF838D.7080202@oracle.com>
	<55C330D1.80307@oracle.com> <55C33FB1.5000708@oracle.com>
Message-ID: <55C3740A.10205@oracle.com>

Please, look at the modified test

http://cr.openjdk.java.net/~kshefov/8060717/webrev.01/

-Konstantin

On 08/06/2015 02:06 PM, Konstantin Shefov wrote:
> Hi Vladimir
>
> Thanks for reviewing
>
>
> On 08/06/2015 01:02 PM, Vladimir Ivanov wrote:
>> Konstantin,
>>
>> Overall, looks good.
>>
>> Why do you create a new ClassLoader here and not simply reference 
>> them directly (they are loaded by application class loader)?
> You a right. Because of class loader hierarchy, all "Test*" classes in 
> this case are loaded by app class loader as an ancestor of url class 
> loader, so it is the same as just reference them directly.
> To make the "Test*" classes loaded by ucl, they need to be outside of 
> classpath, which will produce extra folders and ".java" files in test 
> workspace.
>
> I think non-bcp to bcp test will play just the same role (work with 
> classes loaded by different class loaders).
>
> So I will correct the code. I will add BCP-to-non-BCP & non-BCP-to-BCP 
> cases and remove url classloader.
>
> -Konstantin
>> + public static void testNonBCPRef2Ref() throws Throwable {
>> +        String testClassPath = System.getProperty("test.classes",".");
>> +        URL[] classpath = {(new File(testClassPath)).getCanonicalFile()
>> +            .toURI().toURL()};
>> +        URLClassLoader ucl = URLClassLoader.newInstance(classpath);
>> +        Class testInterface = ucl.loadClass(THIS_CLASS.getSimpleName()
>> +                + "$TestInterface");
>> +        Class testSuperClass = ucl.loadClass(THIS_CLASS.getSimpleName()
>> +                + "$TestSuperClass");
>> +        Class testSubClass1 = ucl.loadClass(THIS_CLASS.getSimpleName()
>> +                + "$TestSubClass1");
>>
>> I see BCP-to-BCP & non-BCP-to-non-BCP ref-to-ref cases covered. What 
>> about BCP-to-non-BCP & non-BCP-to-BCP cases?
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 8/3/15 6:06 PM, Konstantin Shefov wrote:
>>> Michael, thanks for reviewing!
>>>
>>> Vladimir, could you take a look, please?
>>>
>>> -Konstantin
>>>
>>> On 08/02/2015 05:31 PM, Michael Haupt wrote:
>>>> Hi Konstantin,
>>>>
>>>>> Am 31.07.2015 um 18:37 schrieb Konstantin Shefov
>>>>> >:
>>>>> Please review a test improvement. Covered more cases for
>>>>> MethodHandles.explicitCastArguments().
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060717
>>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.00/
>>>>> 
>>>>
>>>> note that mine is a lower-case review and does not count, but: thumbs
>>>> up. The level of detail at which the API is tested improves
>>>> significantly with these changes.
>>>>
>>>> Best,
>>>>
>>>> Michael
>>>>
>>>> -- 
>>>>
>>>> Oracle 
>>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>>> OracleJava Platform Group | LangTools Team | Nashorn
>>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam,
>>>> Germany
>>>> Green Oracle  Oracle is committed
>>>> to developing practices and products that help protect the environment
>>>>
>>>>
>>>
>



From alexander.v.stepanov at oracle.com  Thu Aug  6 15:08:31 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Thu, 06 Aug 2015 18:08:31 +0300
Subject: RFR [9] 8133115: docs: replace  tags (obsolete in html5) for
	java.util.logging, java.util.prefs, java.util.zip, java.util.jar
Message-ID: <55C3786F.5040509@oracle.com>

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133115/webrev.00
for
https://bugs.openjdk.java.net/browse/JDK-8133115

Just a next portion of "" tags removed.

specdiffs did not detect any changes for java.util package:
http://cr.openjdk.java.net/~avstepan/8133115/util.diff.00/overview-summary.html

Thanks,
Alexander



From volker.simonis at gmail.com  Thu Aug  6 15:27:23 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 6 Aug 2015 17:27:23 +0200
Subject: RFR(XS): 8133105: Fix getFinalAttributes() on Windows to handle more
	special cases
Message-ID: 

Hi,

can somebody please review the following small fix contributed by
matthias.baesken at sap.com:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8133105/
https://bugs.openjdk.java.net/browse/JDK-8133105

Getting file attributes on Windows via GetFileAttributesExW() can fail
for some special system files. There is already code in
getFinalAttributes() which handles some of these special cases by
using FindFirstFileW().

However there are still cases which are not covered until now. For
example on PGP WDE (Whole Disk Encryption) ? encrypted machines the
test java/io/File/WinSpecialFiles still fails for PGP files like
C:\pgpwde01. This small change fixes the issue.

Thank you and best regards,
Volker


From lance.andersen at oracle.com  Thu Aug  6 15:33:08 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 6 Aug 2015 11:33:08 -0400
Subject: RFR [9] 8133115: docs: replace  tags (obsolete in html5) for
	java.util.logging, java.util.prefs, java.util.zip, java.util.jar
In-Reply-To: <55C3786F.5040509@oracle.com>
References: <55C3786F.5040509@oracle.com>
Message-ID: <04AE44EA-B02B-4420-B94D-67B495A59B8E@oracle.com>

Looks fine

Best
Lance
On Aug 6, 2015, at 11:08 AM, Alexander Stepanov  wrote:

> Hello,
> 
> Could you please review the following fix:
> http://cr.openjdk.java.net/~avstepan/8133115/webrev.00
> for
> https://bugs.openjdk.java.net/browse/JDK-8133115
> 
> Just a next portion of "" tags removed.
> 
> specdiffs did not detect any changes for java.util package:
> http://cr.openjdk.java.net/~avstepan/8133115/util.diff.00/overview-summary.html
> 
> Thanks,
> Alexander
> 



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  Thu Aug  6 15:33:58 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 6 Aug 2015 11:33:58 -0400
Subject: RFR 9: 8133022: Instant.toEpochMilli() silently overflows
Message-ID: <55C37E66.6010107@Oracle.com>

Please review a small fix and test for Instant.toEpochMilli 
ArithmeticOverflow.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/

Issue:
     https://bugs.openjdk.java.net/browse/JDK-8133022

Thanks, Roger





From alexander.v.stepanov at oracle.com  Thu Aug  6 15:41:52 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Thu, 06 Aug 2015 18:41:52 +0300
Subject: RFR [9] 8133115: docs: replace  tags (obsolete in html5)
	for java.util.logging, java.util.prefs, java.util.zip, java.util.jar
In-Reply-To: <04AE44EA-B02B-4420-B94D-67B495A59B8E@oracle.com>
References: <55C3786F.5040509@oracle.com>
	<04AE44EA-B02B-4420-B94D-67B495A59B8E@oracle.com>
Message-ID: <55C38040.1030001@oracle.com>

Thanks!

On 8/6/2015 6:33 PM, Lance Andersen wrote:
> Looks fine
>
> Best
> Lance
> On Aug 6, 2015, at 11:08 AM, Alexander Stepanov 
>  > wrote:
>
>> Hello,
>>
>> Could you please review the following fix:
>> http://cr.openjdk.java.net/~avstepan/8133115/webrev.00 
>> 
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8133115
>>
>> Just a next portion of "" tags removed.
>>
>> specdiffs did not detect any changes for java.util package:
>> http://cr.openjdk.java.net/~avstepan/8133115/util.diff.00/overview-summary.html
>>
>> Thanks,
>> Alexander
>>
>
> 
> 
> 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 volker.simonis at gmail.com  Thu Aug  6 15:43:11 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 6 Aug 2015 17:43:11 +0200
Subject: RFR 9: 8133022: Instant.toEpochMilli() silently overflows
In-Reply-To: <55C37E66.6010107@Oracle.com>
References: <55C37E66.6010107@Oracle.com>
Message-ID: 

Looks good!

Thanks,
Volker

On Thu, Aug 6, 2015 at 5:33 PM, Roger Riggs  wrote:
> Please review a small fix and test for Instant.toEpochMilli
> ArithmeticOverflow.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
>
> Issue:
>     https://bugs.openjdk.java.net/browse/JDK-8133022
>
> Thanks, Roger
>
>
>


From daniel.fuchs at oracle.com  Thu Aug  6 15:45:47 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 06 Aug 2015 17:45:47 +0200
Subject: RFR 9: 8133022: Instant.toEpochMilli() silently overflows
In-Reply-To: <55C37E66.6010107@Oracle.com>
References: <55C37E66.6010107@Oracle.com>
Message-ID: <55C3812B.7040500@oracle.com>

Hi Roger,

Not a math expert, but this looks good to me :-)

best regards,

-- daniel

On 06/08/15 17:33, Roger Riggs wrote:
> Please review a small fix and test for Instant.toEpochMilli
> ArithmeticOverflow.
>
> Webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
>
> Issue:
>      https://bugs.openjdk.java.net/browse/JDK-8133022
>
> Thanks, Roger
>
>
>



From chris.hegarty at oracle.com  Thu Aug  6 15:47:05 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 6 Aug 2015 16:47:05 +0100
Subject: RFR 9: 8133022: Instant.toEpochMilli() silently overflows
In-Reply-To: <55C37E66.6010107@Oracle.com>
References: <55C37E66.6010107@Oracle.com>
Message-ID: 

Looks fine Roger.

-Chris.

On 6 Aug 2015, at 16:33, Roger Riggs  wrote:

> Please review a small fix and test for Instant.toEpochMilli ArithmeticOverflow.
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
> 
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8133022
> 
> Thanks, Roger
> 
> 
> 



From lance.andersen at oracle.com  Thu Aug  6 15:50:24 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 6 Aug 2015 11:50:24 -0400
Subject: RFR 9: 8133022: Instant.toEpochMilli() silently overflows
In-Reply-To: <55C37E66.6010107@Oracle.com>
References: <55C37E66.6010107@Oracle.com>
Message-ID: <7E51FC24-1728-4C15-B2F3-962F24653938@oracle.com>

+1
On Aug 6, 2015, at 11:33 AM, Roger Riggs  wrote:

> Please review a small fix and test for Instant.toEpochMilli ArithmeticOverflow.
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
> 
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8133022
> 
> Thanks, Roger
> 
> 
> 



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 ivan.gerasimov at oracle.com  Thu Aug  6 16:34:31 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 06 Aug 2015 19:34:31 +0300
Subject: RFR 9: 8133022: Instant.toEpochMilli() silently overflows
In-Reply-To: <55C37E66.6010107@Oracle.com>
References: <55C37E66.6010107@Oracle.com>
Message-ID: <55C38C97.90006@oracle.com>

Hi Roger!

There seems to be another numeric overflow possibility a the line# 1235, 
when 'seconds' is a large negative and 'nanos' is a small positive.

For example,
------------
         Instant inst = Instant.ofEpochSecond(-9223372036854776L, 1);
         System.out.println(inst.toEpochMilli());
------------
prints out 9223372036854775616.


Sincerely yours,
Ivan

On 06.08.2015 18:33, Roger Riggs wrote:
> Please review a small fix and test for Instant.toEpochMilli 
> ArithmeticOverflow.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
>
> Issue:
>     https://bugs.openjdk.java.net/browse/JDK-8133022
>
> Thanks, Roger
>
>
>
>
>



From Roger.Riggs at Oracle.com  Thu Aug  6 16:37:54 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 6 Aug 2015 12:37:54 -0400
Subject: RFR 9: 8133022: Instant.toEpochMilli() silently overflows
In-Reply-To: <55C38C97.90006@oracle.com>
References: <55C37E66.6010107@Oracle.com> <55C38C97.90006@oracle.com>
Message-ID: <55C38D62.2040308@Oracle.com>

Hi Ivan,

I looked at that but didn't find a reproducer.
I'll add that test case and respin.

Thanks, Roger


On 8/6/2015 12:34 PM, Ivan Gerasimov wrote:
> Hi Roger!
>
> There seems to be another numeric overflow possibility a the line# 
> 1235, when 'seconds' is a large negative and 'nanos' is a small positive.
>
> For example,
> ------------
>         Instant inst = Instant.ofEpochSecond(-9223372036854776L, 1);
>         System.out.println(inst.toEpochMilli());
> ------------
> prints out 9223372036854775616.
>
>
> Sincerely yours,
> Ivan
>
> On 06.08.2015 18:33, Roger Riggs wrote:
>> Please review a small fix and test for Instant.toEpochMilli 
>> ArithmeticOverflow.
>>
>> Webrev:
>>    http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
>>
>> Issue:
>>     https://bugs.openjdk.java.net/browse/JDK-8133022
>>
>> Thanks, Roger
>>
>>
>>
>>
>>
>



From martinrb at google.com  Thu Aug  6 16:42:15 2015
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 6 Aug 2015 09:42:15 -0700
Subject: RFR JDK-8022224: Intermittent test failures in
	sun/nio/cs/FindDecoderBugs.java, ,
In-Reply-To: <9C0CCB2B-AD57-4709-8C26-C18586A38CA6@oracle.com>
References: <55C25E52.3010703@oracle.com>
	<921713F5-73B0-4F16-B89C-F997B1C60E8F@oracle.com>
	
	<9C0CCB2B-AD57-4709-8C26-C18586A38CA6@oracle.com>
Message-ID: 

On Thu, Aug 6, 2015 at 12:52 AM, Chris Hegarty 
wrote:

>
> On 6 Aug 2015, at 00:28, Martin Buchholz  wrote:
> >
> > On Wed, Aug 5, 2015 at 12:29 PM, Chris Hegarty 
> wrote:
> > The change looks ok to me Sherman.
> >
> > Should the bug synopsis be updated? It looks like a test bug rather than
> a product one.
> >
> > Why do you say that?  The JISAutoDetect charset is being fixed here, no?
>
> When I first looked at this I expected it to be a test only bug. I was
> just initially surprised to see that it was actually a product bug.  I
> guess I think the synopsis should read something like ?Fix JISAutoDetect
> charset?, or something, rather than specifically mentioning a jdk
> regression test.  Given both Sherman?s and your comments, this is not worth
> debating.
>
>
Oh, I misunderstood.  Your initial "it" refers to the title...


> > Sherman: Thanks for fixing this.  I've observed this in the wild a
> couple of times myself.
> >
> > (Although flaky tests are annoying, finding actual bugs makes it so
> worth it!)
>
> Right.
>
> -Chris.
>
>


From Roger.Riggs at Oracle.com  Thu Aug  6 18:07:06 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 6 Aug 2015 14:07:06 -0400
Subject: RFR 9: 8133022: Instant.toEpochMilli() silently overflows
In-Reply-To: <55C38D62.2040308@Oracle.com>
References: <55C37E66.6010107@Oracle.com> <55C38C97.90006@oracle.com>
	<55C38D62.2040308@Oracle.com>
Message-ID: <55C3A24A.8030901@Oracle.com>

Hi,

Please review the update to include the additional case and fix.

http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/

Thanks, Roger


On 8/6/2015 12:37 PM, Roger Riggs wrote:
> Hi Ivan,
>
> I looked at that but didn't find a reproducer.
> I'll add that test case and respin.
>
> Thanks, Roger
>
>
> On 8/6/2015 12:34 PM, Ivan Gerasimov wrote:
>> Hi Roger!
>>
>> There seems to be another numeric overflow possibility a the line# 
>> 1235, when 'seconds' is a large negative and 'nanos' is a small 
>> positive.
>>
>> For example,
>> ------------
>>         Instant inst = Instant.ofEpochSecond(-9223372036854776L, 1);
>>         System.out.println(inst.toEpochMilli());
>> ------------
>> prints out 9223372036854775616.
>>
>>
>> Sincerely yours,
>> Ivan
>>
>> On 06.08.2015 18:33, Roger Riggs wrote:
>>> Please review a small fix and test for Instant.toEpochMilli 
>>> ArithmeticOverflow.
>>>
>>> Webrev:
>>>    http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
>>>
>>> Issue:
>>>     https://bugs.openjdk.java.net/browse/JDK-8133022
>>>
>>> Thanks, Roger
>>>
>>>
>>>
>>>
>>>
>>
>



From chris.hegarty at oracle.com  Thu Aug  6 18:13:06 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 6 Aug 2015 19:13:06 +0100
Subject: RFR 9: 8133022: Instant.toEpochMilli() silently overflows
In-Reply-To: <55C3A24A.8030901@Oracle.com>
References: <55C37E66.6010107@Oracle.com> <55C38C97.90006@oracle.com>
	<55C38D62.2040308@Oracle.com> <55C3A24A.8030901@Oracle.com>
Message-ID: <932915E8-1CB9-49B4-93AC-8249AB4E4338@oracle.com>

On 6 Aug 2015, at 19:07, Roger Riggs  wrote:

> Hi,
> 
> Please review the update to include the additional case and fix.
> 
> http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/

The updated version looks good Roger.

-Chris.

> Thanks, Roger
> 
> 
> On 8/6/2015 12:37 PM, Roger Riggs wrote:
>> Hi Ivan,
>> 
>> I looked at that but didn't find a reproducer.
>> I'll add that test case and respin.
>> 
>> Thanks, Roger
>> 
>> 
>> On 8/6/2015 12:34 PM, Ivan Gerasimov wrote:
>>> Hi Roger!
>>> 
>>> There seems to be another numeric overflow possibility a the line# 1235, when 'seconds' is a large negative and 'nanos' is a small positive.
>>> 
>>> For example,
>>> ------------
>>>        Instant inst = Instant.ofEpochSecond(-9223372036854776L, 1);
>>>        System.out.println(inst.toEpochMilli());
>>> ------------
>>> prints out 9223372036854775616.
>>> 
>>> 
>>> Sincerely yours,
>>> Ivan
>>> 
>>> On 06.08.2015 18:33, Roger Riggs wrote:
>>>> Please review a small fix and test for Instant.toEpochMilli ArithmeticOverflow.
>>>> 
>>>> Webrev:
>>>>   http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
>>>> 
>>>> Issue:
>>>>    https://bugs.openjdk.java.net/browse/JDK-8133022
>>>> 
>>>> Thanks, Roger
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
> 



From scolebourne at joda.org  Thu Aug  6 19:37:57 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 6 Aug 2015 20:37:57 +0100
Subject: RFR 9: 8133022: Instant.toEpochMilli() silently overflows
In-Reply-To: <932915E8-1CB9-49B4-93AC-8249AB4E4338@oracle.com>
References: <55C37E66.6010107@Oracle.com> <55C38C97.90006@oracle.com>
	<55C38D62.2040308@Oracle.com> <55C3A24A.8030901@Oracle.com>
	<932915E8-1CB9-49B4-93AC-8249AB4E4338@oracle.com>
Message-ID: 

Fine by me.
Stephen

On 6 Aug 2015 19:15, "Chris Hegarty"  wrote:
>
> On 6 Aug 2015, at 19:07, Roger Riggs  wrote:
>
> > Hi,
> >
> > Please review the update to include the additional case and fix.
> >
> > http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
>
> The updated version looks good Roger.
>
> -Chris.
>
> > Thanks, Roger
> >
> >
> > On 8/6/2015 12:37 PM, Roger Riggs wrote:
> >> Hi Ivan,
> >>
> >> I looked at that but didn't find a reproducer.
> >> I'll add that test case and respin.
> >>
> >> Thanks, Roger
> >>
> >>
> >> On 8/6/2015 12:34 PM, Ivan Gerasimov wrote:
> >>> Hi Roger!
> >>>
> >>> There seems to be another numeric overflow possibility a the line#
1235, when 'seconds' is a large negative and 'nanos' is a small positive.
> >>>
> >>> For example,
> >>> ------------
> >>>        Instant inst = Instant.ofEpochSecond(-9223372036854776L, 1);
> >>>        System.out.println(inst.toEpochMilli());
> >>> ------------
> >>> prints out 9223372036854775616.
> >>>
> >>>
> >>> Sincerely yours,
> >>> Ivan
> >>>
> >>> On 06.08.2015 18:33, Roger Riggs wrote:
> >>>> Please review a small fix and test for Instant.toEpochMilli
ArithmeticOverflow.
> >>>>
> >>>> Webrev:
> >>>>   http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
> >>>>
> >>>> Issue:
> >>>>    https://bugs.openjdk.java.net/browse/JDK-8133022
> >>>>
> >>>> Thanks, Roger
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>


From xueming.shen at oracle.com  Thu Aug  6 21:00:36 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 6 Aug 2015 14:00:36 -0700
Subject: RFR 9: 8133022: Instant.toEpochMilli() silently overflows
In-Reply-To: <55C3A24A.8030901@Oracle.com>
References: <55C37E66.6010107@Oracle.com> <55C38C97.90006@oracle.com>
	<55C38D62.2040308@Oracle.com> <55C3A24A.8030901@Oracle.com>
Message-ID: <55C3CAF4.8050406@oracle.com>

looks good.

On 8/6/15 11:07 AM, Roger Riggs wrote:
> Hi,
>
> Please review the update to include the additional case and fix.
>
> http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
>
> Thanks, Roger
>
>
> On 8/6/2015 12:37 PM, Roger Riggs wrote:
>> Hi Ivan,
>>
>> I looked at that but didn't find a reproducer.
>> I'll add that test case and respin.
>>
>> Thanks, Roger
>>
>>
>> On 8/6/2015 12:34 PM, Ivan Gerasimov wrote:
>>> Hi Roger!
>>>
>>> There seems to be another numeric overflow possibility a the line# 
>>> 1235, when 'seconds' is a large negative and 'nanos' is a small 
>>> positive.
>>>
>>> For example,
>>> ------------
>>>         Instant inst = Instant.ofEpochSecond(-9223372036854776L, 1);
>>>         System.out.println(inst.toEpochMilli());
>>> ------------
>>> prints out 9223372036854775616.
>>>
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>> On 06.08.2015 18:33, Roger Riggs wrote:
>>>> Please review a small fix and test for Instant.toEpochMilli 
>>>> ArithmeticOverflow.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
>>>>
>>>> Issue:
>>>>     https://bugs.openjdk.java.net/browse/JDK-8133022
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>



From ivan.gerasimov at oracle.com  Thu Aug  6 21:24:52 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 07 Aug 2015 00:24:52 +0300
Subject: RFR 9: 8133022: Instant.toEpochMilli() silently overflows
In-Reply-To: <55C3A24A.8030901@Oracle.com>
References: <55C37E66.6010107@Oracle.com>
	<55C38C97.90006@oracle.com>	<55C38D62.2040308@Oracle.com>
	<55C3A24A.8030901@Oracle.com>
Message-ID: <55C3D0A4.1010907@oracle.com>

Thanks Roger!

On 06.08.2015 21:07, Roger Riggs wrote:
> Hi,
>
> Please review the update to include the additional case and fix.
>
> http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
>
In TCKInstant.java, the second testcase could be written as
         Instant.ofEpochSecond(Long.MIN_VALUE / 1000 - 1, 1).toEpochMilli();
for more readability and consistency with the other testcase.

In Instant.java, I think, the check for (nanos > 0) at the line #1232 
can be omitted, as it only optimizes one of 100'0000'000 possible cases.
It seems that both branches should handle the case (nanos == 0) correctly.

Otherwise looks good to me!

Sincerely yours,
Ivan

> Thanks, Roger
>
>
> On 8/6/2015 12:37 PM, Roger Riggs wrote:
>> Hi Ivan,
>>
>> I looked at that but didn't find a reproducer.
>> I'll add that test case and respin.
>>
>> Thanks, Roger
>>
>>
>> On 8/6/2015 12:34 PM, Ivan Gerasimov wrote:
>>> Hi Roger!
>>>
>>> There seems to be another numeric overflow possibility a the line# 
>>> 1235, when 'seconds' is a large negative and 'nanos' is a small 
>>> positive.
>>>
>>> For example,
>>> ------------
>>>         Instant inst = Instant.ofEpochSecond(-9223372036854776L, 1);
>>>         System.out.println(inst.toEpochMilli());
>>> ------------
>>> prints out 9223372036854775616.
>>>
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>> On 06.08.2015 18:33, Roger Riggs wrote:
>>>> Please review a small fix and test for Instant.toEpochMilli 
>>>> ArithmeticOverflow.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rriggs/webrev-overflow-8133022/
>>>>
>>>> Issue:
>>>>     https://bugs.openjdk.java.net/browse/JDK-8133022
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>



From kumar.x.srinivasan at oracle.com  Fri Aug  7 12:04:36 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 07 Aug 2015 05:04:36 -0700
Subject: RFR 8124977 cmdline encoding challenges on Windows
In-Reply-To: 
References: 
	
	<558C017A.2020708@oracle.com>
	
	<55A16577.8050302@oracle.com>
	
	<55AD42ED.3040102@oracle.com>
	
Message-ID: <55C49ED4.9090504@oracle.com>

Hi Kirk,

We don't allow any shell tests. There are existing shell based tests,
I have not had a chance to port all of  them.

Your test must be rewritten to use the TestHelper framework, please see
the other tests in jdk/test/tools/launcher for patterns.

Kumar

>> -----Original Message-----
>> From: Xueming Shen [mailto:xueming.shen at oracle.com]
>> Sent: Monday, July 20, 2015 11:50 AM
>>
>> On 07/20/2015 10:22 AM, Kirk Shoop wrote:
>>> So when default system locale differs from the active one, we have
>> different behavior on Linux and Windows. The new options allow a windows
>> user to select the same behavior that one would expect on unix. The
>> switches can certainly be removed, if the compatibility impact is acceptable.
>>
>> Kirk, on Windows file.encoding is from the user locale and the
>> sun.jnu.encoding is from the system locale setting. sun.jnu.encoding is
>> purely for those text encoding sensitive jnu functiond to communicate with
>> the underlying windows system api, when the system locale and the user
>> locale are set to different value. On unix/linux/osx, these two are always set
>> to the same value. Yes, they might be input/output issue if the encoding
>> used by the console (oem codepage) is not compatible with the encoding
>> used by the "user locale"
>> and you are trying to use System.in/out/err for the input/output to the
>> console.
>>
>> Here is the original CCC request regarding the sun.jnu.encoding, which might
>> provide some background info.
>>
>> http://cr.openjdk.java.net/~sherman/4958170.html
>>
>> If you/we are NOT going to change the encoding used by the underlying
>> console, I don't think we need/should change the "encoding" used by the
>> java.io.Console. As I suggested in my previously email, the
>> Java_java_io_Console_encoding() implementation probably need to update
>> to return utf8 if the cp == 65001 (that was 10 years ago, I'm not sure if the
>> 65001 was really used back then when we wrote this code).  My
>> understanding of the issue here is that if you continue to use the "A" version
>> of the API to parse/get the arguments, and try to solve the possible issue
>> triggered by the "incompatibility" of the oem encoding used by the console
>> and the user locale encoding used by the System.in/ out/err, it's fine to
>> define a new system property to specify a preferred encoding for the
>> launcher to use, but this "preferred" encoding should not be used by
>> java.io.Console.
>> But isn't it more reasonable to simply always use the "W" version for this
>> purpose in launcher?
>>
>> -Sherman
>>
> Thank you for the valuable feedback. We have vastly simplified the original patch.
> The new webrev is here:
>    http://cr.openjdk.java.net/~kshoop/8124977/webrev.02/
>
> This webrev uses GetCommandLineW on windows to retrieve the UCS16 commandline and also supports the 65001(UTF-8) codepage (set by chcp 65001) so that when -Dsun.jnu.encoding="UTF-8" is supplied the console output (stdout & stderr) will be in UTF8.
>
> There are no new commandline switches.
>
> Please let us know if there is anything else that needs improvement.
>
> Thanks!
> Kirk and Valery
>



From martinrb at google.com  Fri Aug  7 13:50:03 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 7 Aug 2015 06:50:03 -0700
Subject: RFR 8124977 cmdline encoding challenges on Windows
In-Reply-To: 
References: 
	
	<558C017A.2020708@oracle.com>
	
	<55A16577.8050302@oracle.com>
	
	<55AD42ED.3040102@oracle.com>
	
Message-ID: 

(only half paying attention)

On Wed, Aug 5, 2015 at 7:45 PM, Kirk Shoop  wrote:

>
> This webrev uses GetCommandLineW


That sounds right - this should be the source of truth in win32land.


> on windows to retrieve the UCS16


"UCS16" confuses me.  Do you mean UTF-16 or UCS-2?  I'm guessing the former.
http://stackoverflow.com/questions/4592261/windows-api-ansi-and-wide-character-strings-is-it-utf8-or-ascii-utf-16-or-u


> commandline and also supports the 65001(UTF-8) codepage (set by chcp
> 65001) so that when -Dsun.jnu.encoding="UTF-8" is supplied the console
> output (stdout & stderr) will be in UTF8.
>

Is there a reason why UTF-8 is special here?  Shouldn't we have console
output always match the codepage of the console, when possible, without
effort on the user's part?  Is there a problem that we don't have a
translation table between code pages and Java charsets?


From Roger.Riggs at Oracle.com  Fri Aug  7 18:54:36 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 7 Aug 2015 14:54:36 -0400
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: 
References: <55B6938E.2010806@Oracle.com> <55B6940D.90701@Oracle.com>
	
	<55BAC679.7010108@oracle.com>
	
	<55BBA878.3090509@Oracle.com> <55BBE261.4060902@oracle.com>
	
Message-ID: <55C4FEEC.1010804@Oracle.com>

Hi Volker,

1) ProcessHandle.java:243

For the definition of the new commandLine method I would:

   - Use @link instead of @code for references to commands() and 
arguments() for easy navigation

   - @implNote[1] should I think be changed to @apiNote:
   the text describes not the JDK implementation but is information 
about the
   information returned and is use to the application developer, not the 
JDK implementation.

   -  The specific references to Linux implementation command line 
length parameters seems out of place
       and should be omitted.

         /**
          * Returns the command line of the process.
          * 

          * If {@link #command command()} and  {@link #arguments 
arguments()} return non-null
          * optionals, this is simply a convenience method which 
concatenates
          * the values of the two functions separated by spaces. 
Otherwise it will return a
          * best-effort, platform dependent representation of the 
command line.
          *
          * @apiNote Note that the returned executable pathname and the
          *           arguments may be truncated on some platforms due 
to system
          *           limitations.
          *           

          *           The executable pathname may contain only the
          *           name of the executable without the full path 
information.
          *           It is undecideable whether white space separates 
different
          *           arguments or is part of a single argument.
          *
          * @return an {@code Optional} of the command line
          *         of the process
          */
         public Optional commandLine();


ProcessHandle.java:252: in arguments() method - @apiNote is a better fit 
for the note

ProcessHandleImpl_macosx.c:276:   - indentation +4


2) ProcessHandleImpl_macosx.c:192:
     if (errno != EINVAL) ...  There was previously this test,  I'm 
concerned that if the pid is invalid,
     it will now throw a RuntimeException instead of returning -1.
     I recall a discussion from May that recommended testing for EINVAL.
     The sysctl in getCmdlineAndUserInfo also does not throw if errno != 
EINVAL, so the usage
     is not consistent (probably my coding) but needs investigation.

3) ProcessHandleImpl_solaris.c can do without the includes:
#include "jni_util.h"
#include "java_lang_ProcessHandleImpl.h"
#include "java_lang_ProcessHandleImpl_Info.h"

#include 

4) Ditto ProcessHandleImpl_aix.c

5) ProcessHandleImpl_unix.c: 618:  typo  "fuctions" -> "functions"

6) ProcessHandleImpl_unix.c:463: Would it be worthwhile to put 
sysconf(_SC_GETPW_R_SIZE_MAX) in a static?

7) OnExitTest.java: exits without an error, just output in the log; it 
would escape attention.
     The code respects the timeout setting.
     Suggest removing the 'return' @133; the test will produce some 
errors and when debugging
     the note will be in the log.

8) ProcessHandleImpl_unix.h:58 - update the comment to include 0 as a 
valid parent pid.

Looks pretty good,
Thanks, Roger



[1] http://openjdk.java.net/jeps/8068562 - JEP draft: javadoc tags to 
distinguish API, implementation, specification, and notes

On 8/5/2015 3:56 PM, Volker Simonis wrote:
> Hi,
>
> so here's the webrev which implements the new Info.commandLine()
> method (I chose 'commandLine() ' instead of 'cmdline()' or
> 'commandline()' because the other getters are camel case as well):
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v4/
>
>  From the JavaDoc of the new method:
>
> * If {@code command()} and  {@code arguments()} return non-null
> * optionals, this is simply a convenience method which concatenates
> * the values of the two functions. Otherwise it will return a
> * best-effort, platform dependent representation of the command line.
>
> This didn't change anything on MacOS X where there is no additional
> effort to get the command line.
>
> On Solaris and AIX, Info.commandLine() will always return the contents
> of psinfo.pr_psargs because there's no other method to get the exact
> arguments (i.e. Info.arguments() always returns NULL. I could
> therefore remove the extra handling of AIX/Solaris in the InfoTest
> from my initial change.
>
> On Linux, things are a little more complicated:
>
> - the initial implementation for Linux used arg[0] as 'command' if
> /proc/pid/exe wasn't readable. This was true for all the processes we
> don't own (except if we are running as root). But this information may
> be incomplete, because arg[0] may only contain the command without its
> full path. One example is 'sendmail' for which Info.command() reported
> "sendmail: accepting connections" but Info.arguments() was empty. This
> is wrong, because 'sendmail' changes its argv[] array. I have
> therefore disabled this behavior now that we have the 'commandLine()'
> method.
>
> - /proc/pid/cmdline is limited to PAGE_SIZE (normally 4096) characters
> on Linux. So strictly speaking, this isn't 'exact' information as well
> (there are plenty of complains that especially for Java programs this
> is not enough) and should go to 'commandLine()' instead to 'arguments'
> if /proc/pid/cmdline is truncated. I do check for this now.
>
> - the information in /proc/pid/cmdline can also be changed to
> something other than the original arguments if a program changes
> argv[] (which is not forbidden) but there's probably not much we can
> do to detect this. I've added a corresponding @implNote comment to
> JavaDoc of Info.arguments().
>
> - the initial implementation did not check for incomplete reads of
> /proc/pid/cmdline. This may be a problem on systems with PAGE_SIZE >
> 4096 (on Linux/ppc64 a page size of 65536 is not unusual). I'm now
> always reading the complete contents of /proc/pid/cmdline.
>
> - as far as I understand the current implementation, 'arguments()'
> returns the arguments array WITHOUT 'arg[0]' (which is the program
> name) but may
> be we should specify that more clearly in the JavaDoc of 'arguments()'.
>
> That's it. Hope you like it :)
>
> Regards,
> Volker
>
> On Fri, Jul 31, 2015 at 11:02 PM, Stuart Marks  wrote:
>> Hi Roger, Volker,
>>
>> Glad to see you guys are receptive to this and that it can move forward. Let
>> me know if you'd like me to help out, for example with reviews or something.
>>
>> s'marks
>>
>>
>> On 7/31/15 9:55 AM, Roger Riggs wrote:
>>> Hi Volker,
>>>
>>> I agree that adding an Info.commandline() method would be a good way
>>> to make the command line available and be able to describe that it is
>>> OS dependent and may be truncated.
>>> And having it assemble the command and arguments when they are available
>>> makes
>>> sense.
>>> As an API addition it will need a clear spec and I can run it through CCC
>>> so it
>>> gets
>>> another review and compatibility tests.
>>>
>>> Thanks, Roger
>>>
>>>
>>>
>>>
>>> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>>>> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks
>>>> wrote:
>>>>> On 7/29/15 11:36 AM, Volker Simonis wrote:
>>>>>>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>>>>>>> truncated or incomplete
>>>>>>> values for the executable or arguments.
>>>>>>> Can anyone be a tie-breaker  (with a good rational and suggestion for
>>>>>>> how
>>>>>>> an
>>>>>>> application can use the data).
>>>>>> As I wrote, I agree to hear other opinions here.
>>>>>>
>>>>>> All I want to say that this truncated data is actually what 'ps' is
>>>>>> reporting on Solaris since decades and people seem to be happy with
>>>>>> it. As use case I can imagine logging or monitoring (something like
>>>>>> 'top' in Java) where this data will be just good enough.
>>>>>>
>>>>>> We could specially mark possibly incomplete data by extending the Info
>>>>>> object with functions like commandIsExact() or argumentsIsPrecise().
>>>>>> But notice that we can not statically preset these values per
>>>>>> platform. For example on Solaris, the 'command()' would return a
>>>>>> precise value for processes with the same uid like the VM but only
>>>>>> inaccurate values for all other processes. The "arguments()" would be
>>>>>> always inaccurate on Solaris/AIX.
>>>>> It seems like there are cases where either exact or only approximate
>>>>> information is available. And as you observed, you might get one or the
>>>>> other on the same platform, depending on the UID. It also might depend
>>>>> on
>>>>> process state; I believe that some information becomes inaccessible when
>>>>> the
>>>>> process enters the zombie state.
>>>>>
>>>>> I don't think we should simply ignore one case or the other, but I also
>>>>> don't think we should try to cram the different information into the
>>>>> same
>>>>> API.
>>>>>
>>>>> The current ProcessHandle.Info api has
>>>>>
>>>>>       Optional command()
>>>>>       Optional arguments()
>>>>>
>>>>> It sounds to me like Roger wants these to contain only exact
>>>>> information.
>>>>> That seems reasonable, and this probably needs to be specified more
>>>>> clearly
>>>>> to contrast with what's below.
>>>>>
>>>>> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
>>>>> single string which appears to be the concatenation of the arguments
>>>>> (maybe
>>>>> including the command name). It's also truncated to fit PRARGSZ. It
>>>>> doesn't
>>>>> make sense to me to try to return this as a String[], as the zeroth
>>>>> element
>>>>> of that array, and certainly not parsed out into "words". So maybe
>>>>> instead
>>>>> we should have a different API that returns an imprecise command line as
>>>>> a
>>>>> single string:
>>>>>
>>>>>       Optional cmdline()
>>>>>
>>>>> (Naming bikeshed TBS). The semantics would be that this is the process'
>>>>> command and arguments concatenated into a single string (thus
>>>>> potentially
>>>>> losing argument boundaries) and also possibly truncated based on
>>>>> platform
>>>>> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out
>>>>> in a
>>>>> ps, top, or Activity Monitor style application, for informational
>>>>> purposes.
>>>>>
>>>>> If this were implemented, then on Solaris, command() and arguments()
>>>>> would
>>>>> always return empty optionals.
>>>>>
>>>>> I'm not sure what this should be if the exact information is available.
>>>>> It
>>>>> would be inconvenient if something that just wanted to print out an
>>>>> approximate command line had to check several different APIs to get the
>>>>> information. Maybe cmdline() could assemble the information from exact
>>>>> data
>>>>> if it's is available, by concatenating the Strings from command() and
>>>>> arguments(), as a convenience to the caller. But I could go either way
>>>>> on
>>>>> this.
>>>>>
>>>>> Not sure this counts as a tie-breaker, but it might be a reasonable way
>>>>> forward.
>>>>>
>>>>> s'marks
>>>>>
>>>> Hi Stuart,
>>>>
>>>> thanks a lot for your comments - I like your proposal. For me this
>>>> sounds like a good compromise.
>>>>
>>>> @Roger: should I go and add a new field commandLine and the
>>>> corresponding getter to the Info class? As Stuart proposed, the getter
>>>> could check if 'command' and 'arguments' are available and assemble
>>>> the command line from them. Otherwise it could use the content of the
>>>> commandLine field if that is available.
>>>>
>>>> Regards,
>>>> Volker



From xueming.shen at oracle.com  Fri Aug  7 20:24:22 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 07 Aug 2015 13:24:22 -0700
Subject: RFR JDK-8039390: Unexpected behaviour of String.format with null
	arguments
Message-ID: <55C513F6.6080303@oracle.com>

Hi,

Please help review fix for

issue: https://bugs.openjdk.java.net/browse/JDK-8039390
webrev: http://cr.openjdk.java.net/~sherman/8039390

The j.u.Formatter implementation outputs "null/Null" for all conversions
if the argument is null (except 'b'/'B', in which the result is "false/FALSE").
However the API doc only explicitly specifies this behavior for 'b', 'h' and
's'. With the "Unless otherwise specified, passing a null argument to any
method or constructor in this class will cause a  NullPointerException to
be thrown" at the bottom of the spec, it is confusing which one should be
the expected behavior.

The proposed change here is to add explicit wording to cover all conversions.
(Will go through CCC is approved here).

Thanks,
Sherman


From henry.jen at oracle.com  Sat Aug  8 07:03:39 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Sat, 8 Aug 2015 00:03:39 -0700
Subject: RFR v4 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: 
References: 
	
	
Message-ID: 

Hi,

Another update for argument file support, this version we added a couple measures to ensure compatibility,

1) Compile time directive ENABLE_ARG_FILES is needed to enable the feature, only java is enabled with this webrev.
2) Escape @argument if so desired: Additional prefixes of @ to a @ prefixed option will  act as an escape, ie. the first @ will be removed and the rest of the arguments presented to the launcher literally.
 
For example:
 
java @ foo  gets arguments of @ foo
java @filename, filename expanded
java @@filename will have the leading @ removed and reduced to literal @filename
similarly,
java @@@filenamewill have the leading @ removed and reduced to literal @@filename
 
 3) The option '-Xdisable- at files' can be used on the command line anywhere to prevent further @filename expansion.
 4) Limit the file size must not exceed MAXINT (2, 147, 483, 647) bytes.

Webrev at http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v4/webrev/

Cheers,
Henry



From joe.darcy at oracle.com  Sun Aug  9 18:37:17 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Sun, 9 Aug 2015 11:37:17 -0700
Subject: JDK 9 RFR of JDK-8133231: Mark TimeoutLockLoops.java as failing
	intermittently
Message-ID: <55C79DDD.3000608@oracle.com>

Hello,

The test

java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java

is failing intermittently on Linux (JDK-8029453), apparently due to the 
HotSpot change JDK-8130728.

Until the underlying issues are addressed, I'd like to mark the test as 
"@key intermittent" to aid failure analysis:

diff -r e1aa58e9592c 
test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java
--- 
a/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 
Fri Aug 07 16:09:10 2015 -0700
+++ 
b/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 
Sun Aug 09 11:30:45 2015 -0700
@@ -35,6 +35,7 @@
   * @test
   * @bug 4486658 5031862
   * @run main TimeoutLockLoops
+ * @key intermittent
   * @summary Checks for responsiveness of locks to timeouts.
   * Runs under the assumption that ITERS computations require more than
   * TIMEOUT msecs to complete, which seems to be a safe assumption for

Thanks,

-Joe


From lance.andersen at oracle.com  Sun Aug  9 18:47:25 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sun, 9 Aug 2015 14:47:25 -0400
Subject: JDK 9 RFR of JDK-8133231: Mark TimeoutLockLoops.java as failing
	intermittently
In-Reply-To: <55C79DDD.3000608@oracle.com>
References: <55C79DDD.3000608@oracle.com>
Message-ID: 

+1
On Aug 9, 2015, at 2:37 PM, joe darcy  wrote:

> Hello,
> 
> The test
> 
> java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java
> 
> is failing intermittently on Linux (JDK-8029453), apparently due to the HotSpot change JDK-8130728.
> 
> Until the underlying issues are addressed, I'd like to mark the test as "@key intermittent" to aid failure analysis:
> 
> diff -r e1aa58e9592c test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java
> --- a/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java Fri Aug 07 16:09:10 2015 -0700
> +++ b/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java Sun Aug 09 11:30:45 2015 -0700
> @@ -35,6 +35,7 @@
>  * @test
>  * @bug 4486658 5031862
>  * @run main TimeoutLockLoops
> + * @key intermittent
>  * @summary Checks for responsiveness of locks to timeouts.
>  * Runs under the assumption that ITERS computations require more than
>  * TIMEOUT msecs to complete, which seems to be a safe assumption for
> 
> 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 erik.joelsson at oracle.com  Mon Aug 10 10:02:06 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Aug 2015 12:02:06 +0200
Subject: RFR - 8027634: Support @argfiles for java command-line tool
In-Reply-To: 
References: 
Message-ID: <55C8769E.3080008@oracle.com>

Hello Henry,

Build changes look good to me.

/Erik

On 2015-07-10 05:48, Henry Jen wrote:
> Hi,
>
> Please review proposed patch for JDK-8027634[1]. This patch is to enable java support command line argument file like javac does. The implementation use the same syntax rule, which is implemented in CommandLine.java[3] with java.io.StreamTokenizer.
>
> Some early comment is that we probably don?t need such complexity to support same syntax, also require to quote whole token is a little inconvenient. For example, must be -cp ?c:\\foo bar\\lib;c:\\lib? instead of -cp c:\?foo bar?\lib;c:\lib.
>
> I am debating if such compatibility is necessary useful, after all, easy and intuitive is more important, and with simpler rule, the implementation will be cleaner as well.
>
> Anyhow, with the patch out, at least developer can build idk and have something to test with to see if this can fulfill their use cases.
>
> Also, for tools other than java that use launcher, it?s possible to use -J at argfile to pass arguments. For example, if want to pass -J options to javac, it?s now possible to do so with javac -J at argfile, and put -J options in the argfile.
>
> If the consensus is that such syntax compatibility is not important, we will go ahead remove the escaping support(except probably enable escape for quote itself) in quote, and maybe add support of quote within a token.
>
> CCing build-dev for build changes, jdk9-dev for wider audience for tools.
>
> Cheers,
> Henry
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8027634
> [2] http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javac.html#commandlineargfile
> [3] http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/03e083639ee9/src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java



From erik.joelsson at oracle.com  Mon Aug 10 10:54:55 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Aug 2015 12:54:55 +0200
Subject: RFR v4 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: 
References: 		
	
Message-ID: <55C882FF.6040709@oracle.com>

New build changes look fine to me.

/Erik

On 2015-08-08 09:03, Henry Jen wrote:
> Hi,
>
> Another update for argument file support, this version we added a couple measures to ensure compatibility,
>
> 1) Compile time directive ENABLE_ARG_FILES is needed to enable the feature, only java is enabled with this webrev.
> 2) Escape @argument if so desired: Additional prefixes of @ to a @ prefixed option will  act as an escape, ie. the first @ will be removed and the rest of the arguments presented to the launcher literally.
>   
> For example:
>   
> java @ foo  gets arguments of @ foo
> java @filename, filename expanded
> java @@filename will have the leading @ removed and reduced to literal @filename
> similarly,
> java @@@filenamewill have the leading @ removed and reduced to literal @@filename
>   
>   3) The option '-Xdisable- at files' can be used on the command line anywhere to prevent further @filename expansion.
>   4) Limit the file size must not exceed MAXINT (2, 147, 483, 647) bytes.
>
> Webrev at http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v4/webrev/
>
> Cheers,
> Henry
>



From rob.mckenna at oracle.com  Mon Aug 10 13:06:37 2015
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 10 Aug 2015 14:06:37 +0100
Subject: RFR: 8129957 - Deadlock in JNDI LDAP implementation when closing
	the LDAP context
Message-ID: <55C8A1DD.7020508@oracle.com>

Hi folks,

We have a hang between LdapClient / Ctx due to the fact that 
Connection.cleanup() calls LdapClient.processConnectionClosure which 
locks the unsolicited vector and in turn calls LdapCtx.fireUnsolicited 
which locks the eventSupport object. Unfortunately when an 
LdapCtx.close() occurs at the same time, its removeUnsolicited method 
locks the eventSupport object first and then attempts to call 
LdapClient.removeUnsolicited which attempts to lock the unsolicited vector.

So:

thread 1:

Connection.cleanup ->
LdapClient.processConnectionClosure (LOCK VECTOR) ->
LdapCtx.fireUnsolicited (LOCK EVENTSUPPORT)

(LdapClient is looping through LdapCtx objects in the unsolicited vector)

thread 2:

LdapCtx.close (LOCK LDAPCTX) ->
LdapCtx.removeUnsolicited (LOCK EVENTSUPPORT) ->
LdapClient.removeUnsolicited (LOCK VECTOR)

(A single LdapCtx removes itself from its LdapClient unsolicited list)


My proposed solution is to have both threads lock the LdapClient before 
locking either the unsolicited vector or the eventSupport object.

Webrev at: http://cr.openjdk.java.net/~robm/8129957/webrev.01/

	-Rob


From alexander.v.stepanov at oracle.com  Mon Aug 10 13:39:24 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Mon, 10 Aug 2015 16:39:24 +0300
Subject: RFR [9] 8133188: docs: replace  tags (obsolete in html5) for
	java.util
Message-ID: <55C8A98C.3090002@oracle.com>

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133188/webrev.01
for
https://bugs.openjdk.java.net/browse/JDK-8133188

Just a next portion of "" tags removed.

specdiff report:
http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html
  - some constructs like
"(o==null ? e==null : o.equals(e))"
were replaced with "{@code Objects.equals(o, e)}"
(e.g., 
http://cr.openjdk.java.net/~avstepan/8133188/webrev.01/src/java.base/share/classes/java/util/LinkedList.java.udiff.html); 
- please see JDK-8133188 comments.

Thanks,
Alexander


From martinrb at google.com  Mon Aug 10 14:28:38 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 10 Aug 2015 07:28:38 -0700
Subject: RFR [9] 8133188: docs: replace  tags (obsolete in html5) for
	java.util
In-Reply-To: <55C8A98C.3090002@oracle.com>
References: <55C8A98C.3090002@oracle.com>
Message-ID: 

Hi Alexander,

I've been hoping that someone does cleanups of the jdk as you are doing now.

Some of these source files are part of jsr166 and are maintained
separately, in jsr166 CVS.
http://g.oswego.edu/dl/concurrency-interest/
And that has already been /-cleaned (although it has been done
slightly differently) and will be integrated into jdk9 in an upcoming
merge.  So please leave out:
concurrent/
*Queue.java
*Deque.java
Navigable*.java

On Mon, Aug 10, 2015 at 6:39 AM, Alexander Stepanov <
alexander.v.stepanov at oracle.com> wrote:

> Hello,
>
> Could you please review the following fix:
> http://cr.openjdk.java.net/~avstepan/8133188/webrev.01
> for
> https://bugs.openjdk.java.net/browse/JDK-8133188
>
> Just a next portion of "" tags removed.
>
> specdiff report:
>
> http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html
>  - some constructs like
> "(o==null ? e==null : o.equals(e))"
> were replaced with "{@code Objects.equals(o, e)}"
> (e.g.,
> http://cr.openjdk.java.net/~avstepan/8133188/webrev.01/src/java.base/share/classes/java/util/LinkedList.java.udiff.html);
> - please see JDK-8133188 comments.
>
> Thanks,
> Alexander
>


From volker.simonis at gmail.com  Mon Aug 10 16:57:44 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 10 Aug 2015 18:57:44 +0200
Subject: RFR(XS): 8133105: Fix getFinalAttributes() on Windows to handle
	more special cases
In-Reply-To: 
References: 
Message-ID: 

Hi,

can somebody please review this trivial fix?

Thanks,
Volker


On Thu, Aug 6, 2015 at 5:27 PM, Volker Simonis  wrote:
> Hi,
>
> can somebody please review the following small fix contributed by
> matthias.baesken at sap.com:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8133105/
> https://bugs.openjdk.java.net/browse/JDK-8133105
>
> Getting file attributes on Windows via GetFileAttributesExW() can fail
> for some special system files. There is already code in
> getFinalAttributes() which handles some of these special cases by
> using FindFirstFileW().
>
> However there are still cases which are not covered until now. For
> example on PGP WDE (Whole Disk Encryption) ? encrypted machines the
> test java/io/File/WinSpecialFiles still fails for PGP files like
> C:\pgpwde01. This small change fixes the issue.
>
> Thank you and best regards,
> Volker


From volker.simonis at gmail.com  Mon Aug 10 17:13:36 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 10 Aug 2015 19:13:36 +0200
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: <55C4FEEC.1010804@Oracle.com>
References: <55B6938E.2010806@Oracle.com> <55B6940D.90701@Oracle.com>
	
	<55BAC679.7010108@oracle.com>
	
	<55BBA878.3090509@Oracle.com> <55BBE261.4060902@oracle.com>
	
	<55C4FEEC.1010804@Oracle.com>
Message-ID: 

On Fri, Aug 7, 2015 at 8:54 PM, Roger Riggs  wrote:
> Hi Volker,
>
> 1) ProcessHandle.java:243
>
> For the definition of the new commandLine method I would:
>
>   - Use @link instead of @code for references to commands() and arguments()
> for easy navigation
>
>   - @implNote[1] should I think be changed to @apiNote:
>   the text describes not the JDK implementation but is information about the
>   information returned and is use to the application developer, not the JDK
> implementation.
>
>   -  The specific references to Linux implementation command line length
> parameters seems out of place
>       and should be omitted.
>
>         /**
>          * Returns the command line of the process.
>          * 

>          * If {@link #command command()} and  {@link #arguments arguments()}
> return non-null
>          * optionals, this is simply a convenience method which concatenates
>          * the values of the two functions separated by spaces. Otherwise it
> will return a
>          * best-effort, platform dependent representation of the command
> line.
>          *
>          * @apiNote Note that the returned executable pathname and the
>          *           arguments may be truncated on some platforms due to
> system
>          *           limitations.
>          *           

>          *           The executable pathname may contain only the
>          *           name of the executable without the full path
> information.
>          *           It is undecideable whether white space separates
> different
>          *           arguments or is part of a single argument.
>          *
>          * @return an {@code Optional} of the command line
>          *         of the process
>          */
>         public Optional commandLine();
>
>
> ProcessHandle.java:252: in arguments() method - @apiNote is a better fit for
> the note
>
> ProcessHandleImpl_macosx.c:276:   - indentation +4
>

Thanks for the correction. I've taken your wording you suggested.

>
> 2) ProcessHandleImpl_macosx.c:192:
>     if (errno != EINVAL) ...  There was previously this test,  I'm concerned
> that if the pid is invalid,
>     it will now throw a RuntimeException instead of returning -1.
>     I recall a discussion from May that recommended testing for EINVAL.
>     The sysctl in getCmdlineAndUserInfo also does not throw if errno !=
> EINVAL, so the usage
>     is not consistent (probably my coding) but needs investigation.
>

Not sure about this one and couldn't find any previous discussion
about the topic.

But, according to the sysctl man-page, EINVAL is only returned if:
 - The name array is less than two or greater than CTL_MAXNAME.
 - A non-null newp is given and its specified length in newlen is too
large or too small.

The first case can not happen because we always statically allocate
arrays of the correct size.
The second case can not happen as well, because we always have 'newp == NULL'.

So according to this information I don't see any reason why we should
check for EINVAL. I think the right solution is to check for 'oldlenp
> 0' which we already do. By the way, this is also the check applied
by the psutils (see the implementation of 'get_kinfo_proc()' in [1]).

So I wnated to also removed the last check for EINVAL in
getCmdlineAndUserInfo(). But for some reason, that seems to be really
necessary. Without it, we will get a RuntinmeException if we call
sysinfo for pid==0 for example. Further research showed that the
kernel seems to really return EINVAL for KERN_PROCARGS2 (see function
sysctl_procargsx() in [2]). But KERN_PROCARGS2 isn't specified as a
supported constant in the sysctl man-page, so the information there is
still valid :)

On the other hand, I found that the psutils alo handles EINVAL only
for KERN_PROCARGS2 (see get_arg_list() in [1]).

So to cut a long story short, I think the current implementation is
safe as it is now!

[1] http://psutil.googlecode.com/svn/trunk/psutil/arch/osx/process_info.c
[2] http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/bsd/kern/kern_sysctl.c

> 3) ProcessHandleImpl_solaris.c can do without the includes:
> #include "jni_util.h"
> #include "java_lang_ProcessHandleImpl.h"
> #include "java_lang_ProcessHandleImpl_Info.h"
>
> #include 
>
> 4) Ditto ProcessHandleImpl_aix.c
>

Thanks, fixed.

> 5) ProcessHandleImpl_unix.c: 618:  typo  "fuctions" -> "functions"
>

Fixed.

> 6) ProcessHandleImpl_unix.c:463: Would it be worthwhile to put
> sysconf(_SC_GETPW_R_SIZE_MAX) in a static?
>

Good point! While doing this I realized that 'clock_ticks_per_second'
is only used on Linux. So I moved the declaration of
'clock_ticks_per_second' from ProcessHandleImpl_unix.hpp to
ProcessHandleImpl_linux.cpp and its initialization to  os_initNative()
in the same file.

I also declare a new static 'getpw_buf_size' in
ProcessHandleImpl_unix.cpp and initialize it in
Java_java_lang_ProcessHandleImpl_initNative() in the same file.

> 7) OnExitTest.java: exits without an error, just output in the log; it would
> escape attention.
>     The code respects the timeout setting.
>     Suggest removing the 'return' @133; the test will produce some errors
> and when debugging
>     the note will be in the log.
>

Done.

> 8) ProcessHandleImpl_unix.h:58 - update the comment to include 0 as a valid
> parent pid.
>

Fixed.

> Looks pretty good,
> Thanks, Roger
>

Thanks:)

I've also added two rudimentary tests for the new commandLine()
function to InfoTest.test2():

 - if both, 'command()' and 'arguments()' are available, I check that
'commandLine()' starts with 'command()' and contains all the arguments
from 'arguments()'.

 - otherwise, if 'commandLine()' is available, I check that it at
least contains 'java'.  And as long as it is big enough it should also
contain the corresponding arguments.

The two new tests have been verified to pass on Windows, Linux, MacOS
X, Solaris and AIX.

The new version can be found here:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v6/

Regards,
Volker

>
>
> [1] http://openjdk.java.net/jeps/8068562  - JEP draft: javadoc tags to
> distinguish API, implementation, specification, and notes
>
>
> On 8/5/2015 3:56 PM, Volker Simonis wrote:
>
> Hi,
>
> so here's the webrev which implements the new Info.commandLine()
> method (I chose 'commandLine() ' instead of 'cmdline()' or
> 'commandline()' because the other getters are camel case as well):
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v4/
>
> From the JavaDoc of the new method:
>
> * If {@code command()} and  {@code arguments()} return non-null
> * optionals, this is simply a convenience method which concatenates
> * the values of the two functions. Otherwise it will return a
> * best-effort, platform dependent representation of the command line.
>
> This didn't change anything on MacOS X where there is no additional
> effort to get the command line.
>
> On Solaris and AIX, Info.commandLine() will always return the contents
> of psinfo.pr_psargs because there's no other method to get the exact
> arguments (i.e. Info.arguments() always returns NULL. I could
> therefore remove the extra handling of AIX/Solaris in the InfoTest
> from my initial change.
>
> On Linux, things are a little more complicated:
>
> - the initial implementation for Linux used arg[0] as 'command' if
> /proc/pid/exe wasn't readable. This was true for all the processes we
> don't own (except if we are running as root). But this information may
> be incomplete, because arg[0] may only contain the command without its
> full path. One example is 'sendmail' for which Info.command() reported
> "sendmail: accepting connections" but Info.arguments() was empty. This
> is wrong, because 'sendmail' changes its argv[] array. I have
> therefore disabled this behavior now that we have the 'commandLine()'
> method.
>
> - /proc/pid/cmdline is limited to PAGE_SIZE (normally 4096) characters
> on Linux. So strictly speaking, this isn't 'exact' information as well
> (there are plenty of complains that especially for Java programs this
> is not enough) and should go to 'commandLine()' instead to 'arguments'
> if /proc/pid/cmdline is truncated. I do check for this now.
>
> - the information in /proc/pid/cmdline can also be changed to
> something other than the original arguments if a program changes
> argv[] (which is not forbidden) but there's probably not much we can
> do to detect this. I've added a corresponding @implNote comment to
> JavaDoc of Info.arguments().
>
> - the initial implementation did not check for incomplete reads of
> /proc/pid/cmdline. This may be a problem on systems with PAGE_SIZE >
> 4096 (on Linux/ppc64 a page size of 65536 is not unusual). I'm now
> always reading the complete contents of /proc/pid/cmdline.
>
> - as far as I understand the current implementation, 'arguments()'
> returns the arguments array WITHOUT 'arg[0]' (which is the program
> name) but may
> be we should specify that more clearly in the JavaDoc of 'arguments()'.
>
> That's it. Hope you like it :)
>
> Regards,
> Volker
>
> On Fri, Jul 31, 2015 at 11:02 PM, Stuart Marks 
> wrote:
>
> Hi Roger, Volker,
>
> Glad to see you guys are receptive to this and that it can move forward. Let
> me know if you'd like me to help out, for example with reviews or something.
>
> s'marks
>
>
> On 7/31/15 9:55 AM, Roger Riggs wrote:
>
> Hi Volker,
>
> I agree that adding an Info.commandline() method would be a good way
> to make the command line available and be able to describe that it is
> OS dependent and may be truncated.
> And having it assemble the command and arguments when they are available
> makes
> sense.
> As an API addition it will need a clear spec and I can run it through CCC
> so it
> gets
> another review and compatibility tests.
>
> Thanks, Roger
>
>
>
>
> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>
> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks 
> wrote:
>
> On 7/29/15 11:36 AM, Volker Simonis wrote:
>
> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
> truncated or incomplete
> values for the executable or arguments.
> Can anyone be a tie-breaker  (with a good rational and suggestion for
> how
> an
> application can use the data).
>
> As I wrote, I agree to hear other opinions here.
>
> All I want to say that this truncated data is actually what 'ps' is
> reporting on Solaris since decades and people seem to be happy with
> it. As use case I can imagine logging or monitoring (something like
> 'top' in Java) where this data will be just good enough.
>
> We could specially mark possibly incomplete data by extending the Info
> object with functions like commandIsExact() or argumentsIsPrecise().
> But notice that we can not statically preset these values per
> platform. For example on Solaris, the 'command()' would return a
> precise value for processes with the same uid like the VM but only
> inaccurate values for all other processes. The "arguments()" would be
> always inaccurate on Solaris/AIX.
>
> It seems like there are cases where either exact or only approximate
> information is available. And as you observed, you might get one or the
> other on the same platform, depending on the UID. It also might depend
> on
> process state; I believe that some information becomes inaccessible when
> the
> process enters the zombie state.
>
> I don't think we should simply ignore one case or the other, but I also
> don't think we should try to cram the different information into the
> same
> API.
>
> The current ProcessHandle.Info api has
>
>      Optional command()
>      Optional arguments()
>
> It sounds to me like Roger wants these to contain only exact
> information.
> That seems reasonable, and this probably needs to be specified more
> clearly
> to contrast with what's below.
>
> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
> single string which appears to be the concatenation of the arguments
> (maybe
> including the command name). It's also truncated to fit PRARGSZ. It
> doesn't
> make sense to me to try to return this as a String[], as the zeroth
> element
> of that array, and certainly not parsed out into "words". So maybe
> instead
> we should have a different API that returns an imprecise command line as
> a
> single string:
>
>      Optional cmdline()
>
> (Naming bikeshed TBS). The semantics would be that this is the process'
> command and arguments concatenated into a single string (thus
> potentially
> losing argument boundaries) and also possibly truncated based on
> platform
> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out
> in a
> ps, top, or Activity Monitor style application, for informational
> purposes.
>
> If this were implemented, then on Solaris, command() and arguments()
> would
> always return empty optionals.
>
> I'm not sure what this should be if the exact information is available.
> It
> would be inconvenient if something that just wanted to print out an
> approximate command line had to check several different APIs to get the
> information. Maybe cmdline() could assemble the information from exact
> data
> if it's is available, by concatenating the Strings from command() and
> arguments(), as a convenience to the caller. But I could go either way
> on
> this.
>
> Not sure this counts as a tie-breaker, but it might be a reasonable way
> forward.
>
> s'marks
>
> Hi Stuart,
>
> thanks a lot for your comments - I like your proposal. For me this
> sounds like a good compromise.
>
> @Roger: should I go and add a new field commandLine and the
> corresponding getter to the Info class? As Stuart proposed, the getter
> could check if 'command' and 'arguments' are available and assemble
> the command line from them. Otherwise it could use the content of the
> commandLine field if that is available.
>
> Regards,
> Volker
>
>


From Roger.Riggs at Oracle.com  Tue Aug 11 04:38:30 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 10 Aug 2015 21:38:30 -0700
Subject: RFR(XS): 8133105: Fix getFinalAttributes() on Windows to handle
	more special cases
In-Reply-To: 
References: 
	
Message-ID: <55C97C46.4050502@Oracle.com>

Hi Volker,

Looks fine.

Is there any way to test this?
It seems like it needs a special file system state that would not be 
readily available.

Thanks, Roger


On 8/10/15 9:57 AM, Volker Simonis wrote:
> Hi,
>
> can somebody please review this trivial fix?
>
> Thanks,
> Volker
>
>
> On Thu, Aug 6, 2015 at 5:27 PM, Volker Simonis  wrote:
>> Hi,
>>
>> can somebody please review the following small fix contributed by
>> matthias.baesken at sap.com:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8133105/
>> https://bugs.openjdk.java.net/browse/JDK-8133105
>>
>> Getting file attributes on Windows via GetFileAttributesExW() can fail
>> for some special system files. There is already code in
>> getFinalAttributes() which handles some of these special cases by
>> using FindFirstFileW().
>>
>> However there are still cases which are not covered until now. For
>> example on PGP WDE (Whole Disk Encryption) ? encrypted machines the
>> test java/io/File/WinSpecialFiles still fails for PGP files like
>> C:\pgpwde01. This small change fixes the issue.
>>
>> Thank you and best regards,
>> Volker



From volker.simonis at gmail.com  Tue Aug 11 08:50:46 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 11 Aug 2015 10:50:46 +0200
Subject: RFR(XS): 8133105: Fix getFinalAttributes() on Windows to handle
	more special cases
In-Reply-To: <55C97C46.4050502@Oracle.com>
References: 
	
	<55C97C46.4050502@Oracle.com>
Message-ID: 

On Tue, Aug 11, 2015 at 6:38 AM, Roger Riggs  wrote:
> Hi Volker,
>
> Looks fine.
>

Thanks!

> Is there any way to test this?
> It seems like it needs a special file system state that would not be readily
> available.
>

Yes, it's not easy to reproduce the problem. I've tried to create a
file with the same attributes and access control lists like the
offending PGP files but couldn't succeed to reproduce the problem with
them. Even if I copy the offending file, the problem will not show on
the copy any more. So there must be something special about these
files but I couldn't find out what.

> Thanks, Roger
>
>
>
> On 8/10/15 9:57 AM, Volker Simonis wrote:
>>
>> Hi,
>>
>> can somebody please review this trivial fix?
>>
>> Thanks,
>> Volker
>>
>>
>> On Thu, Aug 6, 2015 at 5:27 PM, Volker Simonis 
>> wrote:
>>>
>>> Hi,
>>>
>>> can somebody please review the following small fix contributed by
>>> matthias.baesken at sap.com:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8133105/
>>> https://bugs.openjdk.java.net/browse/JDK-8133105
>>>
>>> Getting file attributes on Windows via GetFileAttributesExW() can fail
>>> for some special system files. There is already code in
>>> getFinalAttributes() which handles some of these special cases by
>>> using FindFirstFileW().
>>>
>>> However there are still cases which are not covered until now. For
>>> example on PGP WDE (Whole Disk Encryption) ? encrypted machines the
>>> test java/io/File/WinSpecialFiles still fails for PGP files like
>>> C:\pgpwde01. This small change fixes the issue.
>>>
>>> Thank you and best regards,
>>> Volker
>
>


From konstantin.shefov at oracle.com  Tue Aug 11 10:54:09 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Tue, 11 Aug 2015 13:54:09 +0300
Subject: [9] RFR: 8060717: [TESTBUG] Improve test coverage of
	MethodHandles.explicitCastArguments()
In-Reply-To: <55C3740A.10205@oracle.com>
References: <55BBA449.1030603@oracle.com>
	<0B7B1F71-0BE3-400E-A6C2-5FD01E13777A@oracle.com>
	<55BF838D.7080202@oracle.com> <55C330D1.80307@oracle.com>
	<55C33FB1.5000708@oracle.com> <55C3740A.10205@oracle.com>
Message-ID: <55C9D451.2050107@oracle.com>

Kindly reminder.

06.08.2015 17:49, Konstantin Shefov ?????:
> Please, look at the modified test
>
> http://cr.openjdk.java.net/~kshefov/8060717/webrev.01/
>
> -Konstantin
>
> On 08/06/2015 02:06 PM, Konstantin Shefov wrote:
>> Hi Vladimir
>>
>> Thanks for reviewing
>>
>>
>> On 08/06/2015 01:02 PM, Vladimir Ivanov wrote:
>>> Konstantin,
>>>
>>> Overall, looks good.
>>>
>>> Why do you create a new ClassLoader here and not simply reference 
>>> them directly (they are loaded by application class loader)?
>> You a right. Because of class loader hierarchy, all "Test*" classes 
>> in this case are loaded by app class loader as an ancestor of url 
>> class loader, so it is the same as just reference them directly.
>> To make the "Test*" classes loaded by ucl, they need to be outside of 
>> classpath, which will produce extra folders and ".java" files in test 
>> workspace.
>>
>> I think non-bcp to bcp test will play just the same role (work with 
>> classes loaded by different class loaders).
>>
>> So I will correct the code. I will add BCP-to-non-BCP & 
>> non-BCP-to-BCP cases and remove url classloader.
>>
>> -Konstantin
>>> + public static void testNonBCPRef2Ref() throws Throwable {
>>> +        String testClassPath = System.getProperty("test.classes",".");
>>> +        URL[] classpath = {(new 
>>> File(testClassPath)).getCanonicalFile()
>>> +            .toURI().toURL()};
>>> +        URLClassLoader ucl = URLClassLoader.newInstance(classpath);
>>> +        Class testInterface = ucl.loadClass(THIS_CLASS.getSimpleName()
>>> +                + "$TestInterface");
>>> +        Class testSuperClass = 
>>> ucl.loadClass(THIS_CLASS.getSimpleName()
>>> +                + "$TestSuperClass");
>>> +        Class testSubClass1 = ucl.loadClass(THIS_CLASS.getSimpleName()
>>> +                + "$TestSubClass1");
>>>
>>> I see BCP-to-BCP & non-BCP-to-non-BCP ref-to-ref cases covered. What 
>>> about BCP-to-non-BCP & non-BCP-to-BCP cases?
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 8/3/15 6:06 PM, Konstantin Shefov wrote:
>>>> Michael, thanks for reviewing!
>>>>
>>>> Vladimir, could you take a look, please?
>>>>
>>>> -Konstantin
>>>>
>>>> On 08/02/2015 05:31 PM, Michael Haupt wrote:
>>>>> Hi Konstantin,
>>>>>
>>>>>> Am 31.07.2015 um 18:37 schrieb Konstantin Shefov
>>>>>> >>>>> >:
>>>>>> Please review a test improvement. Covered more cases for
>>>>>> MethodHandles.explicitCastArguments().
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060717
>>>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.00/
>>>>>> 
>>>>>
>>>>> note that mine is a lower-case review and does not count, but: thumbs
>>>>> up. The level of detail at which the API is tested improves
>>>>> significantly with these changes.
>>>>>
>>>>> Best,
>>>>>
>>>>> Michael
>>>>>
>>>>> -- 
>>>>>
>>>>> Oracle 
>>>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>>>> OracleJava Platform Group | LangTools Team | Nashorn
>>>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 
>>>>> Potsdam,
>>>>> Germany
>>>>> Green Oracle  Oracle is committed
>>>>> to developing practices and products that help protect the 
>>>>> environment
>>>>>
>>>>>
>>>>
>>
>



From ecki at zusammenkunft.net  Tue Aug 11 11:26:59 2015
From: ecki at zusammenkunft.net (Bernd)
Date: Tue, 11 Aug 2015 13:26:59 +0200
Subject: [JDK-8080741] sigsegv while heap dumping in
	java_lang_Class::signers(oopDesc*)+0x1b
Message-ID: 

Hello,

very similiar to JDK-8080741 we had a crash with 8u51 on Linux. It looks
like it is happening while dumping the heap in a out of memory condition.
The bug talks about it is happenign on constrained heap, but it looks more
like related to OutOfMemory dumps (in both cases).

https://bugs.openjdk.java.net/browse/JDK-8080741


I do have a corefile and a javacore hs_err file, butcant post it
publically. Do you think it is worth to reconsider opening that bug again
(its closed as incomplete currently)? Let me know if you need more extracts
from the log.

# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.51-b03 mixed mode
linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x683c5b]  java_lang_Class::signers(oopDesc*)+0x1b
...
Stack: [0x00007fc56d05c000,0x00007fc56d15d000],  sp=0x00007fc56d15b740,
 free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V  [libjvm.so+0x683c5b]  java_lang_Class::signers(oopDesc*)+0x1b
V  [libjvm.so+0x611072]
 DumperSupport::dump_class_and_array_classes(DumpWriter*, Klass*)+0xb2
V  [libjvm.so+0x461d36]  ClassLoaderDataGraph::classes_do(void
(*)(Klass*))+0x36
V  [libjvm.so+0x6144ce]  VM_HeapDumper::doit()+0x23e
V  [libjvm.so+0xab5d25]  VM_Operation::evaluate()+0x55
V  [libjvm.so+0xab40fa]  VMThread::evaluate_operation(VM_Operation*)+0xba
V  [libjvm.so+0xab447e]  VMThread::loop()+0x1ce
V  [libjvm.so+0xab48f0]  VMThread::run()+0x70
V  [libjvm.so+0x911048]  java_start(Thread*)+0x108

VM_Operation (0x00007fc52d6592a0): HeapDumper, mode: safepoint, requested
by thread 0x00007fc41dbc5000
Other Threads:
=>0x00007fc5a969b800 VMThread [stack:
0x00007fc56d05c000,0x00007fc56d15d000] [id=43113]

Heap:
 garbage-first heap   total 16777216K, used 16640829K [0x00000003c0000000,
0x00000003c0804000, 0x00000007c0000000)
  region size 8192K, 0 young (0K), 0 survivors (0K)
 Metaspace       used 132422K, capacity 147372K, committed 150824K,
reserved 1179648K
  class space    used 15699K, capacity 20230K, committed 20888K, reserved
1048576K
...
GC Heap History (10 events):
Event: 56981.031 GC heap before
{Heap before GC invocations=922 (full 190):
 garbage-first heap   total 16777216K, used 16640829K [0x00000003c0000000,
0x00000003c0804000, 0x00000007c0000000)
  region size 8192K, 0 young (0K), 0 survivors (0K)
 Metaspace       used 132416K, capacity 147372K, committed 150824K,
reserved 1179648K
  class space    used 15698K, capacity 20230K, committed 20888K, reserved
1048576K
Event: 56981.063 GC heap after
Heap after GC invocations=923 (full 190):
 garbage-first heap   total 16777216K, used 16640829K [0x00000003c0000000,
0x00000003c0804000, 0x00000007c0000000)
  region size 8192K, 0 young (0K), 0 survivors (0K)
 Metaspace       used 132416K, capacity 147372K, committed 150824K,
reserved 1179648K
  class space    used 15698K, capacity 20230K, committed 20888K, reserved
1048576K
}
Event: 56981.108 GC heap before
{Heap before GC invocations=923 (full 190):
 garbage-first heap   total 16777216K, used 16640829K [0x00000003c0000000,
0x00000003c0804000, 0x00000007c0000000)
  region size 8192K, 0 young (0K), 0 survivors (0K)
 Metaspace       used 132420K, capacity 147372K, committed 150824K,
reserved 1179648K
  class space    used 15699K, capacity 20230K, committed 20888K, reserved
1048576K

Internal exceptions (10 events):
Event: 56980.917 Thread 0x00007fc55bb3f000 Exception > (0x00000007bfa969b0) thrown at
[/HUDSON/workspace/8-2-build-linux-amd64/jdk8u51/3951/hotspot/src/share/vm/prims/jni.cpp,
line 1598]
Event: 56980.917 Thread 0x00007fc51c8af000 Exception > (0x00000007bfa39b38) thrown at
[/HUDSON/workspace/8-2-build-linux-amd64/jdk8u51/3951/hotspot/src/share/vm/prims/jni.cpp,
line 1598]
...
OS:LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64"

uname:Linux 3.0.101-0.35-default #1 SMP Wed Jul 9 11:43:04 UTC 2014
(c36987d) x86_64
libc:glibc 2.11.3 NPTL 2.11.3
rlimit: STACK 8192k, CORE infinity, NPROC 16384, NOFILE 65535, AS 122580320k
load average:2.57 2.05 2.90
...
vm_info: Java HotSpot(TM) 64-Bit Server VM (25.51-b03) for linux-amd64 JRE
(1.8.0_51-b16), built on Jun  8 2015 19:28:07 by "java_re" with gcc 4.3.0
20080428 (Red Hat 4.3.0-8)


From alexander.v.stepanov at oracle.com  Tue Aug 11 11:33:57 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Tue, 11 Aug 2015 14:33:57 +0300
Subject: RFR [9] 8133188: docs: replace  tags (obsolete in html5)
	for java.util
In-Reply-To: 
References: <55C8A98C.3090002@oracle.com>
	
Message-ID: <55C9DDA5.4090501@oracle.com>

Hello Martin,

the changes were reverted for the following files:

java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
java.base/share/classes/java/util/AbstractQueue.java
java.base/share/classes/java/util/Deque.java
java.base/share/classes/java/util/NavigableMap.java
java.base/share/classes/java/util/NavigableSet.java

webrev updated:
http://cr.openjdk.java.net/~avstepan/8133188/webrev.02

specdiff report (please update the web page):
http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html
(the changes in concurrent are seemingly due to inherited documentation).

Regards,
Alexander

On 8/10/2015 5:28 PM, Martin Buchholz wrote:
> Hi Alexander,
>
> I've been hoping that someone does cleanups of the jdk as you are 
> doing now.
>
> Some of these source files are part of jsr166 and are maintained 
> separately, in jsr166 CVS.
> http://g.oswego.edu/dl/concurrency-interest/
> And that has already been /-cleaned (although it has been 
> done slightly differently) and will be integrated into jdk9 in an 
> upcoming merge.  So please leave out:
> concurrent/
> *Queue.java
> *Deque.java
> Navigable*.java
>
> On Mon, Aug 10, 2015 at 6:39 AM, Alexander Stepanov 
>  > wrote:
>
>     Hello,
>
>     Could you please review the following fix:
>     http://cr.openjdk.java.net/~avstepan/8133188/webrev.01
>     
>     for
>     https://bugs.openjdk.java.net/browse/JDK-8133188
>
>     Just a next portion of "" tags removed.
>
>     specdiff report:
>     http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html
>     
>      - some constructs like
>     "(o==null ? e==null : o.equals(e))"
>     were replaced with "{@code Objects.equals(o, e)}"
>     (e.g.,
>     http://cr.openjdk.java.net/~avstepan/8133188/webrev.01/src/java.base/share/classes/java/util/LinkedList.java.udiff.html
>     );
>     - please see JDK-8133188 comments.
>
>     Thanks,
>     Alexander
>
>



From Roger.Riggs at Oracle.com  Tue Aug 11 15:08:51 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 11 Aug 2015 08:08:51 -0700
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: 
References: <55B6938E.2010806@Oracle.com>	<55B6940D.90701@Oracle.com>		<55BAC679.7010108@oracle.com>		<55BBA878.3090509@Oracle.com>	<55BBE261.4060902@oracle.com>		<55C4FEEC.1010804@Oracle.com>
	
Message-ID: <55CA1003.8030201@Oracle.com>

Hi Volker,

Thanks for checking into the details of the OS X sysctl.  I'm fine with 
the current implementation.

The rest of the updates and the additional tests look fine also.

But I need to check on the CCC status.

Thanks, Roger



On 8/10/15 10:13 AM, Volker Simonis wrote:
> On Fri, Aug 7, 2015 at 8:54 PM, Roger Riggs  wrote:
>> Hi Volker,
>>
>> 1) ProcessHandle.java:243
>>
>> For the definition of the new commandLine method I would:
>>
>>    - Use @link instead of @code for references to commands() and arguments()
>> for easy navigation
>>
>>    - @implNote[1] should I think be changed to @apiNote:
>>    the text describes not the JDK implementation but is information about the
>>    information returned and is use to the application developer, not the JDK
>> implementation.
>>
>>    -  The specific references to Linux implementation command line length
>> parameters seems out of place
>>        and should be omitted.
>>
>>          /**
>>           * Returns the command line of the process.
>>           * 

>>           * If {@link #command command()} and  {@link #arguments arguments()}
>> return non-null
>>           * optionals, this is simply a convenience method which concatenates
>>           * the values of the two functions separated by spaces. Otherwise it
>> will return a
>>           * best-effort, platform dependent representation of the command
>> line.
>>           *
>>           * @apiNote Note that the returned executable pathname and the
>>           *           arguments may be truncated on some platforms due to
>> system
>>           *           limitations.
>>           *           

>>           *           The executable pathname may contain only the
>>           *           name of the executable without the full path
>> information.
>>           *           It is undecideable whether white space separates
>> different
>>           *           arguments or is part of a single argument.
>>           *
>>           * @return an {@code Optional} of the command line
>>           *         of the process
>>           */
>>          public Optional commandLine();
>>
>>
>> ProcessHandle.java:252: in arguments() method - @apiNote is a better fit for
>> the note
>>
>> ProcessHandleImpl_macosx.c:276:   - indentation +4
>>
> Thanks for the correction. I've taken your wording you suggested.
>
>> 2) ProcessHandleImpl_macosx.c:192:
>>      if (errno != EINVAL) ...  There was previously this test,  I'm concerned
>> that if the pid is invalid,
>>      it will now throw a RuntimeException instead of returning -1.
>>      I recall a discussion from May that recommended testing for EINVAL.
>>      The sysctl in getCmdlineAndUserInfo also does not throw if errno !=
>> EINVAL, so the usage
>>      is not consistent (probably my coding) but needs investigation.
>>
> Not sure about this one and couldn't find any previous discussion
> about the topic.
>
> But, according to the sysctl man-page, EINVAL is only returned if:
>   - The name array is less than two or greater than CTL_MAXNAME.
>   - A non-null newp is given and its specified length in newlen is too
> large or too small.
>
> The first case can not happen because we always statically allocate
> arrays of the correct size.
> The second case can not happen as well, because we always have 'newp == NULL'.
>
> So according to this information I don't see any reason why we should
> check for EINVAL. I think the right solution is to check for 'oldlenp
>> 0' which we already do. By the way, this is also the check applied
> by the psutils (see the implementation of 'get_kinfo_proc()' in [1]).
>
> So I wnated to also removed the last check for EINVAL in
> getCmdlineAndUserInfo(). But for some reason, that seems to be really
> necessary. Without it, we will get a RuntinmeException if we call
> sysinfo for pid==0 for example. Further research showed that the
> kernel seems to really return EINVAL for KERN_PROCARGS2 (see function
> sysctl_procargsx() in [2]). But KERN_PROCARGS2 isn't specified as a
> supported constant in the sysctl man-page, so the information there is
> still valid :)
>
> On the other hand, I found that the psutils alo handles EINVAL only
> for KERN_PROCARGS2 (see get_arg_list() in [1]).
>
> So to cut a long story short, I think the current implementation is
> safe as it is now!
>
> [1] http://psutil.googlecode.com/svn/trunk/psutil/arch/osx/process_info.c
> [2] http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/bsd/kern/kern_sysctl.c
>
>> 3) ProcessHandleImpl_solaris.c can do without the includes:
>> #include "jni_util.h"
>> #include "java_lang_ProcessHandleImpl.h"
>> #include "java_lang_ProcessHandleImpl_Info.h"
>>
>> #include 
>>
>> 4) Ditto ProcessHandleImpl_aix.c
>>
> Thanks, fixed.
>
>> 5) ProcessHandleImpl_unix.c: 618:  typo  "fuctions" -> "functions"
>>
> Fixed.
>
>> 6) ProcessHandleImpl_unix.c:463: Would it be worthwhile to put
>> sysconf(_SC_GETPW_R_SIZE_MAX) in a static?
>>
> Good point! While doing this I realized that 'clock_ticks_per_second'
> is only used on Linux. So I moved the declaration of
> 'clock_ticks_per_second' from ProcessHandleImpl_unix.hpp to
> ProcessHandleImpl_linux.cpp and its initialization to  os_initNative()
> in the same file.
>
> I also declare a new static 'getpw_buf_size' in
> ProcessHandleImpl_unix.cpp and initialize it in
> Java_java_lang_ProcessHandleImpl_initNative() in the same file.
>
>> 7) OnExitTest.java: exits without an error, just output in the log; it would
>> escape attention.
>>      The code respects the timeout setting.
>>      Suggest removing the 'return' @133; the test will produce some errors
>> and when debugging
>>      the note will be in the log.
>>
> Done.
>
>> 8) ProcessHandleImpl_unix.h:58 - update the comment to include 0 as a valid
>> parent pid.
>>
> Fixed.
>
>> Looks pretty good,
>> Thanks, Roger
>>
> Thanks:)
>
> I've also added two rudimentary tests for the new commandLine()
> function to InfoTest.test2():
>
>   - if both, 'command()' and 'arguments()' are available, I check that
> 'commandLine()' starts with 'command()' and contains all the arguments
> from 'arguments()'.
>
>   - otherwise, if 'commandLine()' is available, I check that it at
> least contains 'java'.  And as long as it is big enough it should also
> contain the corresponding arguments.
>
> The two new tests have been verified to pass on Windows, Linux, MacOS
> X, Solaris and AIX.
>
> The new version can be found here:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v6/
>
> Regards,
> Volker
>
>>
>> [1] http://openjdk.java.net/jeps/8068562  - JEP draft: javadoc tags to
>> distinguish API, implementation, specification, and notes
>>
>>
>> On 8/5/2015 3:56 PM, Volker Simonis wrote:
>>
>> Hi,
>>
>> so here's the webrev which implements the new Info.commandLine()
>> method (I chose 'commandLine() ' instead of 'cmdline()' or
>> 'commandline()' because the other getters are camel case as well):
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v4/
>>
>>  From the JavaDoc of the new method:
>>
>> * If {@code command()} and  {@code arguments()} return non-null
>> * optionals, this is simply a convenience method which concatenates
>> * the values of the two functions. Otherwise it will return a
>> * best-effort, platform dependent representation of the command line.
>>
>> This didn't change anything on MacOS X where there is no additional
>> effort to get the command line.
>>
>> On Solaris and AIX, Info.commandLine() will always return the contents
>> of psinfo.pr_psargs because there's no other method to get the exact
>> arguments (i.e. Info.arguments() always returns NULL. I could
>> therefore remove the extra handling of AIX/Solaris in the InfoTest
>> from my initial change.
>>
>> On Linux, things are a little more complicated:
>>
>> - the initial implementation for Linux used arg[0] as 'command' if
>> /proc/pid/exe wasn't readable. This was true for all the processes we
>> don't own (except if we are running as root). But this information may
>> be incomplete, because arg[0] may only contain the command without its
>> full path. One example is 'sendmail' for which Info.command() reported
>> "sendmail: accepting connections" but Info.arguments() was empty. This
>> is wrong, because 'sendmail' changes its argv[] array. I have
>> therefore disabled this behavior now that we have the 'commandLine()'
>> method.
>>
>> - /proc/pid/cmdline is limited to PAGE_SIZE (normally 4096) characters
>> on Linux. So strictly speaking, this isn't 'exact' information as well
>> (there are plenty of complains that especially for Java programs this
>> is not enough) and should go to 'commandLine()' instead to 'arguments'
>> if /proc/pid/cmdline is truncated. I do check for this now.
>>
>> - the information in /proc/pid/cmdline can also be changed to
>> something other than the original arguments if a program changes
>> argv[] (which is not forbidden) but there's probably not much we can
>> do to detect this. I've added a corresponding @implNote comment to
>> JavaDoc of Info.arguments().
>>
>> - the initial implementation did not check for incomplete reads of
>> /proc/pid/cmdline. This may be a problem on systems with PAGE_SIZE >
>> 4096 (on Linux/ppc64 a page size of 65536 is not unusual). I'm now
>> always reading the complete contents of /proc/pid/cmdline.
>>
>> - as far as I understand the current implementation, 'arguments()'
>> returns the arguments array WITHOUT 'arg[0]' (which is the program
>> name) but may
>> be we should specify that more clearly in the JavaDoc of 'arguments()'.
>>
>> That's it. Hope you like it :)
>>
>> Regards,
>> Volker
>>
>> On Fri, Jul 31, 2015 at 11:02 PM, Stuart Marks 
>> wrote:
>>
>> Hi Roger, Volker,
>>
>> Glad to see you guys are receptive to this and that it can move forward. Let
>> me know if you'd like me to help out, for example with reviews or something.
>>
>> s'marks
>>
>>
>> On 7/31/15 9:55 AM, Roger Riggs wrote:
>>
>> Hi Volker,
>>
>> I agree that adding an Info.commandline() method would be a good way
>> to make the command line available and be able to describe that it is
>> OS dependent and may be truncated.
>> And having it assemble the command and arguments when they are available
>> makes
>> sense.
>> As an API addition it will need a clear spec and I can run it through CCC
>> so it
>> gets
>> another review and compatibility tests.
>>
>> Thanks, Roger
>>
>>
>>
>>
>> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>>
>> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks 
>> wrote:
>>
>> On 7/29/15 11:36 AM, Volker Simonis wrote:
>>
>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>> truncated or incomplete
>> values for the executable or arguments.
>> Can anyone be a tie-breaker  (with a good rational and suggestion for
>> how
>> an
>> application can use the data).
>>
>> As I wrote, I agree to hear other opinions here.
>>
>> All I want to say that this truncated data is actually what 'ps' is
>> reporting on Solaris since decades and people seem to be happy with
>> it. As use case I can imagine logging or monitoring (something like
>> 'top' in Java) where this data will be just good enough.
>>
>> We could specially mark possibly incomplete data by extending the Info
>> object with functions like commandIsExact() or argumentsIsPrecise().
>> But notice that we can not statically preset these values per
>> platform. For example on Solaris, the 'command()' would return a
>> precise value for processes with the same uid like the VM but only
>> inaccurate values for all other processes. The "arguments()" would be
>> always inaccurate on Solaris/AIX.
>>
>> It seems like there are cases where either exact or only approximate
>> information is available. And as you observed, you might get one or the
>> other on the same platform, depending on the UID. It also might depend
>> on
>> process state; I believe that some information becomes inaccessible when
>> the
>> process enters the zombie state.
>>
>> I don't think we should simply ignore one case or the other, but I also
>> don't think we should try to cram the different information into the
>> same
>> API.
>>
>> The current ProcessHandle.Info api has
>>
>>       Optional command()
>>       Optional arguments()
>>
>> It sounds to me like Roger wants these to contain only exact
>> information.
>> That seems reasonable, and this probably needs to be specified more
>> clearly
>> to contrast with what's below.
>>
>> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
>> single string which appears to be the concatenation of the arguments
>> (maybe
>> including the command name). It's also truncated to fit PRARGSZ. It
>> doesn't
>> make sense to me to try to return this as a String[], as the zeroth
>> element
>> of that array, and certainly not parsed out into "words". So maybe
>> instead
>> we should have a different API that returns an imprecise command line as
>> a
>> single string:
>>
>>       Optional cmdline()
>>
>> (Naming bikeshed TBS). The semantics would be that this is the process'
>> command and arguments concatenated into a single string (thus
>> potentially
>> losing argument boundaries) and also possibly truncated based on
>> platform
>> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out
>> in a
>> ps, top, or Activity Monitor style application, for informational
>> purposes.
>>
>> If this were implemented, then on Solaris, command() and arguments()
>> would
>> always return empty optionals.
>>
>> I'm not sure what this should be if the exact information is available.
>> It
>> would be inconvenient if something that just wanted to print out an
>> approximate command line had to check several different APIs to get the
>> information. Maybe cmdline() could assemble the information from exact
>> data
>> if it's is available, by concatenating the Strings from command() and
>> arguments(), as a convenience to the caller. But I could go either way
>> on
>> this.
>>
>> Not sure this counts as a tie-breaker, but it might be a reasonable way
>> forward.
>>
>> s'marks
>>
>> Hi Stuart,
>>
>> thanks a lot for your comments - I like your proposal. For me this
>> sounds like a good compromise.
>>
>> @Roger: should I go and add a new field commandLine and the
>> corresponding getter to the Info class? As Stuart proposed, the getter
>> could check if 'command' and 'arguments' are available and assemble
>> the command line from them. Otherwise it could use the content of the
>> commandLine field if that is available.
>>
>> Regards,
>> Volker
>>
>>



From Roger.Riggs at Oracle.com  Tue Aug 11 15:12:12 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 11 Aug 2015 08:12:12 -0700
Subject: RFR JDK-8039390: Unexpected behaviour of String.format with null
	arguments
In-Reply-To: <55C513F6.6080303@oracle.com>
References: <55C513F6.6080303@oracle.com>
Message-ID: <55CA10CC.7000804@Oracle.com>

Hi Sherman,

The spec clarifications and the new test look fine.

Thanks, Roger


On 8/7/15 1:24 PM, Xueming Shen wrote:
> Hi,
>
> Please help review fix for
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8039390
> webrev: http://cr.openjdk.java.net/~sherman/8039390
>
> The j.u.Formatter implementation outputs "null/Null" for all conversions
> if the argument is null (except 'b'/'B', in which the result is 
> "false/FALSE").
> However the API doc only explicitly specifies this behavior for 'b', 
> 'h' and
> 's'. With the "Unless otherwise specified, passing a null argument to any
> method or constructor in this class will cause a NullPointerException to
> be thrown" at the bottom of the spec, it is confusing which one should be
> the expected behavior.
>
> The proposed change here is to add explicit wording to cover all 
> conversions.
> (Will go through CCC is approved here).
>
> Thanks,
> Sherman



From volker.simonis at gmail.com  Tue Aug 11 15:52:14 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 11 Aug 2015 17:52:14 +0200
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: <55CA1003.8030201@Oracle.com>
References: <55B6938E.2010806@Oracle.com> <55B6940D.90701@Oracle.com>
	
	<55BAC679.7010108@oracle.com>
	
	<55BBA878.3090509@Oracle.com> <55BBE261.4060902@oracle.com>
	
	<55C4FEEC.1010804@Oracle.com>
	
	<55CA1003.8030201@Oracle.com>
Message-ID: 

On Tue, Aug 11, 2015 at 5:08 PM, Roger Riggs  wrote:
> Hi Volker,
>
> Thanks for checking into the details of the OS X sysctl.  I'm fine with the
> current implementation.
>
> The rest of the updates and the additional tests look fine also.
>

Phew! I was already afraid I would have to switch to double-digit
versions for my webrevs :)

> But I need to check on the CCC status.
>

OK, please let me know once it is ready/approved.

Regards,
Volker

> Thanks, Roger
>
>
>
>
> On 8/10/15 10:13 AM, Volker Simonis wrote:
>
> On Fri, Aug 7, 2015 at 8:54 PM, Roger Riggs  wrote:
>
> Hi Volker,
>
> 1) ProcessHandle.java:243
>
> For the definition of the new commandLine method I would:
>
>   - Use @link instead of @code for references to commands() and arguments()
> for easy navigation
>
>   - @implNote[1] should I think be changed to @apiNote:
>   the text describes not the JDK implementation but is information about the
>   information returned and is use to the application developer, not the JDK
> implementation.
>
>   -  The specific references to Linux implementation command line length
> parameters seems out of place
>       and should be omitted.
>
>         /**
>          * Returns the command line of the process.
>          * 

>          * If {@link #command command()} and  {@link #arguments arguments()}
> return non-null
>          * optionals, this is simply a convenience method which concatenates
>          * the values of the two functions separated by spaces. Otherwise it
> will return a
>          * best-effort, platform dependent representation of the command
> line.
>          *
>          * @apiNote Note that the returned executable pathname and the
>          *           arguments may be truncated on some platforms due to
> system
>          *           limitations.
>          *           

>          *           The executable pathname may contain only the
>          *           name of the executable without the full path
> information.
>          *           It is undecideable whether white space separates
> different
>          *           arguments or is part of a single argument.
>          *
>          * @return an {@code Optional} of the command line
>          *         of the process
>          */
>         public Optional commandLine();
>
>
> ProcessHandle.java:252: in arguments() method - @apiNote is a better fit for
> the note
>
> ProcessHandleImpl_macosx.c:276:   - indentation +4
>
> Thanks for the correction. I've taken your wording you suggested.
>
> 2) ProcessHandleImpl_macosx.c:192:
>     if (errno != EINVAL) ...  There was previously this test,  I'm concerned
> that if the pid is invalid,
>     it will now throw a RuntimeException instead of returning -1.
>     I recall a discussion from May that recommended testing for EINVAL.
>     The sysctl in getCmdlineAndUserInfo also does not throw if errno !=
> EINVAL, so the usage
>     is not consistent (probably my coding) but needs investigation.
>
> Not sure about this one and couldn't find any previous discussion
> about the topic.
>
> But, according to the sysctl man-page, EINVAL is only returned if:
>  - The name array is less than two or greater than CTL_MAXNAME.
>  - A non-null newp is given and its specified length in newlen is too
> large or too small.
>
> The first case can not happen because we always statically allocate
> arrays of the correct size.
> The second case can not happen as well, because we always have 'newp ==
> NULL'.
>
> So according to this information I don't see any reason why we should
> check for EINVAL. I think the right solution is to check for 'oldlenp
>
> 0' which we already do. By the way, this is also the check applied
>
> by the psutils (see the implementation of 'get_kinfo_proc()' in [1]).
>
> So I wnated to also removed the last check for EINVAL in
> getCmdlineAndUserInfo(). But for some reason, that seems to be really
> necessary. Without it, we will get a RuntinmeException if we call
> sysinfo for pid==0 for example. Further research showed that the
> kernel seems to really return EINVAL for KERN_PROCARGS2 (see function
> sysctl_procargsx() in [2]). But KERN_PROCARGS2 isn't specified as a
> supported constant in the sysctl man-page, so the information there is
> still valid :)
>
> On the other hand, I found that the psutils alo handles EINVAL only
> for KERN_PROCARGS2 (see get_arg_list() in [1]).
>
> So to cut a long story short, I think the current implementation is
> safe as it is now!
>
> [1] http://psutil.googlecode.com/svn/trunk/psutil/arch/osx/process_info.c
> [2]
> http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/bsd/kern/kern_sysctl.c
>
> 3) ProcessHandleImpl_solaris.c can do without the includes:
> #include "jni_util.h"
> #include "java_lang_ProcessHandleImpl.h"
> #include "java_lang_ProcessHandleImpl_Info.h"
>
> #include 
>
> 4) Ditto ProcessHandleImpl_aix.c
>
> Thanks, fixed.
>
> 5) ProcessHandleImpl_unix.c: 618:  typo  "fuctions" -> "functions"
>
> Fixed.
>
> 6) ProcessHandleImpl_unix.c:463: Would it be worthwhile to put
> sysconf(_SC_GETPW_R_SIZE_MAX) in a static?
>
> Good point! While doing this I realized that 'clock_ticks_per_second'
> is only used on Linux. So I moved the declaration of
> 'clock_ticks_per_second' from ProcessHandleImpl_unix.hpp to
> ProcessHandleImpl_linux.cpp and its initialization to  os_initNative()
> in the same file.
>
> I also declare a new static 'getpw_buf_size' in
> ProcessHandleImpl_unix.cpp and initialize it in
> Java_java_lang_ProcessHandleImpl_initNative() in the same file.
>
> 7) OnExitTest.java: exits without an error, just output in the log; it would
> escape attention.
>     The code respects the timeout setting.
>     Suggest removing the 'return' @133; the test will produce some errors
> and when debugging
>     the note will be in the log.
>
> Done.
>
> 8) ProcessHandleImpl_unix.h:58 - update the comment to include 0 as a valid
> parent pid.
>
> Fixed.
>
> Looks pretty good,
> Thanks, Roger
>
> Thanks:)
>
> I've also added two rudimentary tests for the new commandLine()
> function to InfoTest.test2():
>
>  - if both, 'command()' and 'arguments()' are available, I check that
> 'commandLine()' starts with 'command()' and contains all the arguments
> from 'arguments()'.
>
>  - otherwise, if 'commandLine()' is available, I check that it at
> least contains 'java'.  And as long as it is big enough it should also
> contain the corresponding arguments.
>
> The two new tests have been verified to pass on Windows, Linux, MacOS
> X, Solaris and AIX.
>
> The new version can be found here:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v6/
>
> Regards,
> Volker
>
>
> [1] http://openjdk.java.net/jeps/8068562  - JEP draft: javadoc tags to
> distinguish API, implementation, specification, and notes
>
>
> On 8/5/2015 3:56 PM, Volker Simonis wrote:
>
> Hi,
>
> so here's the webrev which implements the new Info.commandLine()
> method (I chose 'commandLine() ' instead of 'cmdline()' or
> 'commandline()' because the other getters are camel case as well):
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v4/
>
> From the JavaDoc of the new method:
>
> * If {@code command()} and  {@code arguments()} return non-null
> * optionals, this is simply a convenience method which concatenates
> * the values of the two functions. Otherwise it will return a
> * best-effort, platform dependent representation of the command line.
>
> This didn't change anything on MacOS X where there is no additional
> effort to get the command line.
>
> On Solaris and AIX, Info.commandLine() will always return the contents
> of psinfo.pr_psargs because there's no other method to get the exact
> arguments (i.e. Info.arguments() always returns NULL. I could
> therefore remove the extra handling of AIX/Solaris in the InfoTest
> from my initial change.
>
> On Linux, things are a little more complicated:
>
> - the initial implementation for Linux used arg[0] as 'command' if
> /proc/pid/exe wasn't readable. This was true for all the processes we
> don't own (except if we are running as root). But this information may
> be incomplete, because arg[0] may only contain the command without its
> full path. One example is 'sendmail' for which Info.command() reported
> "sendmail: accepting connections" but Info.arguments() was empty. This
> is wrong, because 'sendmail' changes its argv[] array. I have
> therefore disabled this behavior now that we have the 'commandLine()'
> method.
>
> - /proc/pid/cmdline is limited to PAGE_SIZE (normally 4096) characters
> on Linux. So strictly speaking, this isn't 'exact' information as well
> (there are plenty of complains that especially for Java programs this
> is not enough) and should go to 'commandLine()' instead to 'arguments'
> if /proc/pid/cmdline is truncated. I do check for this now.
>
> - the information in /proc/pid/cmdline can also be changed to
> something other than the original arguments if a program changes
> argv[] (which is not forbidden) but there's probably not much we can
> do to detect this. I've added a corresponding @implNote comment to
> JavaDoc of Info.arguments().
>
> - the initial implementation did not check for incomplete reads of
> /proc/pid/cmdline. This may be a problem on systems with PAGE_SIZE >
> 4096 (on Linux/ppc64 a page size of 65536 is not unusual). I'm now
> always reading the complete contents of /proc/pid/cmdline.
>
> - as far as I understand the current implementation, 'arguments()'
> returns the arguments array WITHOUT 'arg[0]' (which is the program
> name) but may
> be we should specify that more clearly in the JavaDoc of 'arguments()'.
>
> That's it. Hope you like it :)
>
> Regards,
> Volker
>
> On Fri, Jul 31, 2015 at 11:02 PM, Stuart Marks 
> wrote:
>
> Hi Roger, Volker,
>
> Glad to see you guys are receptive to this and that it can move forward. Let
> me know if you'd like me to help out, for example with reviews or something.
>
> s'marks
>
>
> On 7/31/15 9:55 AM, Roger Riggs wrote:
>
> Hi Volker,
>
> I agree that adding an Info.commandline() method would be a good way
> to make the command line available and be able to describe that it is
> OS dependent and may be truncated.
> And having it assemble the command and arguments when they are available
> makes
> sense.
> As an API addition it will need a clear spec and I can run it through CCC
> so it
> gets
> another review and compatibility tests.
>
> Thanks, Roger
>
>
>
>
> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>
> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks 
> wrote:
>
> On 7/29/15 11:36 AM, Volker Simonis wrote:
>
> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
> truncated or incomplete
> values for the executable or arguments.
> Can anyone be a tie-breaker  (with a good rational and suggestion for
> how
> an
> application can use the data).
>
> As I wrote, I agree to hear other opinions here.
>
> All I want to say that this truncated data is actually what 'ps' is
> reporting on Solaris since decades and people seem to be happy with
> it. As use case I can imagine logging or monitoring (something like
> 'top' in Java) where this data will be just good enough.
>
> We could specially mark possibly incomplete data by extending the Info
> object with functions like commandIsExact() or argumentsIsPrecise().
> But notice that we can not statically preset these values per
> platform. For example on Solaris, the 'command()' would return a
> precise value for processes with the same uid like the VM but only
> inaccurate values for all other processes. The "arguments()" would be
> always inaccurate on Solaris/AIX.
>
> It seems like there are cases where either exact or only approximate
> information is available. And as you observed, you might get one or the
> other on the same platform, depending on the UID. It also might depend
> on
> process state; I believe that some information becomes inaccessible when
> the
> process enters the zombie state.
>
> I don't think we should simply ignore one case or the other, but I also
> don't think we should try to cram the different information into the
> same
> API.
>
> The current ProcessHandle.Info api has
>
>      Optional command()
>      Optional arguments()
>
> It sounds to me like Roger wants these to contain only exact
> information.
> That seems reasonable, and this probably needs to be specified more
> clearly
> to contrast with what's below.
>
> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
> single string which appears to be the concatenation of the arguments
> (maybe
> including the command name). It's also truncated to fit PRARGSZ. It
> doesn't
> make sense to me to try to return this as a String[], as the zeroth
> element
> of that array, and certainly not parsed out into "words". So maybe
> instead
> we should have a different API that returns an imprecise command line as
> a
> single string:
>
>      Optional cmdline()
>
> (Naming bikeshed TBS). The semantics would be that this is the process'
> command and arguments concatenated into a single string (thus
> potentially
> losing argument boundaries) and also possibly truncated based on
> platform
> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out
> in a
> ps, top, or Activity Monitor style application, for informational
> purposes.
>
> If this were implemented, then on Solaris, command() and arguments()
> would
> always return empty optionals.
>
> I'm not sure what this should be if the exact information is available.
> It
> would be inconvenient if something that just wanted to print out an
> approximate command line had to check several different APIs to get the
> information. Maybe cmdline() could assemble the information from exact
> data
> if it's is available, by concatenating the Strings from command() and
> arguments(), as a convenience to the caller. But I could go either way
> on
> this.
>
> Not sure this counts as a tie-breaker, but it might be a reasonable way
> forward.
>
> s'marks
>
> Hi Stuart,
>
> thanks a lot for your comments - I like your proposal. For me this
> sounds like a good compromise.
>
> @Roger: should I go and add a new field commandLine and the
> corresponding getter to the Info class? As Stuart proposed, the getter
> could check if 'command' and 'arguments' are available and assemble
> the command line from them. Otherwise it could use the content of the
> commandLine field if that is available.
>
> Regards,
> Volker
>
>
>


From martinrb at google.com  Tue Aug 11 16:10:10 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 11 Aug 2015 09:10:10 -0700
Subject: RFR [9] 8133188: docs: replace  tags (obsolete in html5) for
	java.util
In-Reply-To: <55C9DDA5.4090501@oracle.com>
References: <55C8A98C.3090002@oracle.com>
	
	<55C9DDA5.4090501@oracle.com>
Message-ID: 

Thanks!   Looks good to me.

On Tue, Aug 11, 2015 at 4:33 AM, Alexander Stepanov <
alexander.v.stepanov at oracle.com> wrote:

> Hello Martin,
>
> the changes were reverted for the following files:
>
> java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
> java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
> java.base/share/classes/java/util/AbstractQueue.java
> java.base/share/classes/java/util/Deque.java
> java.base/share/classes/java/util/NavigableMap.java
> java.base/share/classes/java/util/NavigableSet.java
>
> webrev updated:
> http://cr.openjdk.java.net/~avstepan/8133188/webrev.02
>
> specdiff report (please update the web page):
>
> http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html
> (the changes in concurrent are seemingly due to inherited documentation).
>
> Regards,
> Alexander
>
>
> On 8/10/2015 5:28 PM, Martin Buchholz wrote:
>
> Hi Alexander,
>
> I've been hoping that someone does cleanups of the jdk as you are doing
> now.
>
> Some of these source files are part of jsr166 and are maintained
> separately, in jsr166 CVS.
> http://g.oswego.edu/dl/concurrency-interest/
> And that has already been /-cleaned (although it has been done
> slightly differently) and will be integrated into jdk9 in an upcoming
> merge.  So please leave out:
> concurrent/
> *Queue.java
> *Deque.java
> Navigable*.java
>
> On Mon, Aug 10, 2015 at 6:39 AM, Alexander Stepanov <
> alexander.v.stepanov at oracle.com> wrote:
>
>> Hello,
>>
>> Could you please review the following fix:
>> http://cr.openjdk.java.net/~avstepan/8133188/webrev.01
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8133188
>>
>> Just a next portion of "" tags removed.
>>
>> specdiff report:
>>
>> http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html
>>  - some constructs like
>> "(o==null ? e==null : o.equals(e))"
>> were replaced with "{@code Objects.equals(o, e)}"
>> <%7B at codeObjects.equals(o,e)%7D>
>> (e.g.,
>> http://cr.openjdk.java.net/~avstepan/8133188/webrev.01/src/java.base/share/classes/java/util/LinkedList.java.udiff.html);
>> - please see JDK-8133188 comments.
>>
>> Thanks,
>> Alexander
>>
>
>
>


From alexander.v.stepanov at oracle.com  Tue Aug 11 16:10:50 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Tue, 11 Aug 2015 19:10:50 +0300
Subject: RFR [9] 8133188: docs: replace  tags (obsolete in html5)
	for java.util
In-Reply-To: 
References: <55C8A98C.3090002@oracle.com>		<55C9DDA5.4090501@oracle.com>
	
Message-ID: <55CA1E8A.2030500@oracle.com>

Thanks!

Regards,
Alexander

On 8/11/2015 7:10 PM, Martin Buchholz wrote:
> Thanks!   Looks good to me.
>
> On Tue, Aug 11, 2015 at 4:33 AM, Alexander Stepanov 
>  > wrote:
>
>     Hello Martin,
>
>     the changes were reverted for the following files:
>
>     java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
>     java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
>     java.base/share/classes/java/util/AbstractQueue.java
>     java.base/share/classes/java/util/Deque.java
>     java.base/share/classes/java/util/NavigableMap.java
>     java.base/share/classes/java/util/NavigableSet.java
>
>     webrev updated:
>     http://cr.openjdk.java.net/~avstepan/8133188/webrev.02
>     
>
>     specdiff report (please update the web page):
>     http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html
>     
>     (the changes in concurrent are seemingly due to inherited
>     documentation).
>
>     Regards,
>     Alexander
>
>
>     On 8/10/2015 5:28 PM, Martin Buchholz wrote:
>>     Hi Alexander,
>>
>>     I've been hoping that someone does cleanups of the jdk as you are
>>     doing now.
>>
>>     Some of these source files are part of jsr166 and are maintained
>>     separately, in jsr166 CVS.
>>     http://g.oswego.edu/dl/concurrency-interest/
>>     And that has already been /-cleaned (although it has
>>     been done slightly differently) and will be integrated into jdk9
>>     in an upcoming merge.  So please leave out:
>>     concurrent/
>>     *Queue.java
>>     *Deque.java
>>     Navigable*.java
>>
>>     On Mon, Aug 10, 2015 at 6:39 AM, Alexander Stepanov
>>     >     > wrote:
>>
>>         Hello,
>>
>>         Could you please review the following fix:
>>         http://cr.openjdk.java.net/~avstepan/8133188/webrev.01
>>         
>>         for
>>         https://bugs.openjdk.java.net/browse/JDK-8133188
>>
>>         Just a next portion of "" tags removed.
>>
>>         specdiff report:
>>         http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html
>>         
>>          - some constructs like
>>         "(o==null ? e==null : o.equals(e))"
>>         were replaced with "{@code Objects.equals(o, e)}"
>>         
>>         (e.g.,
>>         http://cr.openjdk.java.net/~avstepan/8133188/webrev.01/src/java.base/share/classes/java/util/LinkedList.java.udiff.html
>>         );
>>         - please see JDK-8133188 comments.
>>
>>         Thanks,
>>         Alexander
>>
>>
>
>



From stuart.marks at oracle.com  Tue Aug 11 22:07:53 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 11 Aug 2015 15:07:53 -0700
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: 
References: <55B6938E.2010806@Oracle.com> <55B6940D.90701@Oracle.com>
	
	<55BAC679.7010108@oracle.com>
	
	<55BBA878.3090509@Oracle.com> <55BBE261.4060902@oracle.com>
	
	<55C4FEEC.1010804@Oracle.com>
	
	<55CA1003.8030201@Oracle.com>
	
Message-ID: <55CA7239.2010905@oracle.com>

Hi Volker,

I looked at the proposed specification of commandLine() after the most recent 
round of reviews (which is 8131168.v6 I believe) and it looks fine to me. It 
expresses the intent pretty well. Oh, and the name "commandLine" is fine and it 
fits well with the names of the other methods.

Thanks,

s'marks

On 8/11/15 8:52 AM, Volker Simonis wrote:
> On Tue, Aug 11, 2015 at 5:08 PM, Roger Riggs  wrote:
>> Hi Volker,
>>
>> Thanks for checking into the details of the OS X sysctl.  I'm fine with the
>> current implementation.
>>
>> The rest of the updates and the additional tests look fine also.
>>
>
> Phew! I was already afraid I would have to switch to double-digit
> versions for my webrevs :)
>
>> But I need to check on the CCC status.
>>
>
> OK, please let me know once it is ready/approved.
>
> Regards,
> Volker
>
>> Thanks, Roger
>>
>>
>>
>>
>> On 8/10/15 10:13 AM, Volker Simonis wrote:
>>
>> On Fri, Aug 7, 2015 at 8:54 PM, Roger Riggs  wrote:
>>
>> Hi Volker,
>>
>> 1) ProcessHandle.java:243
>>
>> For the definition of the new commandLine method I would:
>>
>>    - Use @link instead of @code for references to commands() and arguments()
>> for easy navigation
>>
>>    - @implNote[1] should I think be changed to @apiNote:
>>    the text describes not the JDK implementation but is information about the
>>    information returned and is use to the application developer, not the JDK
>> implementation.
>>
>>    -  The specific references to Linux implementation command line length
>> parameters seems out of place
>>        and should be omitted.
>>
>>          /**
>>           * Returns the command line of the process.
>>           * 

>>           * If {@link #command command()} and  {@link #arguments arguments()}
>> return non-null
>>           * optionals, this is simply a convenience method which concatenates
>>           * the values of the two functions separated by spaces. Otherwise it
>> will return a
>>           * best-effort, platform dependent representation of the command
>> line.
>>           *
>>           * @apiNote Note that the returned executable pathname and the
>>           *           arguments may be truncated on some platforms due to
>> system
>>           *           limitations.
>>           *           

>>           *           The executable pathname may contain only the
>>           *           name of the executable without the full path
>> information.
>>           *           It is undecideable whether white space separates
>> different
>>           *           arguments or is part of a single argument.
>>           *
>>           * @return an {@code Optional} of the command line
>>           *         of the process
>>           */
>>          public Optional commandLine();
>>
>>
>> ProcessHandle.java:252: in arguments() method - @apiNote is a better fit for
>> the note
>>
>> ProcessHandleImpl_macosx.c:276:   - indentation +4
>>
>> Thanks for the correction. I've taken your wording you suggested.
>>
>> 2) ProcessHandleImpl_macosx.c:192:
>>      if (errno != EINVAL) ...  There was previously this test,  I'm concerned
>> that if the pid is invalid,
>>      it will now throw a RuntimeException instead of returning -1.
>>      I recall a discussion from May that recommended testing for EINVAL.
>>      The sysctl in getCmdlineAndUserInfo also does not throw if errno !=
>> EINVAL, so the usage
>>      is not consistent (probably my coding) but needs investigation.
>>
>> Not sure about this one and couldn't find any previous discussion
>> about the topic.
>>
>> But, according to the sysctl man-page, EINVAL is only returned if:
>>   - The name array is less than two or greater than CTL_MAXNAME.
>>   - A non-null newp is given and its specified length in newlen is too
>> large or too small.
>>
>> The first case can not happen because we always statically allocate
>> arrays of the correct size.
>> The second case can not happen as well, because we always have 'newp ==
>> NULL'.
>>
>> So according to this information I don't see any reason why we should
>> check for EINVAL. I think the right solution is to check for 'oldlenp
>>
>> 0' which we already do. By the way, this is also the check applied
>>
>> by the psutils (see the implementation of 'get_kinfo_proc()' in [1]).
>>
>> So I wnated to also removed the last check for EINVAL in
>> getCmdlineAndUserInfo(). But for some reason, that seems to be really
>> necessary. Without it, we will get a RuntinmeException if we call
>> sysinfo for pid==0 for example. Further research showed that the
>> kernel seems to really return EINVAL for KERN_PROCARGS2 (see function
>> sysctl_procargsx() in [2]). But KERN_PROCARGS2 isn't specified as a
>> supported constant in the sysctl man-page, so the information there is
>> still valid :)
>>
>> On the other hand, I found that the psutils alo handles EINVAL only
>> for KERN_PROCARGS2 (see get_arg_list() in [1]).
>>
>> So to cut a long story short, I think the current implementation is
>> safe as it is now!
>>
>> [1] http://psutil.googlecode.com/svn/trunk/psutil/arch/osx/process_info.c
>> [2]
>> http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/bsd/kern/kern_sysctl.c
>>
>> 3) ProcessHandleImpl_solaris.c can do without the includes:
>> #include "jni_util.h"
>> #include "java_lang_ProcessHandleImpl.h"
>> #include "java_lang_ProcessHandleImpl_Info.h"
>>
>> #include 
>>
>> 4) Ditto ProcessHandleImpl_aix.c
>>
>> Thanks, fixed.
>>
>> 5) ProcessHandleImpl_unix.c: 618:  typo  "fuctions" -> "functions"
>>
>> Fixed.
>>
>> 6) ProcessHandleImpl_unix.c:463: Would it be worthwhile to put
>> sysconf(_SC_GETPW_R_SIZE_MAX) in a static?
>>
>> Good point! While doing this I realized that 'clock_ticks_per_second'
>> is only used on Linux. So I moved the declaration of
>> 'clock_ticks_per_second' from ProcessHandleImpl_unix.hpp to
>> ProcessHandleImpl_linux.cpp and its initialization to  os_initNative()
>> in the same file.
>>
>> I also declare a new static 'getpw_buf_size' in
>> ProcessHandleImpl_unix.cpp and initialize it in
>> Java_java_lang_ProcessHandleImpl_initNative() in the same file.
>>
>> 7) OnExitTest.java: exits without an error, just output in the log; it would
>> escape attention.
>>      The code respects the timeout setting.
>>      Suggest removing the 'return' @133; the test will produce some errors
>> and when debugging
>>      the note will be in the log.
>>
>> Done.
>>
>> 8) ProcessHandleImpl_unix.h:58 - update the comment to include 0 as a valid
>> parent pid.
>>
>> Fixed.
>>
>> Looks pretty good,
>> Thanks, Roger
>>
>> Thanks:)
>>
>> I've also added two rudimentary tests for the new commandLine()
>> function to InfoTest.test2():
>>
>>   - if both, 'command()' and 'arguments()' are available, I check that
>> 'commandLine()' starts with 'command()' and contains all the arguments
>> from 'arguments()'.
>>
>>   - otherwise, if 'commandLine()' is available, I check that it at
>> least contains 'java'.  And as long as it is big enough it should also
>> contain the corresponding arguments.
>>
>> The two new tests have been verified to pass on Windows, Linux, MacOS
>> X, Solaris and AIX.
>>
>> The new version can be found here:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v6/
>>
>> Regards,
>> Volker
>>
>>
>> [1] http://openjdk.java.net/jeps/8068562  - JEP draft: javadoc tags to
>> distinguish API, implementation, specification, and notes
>>
>>
>> On 8/5/2015 3:56 PM, Volker Simonis wrote:
>>
>> Hi,
>>
>> so here's the webrev which implements the new Info.commandLine()
>> method (I chose 'commandLine() ' instead of 'cmdline()' or
>> 'commandline()' because the other getters are camel case as well):
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v4/
>>
>>  From the JavaDoc of the new method:
>>
>> * If {@code command()} and  {@code arguments()} return non-null
>> * optionals, this is simply a convenience method which concatenates
>> * the values of the two functions. Otherwise it will return a
>> * best-effort, platform dependent representation of the command line.
>>
>> This didn't change anything on MacOS X where there is no additional
>> effort to get the command line.
>>
>> On Solaris and AIX, Info.commandLine() will always return the contents
>> of psinfo.pr_psargs because there's no other method to get the exact
>> arguments (i.e. Info.arguments() always returns NULL. I could
>> therefore remove the extra handling of AIX/Solaris in the InfoTest
>> from my initial change.
>>
>> On Linux, things are a little more complicated:
>>
>> - the initial implementation for Linux used arg[0] as 'command' if
>> /proc/pid/exe wasn't readable. This was true for all the processes we
>> don't own (except if we are running as root). But this information may
>> be incomplete, because arg[0] may only contain the command without its
>> full path. One example is 'sendmail' for which Info.command() reported
>> "sendmail: accepting connections" but Info.arguments() was empty. This
>> is wrong, because 'sendmail' changes its argv[] array. I have
>> therefore disabled this behavior now that we have the 'commandLine()'
>> method.
>>
>> - /proc/pid/cmdline is limited to PAGE_SIZE (normally 4096) characters
>> on Linux. So strictly speaking, this isn't 'exact' information as well
>> (there are plenty of complains that especially for Java programs this
>> is not enough) and should go to 'commandLine()' instead to 'arguments'
>> if /proc/pid/cmdline is truncated. I do check for this now.
>>
>> - the information in /proc/pid/cmdline can also be changed to
>> something other than the original arguments if a program changes
>> argv[] (which is not forbidden) but there's probably not much we can
>> do to detect this. I've added a corresponding @implNote comment to
>> JavaDoc of Info.arguments().
>>
>> - the initial implementation did not check for incomplete reads of
>> /proc/pid/cmdline. This may be a problem on systems with PAGE_SIZE >
>> 4096 (on Linux/ppc64 a page size of 65536 is not unusual). I'm now
>> always reading the complete contents of /proc/pid/cmdline.
>>
>> - as far as I understand the current implementation, 'arguments()'
>> returns the arguments array WITHOUT 'arg[0]' (which is the program
>> name) but may
>> be we should specify that more clearly in the JavaDoc of 'arguments()'.
>>
>> That's it. Hope you like it :)
>>
>> Regards,
>> Volker
>>
>> On Fri, Jul 31, 2015 at 11:02 PM, Stuart Marks 
>> wrote:
>>
>> Hi Roger, Volker,
>>
>> Glad to see you guys are receptive to this and that it can move forward. Let
>> me know if you'd like me to help out, for example with reviews or something.
>>
>> s'marks
>>
>>
>> On 7/31/15 9:55 AM, Roger Riggs wrote:
>>
>> Hi Volker,
>>
>> I agree that adding an Info.commandline() method would be a good way
>> to make the command line available and be able to describe that it is
>> OS dependent and may be truncated.
>> And having it assemble the command and arguments when they are available
>> makes
>> sense.
>> As an API addition it will need a clear spec and I can run it through CCC
>> so it
>> gets
>> another review and compatibility tests.
>>
>> Thanks, Roger
>>
>>
>>
>>
>> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>>
>> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks 
>> wrote:
>>
>> On 7/29/15 11:36 AM, Volker Simonis wrote:
>>
>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>> truncated or incomplete
>> values for the executable or arguments.
>> Can anyone be a tie-breaker  (with a good rational and suggestion for
>> how
>> an
>> application can use the data).
>>
>> As I wrote, I agree to hear other opinions here.
>>
>> All I want to say that this truncated data is actually what 'ps' is
>> reporting on Solaris since decades and people seem to be happy with
>> it. As use case I can imagine logging or monitoring (something like
>> 'top' in Java) where this data will be just good enough.
>>
>> We could specially mark possibly incomplete data by extending the Info
>> object with functions like commandIsExact() or argumentsIsPrecise().
>> But notice that we can not statically preset these values per
>> platform. For example on Solaris, the 'command()' would return a
>> precise value for processes with the same uid like the VM but only
>> inaccurate values for all other processes. The "arguments()" would be
>> always inaccurate on Solaris/AIX.
>>
>> It seems like there are cases where either exact or only approximate
>> information is available. And as you observed, you might get one or the
>> other on the same platform, depending on the UID. It also might depend
>> on
>> process state; I believe that some information becomes inaccessible when
>> the
>> process enters the zombie state.
>>
>> I don't think we should simply ignore one case or the other, but I also
>> don't think we should try to cram the different information into the
>> same
>> API.
>>
>> The current ProcessHandle.Info api has
>>
>>       Optional command()
>>       Optional arguments()
>>
>> It sounds to me like Roger wants these to contain only exact
>> information.
>> That seems reasonable, and this probably needs to be specified more
>> clearly
>> to contrast with what's below.
>>
>> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
>> single string which appears to be the concatenation of the arguments
>> (maybe
>> including the command name). It's also truncated to fit PRARGSZ. It
>> doesn't
>> make sense to me to try to return this as a String[], as the zeroth
>> element
>> of that array, and certainly not parsed out into "words". So maybe
>> instead
>> we should have a different API that returns an imprecise command line as
>> a
>> single string:
>>
>>       Optional cmdline()
>>
>> (Naming bikeshed TBS). The semantics would be that this is the process'
>> command and arguments concatenated into a single string (thus
>> potentially
>> losing argument boundaries) and also possibly truncated based on
>> platform
>> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out
>> in a
>> ps, top, or Activity Monitor style application, for informational
>> purposes.
>>
>> If this were implemented, then on Solaris, command() and arguments()
>> would
>> always return empty optionals.
>>
>> I'm not sure what this should be if the exact information is available.
>> It
>> would be inconvenient if something that just wanted to print out an
>> approximate command line had to check several different APIs to get the
>> information. Maybe cmdline() could assemble the information from exact
>> data
>> if it's is available, by concatenating the Strings from command() and
>> arguments(), as a convenience to the caller. But I could go either way
>> on
>> this.
>>
>> Not sure this counts as a tie-breaker, but it might be a reasonable way
>> forward.
>>
>> s'marks
>>
>> Hi Stuart,
>>
>> thanks a lot for your comments - I like your proposal. For me this
>> sounds like a good compromise.
>>
>> @Roger: should I go and add a new field commandLine and the
>> corresponding getter to the Info class? As Stuart proposed, the getter
>> could check if 'command' and 'arguments' are available and assemble
>> the command line from them. Otherwise it could use the content of the
>> commandLine field if that is available.
>>
>> Regards,
>> Volker
>>
>>
>>


From stuart.marks at oracle.com  Tue Aug 11 22:19:34 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 11 Aug 2015 15:19:34 -0700
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: <55CA7239.2010905@oracle.com>
References: <55B6938E.2010806@Oracle.com> <55B6940D.90701@Oracle.com>
	
	<55BAC679.7010108@oracle.com>
	
	<55BBA878.3090509@Oracle.com> <55BBE261.4060902@oracle.com>
	
	<55C4FEEC.1010804@Oracle.com>
	
	<55CA1003.8030201@Oracle.com>
	
	<55CA7239.2010905@oracle.com>
Message-ID: <55CA74F6.3070502@oracle.com>

.. and of course right after I sent my previous message, I ran across something 
worth noting.

The proposed spec for commandLine() says,

* If {@link #command command()} and  {@link #arguments arguments()} return non-null
* optionals,

The preferred term is "non-empty" instead of non-null. This is kind of nitpicky 
but in fact command() and arguments() should NEVER return an actual null; they 
should always return an Optional that is either empty or that has a value. So I 
think this is important to change lest someone be misled into writing

     if (info.command() == null && info.arguments() == null) ...

Thanks,

s'marks


On 8/11/15 3:07 PM, Stuart Marks wrote:
> Hi Volker,
>
> I looked at the proposed specification of commandLine() after the most recent
> round of reviews (which is 8131168.v6 I believe) and it looks fine to me. It
> expresses the intent pretty well. Oh, and the name "commandLine" is fine and it
> fits well with the names of the other methods.
>
> Thanks,
>
> s'marks
>
> On 8/11/15 8:52 AM, Volker Simonis wrote:
>> On Tue, Aug 11, 2015 at 5:08 PM, Roger Riggs  wrote:
>>> Hi Volker,
>>>
>>> Thanks for checking into the details of the OS X sysctl.  I'm fine with the
>>> current implementation.
>>>
>>> The rest of the updates and the additional tests look fine also.
>>>
>>
>> Phew! I was already afraid I would have to switch to double-digit
>> versions for my webrevs :)
>>
>>> But I need to check on the CCC status.
>>>
>>
>> OK, please let me know once it is ready/approved.
>>
>> Regards,
>> Volker
>>
>>> Thanks, Roger
>>>
>>>
>>>
>>>
>>> On 8/10/15 10:13 AM, Volker Simonis wrote:
>>>
>>> On Fri, Aug 7, 2015 at 8:54 PM, Roger Riggs  wrote:
>>>
>>> Hi Volker,
>>>
>>> 1) ProcessHandle.java:243
>>>
>>> For the definition of the new commandLine method I would:
>>>
>>>    - Use @link instead of @code for references to commands() and arguments()
>>> for easy navigation
>>>
>>>    - @implNote[1] should I think be changed to @apiNote:
>>>    the text describes not the JDK implementation but is information about the
>>>    information returned and is use to the application developer, not the JDK
>>> implementation.
>>>
>>>    -  The specific references to Linux implementation command line length
>>> parameters seems out of place
>>>        and should be omitted.
>>>
>>>          /**
>>>           * Returns the command line of the process.
>>>           * 

>>>           * If {@link #command command()} and  {@link #arguments arguments()}
>>> return non-null
>>>           * optionals, this is simply a convenience method which concatenates
>>>           * the values of the two functions separated by spaces. Otherwise it
>>> will return a
>>>           * best-effort, platform dependent representation of the command
>>> line.
>>>           *
>>>           * @apiNote Note that the returned executable pathname and the
>>>           *           arguments may be truncated on some platforms due to
>>> system
>>>           *           limitations.
>>>           *           

>>>           *           The executable pathname may contain only the
>>>           *           name of the executable without the full path
>>> information.
>>>           *           It is undecideable whether white space separates
>>> different
>>>           *           arguments or is part of a single argument.
>>>           *
>>>           * @return an {@code Optional} of the command line
>>>           *         of the process
>>>           */
>>>          public Optional commandLine();
>>>
>>>
>>> ProcessHandle.java:252: in arguments() method - @apiNote is a better fit for
>>> the note
>>>
>>> ProcessHandleImpl_macosx.c:276:   - indentation +4
>>>
>>> Thanks for the correction. I've taken your wording you suggested.
>>>
>>> 2) ProcessHandleImpl_macosx.c:192:
>>>      if (errno != EINVAL) ...  There was previously this test,  I'm concerned
>>> that if the pid is invalid,
>>>      it will now throw a RuntimeException instead of returning -1.
>>>      I recall a discussion from May that recommended testing for EINVAL.
>>>      The sysctl in getCmdlineAndUserInfo also does not throw if errno !=
>>> EINVAL, so the usage
>>>      is not consistent (probably my coding) but needs investigation.
>>>
>>> Not sure about this one and couldn't find any previous discussion
>>> about the topic.
>>>
>>> But, according to the sysctl man-page, EINVAL is only returned if:
>>>   - The name array is less than two or greater than CTL_MAXNAME.
>>>   - A non-null newp is given and its specified length in newlen is too
>>> large or too small.
>>>
>>> The first case can not happen because we always statically allocate
>>> arrays of the correct size.
>>> The second case can not happen as well, because we always have 'newp ==
>>> NULL'.
>>>
>>> So according to this information I don't see any reason why we should
>>> check for EINVAL. I think the right solution is to check for 'oldlenp
>>>
>>> 0' which we already do. By the way, this is also the check applied
>>>
>>> by the psutils (see the implementation of 'get_kinfo_proc()' in [1]).
>>>
>>> So I wnated to also removed the last check for EINVAL in
>>> getCmdlineAndUserInfo(). But for some reason, that seems to be really
>>> necessary. Without it, we will get a RuntinmeException if we call
>>> sysinfo for pid==0 for example. Further research showed that the
>>> kernel seems to really return EINVAL for KERN_PROCARGS2 (see function
>>> sysctl_procargsx() in [2]). But KERN_PROCARGS2 isn't specified as a
>>> supported constant in the sysctl man-page, so the information there is
>>> still valid :)
>>>
>>> On the other hand, I found that the psutils alo handles EINVAL only
>>> for KERN_PROCARGS2 (see get_arg_list() in [1]).
>>>
>>> So to cut a long story short, I think the current implementation is
>>> safe as it is now!
>>>
>>> [1] http://psutil.googlecode.com/svn/trunk/psutil/arch/osx/process_info.c
>>> [2]
>>> http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/bsd/kern/kern_sysctl.c
>>>
>>> 3) ProcessHandleImpl_solaris.c can do without the includes:
>>> #include "jni_util.h"
>>> #include "java_lang_ProcessHandleImpl.h"
>>> #include "java_lang_ProcessHandleImpl_Info.h"
>>>
>>> #include 
>>>
>>> 4) Ditto ProcessHandleImpl_aix.c
>>>
>>> Thanks, fixed.
>>>
>>> 5) ProcessHandleImpl_unix.c: 618:  typo  "fuctions" -> "functions"
>>>
>>> Fixed.
>>>
>>> 6) ProcessHandleImpl_unix.c:463: Would it be worthwhile to put
>>> sysconf(_SC_GETPW_R_SIZE_MAX) in a static?
>>>
>>> Good point! While doing this I realized that 'clock_ticks_per_second'
>>> is only used on Linux. So I moved the declaration of
>>> 'clock_ticks_per_second' from ProcessHandleImpl_unix.hpp to
>>> ProcessHandleImpl_linux.cpp and its initialization to  os_initNative()
>>> in the same file.
>>>
>>> I also declare a new static 'getpw_buf_size' in
>>> ProcessHandleImpl_unix.cpp and initialize it in
>>> Java_java_lang_ProcessHandleImpl_initNative() in the same file.
>>>
>>> 7) OnExitTest.java: exits without an error, just output in the log; it would
>>> escape attention.
>>>      The code respects the timeout setting.
>>>      Suggest removing the 'return' @133; the test will produce some errors
>>> and when debugging
>>>      the note will be in the log.
>>>
>>> Done.
>>>
>>> 8) ProcessHandleImpl_unix.h:58 - update the comment to include 0 as a valid
>>> parent pid.
>>>
>>> Fixed.
>>>
>>> Looks pretty good,
>>> Thanks, Roger
>>>
>>> Thanks:)
>>>
>>> I've also added two rudimentary tests for the new commandLine()
>>> function to InfoTest.test2():
>>>
>>>   - if both, 'command()' and 'arguments()' are available, I check that
>>> 'commandLine()' starts with 'command()' and contains all the arguments
>>> from 'arguments()'.
>>>
>>>   - otherwise, if 'commandLine()' is available, I check that it at
>>> least contains 'java'.  And as long as it is big enough it should also
>>> contain the corresponding arguments.
>>>
>>> The two new tests have been verified to pass on Windows, Linux, MacOS
>>> X, Solaris and AIX.
>>>
>>> The new version can be found here:
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v6/
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> [1] http://openjdk.java.net/jeps/8068562  - JEP draft: javadoc tags to
>>> distinguish API, implementation, specification, and notes
>>>
>>>
>>> On 8/5/2015 3:56 PM, Volker Simonis wrote:
>>>
>>> Hi,
>>>
>>> so here's the webrev which implements the new Info.commandLine()
>>> method (I chose 'commandLine() ' instead of 'cmdline()' or
>>> 'commandline()' because the other getters are camel case as well):
>>>
>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v4/
>>>
>>>  From the JavaDoc of the new method:
>>>
>>> * If {@code command()} and  {@code arguments()} return non-null
>>> * optionals, this is simply a convenience method which concatenates
>>> * the values of the two functions. Otherwise it will return a
>>> * best-effort, platform dependent representation of the command line.
>>>
>>> This didn't change anything on MacOS X where there is no additional
>>> effort to get the command line.
>>>
>>> On Solaris and AIX, Info.commandLine() will always return the contents
>>> of psinfo.pr_psargs because there's no other method to get the exact
>>> arguments (i.e. Info.arguments() always returns NULL. I could
>>> therefore remove the extra handling of AIX/Solaris in the InfoTest
>>> from my initial change.
>>>
>>> On Linux, things are a little more complicated:
>>>
>>> - the initial implementation for Linux used arg[0] as 'command' if
>>> /proc/pid/exe wasn't readable. This was true for all the processes we
>>> don't own (except if we are running as root). But this information may
>>> be incomplete, because arg[0] may only contain the command without its
>>> full path. One example is 'sendmail' for which Info.command() reported
>>> "sendmail: accepting connections" but Info.arguments() was empty. This
>>> is wrong, because 'sendmail' changes its argv[] array. I have
>>> therefore disabled this behavior now that we have the 'commandLine()'
>>> method.
>>>
>>> - /proc/pid/cmdline is limited to PAGE_SIZE (normally 4096) characters
>>> on Linux. So strictly speaking, this isn't 'exact' information as well
>>> (there are plenty of complains that especially for Java programs this
>>> is not enough) and should go to 'commandLine()' instead to 'arguments'
>>> if /proc/pid/cmdline is truncated. I do check for this now.
>>>
>>> - the information in /proc/pid/cmdline can also be changed to
>>> something other than the original arguments if a program changes
>>> argv[] (which is not forbidden) but there's probably not much we can
>>> do to detect this. I've added a corresponding @implNote comment to
>>> JavaDoc of Info.arguments().
>>>
>>> - the initial implementation did not check for incomplete reads of
>>> /proc/pid/cmdline. This may be a problem on systems with PAGE_SIZE >
>>> 4096 (on Linux/ppc64 a page size of 65536 is not unusual). I'm now
>>> always reading the complete contents of /proc/pid/cmdline.
>>>
>>> - as far as I understand the current implementation, 'arguments()'
>>> returns the arguments array WITHOUT 'arg[0]' (which is the program
>>> name) but may
>>> be we should specify that more clearly in the JavaDoc of 'arguments()'.
>>>
>>> That's it. Hope you like it :)
>>>
>>> Regards,
>>> Volker
>>>
>>> On Fri, Jul 31, 2015 at 11:02 PM, Stuart Marks 
>>> wrote:
>>>
>>> Hi Roger, Volker,
>>>
>>> Glad to see you guys are receptive to this and that it can move forward. Let
>>> me know if you'd like me to help out, for example with reviews or something.
>>>
>>> s'marks
>>>
>>>
>>> On 7/31/15 9:55 AM, Roger Riggs wrote:
>>>
>>> Hi Volker,
>>>
>>> I agree that adding an Info.commandline() method would be a good way
>>> to make the command line available and be able to describe that it is
>>> OS dependent and may be truncated.
>>> And having it assemble the command and arguments when they are available
>>> makes
>>> sense.
>>> As an API addition it will need a clear spec and I can run it through CCC
>>> so it
>>> gets
>>> another review and compatibility tests.
>>>
>>> Thanks, Roger
>>>
>>>
>>>
>>>
>>> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>>>
>>> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks 
>>> wrote:
>>>
>>> On 7/29/15 11:36 AM, Volker Simonis wrote:
>>>
>>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>>> truncated or incomplete
>>> values for the executable or arguments.
>>> Can anyone be a tie-breaker  (with a good rational and suggestion for
>>> how
>>> an
>>> application can use the data).
>>>
>>> As I wrote, I agree to hear other opinions here.
>>>
>>> All I want to say that this truncated data is actually what 'ps' is
>>> reporting on Solaris since decades and people seem to be happy with
>>> it. As use case I can imagine logging or monitoring (something like
>>> 'top' in Java) where this data will be just good enough.
>>>
>>> We could specially mark possibly incomplete data by extending the Info
>>> object with functions like commandIsExact() or argumentsIsPrecise().
>>> But notice that we can not statically preset these values per
>>> platform. For example on Solaris, the 'command()' would return a
>>> precise value for processes with the same uid like the VM but only
>>> inaccurate values for all other processes. The "arguments()" would be
>>> always inaccurate on Solaris/AIX.
>>>
>>> It seems like there are cases where either exact or only approximate
>>> information is available. And as you observed, you might get one or the
>>> other on the same platform, depending on the UID. It also might depend
>>> on
>>> process state; I believe that some information becomes inaccessible when
>>> the
>>> process enters the zombie state.
>>>
>>> I don't think we should simply ignore one case or the other, but I also
>>> don't think we should try to cram the different information into the
>>> same
>>> API.
>>>
>>> The current ProcessHandle.Info api has
>>>
>>>       Optional command()
>>>       Optional arguments()
>>>
>>> It sounds to me like Roger wants these to contain only exact
>>> information.
>>> That seems reasonable, and this probably needs to be specified more
>>> clearly
>>> to contrast with what's below.
>>>
>>> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
>>> single string which appears to be the concatenation of the arguments
>>> (maybe
>>> including the command name). It's also truncated to fit PRARGSZ. It
>>> doesn't
>>> make sense to me to try to return this as a String[], as the zeroth
>>> element
>>> of that array, and certainly not parsed out into "words". So maybe
>>> instead
>>> we should have a different API that returns an imprecise command line as
>>> a
>>> single string:
>>>
>>>       Optional cmdline()
>>>
>>> (Naming bikeshed TBS). The semantics would be that this is the process'
>>> command and arguments concatenated into a single string (thus
>>> potentially
>>> losing argument boundaries) and also possibly truncated based on
>>> platform
>>> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out
>>> in a
>>> ps, top, or Activity Monitor style application, for informational
>>> purposes.
>>>
>>> If this were implemented, then on Solaris, command() and arguments()
>>> would
>>> always return empty optionals.
>>>
>>> I'm not sure what this should be if the exact information is available.
>>> It
>>> would be inconvenient if something that just wanted to print out an
>>> approximate command line had to check several different APIs to get the
>>> information. Maybe cmdline() could assemble the information from exact
>>> data
>>> if it's is available, by concatenating the Strings from command() and
>>> arguments(), as a convenience to the caller. But I could go either way
>>> on
>>> this.
>>>
>>> Not sure this counts as a tie-breaker, but it might be a reasonable way
>>> forward.
>>>
>>> s'marks
>>>
>>> Hi Stuart,
>>>
>>> thanks a lot for your comments - I like your proposal. For me this
>>> sounds like a good compromise.
>>>
>>> @Roger: should I go and add a new field commandLine and the
>>> corresponding getter to the Info class? As Stuart proposed, the getter
>>> could check if 'command' and 'arguments' are available and assemble
>>> the command line from them. Otherwise it could use the content of the
>>> commandLine field if that is available.
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>>


From mandy.chung at oracle.com  Tue Aug 11 22:47:48 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 11 Aug 2015 15:47:48 -0700
Subject: RFR: 8132306: java/lang/ref/ReferenceEnqueue.java fails with
	"RuntimeException: Error: poll() returned null; expected ref object"
In-Reply-To: 
References: 	<55B88FAB.4080302@oracle.com>	<929281CB-55E8-4A0C-A8D1-85ED37348E12@oracle.com>	<55B9E293.80102@gmail.com>
	<55B9EA8A.1080102@oracle.com>	<55B9FA54.5040902@gmail.com>
	<55B9FB50.8050907@oracle.com>	<55B9FF5F.2020706@gmail.com>
	<55BA0E2B.9050101@oracle.com>	<55BA110F.2010101@gmail.com>
	<55BA13E8.1050606@oracle.com>		<55BA9830.8030308@oracle.com>
	
Message-ID: <55CA7B94.5030502@oracle.com>



On 07/30/2015 03:56 PM, Kim Barrett wrote:
> New webrev, with both changes: 
> http://cr.openjdk.java.net/~kbarrett/8132306/webrev.01/ 

Thanks for fixing this.  The change looks fine to me.  Sorry for the 
belated reply as I just got back from vacation.

I agree that this patch includes both of your change and Peter's change.

Mandy


From amaembo at gmail.com  Wed Aug 12 08:47:16 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Wed, 12 Aug 2015 14:47:16 +0600
Subject: Possible long overflow in Collectors.averagingLong and
	LongStream.average
Message-ID: <66545950.20150812144716@gmail.com>

Hello!

The following code prints -1 twice, while users would normally expect
something like 9.223372036854776E18:

double avg1 = Stream.of(Long.MAX_VALUE, Long.MAX_VALUE).collect(
                Collectors.averagingLong(Long::valueOf));
System.out.println(avg1);

double avg2 = LongStream.of(Long.MAX_VALUE, Long.MAX_VALUE).average()
                .getAsDouble();
System.out.println(avg2);

That's because in both cases internally sum is calculated in the long
variable where it may silently overflow. The documentation for both
methods says nothing about such possibility. I guess if it's too late
to fix this behavior, then probably it should be at least properly
documented?

With best regards,
Tagir Valeev.



From kumar.x.srinivasan at oracle.com  Wed Aug 12 14:55:13 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 12 Aug 2015 07:55:13 -0700
Subject: RFR v4 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: 
References: 
	
	
	
Message-ID: <55CB5E51.1040608@oracle.com>

Henry,

Generally looks good here are some comments, on my initial
pass, I am not fully done with args.c I will look at this some
more later today or tomorrow.

args.c:
1.) Can be folded

   45     char *rv;
   46
   47     rv = (char *) JLI_MemAlloc(len + 1);

char *rv = (char *) JLI_MemAlloc(len + 1);

2.) replace the defines with enum ?
  
   53 #define FIND_NEXT     0
   54 #define IN_COMMENT    1
   55 #define IN_QUOTE      2
   56 #define IN_ESCAPE     3
   57 #define SKIP_LEAD_WS  4
   58 #define IN_TOKEN      5

3.) I would rename the following, this is maintaining the state of
the state machine right ? So rename stage -> state

4.)
expectingNoDash is expectingMain right ? if so I would rename it so.

5.)

   84     if (isJava) {
   85         firstAppArgIndex = -1;
   86     } else {
   87         // tools, this value remains 0 all the time.
   88         firstAppArgIndex = 0;
   89     }
   90 }

can be written with unary operator

firstAppArgIndex = isJava ? -1 : 0;


TestHelper.java:

Why add findInOutput method ? this seems to be identical
to "matches" at line 606, which does exactly that.

ArgFileSyntax.java
Nice, but I think the creation and storage of test case can be simplified,
basically loadCases(), also please avoid  Xbootclasspath. The trouble
with these tests which operate loops, are very painful to debug
and isolate a failing case,  on the night before GA.

Can we do something like this.....

Map> tests = new ArrayList<>();
tests.put("testing quotes", Array.asList({{...}, {....}});
tests.add("no recurse expansion", Array.asList({{...}, {....}});

The execute each test, with a description of what the test is doing.
This way if a test fails its easy to zero in on the failing test.

Kumar


On 8/8/2015 12:03 AM, Henry Jen wrote:
> Hi,
>
> Another update for argument file support, this version we added a couple measures to ensure compatibility,
>
> 1) Compile time directive ENABLE_ARG_FILES is needed to enable the feature, only java is enabled with this webrev.
> 2) Escape @argument if so desired: Additional prefixes of @ to a @ prefixed option will  act as an escape, ie. the first @ will be removed and the rest of the arguments presented to the launcher literally.
>   
> For example:
>   
> java @ foo  gets arguments of @ foo
> java @filename, filename expanded
> java @@filename will have the leading @ removed and reduced to literal @filename
> similarly,
> java @@@filenamewill have the leading @ removed and reduced to literal @@filename
>   
>   3) The option '-Xdisable- at files' can be used on the command line anywhere to prevent further @filename expansion.
>   4) Limit the file size must not exceed MAXINT (2, 147, 483, 647) bytes.
>
> Webrev athttp://cr.openjdk.java.net/~henryjen/jdk9/8027634/v4/webrev/
>
> Cheers,
> Henry
>



From volker.simonis at gmail.com  Wed Aug 12 15:10:05 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 12 Aug 2015 17:10:05 +0200
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: <55CA74F6.3070502@oracle.com>
References: <55B6938E.2010806@Oracle.com> <55B6940D.90701@Oracle.com>
	
	<55BAC679.7010108@oracle.com>
	
	<55BBA878.3090509@Oracle.com> <55BBE261.4060902@oracle.com>
	
	<55C4FEEC.1010804@Oracle.com>
	
	<55CA1003.8030201@Oracle.com>
	
	<55CA7239.2010905@oracle.com> <55CA74F6.3070502@oracle.com>
Message-ID: 

Hi Stuart,

thanks for verifying the changes one more time.

On Wed, Aug 12, 2015 at 12:19 AM, Stuart Marks  wrote:
> .. and of course right after I sent my previous message, I ran across
> something worth noting.
>
> The proposed spec for commandLine() says,
>
> * If {@link #command command()} and  {@link #arguments arguments()} return
> non-null
> * optionals,
>
> The preferred term is "non-empty" instead of non-null. This is kind of
> nitpicky but in fact command() and arguments() should NEVER return an actual
> null; they should always return an Optional that is either empty or that has
> a value. So I think this is important to change lest someone be misled into
> writing
>
>     if (info.command() == null && info.arguments() == null) ...
>

Good point. I've updated the documentation accordingly and created:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v7/

Regards,
Volker

> Thanks,
>
> s'marks
>
>
>
> On 8/11/15 3:07 PM, Stuart Marks wrote:
>>
>> Hi Volker,
>>
>> I looked at the proposed specification of commandLine() after the most
>> recent
>> round of reviews (which is 8131168.v6 I believe) and it looks fine to me.
>> It
>> expresses the intent pretty well. Oh, and the name "commandLine" is fine
>> and it
>> fits well with the names of the other methods.
>>
>> Thanks,
>>
>> s'marks
>>
>> On 8/11/15 8:52 AM, Volker Simonis wrote:
>>>
>>> On Tue, Aug 11, 2015 at 5:08 PM, Roger Riggs 
>>> wrote:
>>>>
>>>> Hi Volker,
>>>>
>>>> Thanks for checking into the details of the OS X sysctl.  I'm fine with
>>>> the
>>>> current implementation.
>>>>
>>>> The rest of the updates and the additional tests look fine also.
>>>>
>>>
>>> Phew! I was already afraid I would have to switch to double-digit
>>> versions for my webrevs :)
>>>
>>>> But I need to check on the CCC status.
>>>>
>>>
>>> OK, please let me know once it is ready/approved.
>>>
>>> Regards,
>>> Volker
>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>>
>>>>
>>>> On 8/10/15 10:13 AM, Volker Simonis wrote:
>>>>
>>>> On Fri, Aug 7, 2015 at 8:54 PM, Roger Riggs 
>>>> wrote:
>>>>
>>>> Hi Volker,
>>>>
>>>> 1) ProcessHandle.java:243
>>>>
>>>> For the definition of the new commandLine method I would:
>>>>
>>>>    - Use @link instead of @code for references to commands() and
>>>> arguments()
>>>> for easy navigation
>>>>
>>>>    - @implNote[1] should I think be changed to @apiNote:
>>>>    the text describes not the JDK implementation but is information
>>>> about the
>>>>    information returned and is use to the application developer, not the
>>>> JDK
>>>> implementation.
>>>>
>>>>    -  The specific references to Linux implementation command line
>>>> length
>>>> parameters seems out of place
>>>>        and should be omitted.
>>>>
>>>>          /**
>>>>           * Returns the command line of the process.
>>>>           * 

>>>>           * If {@link #command command()} and  {@link #arguments
>>>> arguments()}
>>>> return non-null
>>>>           * optionals, this is simply a convenience method which
>>>> concatenates
>>>>           * the values of the two functions separated by spaces.
>>>> Otherwise it
>>>> will return a
>>>>           * best-effort, platform dependent representation of the
>>>> command
>>>> line.
>>>>           *
>>>>           * @apiNote Note that the returned executable pathname and the
>>>>           *           arguments may be truncated on some platforms due
>>>> to
>>>> system
>>>>           *           limitations.
>>>>           *           

>>>>           *           The executable pathname may contain only the
>>>>           *           name of the executable without the full path
>>>> information.
>>>>           *           It is undecideable whether white space separates
>>>> different
>>>>           *           arguments or is part of a single argument.
>>>>           *
>>>>           * @return an {@code Optional} of the command line
>>>>           *         of the process
>>>>           */
>>>>          public Optional commandLine();
>>>>
>>>>
>>>> ProcessHandle.java:252: in arguments() method - @apiNote is a better fit
>>>> for
>>>> the note
>>>>
>>>> ProcessHandleImpl_macosx.c:276:   - indentation +4
>>>>
>>>> Thanks for the correction. I've taken your wording you suggested.
>>>>
>>>> 2) ProcessHandleImpl_macosx.c:192:
>>>>      if (errno != EINVAL) ...  There was previously this test,  I'm
>>>> concerned
>>>> that if the pid is invalid,
>>>>      it will now throw a RuntimeException instead of returning -1.
>>>>      I recall a discussion from May that recommended testing for EINVAL.
>>>>      The sysctl in getCmdlineAndUserInfo also does not throw if errno !=
>>>> EINVAL, so the usage
>>>>      is not consistent (probably my coding) but needs investigation.
>>>>
>>>> Not sure about this one and couldn't find any previous discussion
>>>> about the topic.
>>>>
>>>> But, according to the sysctl man-page, EINVAL is only returned if:
>>>>   - The name array is less than two or greater than CTL_MAXNAME.
>>>>   - A non-null newp is given and its specified length in newlen is too
>>>> large or too small.
>>>>
>>>> The first case can not happen because we always statically allocate
>>>> arrays of the correct size.
>>>> The second case can not happen as well, because we always have 'newp ==
>>>> NULL'.
>>>>
>>>> So according to this information I don't see any reason why we should
>>>> check for EINVAL. I think the right solution is to check for 'oldlenp
>>>>
>>>> 0' which we already do. By the way, this is also the check applied
>>>>
>>>> by the psutils (see the implementation of 'get_kinfo_proc()' in [1]).
>>>>
>>>> So I wnated to also removed the last check for EINVAL in
>>>> getCmdlineAndUserInfo(). But for some reason, that seems to be really
>>>> necessary. Without it, we will get a RuntinmeException if we call
>>>> sysinfo for pid==0 for example. Further research showed that the
>>>> kernel seems to really return EINVAL for KERN_PROCARGS2 (see function
>>>> sysctl_procargsx() in [2]). But KERN_PROCARGS2 isn't specified as a
>>>> supported constant in the sysctl man-page, so the information there is
>>>> still valid :)
>>>>
>>>> On the other hand, I found that the psutils alo handles EINVAL only
>>>> for KERN_PROCARGS2 (see get_arg_list() in [1]).
>>>>
>>>> So to cut a long story short, I think the current implementation is
>>>> safe as it is now!
>>>>
>>>> [1]
>>>> http://psutil.googlecode.com/svn/trunk/psutil/arch/osx/process_info.c
>>>> [2]
>>>>
>>>> http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/bsd/kern/kern_sysctl.c
>>>>
>>>> 3) ProcessHandleImpl_solaris.c can do without the includes:
>>>> #include "jni_util.h"
>>>> #include "java_lang_ProcessHandleImpl.h"
>>>> #include "java_lang_ProcessHandleImpl_Info.h"
>>>>
>>>> #include 
>>>>
>>>> 4) Ditto ProcessHandleImpl_aix.c
>>>>
>>>> Thanks, fixed.
>>>>
>>>> 5) ProcessHandleImpl_unix.c: 618:  typo  "fuctions" -> "functions"
>>>>
>>>> Fixed.
>>>>
>>>> 6) ProcessHandleImpl_unix.c:463: Would it be worthwhile to put
>>>> sysconf(_SC_GETPW_R_SIZE_MAX) in a static?
>>>>
>>>> Good point! While doing this I realized that 'clock_ticks_per_second'
>>>> is only used on Linux. So I moved the declaration of
>>>> 'clock_ticks_per_second' from ProcessHandleImpl_unix.hpp to
>>>> ProcessHandleImpl_linux.cpp and its initialization to  os_initNative()
>>>> in the same file.
>>>>
>>>> I also declare a new static 'getpw_buf_size' in
>>>> ProcessHandleImpl_unix.cpp and initialize it in
>>>> Java_java_lang_ProcessHandleImpl_initNative() in the same file.
>>>>
>>>> 7) OnExitTest.java: exits without an error, just output in the log; it
>>>> would
>>>> escape attention.
>>>>      The code respects the timeout setting.
>>>>      Suggest removing the 'return' @133; the test will produce some
>>>> errors
>>>> and when debugging
>>>>      the note will be in the log.
>>>>
>>>> Done.
>>>>
>>>> 8) ProcessHandleImpl_unix.h:58 - update the comment to include 0 as a
>>>> valid
>>>> parent pid.
>>>>
>>>> Fixed.
>>>>
>>>> Looks pretty good,
>>>> Thanks, Roger
>>>>
>>>> Thanks:)
>>>>
>>>> I've also added two rudimentary tests for the new commandLine()
>>>> function to InfoTest.test2():
>>>>
>>>>   - if both, 'command()' and 'arguments()' are available, I check that
>>>> 'commandLine()' starts with 'command()' and contains all the arguments
>>>> from 'arguments()'.
>>>>
>>>>   - otherwise, if 'commandLine()' is available, I check that it at
>>>> least contains 'java'.  And as long as it is big enough it should also
>>>> contain the corresponding arguments.
>>>>
>>>> The two new tests have been verified to pass on Windows, Linux, MacOS
>>>> X, Solaris and AIX.
>>>>
>>>> The new version can be found here:
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v6/
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>> [1] http://openjdk.java.net/jeps/8068562  - JEP draft: javadoc tags to
>>>> distinguish API, implementation, specification, and notes
>>>>
>>>>
>>>> On 8/5/2015 3:56 PM, Volker Simonis wrote:
>>>>
>>>> Hi,
>>>>
>>>> so here's the webrev which implements the new Info.commandLine()
>>>> method (I chose 'commandLine() ' instead of 'cmdline()' or
>>>> 'commandline()' because the other getters are camel case as well):
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v4/
>>>>
>>>>  From the JavaDoc of the new method:
>>>>
>>>> * If {@code command()} and  {@code arguments()} return non-null
>>>> * optionals, this is simply a convenience method which concatenates
>>>> * the values of the two functions. Otherwise it will return a
>>>> * best-effort, platform dependent representation of the command line.
>>>>
>>>> This didn't change anything on MacOS X where there is no additional
>>>> effort to get the command line.
>>>>
>>>> On Solaris and AIX, Info.commandLine() will always return the contents
>>>> of psinfo.pr_psargs because there's no other method to get the exact
>>>> arguments (i.e. Info.arguments() always returns NULL. I could
>>>> therefore remove the extra handling of AIX/Solaris in the InfoTest
>>>> from my initial change.
>>>>
>>>> On Linux, things are a little more complicated:
>>>>
>>>> - the initial implementation for Linux used arg[0] as 'command' if
>>>> /proc/pid/exe wasn't readable. This was true for all the processes we
>>>> don't own (except if we are running as root). But this information may
>>>> be incomplete, because arg[0] may only contain the command without its
>>>> full path. One example is 'sendmail' for which Info.command() reported
>>>> "sendmail: accepting connections" but Info.arguments() was empty. This
>>>> is wrong, because 'sendmail' changes its argv[] array. I have
>>>> therefore disabled this behavior now that we have the 'commandLine()'
>>>> method.
>>>>
>>>> - /proc/pid/cmdline is limited to PAGE_SIZE (normally 4096) characters
>>>> on Linux. So strictly speaking, this isn't 'exact' information as well
>>>> (there are plenty of complains that especially for Java programs this
>>>> is not enough) and should go to 'commandLine()' instead to 'arguments'
>>>> if /proc/pid/cmdline is truncated. I do check for this now.
>>>>
>>>> - the information in /proc/pid/cmdline can also be changed to
>>>> something other than the original arguments if a program changes
>>>> argv[] (which is not forbidden) but there's probably not much we can
>>>> do to detect this. I've added a corresponding @implNote comment to
>>>> JavaDoc of Info.arguments().
>>>>
>>>> - the initial implementation did not check for incomplete reads of
>>>> /proc/pid/cmdline. This may be a problem on systems with PAGE_SIZE >
>>>> 4096 (on Linux/ppc64 a page size of 65536 is not unusual). I'm now
>>>> always reading the complete contents of /proc/pid/cmdline.
>>>>
>>>> - as far as I understand the current implementation, 'arguments()'
>>>> returns the arguments array WITHOUT 'arg[0]' (which is the program
>>>> name) but may
>>>> be we should specify that more clearly in the JavaDoc of 'arguments()'.
>>>>
>>>> That's it. Hope you like it :)
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>> On Fri, Jul 31, 2015 at 11:02 PM, Stuart Marks 
>>>> wrote:
>>>>
>>>> Hi Roger, Volker,
>>>>
>>>> Glad to see you guys are receptive to this and that it can move forward.
>>>> Let
>>>> me know if you'd like me to help out, for example with reviews or
>>>> something.
>>>>
>>>> s'marks
>>>>
>>>>
>>>> On 7/31/15 9:55 AM, Roger Riggs wrote:
>>>>
>>>> Hi Volker,
>>>>
>>>> I agree that adding an Info.commandline() method would be a good way
>>>> to make the command line available and be able to describe that it is
>>>> OS dependent and may be truncated.
>>>> And having it assemble the command and arguments when they are available
>>>> makes
>>>> sense.
>>>> As an API addition it will need a clear spec and I can run it through
>>>> CCC
>>>> so it
>>>> gets
>>>> another review and compatibility tests.
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>>
>>>>
>>>> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>>>>
>>>> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks 
>>>> wrote:
>>>>
>>>> On 7/29/15 11:36 AM, Volker Simonis wrote:
>>>>
>>>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>>>> truncated or incomplete
>>>> values for the executable or arguments.
>>>> Can anyone be a tie-breaker  (with a good rational and suggestion for
>>>> how
>>>> an
>>>> application can use the data).
>>>>
>>>> As I wrote, I agree to hear other opinions here.
>>>>
>>>> All I want to say that this truncated data is actually what 'ps' is
>>>> reporting on Solaris since decades and people seem to be happy with
>>>> it. As use case I can imagine logging or monitoring (something like
>>>> 'top' in Java) where this data will be just good enough.
>>>>
>>>> We could specially mark possibly incomplete data by extending the Info
>>>> object with functions like commandIsExact() or argumentsIsPrecise().
>>>> But notice that we can not statically preset these values per
>>>> platform. For example on Solaris, the 'command()' would return a
>>>> precise value for processes with the same uid like the VM but only
>>>> inaccurate values for all other processes. The "arguments()" would be
>>>> always inaccurate on Solaris/AIX.
>>>>
>>>> It seems like there are cases where either exact or only approximate
>>>> information is available. And as you observed, you might get one or the
>>>> other on the same platform, depending on the UID. It also might depend
>>>> on
>>>> process state; I believe that some information becomes inaccessible when
>>>> the
>>>> process enters the zombie state.
>>>>
>>>> I don't think we should simply ignore one case or the other, but I also
>>>> don't think we should try to cram the different information into the
>>>> same
>>>> API.
>>>>
>>>> The current ProcessHandle.Info api has
>>>>
>>>>       Optional command()
>>>>       Optional arguments()
>>>>
>>>> It sounds to me like Roger wants these to contain only exact
>>>> information.
>>>> That seems reasonable, and this probably needs to be specified more
>>>> clearly
>>>> to contrast with what's below.
>>>>
>>>> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
>>>> single string which appears to be the concatenation of the arguments
>>>> (maybe
>>>> including the command name). It's also truncated to fit PRARGSZ. It
>>>> doesn't
>>>> make sense to me to try to return this as a String[], as the zeroth
>>>> element
>>>> of that array, and certainly not parsed out into "words". So maybe
>>>> instead
>>>> we should have a different API that returns an imprecise command line as
>>>> a
>>>> single string:
>>>>
>>>>       Optional cmdline()
>>>>
>>>> (Naming bikeshed TBS). The semantics would be that this is the process'
>>>> command and arguments concatenated into a single string (thus
>>>> potentially
>>>> losing argument boundaries) and also possibly truncated based on
>>>> platform
>>>> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out
>>>> in a
>>>> ps, top, or Activity Monitor style application, for informational
>>>> purposes.
>>>>
>>>> If this were implemented, then on Solaris, command() and arguments()
>>>> would
>>>> always return empty optionals.
>>>>
>>>> I'm not sure what this should be if the exact information is available.
>>>> It
>>>> would be inconvenient if something that just wanted to print out an
>>>> approximate command line had to check several different APIs to get the
>>>> information. Maybe cmdline() could assemble the information from exact
>>>> data
>>>> if it's is available, by concatenating the Strings from command() and
>>>> arguments(), as a convenience to the caller. But I could go either way
>>>> on
>>>> this.
>>>>
>>>> Not sure this counts as a tie-breaker, but it might be a reasonable way
>>>> forward.
>>>>
>>>> s'marks
>>>>
>>>> Hi Stuart,
>>>>
>>>> thanks a lot for your comments - I like your proposal. For me this
>>>> sounds like a good compromise.
>>>>
>>>> @Roger: should I go and add a new field commandLine and the
>>>> corresponding getter to the Info class? As Stuart proposed, the getter
>>>> could check if 'command' and 'arguments' are available and assemble
>>>> the command line from them. Otherwise it could use the content of the
>>>> commandLine field if that is available.
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>>
>


From henry.jen at oracle.com  Wed Aug 12 15:13:45 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 12 Aug 2015 08:13:45 -0700
Subject: RFR v4 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <55CB5E51.1040608@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
Message-ID: <5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>


> On Aug 12, 2015, at 7:55 AM, Kumar Srinivasan  wrote:
> 
> Henry,
> 
> Generally looks good here are some comments, on my initial
> pass, I am not fully done with args.c I will look at this some
> more later today or tomorrow.
> 
> 4.)
> expectingNoDash is expectingMain right ? if so I would rename it so.
> 

Not really, it is expecting a argument without dash, such as -cp or -classpath.

> 
> 
> TestHelper.java:
> 
> Why add findInOutput method ? this seems to be identical
> to "matches" at line 606, which does exactly that.
> 

To return a string, this is used when trying to match a pattern and get information from that line, I used to get the starting index for an argument in verifyOptions.

Guess I can remove that now as each use of verifyOptions all starts from 1.

> ArgFileSyntax.java
> Nice, but I think the creation and storage of test case can be simplified,
> basically loadCases(), also please avoid  Xbootclasspath. The trouble
> with these tests which operate loops, are very painful to debug
> and isolate a failing case,  on the night before GA.
> 

I wrote that because I start with testng as a DataProvider, we can change that.

> Can we do something like this.....
> 
> Map> tests = new ArrayList<>();
> tests.put("testing quotes", Array.asList({{...}, {....}});
> tests.add("no recurse expansion", Array.asList({{...}, {....}});
> 
> The execute each test, with a description of what the test is doing.
> This way if a test fails its easy to zero in on the failing test.
> 

verifyOutput will print out what line is not matching, so it?s pretty easy to identify which case failed.

Cheers,
Henry



From alexander.v.stepanov at oracle.com  Wed Aug 12 15:46:12 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Wed, 12 Aug 2015 18:46:12 +0300
Subject: RFR [9] 8133459: replace  tags (obsolete in html5) in java.nio
	docs
Message-ID: <55CB6A44.7010300@oracle.com>

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133459/webrev.00/index.html
for
https://bugs.openjdk.java.net/browse/JDK-8133459

Just a next portion of deprecated '' tags replaced (didn't touch all 
these multiple ' 's to avoid undesirable formatting changes).

specdiff did not detect any changes in java.nio.*

Regards,
Alexander



From lance.andersen at oracle.com  Wed Aug 12 16:41:51 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 12 Aug 2015 12:41:51 -0400
Subject: RFR [9] 8133459: replace  tags (obsolete in html5) in
	java.nio docs
In-Reply-To: <55CB6A44.7010300@oracle.com>
References: <55CB6A44.7010300@oracle.com>
Message-ID: 

Hi Alexander,

Nothing seems amiss in the changes and you indicated the specdiff shows no issues so you should be good to go

Best
Lance
On Aug 12, 2015, at 11:46 AM, Alexander Stepanov  wrote:

> Hello,
> 
> Could you please review the following fix:
> http://cr.openjdk.java.net/~avstepan/8133459/webrev.00/index.html
> for
> https://bugs.openjdk.java.net/browse/JDK-8133459
> 
> Just a next portion of deprecated '' tags replaced (didn't touch all these multiple ' 's to avoid undesirable formatting changes).
> 
> specdiff did not detect any changes in java.nio.*
> 
> Regards,
> Alexander
> 



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 alexander.v.stepanov at oracle.com  Wed Aug 12 16:46:35 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Wed, 12 Aug 2015 19:46:35 +0300
Subject: RFR [9] 8133459: replace  tags (obsolete in html5) in java.nio
	docs
In-Reply-To: 
References: <55CB6A44.7010300@oracle.com>
	
Message-ID: <55CB786B.4000104@oracle.com>

Hello Lance,

Thanks!

Regards,
Alexander

On 8/12/2015 7:41 PM, Lance Andersen wrote:
> Hi Alexander,
>
> Nothing seems amiss in the changes and you indicated the specdiff 
> shows no issues so you should be good to go
>
> Best
> Lance
> On Aug 12, 2015, at 11:46 AM, Alexander Stepanov 
>  > wrote:
>
>> Hello,
>>
>> Could you please review the following fix:
>> http://cr.openjdk.java.net/~avstepan/8133459/webrev.00/index.html 
>> 
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8133459
>>
>> Just a next portion of deprecated '' tags replaced (didn't touch 
>> all these multiple ' 's to avoid undesirable formatting changes).
>>
>> specdiff did not detect any changes in java.nio.*
>>
>> Regards,
>> Alexander
>>
>
> 
> 
> 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 stuart.marks at oracle.com  Wed Aug 12 16:47:16 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 12 Aug 2015 09:47:16 -0700
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: 
References: <55B6938E.2010806@Oracle.com> <55B6940D.90701@Oracle.com>
	
	<55BAC679.7010108@oracle.com>
	
	<55BBA878.3090509@Oracle.com> <55BBE261.4060902@oracle.com>
	
	<55C4FEEC.1010804@Oracle.com>
	
	<55CA1003.8030201@Oracle.com>
	
	<55CA7239.2010905@oracle.com> <55CA74F6.3070502@oracle.com>
	
Message-ID: <55CB7894.5050609@oracle.com>



On 8/12/15 8:10 AM, Volker Simonis wrote:
> On Wed, Aug 12, 2015 at 12:19 AM, Stuart Marks  wrote:
>> The proposed spec for commandLine() says,
>>
>> * If {@link #command command()} and  {@link #arguments arguments()} return
>> non-null
>> * optionals,
>>
>> The preferred term is "non-empty" instead of non-null.
>
> Good point. I've updated the documentation accordingly and created:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v7/

Thanks for making the change. The update looks good.

s'marks

>
> Regards,
> Volker
>
>> Thanks,
>>
>> s'marks
>>
>>
>>
>> On 8/11/15 3:07 PM, Stuart Marks wrote:
>>>
>>> Hi Volker,
>>>
>>> I looked at the proposed specification of commandLine() after the most
>>> recent
>>> round of reviews (which is 8131168.v6 I believe) and it looks fine to me.
>>> It
>>> expresses the intent pretty well. Oh, and the name "commandLine" is fine
>>> and it
>>> fits well with the names of the other methods.
>>>
>>> Thanks,
>>>
>>> s'marks
>>>
>>> On 8/11/15 8:52 AM, Volker Simonis wrote:
>>>>
>>>> On Tue, Aug 11, 2015 at 5:08 PM, Roger Riggs 
>>>> wrote:
>>>>>
>>>>> Hi Volker,
>>>>>
>>>>> Thanks for checking into the details of the OS X sysctl.  I'm fine with
>>>>> the
>>>>> current implementation.
>>>>>
>>>>> The rest of the updates and the additional tests look fine also.
>>>>>
>>>>
>>>> Phew! I was already afraid I would have to switch to double-digit
>>>> versions for my webrevs :)
>>>>
>>>>> But I need to check on the CCC status.
>>>>>
>>>>
>>>> OK, please let me know once it is ready/approved.
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 8/10/15 10:13 AM, Volker Simonis wrote:
>>>>>
>>>>> On Fri, Aug 7, 2015 at 8:54 PM, Roger Riggs 
>>>>> wrote:
>>>>>
>>>>> Hi Volker,
>>>>>
>>>>> 1) ProcessHandle.java:243
>>>>>
>>>>> For the definition of the new commandLine method I would:
>>>>>
>>>>>     - Use @link instead of @code for references to commands() and
>>>>> arguments()
>>>>> for easy navigation
>>>>>
>>>>>     - @implNote[1] should I think be changed to @apiNote:
>>>>>     the text describes not the JDK implementation but is information
>>>>> about the
>>>>>     information returned and is use to the application developer, not the
>>>>> JDK
>>>>> implementation.
>>>>>
>>>>>     -  The specific references to Linux implementation command line
>>>>> length
>>>>> parameters seems out of place
>>>>>         and should be omitted.
>>>>>
>>>>>           /**
>>>>>            * Returns the command line of the process.
>>>>>            * 

>>>>>            * If {@link #command command()} and  {@link #arguments
>>>>> arguments()}
>>>>> return non-null
>>>>>            * optionals, this is simply a convenience method which
>>>>> concatenates
>>>>>            * the values of the two functions separated by spaces.
>>>>> Otherwise it
>>>>> will return a
>>>>>            * best-effort, platform dependent representation of the
>>>>> command
>>>>> line.
>>>>>            *
>>>>>            * @apiNote Note that the returned executable pathname and the
>>>>>            *           arguments may be truncated on some platforms due
>>>>> to
>>>>> system
>>>>>            *           limitations.
>>>>>            *           

>>>>>            *           The executable pathname may contain only the
>>>>>            *           name of the executable without the full path
>>>>> information.
>>>>>            *           It is undecideable whether white space separates
>>>>> different
>>>>>            *           arguments or is part of a single argument.
>>>>>            *
>>>>>            * @return an {@code Optional} of the command line
>>>>>            *         of the process
>>>>>            */
>>>>>           public Optional commandLine();
>>>>>
>>>>>
>>>>> ProcessHandle.java:252: in arguments() method - @apiNote is a better fit
>>>>> for
>>>>> the note
>>>>>
>>>>> ProcessHandleImpl_macosx.c:276:   - indentation +4
>>>>>
>>>>> Thanks for the correction. I've taken your wording you suggested.
>>>>>
>>>>> 2) ProcessHandleImpl_macosx.c:192:
>>>>>       if (errno != EINVAL) ...  There was previously this test,  I'm
>>>>> concerned
>>>>> that if the pid is invalid,
>>>>>       it will now throw a RuntimeException instead of returning -1.
>>>>>       I recall a discussion from May that recommended testing for EINVAL.
>>>>>       The sysctl in getCmdlineAndUserInfo also does not throw if errno !=
>>>>> EINVAL, so the usage
>>>>>       is not consistent (probably my coding) but needs investigation.
>>>>>
>>>>> Not sure about this one and couldn't find any previous discussion
>>>>> about the topic.
>>>>>
>>>>> But, according to the sysctl man-page, EINVAL is only returned if:
>>>>>    - The name array is less than two or greater than CTL_MAXNAME.
>>>>>    - A non-null newp is given and its specified length in newlen is too
>>>>> large or too small.
>>>>>
>>>>> The first case can not happen because we always statically allocate
>>>>> arrays of the correct size.
>>>>> The second case can not happen as well, because we always have 'newp ==
>>>>> NULL'.
>>>>>
>>>>> So according to this information I don't see any reason why we should
>>>>> check for EINVAL. I think the right solution is to check for 'oldlenp
>>>>>
>>>>> 0' which we already do. By the way, this is also the check applied
>>>>>
>>>>> by the psutils (see the implementation of 'get_kinfo_proc()' in [1]).
>>>>>
>>>>> So I wnated to also removed the last check for EINVAL in
>>>>> getCmdlineAndUserInfo(). But for some reason, that seems to be really
>>>>> necessary. Without it, we will get a RuntinmeException if we call
>>>>> sysinfo for pid==0 for example. Further research showed that the
>>>>> kernel seems to really return EINVAL for KERN_PROCARGS2 (see function
>>>>> sysctl_procargsx() in [2]). But KERN_PROCARGS2 isn't specified as a
>>>>> supported constant in the sysctl man-page, so the information there is
>>>>> still valid :)
>>>>>
>>>>> On the other hand, I found that the psutils alo handles EINVAL only
>>>>> for KERN_PROCARGS2 (see get_arg_list() in [1]).
>>>>>
>>>>> So to cut a long story short, I think the current implementation is
>>>>> safe as it is now!
>>>>>
>>>>> [1]
>>>>> http://psutil.googlecode.com/svn/trunk/psutil/arch/osx/process_info.c
>>>>> [2]
>>>>>
>>>>> http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/bsd/kern/kern_sysctl.c
>>>>>
>>>>> 3) ProcessHandleImpl_solaris.c can do without the includes:
>>>>> #include "jni_util.h"
>>>>> #include "java_lang_ProcessHandleImpl.h"
>>>>> #include "java_lang_ProcessHandleImpl_Info.h"
>>>>>
>>>>> #include 
>>>>>
>>>>> 4) Ditto ProcessHandleImpl_aix.c
>>>>>
>>>>> Thanks, fixed.
>>>>>
>>>>> 5) ProcessHandleImpl_unix.c: 618:  typo  "fuctions" -> "functions"
>>>>>
>>>>> Fixed.
>>>>>
>>>>> 6) ProcessHandleImpl_unix.c:463: Would it be worthwhile to put
>>>>> sysconf(_SC_GETPW_R_SIZE_MAX) in a static?
>>>>>
>>>>> Good point! While doing this I realized that 'clock_ticks_per_second'
>>>>> is only used on Linux. So I moved the declaration of
>>>>> 'clock_ticks_per_second' from ProcessHandleImpl_unix.hpp to
>>>>> ProcessHandleImpl_linux.cpp and its initialization to  os_initNative()
>>>>> in the same file.
>>>>>
>>>>> I also declare a new static 'getpw_buf_size' in
>>>>> ProcessHandleImpl_unix.cpp and initialize it in
>>>>> Java_java_lang_ProcessHandleImpl_initNative() in the same file.
>>>>>
>>>>> 7) OnExitTest.java: exits without an error, just output in the log; it
>>>>> would
>>>>> escape attention.
>>>>>       The code respects the timeout setting.
>>>>>       Suggest removing the 'return' @133; the test will produce some
>>>>> errors
>>>>> and when debugging
>>>>>       the note will be in the log.
>>>>>
>>>>> Done.
>>>>>
>>>>> 8) ProcessHandleImpl_unix.h:58 - update the comment to include 0 as a
>>>>> valid
>>>>> parent pid.
>>>>>
>>>>> Fixed.
>>>>>
>>>>> Looks pretty good,
>>>>> Thanks, Roger
>>>>>
>>>>> Thanks:)
>>>>>
>>>>> I've also added two rudimentary tests for the new commandLine()
>>>>> function to InfoTest.test2():
>>>>>
>>>>>    - if both, 'command()' and 'arguments()' are available, I check that
>>>>> 'commandLine()' starts with 'command()' and contains all the arguments
>>>>> from 'arguments()'.
>>>>>
>>>>>    - otherwise, if 'commandLine()' is available, I check that it at
>>>>> least contains 'java'.  And as long as it is big enough it should also
>>>>> contain the corresponding arguments.
>>>>>
>>>>> The two new tests have been verified to pass on Windows, Linux, MacOS
>>>>> X, Solaris and AIX.
>>>>>
>>>>> The new version can be found here:
>>>>>
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v6/
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>>
>>>>> [1] http://openjdk.java.net/jeps/8068562  - JEP draft: javadoc tags to
>>>>> distinguish API, implementation, specification, and notes
>>>>>
>>>>>
>>>>> On 8/5/2015 3:56 PM, Volker Simonis wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> so here's the webrev which implements the new Info.commandLine()
>>>>> method (I chose 'commandLine() ' instead of 'cmdline()' or
>>>>> 'commandline()' because the other getters are camel case as well):
>>>>>
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v4/
>>>>>
>>>>>   From the JavaDoc of the new method:
>>>>>
>>>>> * If {@code command()} and  {@code arguments()} return non-null
>>>>> * optionals, this is simply a convenience method which concatenates
>>>>> * the values of the two functions. Otherwise it will return a
>>>>> * best-effort, platform dependent representation of the command line.
>>>>>
>>>>> This didn't change anything on MacOS X where there is no additional
>>>>> effort to get the command line.
>>>>>
>>>>> On Solaris and AIX, Info.commandLine() will always return the contents
>>>>> of psinfo.pr_psargs because there's no other method to get the exact
>>>>> arguments (i.e. Info.arguments() always returns NULL. I could
>>>>> therefore remove the extra handling of AIX/Solaris in the InfoTest
>>>>> from my initial change.
>>>>>
>>>>> On Linux, things are a little more complicated:
>>>>>
>>>>> - the initial implementation for Linux used arg[0] as 'command' if
>>>>> /proc/pid/exe wasn't readable. This was true for all the processes we
>>>>> don't own (except if we are running as root). But this information may
>>>>> be incomplete, because arg[0] may only contain the command without its
>>>>> full path. One example is 'sendmail' for which Info.command() reported
>>>>> "sendmail: accepting connections" but Info.arguments() was empty. This
>>>>> is wrong, because 'sendmail' changes its argv[] array. I have
>>>>> therefore disabled this behavior now that we have the 'commandLine()'
>>>>> method.
>>>>>
>>>>> - /proc/pid/cmdline is limited to PAGE_SIZE (normally 4096) characters
>>>>> on Linux. So strictly speaking, this isn't 'exact' information as well
>>>>> (there are plenty of complains that especially for Java programs this
>>>>> is not enough) and should go to 'commandLine()' instead to 'arguments'
>>>>> if /proc/pid/cmdline is truncated. I do check for this now.
>>>>>
>>>>> - the information in /proc/pid/cmdline can also be changed to
>>>>> something other than the original arguments if a program changes
>>>>> argv[] (which is not forbidden) but there's probably not much we can
>>>>> do to detect this. I've added a corresponding @implNote comment to
>>>>> JavaDoc of Info.arguments().
>>>>>
>>>>> - the initial implementation did not check for incomplete reads of
>>>>> /proc/pid/cmdline. This may be a problem on systems with PAGE_SIZE >
>>>>> 4096 (on Linux/ppc64 a page size of 65536 is not unusual). I'm now
>>>>> always reading the complete contents of /proc/pid/cmdline.
>>>>>
>>>>> - as far as I understand the current implementation, 'arguments()'
>>>>> returns the arguments array WITHOUT 'arg[0]' (which is the program
>>>>> name) but may
>>>>> be we should specify that more clearly in the JavaDoc of 'arguments()'.
>>>>>
>>>>> That's it. Hope you like it :)
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>> On Fri, Jul 31, 2015 at 11:02 PM, Stuart Marks 
>>>>> wrote:
>>>>>
>>>>> Hi Roger, Volker,
>>>>>
>>>>> Glad to see you guys are receptive to this and that it can move forward.
>>>>> Let
>>>>> me know if you'd like me to help out, for example with reviews or
>>>>> something.
>>>>>
>>>>> s'marks
>>>>>
>>>>>
>>>>> On 7/31/15 9:55 AM, Roger Riggs wrote:
>>>>>
>>>>> Hi Volker,
>>>>>
>>>>> I agree that adding an Info.commandline() method would be a good way
>>>>> to make the command line available and be able to describe that it is
>>>>> OS dependent and may be truncated.
>>>>> And having it assemble the command and arguments when they are available
>>>>> makes
>>>>> sense.
>>>>> As an API addition it will need a clear spec and I can run it through
>>>>> CCC
>>>>> so it
>>>>> gets
>>>>> another review and compatibility tests.
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>>>>>
>>>>> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks 
>>>>> wrote:
>>>>>
>>>>> On 7/29/15 11:36 AM, Volker Simonis wrote:
>>>>>
>>>>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>>>>> truncated or incomplete
>>>>> values for the executable or arguments.
>>>>> Can anyone be a tie-breaker  (with a good rational and suggestion for
>>>>> how
>>>>> an
>>>>> application can use the data).
>>>>>
>>>>> As I wrote, I agree to hear other opinions here.
>>>>>
>>>>> All I want to say that this truncated data is actually what 'ps' is
>>>>> reporting on Solaris since decades and people seem to be happy with
>>>>> it. As use case I can imagine logging or monitoring (something like
>>>>> 'top' in Java) where this data will be just good enough.
>>>>>
>>>>> We could specially mark possibly incomplete data by extending the Info
>>>>> object with functions like commandIsExact() or argumentsIsPrecise().
>>>>> But notice that we can not statically preset these values per
>>>>> platform. For example on Solaris, the 'command()' would return a
>>>>> precise value for processes with the same uid like the VM but only
>>>>> inaccurate values for all other processes. The "arguments()" would be
>>>>> always inaccurate on Solaris/AIX.
>>>>>
>>>>> It seems like there are cases where either exact or only approximate
>>>>> information is available. And as you observed, you might get one or the
>>>>> other on the same platform, depending on the UID. It also might depend
>>>>> on
>>>>> process state; I believe that some information becomes inaccessible when
>>>>> the
>>>>> process enters the zombie state.
>>>>>
>>>>> I don't think we should simply ignore one case or the other, but I also
>>>>> don't think we should try to cram the different information into the
>>>>> same
>>>>> API.
>>>>>
>>>>> The current ProcessHandle.Info api has
>>>>>
>>>>>        Optional command()
>>>>>        Optional arguments()
>>>>>
>>>>> It sounds to me like Roger wants these to contain only exact
>>>>> information.
>>>>> That seems reasonable, and this probably needs to be specified more
>>>>> clearly
>>>>> to contrast with what's below.
>>>>>
>>>>> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
>>>>> single string which appears to be the concatenation of the arguments
>>>>> (maybe
>>>>> including the command name). It's also truncated to fit PRARGSZ. It
>>>>> doesn't
>>>>> make sense to me to try to return this as a String[], as the zeroth
>>>>> element
>>>>> of that array, and certainly not parsed out into "words". So maybe
>>>>> instead
>>>>> we should have a different API that returns an imprecise command line as
>>>>> a
>>>>> single string:
>>>>>
>>>>>        Optional cmdline()
>>>>>
>>>>> (Naming bikeshed TBS). The semantics would be that this is the process'
>>>>> command and arguments concatenated into a single string (thus
>>>>> potentially
>>>>> losing argument boundaries) and also possibly truncated based on
>>>>> platform
>>>>> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out
>>>>> in a
>>>>> ps, top, or Activity Monitor style application, for informational
>>>>> purposes.
>>>>>
>>>>> If this were implemented, then on Solaris, command() and arguments()
>>>>> would
>>>>> always return empty optionals.
>>>>>
>>>>> I'm not sure what this should be if the exact information is available.
>>>>> It
>>>>> would be inconvenient if something that just wanted to print out an
>>>>> approximate command line had to check several different APIs to get the
>>>>> information. Maybe cmdline() could assemble the information from exact
>>>>> data
>>>>> if it's is available, by concatenating the Strings from command() and
>>>>> arguments(), as a convenience to the caller. But I could go either way
>>>>> on
>>>>> this.
>>>>>
>>>>> Not sure this counts as a tie-breaker, but it might be a reasonable way
>>>>> forward.
>>>>>
>>>>> s'marks
>>>>>
>>>>> Hi Stuart,
>>>>>
>>>>> thanks a lot for your comments - I like your proposal. For me this
>>>>> sounds like a good compromise.
>>>>>
>>>>> @Roger: should I go and add a new field commandLine and the
>>>>> corresponding getter to the Info class? As Stuart proposed, the getter
>>>>> could check if 'command' and 'arguments' are available and assemble
>>>>> the command line from them. Otherwise it could use the content of the
>>>>> commandLine field if that is available.
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>>
>>>>>
>>


From kumar.x.srinivasan at oracle.com  Wed Aug 12 16:47:10 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 12 Aug 2015 09:47:10 -0700
Subject: JDK 9 RFR of JDK-8079769: tools/pack200/PackTestZip64.java may
	timeout at preparing the large test file
In-Reply-To: <55C369D1.7040906@oracle.com>
References: <55C369D1.7040906@oracle.com>
Message-ID: <55CB788E.7030004@oracle.com>

Looks good.

Kumar

On 8/6/2015 7:06 AM, Amy Lu wrote:
> Please review the fix for test issue: tools/pack200/PackTestZip64.java 
> may timeout at preparing the large test file
>
> This test tries to create a big jar file for testing by adding a large 
> number (Short.MAX_VALUE * 2 + 2) of small files to the golden jar 
> (golden.jar). This prepare work is i/o sensitive and may take long 
> thus may timeout (depending on the run timeout settings), especially 
> when many tests run in concurrency.
>
> To make the test more stable, without losing test coverage, this fix 
> makes:
> * PackTestZip64.java tests on the golden.jar only
> * PackTestZip64Manual.java still tests on the big jar
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8079769
> webrev: http://cr.openjdk.java.net/~amlu/8079769/webrev.00/
>
> Thanks,
> Amy



From aleksej.efimov at oracle.com  Thu Aug 13 13:54:11 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 13 Aug 2015 16:54:11 +0300
Subject: [9] RFR: 8133321: (tz) Support tzdata2015f
Message-ID: <55CCA183.7010203@oracle.com>

Hello,

Please review latest tzdata (2015f)  integration into JDK9:
http://cr.openjdk.java.net/~aefimov/tzdata/2015f/9/00

Testing shows no TZ related failures on all platforms.

Thanks,
Aleksej

JBS: https://bugs.openjdk.java.net/browse/JDK-8133321



From alexander.v.stepanov at oracle.com  Thu Aug 13 14:42:31 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Thu, 13 Aug 2015 17:42:31 +0300
Subject: RFR [9] 8133480: replace some  tags (obsolete in html5) in
	core-libs docs
Message-ID: <55CCACD7.6070801@oracle.com>

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133480/webrev.00
for
https://bugs.openjdk.java.net/browse/JDK-8133480

Just another portion of deprecated  tags replaced with {@code }.
A single misprint was fixed; no other changes indicated by specdiff.

Thanks,
Alexander


From kumar.x.srinivasan at oracle.com  Thu Aug 13 16:38:09 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 13 Aug 2015 09:38:09 -0700
Subject: RFR v4 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
Message-ID: <55CCC7F1.8070902@oracle.com>

Henry,



I am still not complete, but here are some more comments and specifics.

args.c

1.
-static int firstAppArgIndex = -1;

+#define NOT_FOUND  -1;
+static int firstAppArgIndex = NOT_FOUND;

2.
     // Any @argument comes in here is an argument as is.
     // Expansion should had done before checkArg called.

I think you are trying to say
    // All arguments arrive here must be a launcher argument,
    // ie. by now, all argfile expansions must have been performed.


3. void JLI_InitArgProcessing(jboolean isJava, jboolean disableArgFile) {
     // No expansion for relaunch


The launcher might re-exec itself, this might happen under certain
circumstances on *nix, is the above logic to prevent subsequent
expansion on relaunch ? However when a re-exec occurs, the
expanded args will be sent to the second invocation of the launcher.

So what does "relaunch" mean ? in your comment ?

ArgFileSyntax.java:

usage of ArrayList vs. Arrays will simplify things.

     // arg file content,  expected options
     static String[] testCaseArrays[][] = {
         { // empty file
             {}, {}
         },

...
     public List>> loadCases() {
         List>> rv = new ArrayList<>();
         for (String[][] testCaseArray : testCaseArrays) {
             List> testCase = new ArrayList<>(2);
             testCase.add(Arrays.asList(testCaseArray[0]));
             testCase.add(Arrays.asList(testCaseArray[1]));
             rv.add(testCase);
         }
         // long lines
.....
     @Test
     public void testSyntax() throws IOException {
         List>> allCases = loadCases();
         for (List> testCase : allCases) {
             verifyParsing(testCase.get(0), testCase.get(1));
         }
     }


ArgsFileTest.java:

use case coverage looks great, still haven't finished with this
yet.

Kumar

>> On Aug 12, 2015, at 7:55 AM, Kumar Srinivasan  wrote:
>>
>> Henry,
>>
>> Generally looks good here are some comments, on my initial
>> pass, I am not fully done with args.c I will look at this some
>> more later today or tomorrow.
>>
>> 4.)
>> expectingNoDash is expectingMain right ? if so I would rename it so.
>>
> Not really, it is expecting a argument without dash, such as -cp or -classpath.
>
>>
>> TestHelper.java:
>>
>> Why add findInOutput method ? this seems to be identical
>> to "matches" at line 606, which does exactly that.
>>
> To return a string, this is used when trying to match a pattern and get information from that line, I used to get the starting index for an argument in verifyOptions.
>
> Guess I can remove that now as each use of verifyOptions all starts from 1.
>
>> ArgFileSyntax.java
>> Nice, but I think the creation and storage of test case can be simplified,
>> basically loadCases(), also please avoid  Xbootclasspath. The trouble
>> with these tests which operate loops, are very painful to debug
>> and isolate a failing case,  on the night before GA.
>>
> I wrote that because I start with testng as a DataProvider, we can change that.
>
>> Can we do something like this.....
>>
>> Map> tests = new ArrayList<>();
>> tests.put("testing quotes", Array.asList({{...}, {....}});
>> tests.add("no recurse expansion", Array.asList({{...}, {....}});
>>
>> The execute each test, with a description of what the test is doing.
>> This way if a test fails its easy to zero in on the failing test.
>>
> verifyOutput will print out what line is not matching, so it?s pretty easy to identify which case failed.
>
> Cheers,
> Henry
>



From henry.jen at oracle.com  Thu Aug 13 17:36:16 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 13 Aug 2015 10:36:16 -0700
Subject: RFR v4 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <55CCC7F1.8070902@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
Message-ID: <71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>


> On Aug 13, 2015, at 9:38 AM, Kumar Srinivasan  wrote:
> 
> 3. void JLI_InitArgProcessing(jboolean isJava, jboolean disableArgFile) {
>    // No expansion for relaunch
> 
> 
> The launcher might re-exec itself, this might happen under certain
> circumstances on *nix, is the above logic to prevent subsequent
> expansion on relaunch ? However when a re-exec occurs, the
> expanded args will be sent to the second invocation of the launcher.
> 
> So what does "relaunch" mean ? in your comment ?

Right, relaunch means that re-exec. As the first time, the arguments has expanded, we don?t want to do that again for succeeding runs.

For example an argument @@arg, it will become @arg at the second execution because of escape. That should not be expanded again.

Cheers,
Henry



From lance.andersen at oracle.com  Thu Aug 13 17:42:52 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 13 Aug 2015 13:42:52 -0400
Subject: RFR [9] 8133480: replace some  tags (obsolete in html5) in
	core-libs docs
In-Reply-To: <55CCACD7.6070801@oracle.com>
References: <55CCACD7.6070801@oracle.com>
Message-ID: <973DBB67-4EBC-4F78-AA65-6EBEDBC34401@oracle.com>

looks OK.  Nothing obvious stands out.

Best
Lance
On Aug 13, 2015, at 10:42 AM, Alexander Stepanov  wrote:

> Hello,
> 
> Could you please review the following fix:
> http://cr.openjdk.java.net/~avstepan/8133480/webrev.00
> for
> https://bugs.openjdk.java.net/browse/JDK-8133480
> 
> Just another portion of deprecated  tags replaced with {@code }.
> A single misprint was fixed; no other changes indicated by specdiff.
> 
> Thanks,
> Alexander



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 joe.darcy at oracle.com  Thu Aug 13 21:18:49 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 13 Aug 2015 14:18:49 -0700
Subject: JDK 9 RFR of JDK-8133588: Place TimeoutLockLoops.java on the problem
	lis
Message-ID: <55CD09B9.6030108@oracle.com>

Hello,

Until a fix for JDK-8029453 is in place, the test TimeoutLockLoops.java 
should be placed on the problem list for Linux since it fails 
intermittently, but fairly frequently, on that OS:

--- a/test/ProblemList.txt    Thu Aug 13 09:36:14 2015 -0700
+++ b/test/ProblemList.txt    Thu Aug 13 14:14:39 2015 -0700
@@ -353,6 +353,10 @@
  # 8062512
  java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.java generic-all

+# 8029453
+java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java linux-all
+
+
  ############################################################################

  # jdk_instrument

Thanks,

-Joe


From david.holmes at oracle.com  Thu Aug 13 21:30:51 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 14 Aug 2015 07:30:51 +1000
Subject: JDK 9 RFR of JDK-8133588: Place TimeoutLockLoops.java on the
	problem lis
In-Reply-To: <55CD09B9.6030108@oracle.com>
References: <55CD09B9.6030108@oracle.com>
Message-ID: <55CD0C8B.2080200@oracle.com>

Joe,

This is making it hard to clean up everything at once. I'm already 
delayed from pushing the fix because the "@key intermittent" change is 
not in hs-rt yet. If this change also goes in then I again have to wait 
for it to arrive before I can reverse it. It will take a month for 
everything to get back to where it should be. :(

This also seems to defeat the purpose of adding the "intermittent" tag.

David

On 14/08/2015 7:18 AM, joe darcy wrote:
> Hello,
>
> Until a fix for JDK-8029453 is in place, the test TimeoutLockLoops.java
> should be placed on the problem list for Linux since it fails
> intermittently, but fairly frequently, on that OS:
>
> --- a/test/ProblemList.txt    Thu Aug 13 09:36:14 2015 -0700
> +++ b/test/ProblemList.txt    Thu Aug 13 14:14:39 2015 -0700
> @@ -353,6 +353,10 @@
>   # 8062512
>   java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.java generic-all
>
> +# 8029453
> +java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java linux-all
> +
> +
>   ############################################################################
>
>   # jdk_instrument
>
> Thanks,
>
> -Joe


From joe.darcy at oracle.com  Thu Aug 13 21:42:23 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 13 Aug 2015 14:42:23 -0700
Subject: JDK 9 RFR of JDK-8133588: Place TimeoutLockLoops.java on the
	problem lis
In-Reply-To: <55CD0C8B.2080200@oracle.com>
References: <55CD09B9.6030108@oracle.com> <55CD0C8B.2080200@oracle.com>
Message-ID: <55CD0F3F.2080907@oracle.com>

Hi David,

On 8/13/2015 2:30 PM, David Holmes wrote:
> Joe,
>
> This is making it hard to clean up everything at once. I'm already 
> delayed from pushing the fix because the "@key intermittent" change is 
> not in hs-rt yet.

If the test needs to be updated as part of the fix for JDK-8029453, 
presumably it should be a trivial merge with the "intermittent" change 
if it doesn't arrive at the same time. If the intermittent-ness give a 
false positive for a while, I think that is acceptable given how changes 
flow around. (The reversal of just the intermittent tag could also be 
done in dev directly after any HotSpot changes for JDK-8029453 get 
integrated into dev.)

> If this change also goes in then I again have to wait for it to arrive 
> before I can reverse it. It will take a month for everything to get 
> back to where it should be. :(

If the HotSpot repos don't pull down this change promptly, I think it is 
fine if the problem list is updated after the HotSpot fix gets into dev.

My main concern here is not have have the test intermittently failing in 
the testing of dev for several more weeks.

Thanks,

-Joe

> This also seems to defeat the purpose of adding the "intermittent" tag.
>
> David
>
> On 14/08/2015 7:18 AM, joe darcy wrote:
>> Hello,
>>
>> Until a fix for JDK-8029453 is in place, the test TimeoutLockLoops.java
>> should be placed on the problem list for Linux since it fails
>> intermittently, but fairly frequently, on that OS:
>>
>> --- a/test/ProblemList.txt    Thu Aug 13 09:36:14 2015 -0700
>> +++ b/test/ProblemList.txt    Thu Aug 13 14:14:39 2015 -0700
>> @@ -353,6 +353,10 @@
>>   # 8062512
>> java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.java 
>> generic-all
>>
>> +# 8029453
>> +java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 
>> linux-all
>> +
>> +
>> ############################################################################
>>
>>   # jdk_instrument
>>
>> Thanks,
>>
>> -Joe



From masayoshi.okutsu at oracle.com  Thu Aug 13 22:46:33 2015
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 14 Aug 2015 07:46:33 +0900
Subject: [9] RFR: 8133321: (tz) Support tzdata2015f
In-Reply-To: <55CCA183.7010203@oracle.com>
References: <55CCA183.7010203@oracle.com>
Message-ID: <55CD1E49.5000701@oracle.com>

Looks good to me.

Masayoshi

On 8/13/2015 10:54 PM, Aleksej Efimov wrote:
> Hello,
>
> Please review latest tzdata (2015f)  integration into JDK9:
> http://cr.openjdk.java.net/~aefimov/tzdata/2015f/9/00
>
> Testing shows no TZ related failures on all platforms.
>
> Thanks,
> Aleksej
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8133321
>



From Roger.Riggs at Oracle.com  Fri Aug 14 01:24:38 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 13 Aug 2015 18:24:38 -0700
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: 
References: <55B6938E.2010806@Oracle.com>	<55B6940D.90701@Oracle.com>		<55BAC679.7010108@oracle.com>		<55BBA878.3090509@Oracle.com>	<55BBE261.4060902@oracle.com>		<55C4FEEC.1010804@Oracle.com>		<55CA1003.8030201@Oracle.com>		<55CA7239.2010905@oracle.com>	<55CA74F6.3070502@oracle.com>
	
Message-ID: <55CD4356.4090407@Oracle.com>

Hi Volker,

The internal reviews are complete and accepted.

The code looks fine.  Please push it.  I"ll be going on vacation so if 
it breaks something,
someone else will need to pick up the pieces or back it out.

Many thanks for the work to refactor and cleanup the details.

Roger



On 8/12/15 8:10 AM, Volker Simonis wrote:
> Hi Stuart,
>
> thanks for verifying the changes one more time.
>
> On Wed, Aug 12, 2015 at 12:19 AM, Stuart Marks  wrote:
>> .. and of course right after I sent my previous message, I ran across
>> something worth noting.
>>
>> The proposed spec for commandLine() says,
>>
>> * If {@link #command command()} and  {@link #arguments arguments()} return
>> non-null
>> * optionals,
>>
>> The preferred term is "non-empty" instead of non-null. This is kind of
>> nitpicky but in fact command() and arguments() should NEVER return an actual
>> null; they should always return an Optional that is either empty or that has
>> a value. So I think this is important to change lest someone be misled into
>> writing
>>
>>      if (info.command() == null && info.arguments() == null) ...
>>
> Good point. I've updated the documentation accordingly and created:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v7/
>
> Regards,
> Volker
>
>> Thanks,
>>
>> s'marks
>>
>>
>>
>> On 8/11/15 3:07 PM, Stuart Marks wrote:
>>> Hi Volker,
>>>
>>> I looked at the proposed specification of commandLine() after the most
>>> recent
>>> round of reviews (which is 8131168.v6 I believe) and it looks fine to me.
>>> It
>>> expresses the intent pretty well. Oh, and the name "commandLine" is fine
>>> and it
>>> fits well with the names of the other methods.
>>>
>>> Thanks,
>>>
>>> s'marks
>>>
>>> On 8/11/15 8:52 AM, Volker Simonis wrote:
>>>> On Tue, Aug 11, 2015 at 5:08 PM, Roger Riggs 
>>>> wrote:
>>>>> Hi Volker,
>>>>>
>>>>> Thanks for checking into the details of the OS X sysctl.  I'm fine with
>>>>> the
>>>>> current implementation.
>>>>>
>>>>> The rest of the updates and the additional tests look fine also.
>>>>>
>>>> Phew! I was already afraid I would have to switch to double-digit
>>>> versions for my webrevs :)
>>>>
>>>>> But I need to check on the CCC status.
>>>>>
>>>> OK, please let me know once it is ready/approved.
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 8/10/15 10:13 AM, Volker Simonis wrote:
>>>>>
>>>>> On Fri, Aug 7, 2015 at 8:54 PM, Roger Riggs 
>>>>> wrote:
>>>>>
>>>>> Hi Volker,
>>>>>
>>>>> 1) ProcessHandle.java:243
>>>>>
>>>>> For the definition of the new commandLine method I would:
>>>>>
>>>>>     - Use @link instead of @code for references to commands() and
>>>>> arguments()
>>>>> for easy navigation
>>>>>
>>>>>     - @implNote[1] should I think be changed to @apiNote:
>>>>>     the text describes not the JDK implementation but is information
>>>>> about the
>>>>>     information returned and is use to the application developer, not the
>>>>> JDK
>>>>> implementation.
>>>>>
>>>>>     -  The specific references to Linux implementation command line
>>>>> length
>>>>> parameters seems out of place
>>>>>         and should be omitted.
>>>>>
>>>>>           /**
>>>>>            * Returns the command line of the process.
>>>>>            * 

>>>>>            * If {@link #command command()} and  {@link #arguments
>>>>> arguments()}
>>>>> return non-null
>>>>>            * optionals, this is simply a convenience method which
>>>>> concatenates
>>>>>            * the values of the two functions separated by spaces.
>>>>> Otherwise it
>>>>> will return a
>>>>>            * best-effort, platform dependent representation of the
>>>>> command
>>>>> line.
>>>>>            *
>>>>>            * @apiNote Note that the returned executable pathname and the
>>>>>            *           arguments may be truncated on some platforms due
>>>>> to
>>>>> system
>>>>>            *           limitations.
>>>>>            *           

>>>>>            *           The executable pathname may contain only the
>>>>>            *           name of the executable without the full path
>>>>> information.
>>>>>            *           It is undecideable whether white space separates
>>>>> different
>>>>>            *           arguments or is part of a single argument.
>>>>>            *
>>>>>            * @return an {@code Optional} of the command line
>>>>>            *         of the process
>>>>>            */
>>>>>           public Optional commandLine();
>>>>>
>>>>>
>>>>> ProcessHandle.java:252: in arguments() method - @apiNote is a better fit
>>>>> for
>>>>> the note
>>>>>
>>>>> ProcessHandleImpl_macosx.c:276:   - indentation +4
>>>>>
>>>>> Thanks for the correction. I've taken your wording you suggested.
>>>>>
>>>>> 2) ProcessHandleImpl_macosx.c:192:
>>>>>       if (errno != EINVAL) ...  There was previously this test,  I'm
>>>>> concerned
>>>>> that if the pid is invalid,
>>>>>       it will now throw a RuntimeException instead of returning -1.
>>>>>       I recall a discussion from May that recommended testing for EINVAL.
>>>>>       The sysctl in getCmdlineAndUserInfo also does not throw if errno !=
>>>>> EINVAL, so the usage
>>>>>       is not consistent (probably my coding) but needs investigation.
>>>>>
>>>>> Not sure about this one and couldn't find any previous discussion
>>>>> about the topic.
>>>>>
>>>>> But, according to the sysctl man-page, EINVAL is only returned if:
>>>>>    - The name array is less than two or greater than CTL_MAXNAME.
>>>>>    - A non-null newp is given and its specified length in newlen is too
>>>>> large or too small.
>>>>>
>>>>> The first case can not happen because we always statically allocate
>>>>> arrays of the correct size.
>>>>> The second case can not happen as well, because we always have 'newp ==
>>>>> NULL'.
>>>>>
>>>>> So according to this information I don't see any reason why we should
>>>>> check for EINVAL. I think the right solution is to check for 'oldlenp
>>>>>
>>>>> 0' which we already do. By the way, this is also the check applied
>>>>>
>>>>> by the psutils (see the implementation of 'get_kinfo_proc()' in [1]).
>>>>>
>>>>> So I wnated to also removed the last check for EINVAL in
>>>>> getCmdlineAndUserInfo(). But for some reason, that seems to be really
>>>>> necessary. Without it, we will get a RuntinmeException if we call
>>>>> sysinfo for pid==0 for example. Further research showed that the
>>>>> kernel seems to really return EINVAL for KERN_PROCARGS2 (see function
>>>>> sysctl_procargsx() in [2]). But KERN_PROCARGS2 isn't specified as a
>>>>> supported constant in the sysctl man-page, so the information there is
>>>>> still valid :)
>>>>>
>>>>> On the other hand, I found that the psutils alo handles EINVAL only
>>>>> for KERN_PROCARGS2 (see get_arg_list() in [1]).
>>>>>
>>>>> So to cut a long story short, I think the current implementation is
>>>>> safe as it is now!
>>>>>
>>>>> [1]
>>>>> http://psutil.googlecode.com/svn/trunk/psutil/arch/osx/process_info.c
>>>>> [2]
>>>>>
>>>>> http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/bsd/kern/kern_sysctl.c
>>>>>
>>>>> 3) ProcessHandleImpl_solaris.c can do without the includes:
>>>>> #include "jni_util.h"
>>>>> #include "java_lang_ProcessHandleImpl.h"
>>>>> #include "java_lang_ProcessHandleImpl_Info.h"
>>>>>
>>>>> #include 
>>>>>
>>>>> 4) Ditto ProcessHandleImpl_aix.c
>>>>>
>>>>> Thanks, fixed.
>>>>>
>>>>> 5) ProcessHandleImpl_unix.c: 618:  typo  "fuctions" -> "functions"
>>>>>
>>>>> Fixed.
>>>>>
>>>>> 6) ProcessHandleImpl_unix.c:463: Would it be worthwhile to put
>>>>> sysconf(_SC_GETPW_R_SIZE_MAX) in a static?
>>>>>
>>>>> Good point! While doing this I realized that 'clock_ticks_per_second'
>>>>> is only used on Linux. So I moved the declaration of
>>>>> 'clock_ticks_per_second' from ProcessHandleImpl_unix.hpp to
>>>>> ProcessHandleImpl_linux.cpp and its initialization to  os_initNative()
>>>>> in the same file.
>>>>>
>>>>> I also declare a new static 'getpw_buf_size' in
>>>>> ProcessHandleImpl_unix.cpp and initialize it in
>>>>> Java_java_lang_ProcessHandleImpl_initNative() in the same file.
>>>>>
>>>>> 7) OnExitTest.java: exits without an error, just output in the log; it
>>>>> would
>>>>> escape attention.
>>>>>       The code respects the timeout setting.
>>>>>       Suggest removing the 'return' @133; the test will produce some
>>>>> errors
>>>>> and when debugging
>>>>>       the note will be in the log.
>>>>>
>>>>> Done.
>>>>>
>>>>> 8) ProcessHandleImpl_unix.h:58 - update the comment to include 0 as a
>>>>> valid
>>>>> parent pid.
>>>>>
>>>>> Fixed.
>>>>>
>>>>> Looks pretty good,
>>>>> Thanks, Roger
>>>>>
>>>>> Thanks:)
>>>>>
>>>>> I've also added two rudimentary tests for the new commandLine()
>>>>> function to InfoTest.test2():
>>>>>
>>>>>    - if both, 'command()' and 'arguments()' are available, I check that
>>>>> 'commandLine()' starts with 'command()' and contains all the arguments
>>>>> from 'arguments()'.
>>>>>
>>>>>    - otherwise, if 'commandLine()' is available, I check that it at
>>>>> least contains 'java'.  And as long as it is big enough it should also
>>>>> contain the corresponding arguments.
>>>>>
>>>>> The two new tests have been verified to pass on Windows, Linux, MacOS
>>>>> X, Solaris and AIX.
>>>>>
>>>>> The new version can be found here:
>>>>>
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v6/
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>>
>>>>> [1] http://openjdk.java.net/jeps/8068562  - JEP draft: javadoc tags to
>>>>> distinguish API, implementation, specification, and notes
>>>>>
>>>>>
>>>>> On 8/5/2015 3:56 PM, Volker Simonis wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> so here's the webrev which implements the new Info.commandLine()
>>>>> method (I chose 'commandLine() ' instead of 'cmdline()' or
>>>>> 'commandline()' because the other getters are camel case as well):
>>>>>
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v4/
>>>>>
>>>>>   From the JavaDoc of the new method:
>>>>>
>>>>> * If {@code command()} and  {@code arguments()} return non-null
>>>>> * optionals, this is simply a convenience method which concatenates
>>>>> * the values of the two functions. Otherwise it will return a
>>>>> * best-effort, platform dependent representation of the command line.
>>>>>
>>>>> This didn't change anything on MacOS X where there is no additional
>>>>> effort to get the command line.
>>>>>
>>>>> On Solaris and AIX, Info.commandLine() will always return the contents
>>>>> of psinfo.pr_psargs because there's no other method to get the exact
>>>>> arguments (i.e. Info.arguments() always returns NULL. I could
>>>>> therefore remove the extra handling of AIX/Solaris in the InfoTest
>>>>> from my initial change.
>>>>>
>>>>> On Linux, things are a little more complicated:
>>>>>
>>>>> - the initial implementation for Linux used arg[0] as 'command' if
>>>>> /proc/pid/exe wasn't readable. This was true for all the processes we
>>>>> don't own (except if we are running as root). But this information may
>>>>> be incomplete, because arg[0] may only contain the command without its
>>>>> full path. One example is 'sendmail' for which Info.command() reported
>>>>> "sendmail: accepting connections" but Info.arguments() was empty. This
>>>>> is wrong, because 'sendmail' changes its argv[] array. I have
>>>>> therefore disabled this behavior now that we have the 'commandLine()'
>>>>> method.
>>>>>
>>>>> - /proc/pid/cmdline is limited to PAGE_SIZE (normally 4096) characters
>>>>> on Linux. So strictly speaking, this isn't 'exact' information as well
>>>>> (there are plenty of complains that especially for Java programs this
>>>>> is not enough) and should go to 'commandLine()' instead to 'arguments'
>>>>> if /proc/pid/cmdline is truncated. I do check for this now.
>>>>>
>>>>> - the information in /proc/pid/cmdline can also be changed to
>>>>> something other than the original arguments if a program changes
>>>>> argv[] (which is not forbidden) but there's probably not much we can
>>>>> do to detect this. I've added a corresponding @implNote comment to
>>>>> JavaDoc of Info.arguments().
>>>>>
>>>>> - the initial implementation did not check for incomplete reads of
>>>>> /proc/pid/cmdline. This may be a problem on systems with PAGE_SIZE >
>>>>> 4096 (on Linux/ppc64 a page size of 65536 is not unusual). I'm now
>>>>> always reading the complete contents of /proc/pid/cmdline.
>>>>>
>>>>> - as far as I understand the current implementation, 'arguments()'
>>>>> returns the arguments array WITHOUT 'arg[0]' (which is the program
>>>>> name) but may
>>>>> be we should specify that more clearly in the JavaDoc of 'arguments()'.
>>>>>
>>>>> That's it. Hope you like it :)
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>> On Fri, Jul 31, 2015 at 11:02 PM, Stuart Marks 
>>>>> wrote:
>>>>>
>>>>> Hi Roger, Volker,
>>>>>
>>>>> Glad to see you guys are receptive to this and that it can move forward.
>>>>> Let
>>>>> me know if you'd like me to help out, for example with reviews or
>>>>> something.
>>>>>
>>>>> s'marks
>>>>>
>>>>>
>>>>> On 7/31/15 9:55 AM, Roger Riggs wrote:
>>>>>
>>>>> Hi Volker,
>>>>>
>>>>> I agree that adding an Info.commandline() method would be a good way
>>>>> to make the command line available and be able to describe that it is
>>>>> OS dependent and may be truncated.
>>>>> And having it assemble the command and arguments when they are available
>>>>> makes
>>>>> sense.
>>>>> As an API addition it will need a clear spec and I can run it through
>>>>> CCC
>>>>> so it
>>>>> gets
>>>>> another review and compatibility tests.
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>>>>>
>>>>> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks 
>>>>> wrote:
>>>>>
>>>>> On 7/29/15 11:36 AM, Volker Simonis wrote:
>>>>>
>>>>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>>>>> truncated or incomplete
>>>>> values for the executable or arguments.
>>>>> Can anyone be a tie-breaker  (with a good rational and suggestion for
>>>>> how
>>>>> an
>>>>> application can use the data).
>>>>>
>>>>> As I wrote, I agree to hear other opinions here.
>>>>>
>>>>> All I want to say that this truncated data is actually what 'ps' is
>>>>> reporting on Solaris since decades and people seem to be happy with
>>>>> it. As use case I can imagine logging or monitoring (something like
>>>>> 'top' in Java) where this data will be just good enough.
>>>>>
>>>>> We could specially mark possibly incomplete data by extending the Info
>>>>> object with functions like commandIsExact() or argumentsIsPrecise().
>>>>> But notice that we can not statically preset these values per
>>>>> platform. For example on Solaris, the 'command()' would return a
>>>>> precise value for processes with the same uid like the VM but only
>>>>> inaccurate values for all other processes. The "arguments()" would be
>>>>> always inaccurate on Solaris/AIX.
>>>>>
>>>>> It seems like there are cases where either exact or only approximate
>>>>> information is available. And as you observed, you might get one or the
>>>>> other on the same platform, depending on the UID. It also might depend
>>>>> on
>>>>> process state; I believe that some information becomes inaccessible when
>>>>> the
>>>>> process enters the zombie state.
>>>>>
>>>>> I don't think we should simply ignore one case or the other, but I also
>>>>> don't think we should try to cram the different information into the
>>>>> same
>>>>> API.
>>>>>
>>>>> The current ProcessHandle.Info api has
>>>>>
>>>>>        Optional command()
>>>>>        Optional arguments()
>>>>>
>>>>> It sounds to me like Roger wants these to contain only exact
>>>>> information.
>>>>> That seems reasonable, and this probably needs to be specified more
>>>>> clearly
>>>>> to contrast with what's below.
>>>>>
>>>>> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
>>>>> single string which appears to be the concatenation of the arguments
>>>>> (maybe
>>>>> including the command name). It's also truncated to fit PRARGSZ. It
>>>>> doesn't
>>>>> make sense to me to try to return this as a String[], as the zeroth
>>>>> element
>>>>> of that array, and certainly not parsed out into "words". So maybe
>>>>> instead
>>>>> we should have a different API that returns an imprecise command line as
>>>>> a
>>>>> single string:
>>>>>
>>>>>        Optional cmdline()
>>>>>
>>>>> (Naming bikeshed TBS). The semantics would be that this is the process'
>>>>> command and arguments concatenated into a single string (thus
>>>>> potentially
>>>>> losing argument boundaries) and also possibly truncated based on
>>>>> platform
>>>>> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out
>>>>> in a
>>>>> ps, top, or Activity Monitor style application, for informational
>>>>> purposes.
>>>>>
>>>>> If this were implemented, then on Solaris, command() and arguments()
>>>>> would
>>>>> always return empty optionals.
>>>>>
>>>>> I'm not sure what this should be if the exact information is available.
>>>>> It
>>>>> would be inconvenient if something that just wanted to print out an
>>>>> approximate command line had to check several different APIs to get the
>>>>> information. Maybe cmdline() could assemble the information from exact
>>>>> data
>>>>> if it's is available, by concatenating the Strings from command() and
>>>>> arguments(), as a convenience to the caller. But I could go either way
>>>>> on
>>>>> this.
>>>>>
>>>>> Not sure this counts as a tie-breaker, but it might be a reasonable way
>>>>> forward.
>>>>>
>>>>> s'marks
>>>>>
>>>>> Hi Stuart,
>>>>>
>>>>> thanks a lot for your comments - I like your proposal. For me this
>>>>> sounds like a good compromise.
>>>>>
>>>>> @Roger: should I go and add a new field commandLine and the
>>>>> corresponding getter to the Info class? As Stuart proposed, the getter
>>>>> could check if 'command' and 'arguments' are available and assemble
>>>>> the command line from them. Otherwise it could use the content of the
>>>>> commandLine field if that is available.
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>>
>>>>>



From david.holmes at oracle.com  Fri Aug 14 02:19:13 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 14 Aug 2015 12:19:13 +1000
Subject: JDK 9 RFR of JDK-8133588: Place TimeoutLockLoops.java on the
	problem lis
In-Reply-To: <55CD0F3F.2080907@oracle.com>
References: <55CD09B9.6030108@oracle.com> <55CD0C8B.2080200@oracle.com>
	<55CD0F3F.2080907@oracle.com>
Message-ID: <55CD5021.5050902@oracle.com>

On 14/08/2015 7:42 AM, Joseph D. Darcy wrote:
> Hi David,
>
> On 8/13/2015 2:30 PM, David Holmes wrote:
>> Joe,
>>
>> This is making it hard to clean up everything at once. I'm already
>> delayed from pushing the fix because the "@key intermittent" change is
>> not in hs-rt yet.
>
> If the test needs to be updated as part of the fix for JDK-8029453,
> presumably it should be a trivial merge with the "intermittent" change
> if it doesn't arrive at the same time. If the intermittent-ness give a
> false positive for a while, I think that is acceptable given how changes
> flow around. (The reversal of just the intermittent tag could also be
> done in dev directly after any HotSpot changes for JDK-8029453 get
> integrated into dev.)

The intended change is to remove the intermittent tag as it should no 
longer be an intermittent failure. But of course I can't remove the tag 
until the change that adds it turns up in my repo.

>> If this change also goes in then I again have to wait for it to arrive
>> before I can reverse it. It will take a month for everything to get
>> back to where it should be. :(
>
> If the HotSpot repos don't pull down this change promptly, I think it is
> fine if the problem list is updated after the HotSpot fix gets into dev.
>
> My main concern here is not have have the test intermittently failing in
> the testing of dev for several more weeks.

Ok. I'm pushing the fix now so that it will hit dev in two weeks time. 
I've filed:

https://bugs.openjdk.java.net/browse/JDK-8133611

to remove it from the problem list and remove the intermittent tag once 
it hits dev - and I'll push that directly to dev as you suggest.

Thanks,
David

> Thanks,
>
> -Joe
>
>> This also seems to defeat the purpose of adding the "intermittent" tag.
>>
>> David
>>
>> On 14/08/2015 7:18 AM, joe darcy wrote:
>>> Hello,
>>>
>>> Until a fix for JDK-8029453 is in place, the test TimeoutLockLoops.java
>>> should be placed on the problem list for Linux since it fails
>>> intermittently, but fairly frequently, on that OS:
>>>
>>> --- a/test/ProblemList.txt    Thu Aug 13 09:36:14 2015 -0700
>>> +++ b/test/ProblemList.txt    Thu Aug 13 14:14:39 2015 -0700
>>> @@ -353,6 +353,10 @@
>>>   # 8062512
>>> java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.java
>>> generic-all
>>>
>>> +# 8029453
>>> +java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java
>>> linux-all
>>> +
>>> +
>>> ############################################################################
>>>
>>>
>>>   # jdk_instrument
>>>
>>> Thanks,
>>>
>>> -Joe
>


From volker.simonis at gmail.com  Fri Aug 14 09:48:30 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 14 Aug 2015 11:48:30 +0200
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: <55CD4356.4090407@Oracle.com>
References: <55B6938E.2010806@Oracle.com> <55B6940D.90701@Oracle.com>
	
	<55BAC679.7010108@oracle.com>
	
	<55BBA878.3090509@Oracle.com> <55BBE261.4060902@oracle.com>
	
	<55C4FEEC.1010804@Oracle.com>
	
	<55CA1003.8030201@Oracle.com>
	
	<55CA7239.2010905@oracle.com> <55CA74F6.3070502@oracle.com>
	
	<55CD4356.4090407@Oracle.com>
Message-ID: 

On Fri, Aug 14, 2015 at 3:24 AM, Roger Riggs  wrote:
> Hi Volker,
>
> The internal reviews are complete and accepted.
>
> The code looks fine.  Please push it.  I"ll be going on vacation so if it
> breaks something,
> someone else will need to pick up the pieces or back it out.
>

Great - I've just pushed the code!

The only minor addition I've done was to add the new commandLine field
to ProcessHandlImpl_win.c as well. It is currently not used, but for
the sake of completeness I think it's more consistent now.

Before pushing I've synced and build on Linux, Solaris, MacOS X, AIX
and Windows. I've also rerun the ProcessHandle jtreg tests and they
all passed. So hopefully nothing will break and there will be no
reason for backing the change because I am already on vacation :)

Thanks for your feedback and help and have a good vacation!
Volker

> Many thanks for the work to refactor and cleanup the details.
>
> Roger
>
>
>
> On 8/12/15 8:10 AM, Volker Simonis wrote:
>
> Hi Stuart,
>
> thanks for verifying the changes one more time.
>
> On Wed, Aug 12, 2015 at 12:19 AM, Stuart Marks 
> wrote:
>
> .. and of course right after I sent my previous message, I ran across
> something worth noting.
>
> The proposed spec for commandLine() says,
>
> * If {@link #command command()} and  {@link #arguments arguments()} return
> non-null
> * optionals,
>
> The preferred term is "non-empty" instead of non-null. This is kind of
> nitpicky but in fact command() and arguments() should NEVER return an actual
> null; they should always return an Optional that is either empty or that has
> a value. So I think this is important to change lest someone be misled into
> writing
>
>     if (info.command() == null && info.arguments() == null) ...
>
> Good point. I've updated the documentation accordingly and created:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v7/
>
> Regards,
> Volker
>
> Thanks,
>
> s'marks
>
>
>
> On 8/11/15 3:07 PM, Stuart Marks wrote:
>
> Hi Volker,
>
> I looked at the proposed specification of commandLine() after the most
> recent
> round of reviews (which is 8131168.v6 I believe) and it looks fine to me.
> It
> expresses the intent pretty well. Oh, and the name "commandLine" is fine
> and it
> fits well with the names of the other methods.
>
> Thanks,
>
> s'marks
>
> On 8/11/15 8:52 AM, Volker Simonis wrote:
>
> On Tue, Aug 11, 2015 at 5:08 PM, Roger Riggs 
> wrote:
>
> Hi Volker,
>
> Thanks for checking into the details of the OS X sysctl.  I'm fine with
> the
> current implementation.
>
> The rest of the updates and the additional tests look fine also.
>
> Phew! I was already afraid I would have to switch to double-digit
> versions for my webrevs :)
>
> But I need to check on the CCC status.
>
> OK, please let me know once it is ready/approved.
>
> Regards,
> Volker
>
> Thanks, Roger
>
>
>
>
> On 8/10/15 10:13 AM, Volker Simonis wrote:
>
> On Fri, Aug 7, 2015 at 8:54 PM, Roger Riggs 
> wrote:
>
> Hi Volker,
>
> 1) ProcessHandle.java:243
>
> For the definition of the new commandLine method I would:
>
>    - Use @link instead of @code for references to commands() and
> arguments()
> for easy navigation
>
>    - @implNote[1] should I think be changed to @apiNote:
>    the text describes not the JDK implementation but is information
> about the
>    information returned and is use to the application developer, not the
> JDK
> implementation.
>
>    -  The specific references to Linux implementation command line
> length
> parameters seems out of place
>        and should be omitted.
>
>          /**
>           * Returns the command line of the process.
>           * 

>           * If {@link #command command()} and  {@link #arguments
> arguments()}
> return non-null
>           * optionals, this is simply a convenience method which
> concatenates
>           * the values of the two functions separated by spaces.
> Otherwise it
> will return a
>           * best-effort, platform dependent representation of the
> command
> line.
>           *
>           * @apiNote Note that the returned executable pathname and the
>           *           arguments may be truncated on some platforms due
> to
> system
>           *           limitations.
>           *           

>           *           The executable pathname may contain only the
>           *           name of the executable without the full path
> information.
>           *           It is undecideable whether white space separates
> different
>           *           arguments or is part of a single argument.
>           *
>           * @return an {@code Optional} of the command line
>           *         of the process
>           */
>          public Optional commandLine();
>
>
> ProcessHandle.java:252: in arguments() method - @apiNote is a better fit
> for
> the note
>
> ProcessHandleImpl_macosx.c:276:   - indentation +4
>
> Thanks for the correction. I've taken your wording you suggested.
>
> 2) ProcessHandleImpl_macosx.c:192:
>      if (errno != EINVAL) ...  There was previously this test,  I'm
> concerned
> that if the pid is invalid,
>      it will now throw a RuntimeException instead of returning -1.
>      I recall a discussion from May that recommended testing for EINVAL.
>      The sysctl in getCmdlineAndUserInfo also does not throw if errno !=
> EINVAL, so the usage
>      is not consistent (probably my coding) but needs investigation.
>
> Not sure about this one and couldn't find any previous discussion
> about the topic.
>
> But, according to the sysctl man-page, EINVAL is only returned if:
>   - The name array is less than two or greater than CTL_MAXNAME.
>   - A non-null newp is given and its specified length in newlen is too
> large or too small.
>
> The first case can not happen because we always statically allocate
> arrays of the correct size.
> The second case can not happen as well, because we always have 'newp ==
> NULL'.
>
> So according to this information I don't see any reason why we should
> check for EINVAL. I think the right solution is to check for 'oldlenp
>
> 0' which we already do. By the way, this is also the check applied
>
> by the psutils (see the implementation of 'get_kinfo_proc()' in [1]).
>
> So I wnated to also removed the last check for EINVAL in
> getCmdlineAndUserInfo(). But for some reason, that seems to be really
> necessary. Without it, we will get a RuntinmeException if we call
> sysinfo for pid==0 for example. Further research showed that the
> kernel seems to really return EINVAL for KERN_PROCARGS2 (see function
> sysctl_procargsx() in [2]). But KERN_PROCARGS2 isn't specified as a
> supported constant in the sysctl man-page, so the information there is
> still valid :)
>
> On the other hand, I found that the psutils alo handles EINVAL only
> for KERN_PROCARGS2 (see get_arg_list() in [1]).
>
> So to cut a long story short, I think the current implementation is
> safe as it is now!
>
> [1]
> http://psutil.googlecode.com/svn/trunk/psutil/arch/osx/process_info.c
> [2]
>
> http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/bsd/kern/kern_sysctl.c
>
> 3) ProcessHandleImpl_solaris.c can do without the includes:
> #include "jni_util.h"
> #include "java_lang_ProcessHandleImpl.h"
> #include "java_lang_ProcessHandleImpl_Info.h"
>
> #include 
>
> 4) Ditto ProcessHandleImpl_aix.c
>
> Thanks, fixed.
>
> 5) ProcessHandleImpl_unix.c: 618:  typo  "fuctions" -> "functions"
>
> Fixed.
>
> 6) ProcessHandleImpl_unix.c:463: Would it be worthwhile to put
> sysconf(_SC_GETPW_R_SIZE_MAX) in a static?
>
> Good point! While doing this I realized that 'clock_ticks_per_second'
> is only used on Linux. So I moved the declaration of
> 'clock_ticks_per_second' from ProcessHandleImpl_unix.hpp to
> ProcessHandleImpl_linux.cpp and its initialization to  os_initNative()
> in the same file.
>
> I also declare a new static 'getpw_buf_size' in
> ProcessHandleImpl_unix.cpp and initialize it in
> Java_java_lang_ProcessHandleImpl_initNative() in the same file.
>
> 7) OnExitTest.java: exits without an error, just output in the log; it
> would
> escape attention.
>      The code respects the timeout setting.
>      Suggest removing the 'return' @133; the test will produce some
> errors
> and when debugging
>      the note will be in the log.
>
> Done.
>
> 8) ProcessHandleImpl_unix.h:58 - update the comment to include 0 as a
> valid
> parent pid.
>
> Fixed.
>
> Looks pretty good,
> Thanks, Roger
>
> Thanks:)
>
> I've also added two rudimentary tests for the new commandLine()
> function to InfoTest.test2():
>
>   - if both, 'command()' and 'arguments()' are available, I check that
> 'commandLine()' starts with 'command()' and contains all the arguments
> from 'arguments()'.
>
>   - otherwise, if 'commandLine()' is available, I check that it at
> least contains 'java'.  And as long as it is big enough it should also
> contain the corresponding arguments.
>
> The two new tests have been verified to pass on Windows, Linux, MacOS
> X, Solaris and AIX.
>
> The new version can be found here:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v6/
>
> Regards,
> Volker
>
>
> [1] http://openjdk.java.net/jeps/8068562  - JEP draft: javadoc tags to
> distinguish API, implementation, specification, and notes
>
>
> On 8/5/2015 3:56 PM, Volker Simonis wrote:
>
> Hi,
>
> so here's the webrev which implements the new Info.commandLine()
> method (I chose 'commandLine() ' instead of 'cmdline()' or
> 'commandline()' because the other getters are camel case as well):
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v4/
>
>  From the JavaDoc of the new method:
>
> * If {@code command()} and  {@code arguments()} return non-null
> * optionals, this is simply a convenience method which concatenates
> * the values of the two functions. Otherwise it will return a
> * best-effort, platform dependent representation of the command line.
>
> This didn't change anything on MacOS X where there is no additional
> effort to get the command line.
>
> On Solaris and AIX, Info.commandLine() will always return the contents
> of psinfo.pr_psargs because there's no other method to get the exact
> arguments (i.e. Info.arguments() always returns NULL. I could
> therefore remove the extra handling of AIX/Solaris in the InfoTest
> from my initial change.
>
> On Linux, things are a little more complicated:
>
> - the initial implementation for Linux used arg[0] as 'command' if
> /proc/pid/exe wasn't readable. This was true for all the processes we
> don't own (except if we are running as root). But this information may
> be incomplete, because arg[0] may only contain the command without its
> full path. One example is 'sendmail' for which Info.command() reported
> "sendmail: accepting connections" but Info.arguments() was empty. This
> is wrong, because 'sendmail' changes its argv[] array. I have
> therefore disabled this behavior now that we have the 'commandLine()'
> method.
>
> - /proc/pid/cmdline is limited to PAGE_SIZE (normally 4096) characters
> on Linux. So strictly speaking, this isn't 'exact' information as well
> (there are plenty of complains that especially for Java programs this
> is not enough) and should go to 'commandLine()' instead to 'arguments'
> if /proc/pid/cmdline is truncated. I do check for this now.
>
> - the information in /proc/pid/cmdline can also be changed to
> something other than the original arguments if a program changes
> argv[] (which is not forbidden) but there's probably not much we can
> do to detect this. I've added a corresponding @implNote comment to
> JavaDoc of Info.arguments().
>
> - the initial implementation did not check for incomplete reads of
> /proc/pid/cmdline. This may be a problem on systems with PAGE_SIZE >
> 4096 (on Linux/ppc64 a page size of 65536 is not unusual). I'm now
> always reading the complete contents of /proc/pid/cmdline.
>
> - as far as I understand the current implementation, 'arguments()'
> returns the arguments array WITHOUT 'arg[0]' (which is the program
> name) but may
> be we should specify that more clearly in the JavaDoc of 'arguments()'.
>
> That's it. Hope you like it :)
>
> Regards,
> Volker
>
> On Fri, Jul 31, 2015 at 11:02 PM, Stuart Marks 
> wrote:
>
> Hi Roger, Volker,
>
> Glad to see you guys are receptive to this and that it can move forward.
> Let
> me know if you'd like me to help out, for example with reviews or
> something.
>
> s'marks
>
>
> On 7/31/15 9:55 AM, Roger Riggs wrote:
>
> Hi Volker,
>
> I agree that adding an Info.commandline() method would be a good way
> to make the command line available and be able to describe that it is
> OS dependent and may be truncated.
> And having it assemble the command and arguments when they are available
> makes
> sense.
> As an API addition it will need a clear spec and I can run it through
> CCC
> so it
> gets
> another review and compatibility tests.
>
> Thanks, Roger
>
>
>
>
> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>
> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks 
> wrote:
>
> On 7/29/15 11:36 AM, Volker Simonis wrote:
>
> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
> truncated or incomplete
> values for the executable or arguments.
> Can anyone be a tie-breaker  (with a good rational and suggestion for
> how
> an
> application can use the data).
>
> As I wrote, I agree to hear other opinions here.
>
> All I want to say that this truncated data is actually what 'ps' is
> reporting on Solaris since decades and people seem to be happy with
> it. As use case I can imagine logging or monitoring (something like
> 'top' in Java) where this data will be just good enough.
>
> We could specially mark possibly incomplete data by extending the Info
> object with functions like commandIsExact() or argumentsIsPrecise().
> But notice that we can not statically preset these values per
> platform. For example on Solaris, the 'command()' would return a
> precise value for processes with the same uid like the VM but only
> inaccurate values for all other processes. The "arguments()" would be
> always inaccurate on Solaris/AIX.
>
> It seems like there are cases where either exact or only approximate
> information is available. And as you observed, you might get one or the
> other on the same platform, depending on the UID. It also might depend
> on
> process state; I believe that some information becomes inaccessible when
> the
> process enters the zombie state.
>
> I don't think we should simply ignore one case or the other, but I also
> don't think we should try to cram the different information into the
> same
> API.
>
> The current ProcessHandle.Info api has
>
>       Optional command()
>       Optional arguments()
>
> It sounds to me like Roger wants these to contain only exact
> information.
> That seems reasonable, and this probably needs to be specified more
> clearly
> to contrast with what's below.
>
> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
> single string which appears to be the concatenation of the arguments
> (maybe
> including the command name). It's also truncated to fit PRARGSZ. It
> doesn't
> make sense to me to try to return this as a String[], as the zeroth
> element
> of that array, and certainly not parsed out into "words". So maybe
> instead
> we should have a different API that returns an imprecise command line as
> a
> single string:
>
>       Optional cmdline()
>
> (Naming bikeshed TBS). The semantics would be that this is the process'
> command and arguments concatenated into a single string (thus
> potentially
> losing argument boundaries) and also possibly truncated based on
> platform
> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out
> in a
> ps, top, or Activity Monitor style application, for informational
> purposes.
>
> If this were implemented, then on Solaris, command() and arguments()
> would
> always return empty optionals.
>
> I'm not sure what this should be if the exact information is available.
> It
> would be inconvenient if something that just wanted to print out an
> approximate command line had to check several different APIs to get the
> information. Maybe cmdline() could assemble the information from exact
> data
> if it's is available, by concatenating the Strings from command() and
> arguments(), as a convenience to the caller. But I could go either way
> on
> this.
>
> Not sure this counts as a tie-breaker, but it might be a reasonable way
> forward.
>
> s'marks
>
> Hi Stuart,
>
> thanks a lot for your comments - I like your proposal. For me this
> sounds like a good compromise.
>
> @Roger: should I go and add a new field commandLine and the
> corresponding getter to the Info class? As Stuart proposed, the getter
> could check if 'command' and 'arguments' are available and assemble
> the command line from them. Otherwise it could use the content of the
> commandLine field if that is available.
>
> Regards,
> Volker
>
>
>
>


From alexander.v.stepanov at oracle.com  Fri Aug 14 10:18:15 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Fri, 14 Aug 2015 13:18:15 +0300
Subject: RFR [9] 8133480: replace some  tags (obsolete in html5) in
	core-libs docs
In-Reply-To: <973DBB67-4EBC-4F78-AA65-6EBEDBC34401@oracle.com>
References: <55CCACD7.6070801@oracle.com>
	<973DBB67-4EBC-4F78-AA65-6EBEDBC34401@oracle.com>
Message-ID: <55CDC067.2010100@oracle.com>

Thanks!

Regards,
Alexander

On 8/13/2015 8:42 PM, Lance Andersen wrote:
> looks OK.  Nothing obvious stands out.
>
> Best
> Lance
> On Aug 13, 2015, at 10:42 AM, Alexander Stepanov 
>  > wrote:
>
>> Hello,
>>
>> Could you please review the following fix:
>> http://cr.openjdk.java.net/~avstepan/8133480/webrev.00 
>> 
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8133480
>>
>> Just another portion of deprecated  tags replaced with {@code }.
>> A single misprint was fixed; no other changes indicated by specdiff.
>>
>> Thanks,
>> Alexander
>
> 
> 
> 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 konstantin.shefov at oracle.com  Fri Aug 14 10:53:09 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 14 Aug 2015 13:53:09 +0300
Subject: [9] RFR: 8133543: [TESTBUG]
	java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java
	should be modified
Message-ID: <55CDC895.8020602@oracle.com>

Hello,

Please review a test bug fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8133543
Webrev: http://cr.openjdk.java.net/~kshefov/8133543/webrev.00/

-Konstantin


From konstantin.shefov at oracle.com  Fri Aug 14 12:00:51 2015
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 14 Aug 2015 15:00:51 +0300
Subject: [9] RFR: 8060717: [TESTBUG] Improve test coverage of
	MethodHandles.explicitCastArguments()
In-Reply-To: <55C3740A.10205@oracle.com>
References: <55BBA449.1030603@oracle.com>	<0B7B1F71-0BE3-400E-A6C2-5FD01E13777A@oracle.com>	<55BF838D.7080202@oracle.com>
	<55C330D1.80307@oracle.com> <55C33FB1.5000708@oracle.com>
	<55C3740A.10205@oracle.com>
Message-ID: <55CDD873.4000009@oracle.com>

Vladimir,

Please review the modified test.

Thanks
-Konstantin

On 08/06/2015 05:49 PM, Konstantin Shefov wrote:
> Please, look at the modified test
>
> http://cr.openjdk.java.net/~kshefov/8060717/webrev.01/
>
> -Konstantin
>
> On 08/06/2015 02:06 PM, Konstantin Shefov wrote:
>> Hi Vladimir
>>
>> Thanks for reviewing
>>
>>
>> On 08/06/2015 01:02 PM, Vladimir Ivanov wrote:
>>> Konstantin,
>>>
>>> Overall, looks good.
>>>
>>> Why do you create a new ClassLoader here and not simply reference 
>>> them directly (they are loaded by application class loader)?
>> You a right. Because of class loader hierarchy, all "Test*" classes 
>> in this case are loaded by app class loader as an ancestor of url 
>> class loader, so it is the same as just reference them directly.
>> To make the "Test*" classes loaded by ucl, they need to be outside of 
>> classpath, which will produce extra folders and ".java" files in test 
>> workspace.
>>
>> I think non-bcp to bcp test will play just the same role (work with 
>> classes loaded by different class loaders).
>>
>> So I will correct the code. I will add BCP-to-non-BCP & 
>> non-BCP-to-BCP cases and remove url classloader.
>>
>> -Konstantin
>>> + public static void testNonBCPRef2Ref() throws Throwable {
>>> +        String testClassPath = System.getProperty("test.classes",".");
>>> +        URL[] classpath = {(new 
>>> File(testClassPath)).getCanonicalFile()
>>> +            .toURI().toURL()};
>>> +        URLClassLoader ucl = URLClassLoader.newInstance(classpath);
>>> +        Class testInterface = ucl.loadClass(THIS_CLASS.getSimpleName()
>>> +                + "$TestInterface");
>>> +        Class testSuperClass = 
>>> ucl.loadClass(THIS_CLASS.getSimpleName()
>>> +                + "$TestSuperClass");
>>> +        Class testSubClass1 = ucl.loadClass(THIS_CLASS.getSimpleName()
>>> +                + "$TestSubClass1");
>>>
>>> I see BCP-to-BCP & non-BCP-to-non-BCP ref-to-ref cases covered. What 
>>> about BCP-to-non-BCP & non-BCP-to-BCP cases?
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 8/3/15 6:06 PM, Konstantin Shefov wrote:
>>>> Michael, thanks for reviewing!
>>>>
>>>> Vladimir, could you take a look, please?
>>>>
>>>> -Konstantin
>>>>
>>>> On 08/02/2015 05:31 PM, Michael Haupt wrote:
>>>>> Hi Konstantin,
>>>>>
>>>>>> Am 31.07.2015 um 18:37 schrieb Konstantin Shefov
>>>>>> >>>>> >:
>>>>>> Please review a test improvement. Covered more cases for
>>>>>> MethodHandles.explicitCastArguments().
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060717
>>>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.00/
>>>>>> 
>>>>>
>>>>> note that mine is a lower-case review and does not count, but: thumbs
>>>>> up. The level of detail at which the API is tested improves
>>>>> significantly with these changes.
>>>>>
>>>>> Best,
>>>>>
>>>>> Michael
>>>>>
>>>>> -- 
>>>>>
>>>>> Oracle 
>>>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>>>> OracleJava Platform Group | LangTools Team | Nashorn
>>>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 
>>>>> Potsdam,
>>>>> Germany
>>>>> Green Oracle  Oracle is committed
>>>>> to developing practices and products that help protect the 
>>>>> environment
>>>>>
>>>>>
>>>>
>>
>



From Roger.Riggs at Oracle.com  Fri Aug 14 12:40:42 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 14 Aug 2015 05:40:42 -0700
Subject: RFR (M/L): 8131168: Refactor ProcessHandleImpl_*.c and add
	implememtation for AIX
In-Reply-To: 
References: <55B6938E.2010806@Oracle.com>	<55B6940D.90701@Oracle.com>		<55BAC679.7010108@oracle.com>		<55BBA878.3090509@Oracle.com>	<55BBE261.4060902@oracle.com>		<55C4FEEC.1010804@Oracle.com>		<55CA1003.8030201@Oracle.com>		<55CA7239.2010905@oracle.com>	<55CA74F6.3070502@oracle.com>		<55CD4356.4090407@Oracle.com>
	
Message-ID: <55CDE1CA.7080802@Oracle.com>

Thanks Volker. Have a good vacation.

On 8/14/15 2:48 AM, Volker Simonis wrote:
> On Fri, Aug 14, 2015 at 3:24 AM, Roger Riggs  wrote:
>> Hi Volker,
>>
>> The internal reviews are complete and accepted.
>>
>> The code looks fine.  Please push it.  I"ll be going on vacation so if it
>> breaks something,
>> someone else will need to pick up the pieces or back it out.
>>
> Great - I've just pushed the code!
>
> The only minor addition I've done was to add the new commandLine field
> to ProcessHandlImpl_win.c as well. It is currently not used, but for
> the sake of completeness I think it's more consistent now.
>
> Before pushing I've synced and build on Linux, Solaris, MacOS X, AIX
> and Windows. I've also rerun the ProcessHandle jtreg tests and they
> all passed. So hopefully nothing will break and there will be no
> reason for backing the change because I am already on vacation :)
>
> Thanks for your feedback and help and have a good vacation!
> Volker
>
>> Many thanks for the work to refactor and cleanup the details.
>>
>> Roger
>>
>>
>>
>> On 8/12/15 8:10 AM, Volker Simonis wrote:
>>
>> Hi Stuart,
>>
>> thanks for verifying the changes one more time.
>>
>> On Wed, Aug 12, 2015 at 12:19 AM, Stuart Marks 
>> wrote:
>>
>> .. and of course right after I sent my previous message, I ran across
>> something worth noting.
>>
>> The proposed spec for commandLine() says,
>>
>> * If {@link #command command()} and  {@link #arguments arguments()} return
>> non-null
>> * optionals,
>>
>> The preferred term is "non-empty" instead of non-null. This is kind of
>> nitpicky but in fact command() and arguments() should NEVER return an actual
>> null; they should always return an Optional that is either empty or that has
>> a value. So I think this is important to change lest someone be misled into
>> writing
>>
>>      if (info.command() == null && info.arguments() == null) ...
>>
>> Good point. I've updated the documentation accordingly and created:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v7/
>>
>> Regards,
>> Volker
>>
>> Thanks,
>>
>> s'marks
>>
>>
>>
>> On 8/11/15 3:07 PM, Stuart Marks wrote:
>>
>> Hi Volker,
>>
>> I looked at the proposed specification of commandLine() after the most
>> recent
>> round of reviews (which is 8131168.v6 I believe) and it looks fine to me.
>> It
>> expresses the intent pretty well. Oh, and the name "commandLine" is fine
>> and it
>> fits well with the names of the other methods.
>>
>> Thanks,
>>
>> s'marks
>>
>> On 8/11/15 8:52 AM, Volker Simonis wrote:
>>
>> On Tue, Aug 11, 2015 at 5:08 PM, Roger Riggs 
>> wrote:
>>
>> Hi Volker,
>>
>> Thanks for checking into the details of the OS X sysctl.  I'm fine with
>> the
>> current implementation.
>>
>> The rest of the updates and the additional tests look fine also.
>>
>> Phew! I was already afraid I would have to switch to double-digit
>> versions for my webrevs :)
>>
>> But I need to check on the CCC status.
>>
>> OK, please let me know once it is ready/approved.
>>
>> Regards,
>> Volker
>>
>> Thanks, Roger
>>
>>
>>
>>
>> On 8/10/15 10:13 AM, Volker Simonis wrote:
>>
>> On Fri, Aug 7, 2015 at 8:54 PM, Roger Riggs 
>> wrote:
>>
>> Hi Volker,
>>
>> 1) ProcessHandle.java:243
>>
>> For the definition of the new commandLine method I would:
>>
>>     - Use @link instead of @code for references to commands() and
>> arguments()
>> for easy navigation
>>
>>     - @implNote[1] should I think be changed to @apiNote:
>>     the text describes not the JDK implementation but is information
>> about the
>>     information returned and is use to the application developer, not the
>> JDK
>> implementation.
>>
>>     -  The specific references to Linux implementation command line
>> length
>> parameters seems out of place
>>         and should be omitted.
>>
>>           /**
>>            * Returns the command line of the process.
>>            * 

>>            * If {@link #command command()} and  {@link #arguments
>> arguments()}
>> return non-null
>>            * optionals, this is simply a convenience method which
>> concatenates
>>            * the values of the two functions separated by spaces.
>> Otherwise it
>> will return a
>>            * best-effort, platform dependent representation of the
>> command
>> line.
>>            *
>>            * @apiNote Note that the returned executable pathname and the
>>            *           arguments may be truncated on some platforms due
>> to
>> system
>>            *           limitations.
>>            *           

>>            *           The executable pathname may contain only the
>>            *           name of the executable without the full path
>> information.
>>            *           It is undecideable whether white space separates
>> different
>>            *           arguments or is part of a single argument.
>>            *
>>            * @return an {@code Optional} of the command line
>>            *         of the process
>>            */
>>           public Optional commandLine();
>>
>>
>> ProcessHandle.java:252: in arguments() method - @apiNote is a better fit
>> for
>> the note
>>
>> ProcessHandleImpl_macosx.c:276:   - indentation +4
>>
>> Thanks for the correction. I've taken your wording you suggested.
>>
>> 2) ProcessHandleImpl_macosx.c:192:
>>       if (errno != EINVAL) ...  There was previously this test,  I'm
>> concerned
>> that if the pid is invalid,
>>       it will now throw a RuntimeException instead of returning -1.
>>       I recall a discussion from May that recommended testing for EINVAL.
>>       The sysctl in getCmdlineAndUserInfo also does not throw if errno !=
>> EINVAL, so the usage
>>       is not consistent (probably my coding) but needs investigation.
>>
>> Not sure about this one and couldn't find any previous discussion
>> about the topic.
>>
>> But, according to the sysctl man-page, EINVAL is only returned if:
>>    - The name array is less than two or greater than CTL_MAXNAME.
>>    - A non-null newp is given and its specified length in newlen is too
>> large or too small.
>>
>> The first case can not happen because we always statically allocate
>> arrays of the correct size.
>> The second case can not happen as well, because we always have 'newp ==
>> NULL'.
>>
>> So according to this information I don't see any reason why we should
>> check for EINVAL. I think the right solution is to check for 'oldlenp
>>
>> 0' which we already do. By the way, this is also the check applied
>>
>> by the psutils (see the implementation of 'get_kinfo_proc()' in [1]).
>>
>> So I wnated to also removed the last check for EINVAL in
>> getCmdlineAndUserInfo(). But for some reason, that seems to be really
>> necessary. Without it, we will get a RuntinmeException if we call
>> sysinfo for pid==0 for example. Further research showed that the
>> kernel seems to really return EINVAL for KERN_PROCARGS2 (see function
>> sysctl_procargsx() in [2]). But KERN_PROCARGS2 isn't specified as a
>> supported constant in the sysctl man-page, so the information there is
>> still valid :)
>>
>> On the other hand, I found that the psutils alo handles EINVAL only
>> for KERN_PROCARGS2 (see get_arg_list() in [1]).
>>
>> So to cut a long story short, I think the current implementation is
>> safe as it is now!
>>
>> [1]
>> http://psutil.googlecode.com/svn/trunk/psutil/arch/osx/process_info.c
>> [2]
>>
>> http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/bsd/kern/kern_sysctl.c
>>
>> 3) ProcessHandleImpl_solaris.c can do without the includes:
>> #include "jni_util.h"
>> #include "java_lang_ProcessHandleImpl.h"
>> #include "java_lang_ProcessHandleImpl_Info.h"
>>
>> #include 
>>
>> 4) Ditto ProcessHandleImpl_aix.c
>>
>> Thanks, fixed.
>>
>> 5) ProcessHandleImpl_unix.c: 618:  typo  "fuctions" -> "functions"
>>
>> Fixed.
>>
>> 6) ProcessHandleImpl_unix.c:463: Would it be worthwhile to put
>> sysconf(_SC_GETPW_R_SIZE_MAX) in a static?
>>
>> Good point! While doing this I realized that 'clock_ticks_per_second'
>> is only used on Linux. So I moved the declaration of
>> 'clock_ticks_per_second' from ProcessHandleImpl_unix.hpp to
>> ProcessHandleImpl_linux.cpp and its initialization to  os_initNative()
>> in the same file.
>>
>> I also declare a new static 'getpw_buf_size' in
>> ProcessHandleImpl_unix.cpp and initialize it in
>> Java_java_lang_ProcessHandleImpl_initNative() in the same file.
>>
>> 7) OnExitTest.java: exits without an error, just output in the log; it
>> would
>> escape attention.
>>       The code respects the timeout setting.
>>       Suggest removing the 'return' @133; the test will produce some
>> errors
>> and when debugging
>>       the note will be in the log.
>>
>> Done.
>>
>> 8) ProcessHandleImpl_unix.h:58 - update the comment to include 0 as a
>> valid
>> parent pid.
>>
>> Fixed.
>>
>> Looks pretty good,
>> Thanks, Roger
>>
>> Thanks:)
>>
>> I've also added two rudimentary tests for the new commandLine()
>> function to InfoTest.test2():
>>
>>    - if both, 'command()' and 'arguments()' are available, I check that
>> 'commandLine()' starts with 'command()' and contains all the arguments
>> from 'arguments()'.
>>
>>    - otherwise, if 'commandLine()' is available, I check that it at
>> least contains 'java'.  And as long as it is big enough it should also
>> contain the corresponding arguments.
>>
>> The two new tests have been verified to pass on Windows, Linux, MacOS
>> X, Solaris and AIX.
>>
>> The new version can be found here:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v6/
>>
>> Regards,
>> Volker
>>
>>
>> [1] http://openjdk.java.net/jeps/8068562  - JEP draft: javadoc tags to
>> distinguish API, implementation, specification, and notes
>>
>>
>> On 8/5/2015 3:56 PM, Volker Simonis wrote:
>>
>> Hi,
>>
>> so here's the webrev which implements the new Info.commandLine()
>> method (I chose 'commandLine() ' instead of 'cmdline()' or
>> 'commandline()' because the other getters are camel case as well):
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8131168.v4/
>>
>>   From the JavaDoc of the new method:
>>
>> * If {@code command()} and  {@code arguments()} return non-null
>> * optionals, this is simply a convenience method which concatenates
>> * the values of the two functions. Otherwise it will return a
>> * best-effort, platform dependent representation of the command line.
>>
>> This didn't change anything on MacOS X where there is no additional
>> effort to get the command line.
>>
>> On Solaris and AIX, Info.commandLine() will always return the contents
>> of psinfo.pr_psargs because there's no other method to get the exact
>> arguments (i.e. Info.arguments() always returns NULL. I could
>> therefore remove the extra handling of AIX/Solaris in the InfoTest
>> from my initial change.
>>
>> On Linux, things are a little more complicated:
>>
>> - the initial implementation for Linux used arg[0] as 'command' if
>> /proc/pid/exe wasn't readable. This was true for all the processes we
>> don't own (except if we are running as root). But this information may
>> be incomplete, because arg[0] may only contain the command without its
>> full path. One example is 'sendmail' for which Info.command() reported
>> "sendmail: accepting connections" but Info.arguments() was empty. This
>> is wrong, because 'sendmail' changes its argv[] array. I have
>> therefore disabled this behavior now that we have the 'commandLine()'
>> method.
>>
>> - /proc/pid/cmdline is limited to PAGE_SIZE (normally 4096) characters
>> on Linux. So strictly speaking, this isn't 'exact' information as well
>> (there are plenty of complains that especially for Java programs this
>> is not enough) and should go to 'commandLine()' instead to 'arguments'
>> if /proc/pid/cmdline is truncated. I do check for this now.
>>
>> - the information in /proc/pid/cmdline can also be changed to
>> something other than the original arguments if a program changes
>> argv[] (which is not forbidden) but there's probably not much we can
>> do to detect this. I've added a corresponding @implNote comment to
>> JavaDoc of Info.arguments().
>>
>> - the initial implementation did not check for incomplete reads of
>> /proc/pid/cmdline. This may be a problem on systems with PAGE_SIZE >
>> 4096 (on Linux/ppc64 a page size of 65536 is not unusual). I'm now
>> always reading the complete contents of /proc/pid/cmdline.
>>
>> - as far as I understand the current implementation, 'arguments()'
>> returns the arguments array WITHOUT 'arg[0]' (which is the program
>> name) but may
>> be we should specify that more clearly in the JavaDoc of 'arguments()'.
>>
>> That's it. Hope you like it :)
>>
>> Regards,
>> Volker
>>
>> On Fri, Jul 31, 2015 at 11:02 PM, Stuart Marks 
>> wrote:
>>
>> Hi Roger, Volker,
>>
>> Glad to see you guys are receptive to this and that it can move forward.
>> Let
>> me know if you'd like me to help out, for example with reviews or
>> something.
>>
>> s'marks
>>
>>
>> On 7/31/15 9:55 AM, Roger Riggs wrote:
>>
>> Hi Volker,
>>
>> I agree that adding an Info.commandline() method would be a good way
>> to make the command line available and be able to describe that it is
>> OS dependent and may be truncated.
>> And having it assemble the command and arguments when they are available
>> makes
>> sense.
>> As an API addition it will need a clear spec and I can run it through
>> CCC
>> so it
>> gets
>> another review and compatibility tests.
>>
>> Thanks, Roger
>>
>>
>>
>>
>> On 7/31/2015 5:03 AM, Volker Simonis wrote:
>>
>> On Fri, Jul 31, 2015 at 2:51 AM, Stuart Marks 
>> wrote:
>>
>> On 7/29/15 11:36 AM, Volker Simonis wrote:
>>
>> !! ProcessHandleImpl_unix: 709-738:  I still disagree with returning
>> truncated or incomplete
>> values for the executable or arguments.
>> Can anyone be a tie-breaker  (with a good rational and suggestion for
>> how
>> an
>> application can use the data).
>>
>> As I wrote, I agree to hear other opinions here.
>>
>> All I want to say that this truncated data is actually what 'ps' is
>> reporting on Solaris since decades and people seem to be happy with
>> it. As use case I can imagine logging or monitoring (something like
>> 'top' in Java) where this data will be just good enough.
>>
>> We could specially mark possibly incomplete data by extending the Info
>> object with functions like commandIsExact() or argumentsIsPrecise().
>> But notice that we can not statically preset these values per
>> platform. For example on Solaris, the 'command()' would return a
>> precise value for processes with the same uid like the VM but only
>> inaccurate values for all other processes. The "arguments()" would be
>> always inaccurate on Solaris/AIX.
>>
>> It seems like there are cases where either exact or only approximate
>> information is available. And as you observed, you might get one or the
>> other on the same platform, depending on the UID. It also might depend
>> on
>> process state; I believe that some information becomes inaccessible when
>> the
>> process enters the zombie state.
>>
>> I don't think we should simply ignore one case or the other, but I also
>> don't think we should try to cram the different information into the
>> same
>> API.
>>
>> The current ProcessHandle.Info api has
>>
>>        Optional command()
>>        Optional arguments()
>>
>> It sounds to me like Roger wants these to contain only exact
>> information.
>> That seems reasonable, and this probably needs to be specified more
>> clearly
>> to contrast with what's below.
>>
>> On Solaris, the psinfo_t struct has char pr_psargs[PRARGSZ] which is a
>> single string which appears to be the concatenation of the arguments
>> (maybe
>> including the command name). It's also truncated to fit PRARGSZ. It
>> doesn't
>> make sense to me to try to return this as a String[], as the zeroth
>> element
>> of that array, and certainly not parsed out into "words". So maybe
>> instead
>> we should have a different API that returns an imprecise command line as
>> a
>> single string:
>>
>>        Optional cmdline()
>>
>> (Naming bikeshed TBS). The semantics would be that this is the process'
>> command and arguments concatenated into a single string (thus
>> potentially
>> losing argument boundaries) and also possibly truncated based on
>> platform
>> (COUGHsolarisCOUGH) limitations. It's certainly useful for printing out
>> in a
>> ps, top, or Activity Monitor style application, for informational
>> purposes.
>>
>> If this were implemented, then on Solaris, command() and arguments()
>> would
>> always return empty optionals.
>>
>> I'm not sure what this should be if the exact information is available.
>> It
>> would be inconvenient if something that just wanted to print out an
>> approximate command line had to check several different APIs to get the
>> information. Maybe cmdline() could assemble the information from exact
>> data
>> if it's is available, by concatenating the Strings from command() and
>> arguments(), as a convenience to the caller. But I could go either way
>> on
>> this.
>>
>> Not sure this counts as a tie-breaker, but it might be a reasonable way
>> forward.
>>
>> s'marks
>>
>> Hi Stuart,
>>
>> thanks a lot for your comments - I like your proposal. For me this
>> sounds like a good compromise.
>>
>> @Roger: should I go and add a new field commandLine and the
>> corresponding getter to the Info class? As Stuart proposed, the getter
>> could check if 'command' and 'arguments' are available and assemble
>> the command line from them. Otherwise it could use the content of the
>> commandLine field if that is available.
>>
>> Regards,
>> Volker
>>
>>
>>
>>



From michael.haupt at oracle.com  Fri Aug 14 17:23:28 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Fri, 14 Aug 2015 10:23:28 -0700
Subject: [9] RFR: 8133543: [TESTBUG]
	java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java
	should be modified
In-Reply-To: <55CDC895.8020602@oracle.com>
References: <55CDC895.8020602@oracle.com>
Message-ID: <0871A453-8D9B-4530-8158-A2919F8607EB@oracle.com>

Hi Konstantin,

excellent, thank you. This is a lower-case review, but thumbs up.

Best,

Michael

> Am 14.08.2015 um 03:53 schrieb Konstantin Shefov :
> 
> Hello,
> 
> Please review a test bug fix.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8133543
> Webrev: http://cr.openjdk.java.net/~kshefov/8133543/webrev.00/
> 
> -Konstantin

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 	Oracle is committed to developing practices and products that help protect the environment



From vladimir.x.ivanov at oracle.com  Fri Aug 14 19:29:09 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 14 Aug 2015 12:29:09 -0700
Subject: [9] RFR: 8133543: [TESTBUG]
	java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java
	should be modified
In-Reply-To: <55CDC895.8020602@oracle.com>
References: <55CDC895.8020602@oracle.com>
Message-ID: <55CE4185.9010407@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 8/14/15 3:53 AM, Konstantin Shefov wrote:
> Hello,
>
> Please review a test bug fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8133543
> Webrev: http://cr.openjdk.java.net/~kshefov/8133543/webrev.00/
>
> -Konstantin


From vladimir.x.ivanov at oracle.com  Fri Aug 14 19:29:47 2015
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 14 Aug 2015 12:29:47 -0700
Subject: [9] RFR: 8060717: [TESTBUG] Improve test coverage of
	MethodHandles.explicitCastArguments()
In-Reply-To: <55C9D451.2050107@oracle.com>
References: <55BBA449.1030603@oracle.com>
	<0B7B1F71-0BE3-400E-A6C2-5FD01E13777A@oracle.com>
	<55BF838D.7080202@oracle.com> <55C330D1.80307@oracle.com>
	<55C33FB1.5000708@oracle.com> <55C3740A.10205@oracle.com>
	<55C9D451.2050107@oracle.com>
Message-ID: <55CE41AB.6030605@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 8/11/15 3:54 AM, Konstantin Shefov wrote:
> Kindly reminder.
>
> 06.08.2015 17:49, Konstantin Shefov ?????:
>> Please, look at the modified test
>>
>> http://cr.openjdk.java.net/~kshefov/8060717/webrev.01/
>>
>> -Konstantin
>>
>> On 08/06/2015 02:06 PM, Konstantin Shefov wrote:
>>> Hi Vladimir
>>>
>>> Thanks for reviewing
>>>
>>>
>>> On 08/06/2015 01:02 PM, Vladimir Ivanov wrote:
>>>> Konstantin,
>>>>
>>>> Overall, looks good.
>>>>
>>>> Why do you create a new ClassLoader here and not simply reference
>>>> them directly (they are loaded by application class loader)?
>>> You a right. Because of class loader hierarchy, all "Test*" classes
>>> in this case are loaded by app class loader as an ancestor of url
>>> class loader, so it is the same as just reference them directly.
>>> To make the "Test*" classes loaded by ucl, they need to be outside of
>>> classpath, which will produce extra folders and ".java" files in test
>>> workspace.
>>>
>>> I think non-bcp to bcp test will play just the same role (work with
>>> classes loaded by different class loaders).
>>>
>>> So I will correct the code. I will add BCP-to-non-BCP &
>>> non-BCP-to-BCP cases and remove url classloader.
>>>
>>> -Konstantin
>>>> + public static void testNonBCPRef2Ref() throws Throwable {
>>>> +        String testClassPath = System.getProperty("test.classes",".");
>>>> +        URL[] classpath = {(new
>>>> File(testClassPath)).getCanonicalFile()
>>>> +            .toURI().toURL()};
>>>> +        URLClassLoader ucl = URLClassLoader.newInstance(classpath);
>>>> +        Class testInterface = ucl.loadClass(THIS_CLASS.getSimpleName()
>>>> +                + "$TestInterface");
>>>> +        Class testSuperClass =
>>>> ucl.loadClass(THIS_CLASS.getSimpleName()
>>>> +                + "$TestSuperClass");
>>>> +        Class testSubClass1 = ucl.loadClass(THIS_CLASS.getSimpleName()
>>>> +                + "$TestSubClass1");
>>>>
>>>> I see BCP-to-BCP & non-BCP-to-non-BCP ref-to-ref cases covered. What
>>>> about BCP-to-non-BCP & non-BCP-to-BCP cases?
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 8/3/15 6:06 PM, Konstantin Shefov wrote:
>>>>> Michael, thanks for reviewing!
>>>>>
>>>>> Vladimir, could you take a look, please?
>>>>>
>>>>> -Konstantin
>>>>>
>>>>> On 08/02/2015 05:31 PM, Michael Haupt wrote:
>>>>>> Hi Konstantin,
>>>>>>
>>>>>>> Am 31.07.2015 um 18:37 schrieb Konstantin Shefov
>>>>>>> >>>>>> >:
>>>>>>> Please review a test improvement. Covered more cases for
>>>>>>> MethodHandles.explicitCastArguments().
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060717
>>>>>>> Webrev: http://cr.openjdk.java.net/~kshefov/8060717/webrev.00/
>>>>>>> 
>>>>>>
>>>>>> note that mine is a lower-case review and does not count, but: thumbs
>>>>>> up. The level of detail at which the API is tested improves
>>>>>> significantly with these changes.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Oracle 
>>>>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>>>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>>>>> OracleJava Platform Group | LangTools Team | Nashorn
>>>>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467
>>>>>> Potsdam,
>>>>>> Germany
>>>>>> Green Oracle  Oracle is committed
>>>>>> to developing practices and products that help protect the
>>>>>> environment
>>>>>>
>>>>>>
>>>>>
>>>
>>
>


From henry.jen at oracle.com  Fri Aug 14 20:10:50 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 14 Aug 2015 13:10:50 -0700
Subject: RFR v5 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
Message-ID: 

Hi,

Another minor revision address comments, no real behavior changes except use JLI_StrCmp instead of JLI_StrCCmp in checkArg().

http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v5/webrev/

Cheers,
Henry



From mandy.chung at oracle.com  Fri Aug 14 23:07:52 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 14 Aug 2015 16:07:52 -0700
Subject: RFR v5 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: 
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
	
Message-ID: <7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>


> On Aug 14, 2015, at 1:10 PM, Henry Jen  wrote:
> 
> Hi,
> 
> Another minor revision address comments, no real behavior changes except use JLI_StrCmp instead of JLI_StrCCmp in checkArg().
> 
> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v5/webrev/

main.c
   JLI_PreprocessingArg returns NULL if not @argfile

Would it be better to return JLI_List containing one element as argv[i]?  We want to avoid new/free JLI_List for every argument and maybe a preallocated reusable copy for single element list to use (non-growable)?

 140                 // Shallow free, we reuse the string to avoid copy
 141                 JLI_MemFree(argsInFile->elements);
 142                 JLI_MemFree(argsInFile);

What about adding JLI_List_free(JLI_List sl, boolean shadow)?  This would be useful for the reusable single element list. Same comment applied to cmdtoargs.c

args.c
  You have #define NOT_FOUND -1 but NOT_FOUND is not used else where.

  void JLI_InitArgProcessing(jboolean isJava, jboolean disableArgFile) {
      // for tools, this value remains 0 all the time.
      firstAppArgIndex = isJava ? -1 : 0;

If I understand correctly, firstAppArgIndex set to 0 means that @argfile is disabled.  On the other hand, ENABLE_ARG_FILES is also the flag to enable JDK tools to enable @argfile (disabled by default).  It seems to me that you no longer needs isJava parameter here.  Might be killSwitchOn can be replaced with firstAppArgIndex == 0 case (not sure - will let you think about that.)   killSwitchOn is unclear what it means;  maybe renaming it to disableArgFile?

You may have to try building one tool with ENABLE_ARG_FILES to verify the change.

JLI_PreprocessArg - as mentioned in the comment above, I suggest to have JLI_PreprocessArg to always return a non-null JLI_List and perhaps renaming the method to JLI_ExpandArgumentList

            // We can not just update the idx here because if -jar @file
            // still need expansion of @file to get the argument for -jar

I only skimmed on the tests.
    ArgFileSyntax.java line 167-170: nit: indentation should be 4-space

It might be useful to add a few negative tests to sanity check especially on the quotation.

TestHelper.java has no change - should be reverted.

Mandy



From amaembo at gmail.com  Sat Aug 15 10:15:32 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Sat, 15 Aug 2015 16:15:32 +0600
Subject: Possible long overflow in Collectors.averagingLong and
	LongStream.average
In-Reply-To: <66545950.20150812144716@gmail.com>
References: <66545950.20150812144716@gmail.com>
Message-ID: <1773604773.20150815161532@gmail.com>

Hello!

Just for information: as finite stream size is very unlikely to exceed
Long.MAX_VALUE (and even if exceeds it will take enormous CPU time to
process such stream), the problem can be fixed just by tracking 128
bit sum instead of 64 bit. It's not very difficult to implement it:
just two long values should be used with proper carry. Here's the
sample implementation:

https://gist.github.com/amaembo/1edf2045b687a0ac9db8

Here averageInt and averageLong collectors are implemented which work
exactly like ones available in JDK, but don't overflow. The final
division is implemented using BigDecimal only if long overflow
occurred, thus for non-overflow scenarios the overhead compared to
current implementation is quite low (would be even lower had
Long.compareUnsigned be intrinsified).

Tracking the sum in BigInteger variable would be significantly slower
and require continuous heap allocations as BigInteger is immutable.

With best regards,
Tagir Valeev.

TFV> The following code prints -1 twice, while users would normally expect
TFV> something like 9.223372036854776E18:

TFV> double avg1 = Stream.of(Long.MAX_VALUE, Long.MAX_VALUE).collect(
TFV>                 Collectors.averagingLong(Long::valueOf));
TFV> System.out.println(avg1);

TFV> double avg2 = LongStream.of(Long.MAX_VALUE, Long.MAX_VALUE).average()
TFV>                 .getAsDouble();
TFV> System.out.println(avg2);

TFV> That's because in both cases internally sum is calculated in the long
TFV> variable where it may silently overflow. The documentation for both
TFV> methods says nothing about such possibility. I guess if it's too late
TFV> to fix this behavior, then probably it should be at least properly
TFV> documented?

TFV> With best regards,
TFV> Tagir Valeev.



From henry.jen at oracle.com  Sun Aug 16 23:51:31 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Sun, 16 Aug 2015 16:51:31 -0700
Subject: RFR v5 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
	
	<7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>
Message-ID: <5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>

Thanks for reviewing, comment inline below,

> On Aug 14, 2015, at 4:07 PM, Mandy Chung  wrote:
> 
> 
>> On Aug 14, 2015, at 1:10 PM, Henry Jen  wrote:
>> 
>> Hi,
>> 
>> Another minor revision address comments, no real behavior changes except use JLI_StrCmp instead of JLI_StrCCmp in checkArg().
>> 
>> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v5/webrev/
> 
> main.c
>   JLI_PreprocessingArg returns NULL if not @argfile
> 
> Would it be better to return JLI_List containing one element as argv[i]?  We want to avoid new/free JLI_List for every argument and maybe a preallocated reusable copy for single element list to use (non-growable)?

Only argument with @prefix will be expanded, for any other cases, the function return NULL. This avoid any copy when not necessary. Regular argument is left alone, so that caller will just use the original value.

> 
> 140                 // Shallow free, we reuse the string to avoid copy
> 141                 JLI_MemFree(argsInFile->elements);
> 142                 JLI_MemFree(argsInFile);
> 
> What about adding JLI_List_free(JLI_List sl, boolean shadow)?  This would be useful for the reusable single element list. Same comment applied to cmdtoargs.c
> 

Thought of that, but decided to keep in place for clarity. When move into a function, then we want to check for NULL, and ask  how shallow the free is, do we keep the array but free the list or both?

> args.c
>  You have #define NOT_FOUND -1 but NOT_FOUND is not used else where.
> 

Used right under to initialize firstAppArgIndex, and should be used in following statement you shown.

>  void JLI_InitArgProcessing(jboolean isJava, jboolean disableArgFile) {
>      // for tools, this value remains 0 all the time.
>      firstAppArgIndex = isJava ? -1 : 0;
> 
> If I understand correctly, firstAppArgIndex set to 0 means that @argfile is disabled.  On the other hand, ENABLE_ARG_FILES is also the flag to enable JDK tools to enable @argfile (disabled by default).  It seems to me that you no longer needs isJava parameter here.

firstAppArgIndex is the first index of user?s application argument, has nothing to do with disable @argfile. This value remains 0 for launcher-based tools, and returned by JLI_GetAppArgIndex().

A tools can have ENABLE_ARG_FILES to enable argument expansion, but we still need to know it?s a launcher-based tool.

>  Might be killSwitchOn can be replaced with firstAppArgIndex == 0 case (not sure - will let you think about that.)   killSwitchOn is unclear what it means;  maybe renaming it to disableArgFile?
> 

As explained earlier, firstAppArgIndex is different. We can rename killSwitchOn, it was clear as we discussed kill switch, the -X:disable- at files option. disableArgFile is used as the function argument, thus I left them as is.

> You may have to try building one tool with ENABLE_ARG_FILES to verify the change.

java is built with the flag. Others are not. I tested with javac before the flag is reversed, so we know the flag is working.

> 
> JLI_PreprocessArg - as mentioned in the comment above, I suggest to have JLI_PreprocessArg to always return a non-null JLI_List and perhaps renaming the method to JLI_ExpandArgumentList
> 

NULL is better than non-NULL copy so that we don?t need to copy the argument or check content when it?s not @ prefixed.
The function was named JLI_ExpandArgumentList, later renamed to current form as it also check each argument to determine the location of first user argument for main class.

>            // We can not just update the idx here because if -jar @file
>            // still need expansion of @file to get the argument for -jar
> 
> I only skimmed on the tests.
>    ArgFileSyntax.java line 167-170: nit: indentation should be 4-space
> 

You are right, thanks. When I was making those changes, I noted the editor changed something, but didn?t realize it?s the indentation.

> It might be useful to add a few negative tests to sanity check especially on the quotation.
> 

Make sense. Do you mean test cases that will fail launch of java?

> TestHelper.java has no change - should be reverted.
> 

It has two minor indentation clean up, I can revert them, but think since we were here, perhaps just fix it.

Cheers,
Henry

From henry.jen at oracle.com  Mon Aug 17 14:10:48 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 17 Aug 2015 07:10:48 -0700
Subject: RFR v5 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
	
	<7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>
	<5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>
Message-ID: 


> On Aug 16, 2015, at 4:51 PM, Henry Jen  wrote:
> 
> Thanks for reviewing, comment inline below,
> 
>> On Aug 14, 2015, at 4:07 PM, Mandy Chung  wrote:
>> 
>> 
>>> On Aug 14, 2015, at 1:10 PM, Henry Jen  wrote:
>>> 
>>> Hi,
>>> 
>>> Another minor revision address comments, no real behavior changes except use JLI_StrCmp instead of JLI_StrCCmp in checkArg().
>>> 
>>> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v5/webrev/
>> 
>> main.c
>>  JLI_PreprocessingArg returns NULL if not @argfile
>> 
>> Would it be better to return JLI_List containing one element as argv[i]?  We want to avoid new/free JLI_List for every argument and maybe a preallocated reusable copy for single element list to use (non-growable)?
> 
> Only argument with @prefix will be expanded, for any other cases, the function return NULL. This avoid any copy when not necessary. Regular argument is left alone, so that caller will just use the original value.

I think I may be talking at a different thing, guess you meant the make JLI_List JLI_PreprocessArg(const char*) to void JLI_PreprocessArg(JLI_List, const char*) and pass in a list to hold all the arguments.

That is reasonable. Considered that but didn?t do it eventually because not much benefits and hide the ?expansion? fact. Since now you mentioned this, it probably worth to do it that way.

Cheers,
Henry




From henry.jen at oracle.com  Mon Aug 17 15:00:32 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 17 Aug 2015 08:00:32 -0700
Subject: RFR v5 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: 
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
	
	<7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>
	<5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>
	
Message-ID: <530BD95D-3B01-4A47-B4D8-7FD9E83C80CD@oracle.com>

On Aug 17, 2015, at 7:10 AM, Henry Jen  wrote:
> 
>> 
>> On Aug 16, 2015, at 4:51 PM, Henry Jen  wrote:
>> 
>> Thanks for reviewing, comment inline below,
>> 
>>> On Aug 14, 2015, at 4:07 PM, Mandy Chung  wrote:
>>> 
>>> 
>>>> On Aug 14, 2015, at 1:10 PM, Henry Jen  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Another minor revision address comments, no real behavior changes except use JLI_StrCmp instead of JLI_StrCCmp in checkArg().
>>>> 
>>>> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v5/webrev/
>>> 
>>> main.c
>>> JLI_PreprocessingArg returns NULL if not @argfile
>>> 
>>> Would it be better to return JLI_List containing one element as argv[i]?  We want to avoid new/free JLI_List for every argument and maybe a preallocated reusable copy for single element list to use (non-growable)?
>> 
>> Only argument with @prefix will be expanded, for any other cases, the function return NULL. This avoid any copy when not necessary. Regular argument is left alone, so that caller will just use the original value.
> 
> I think I may be talking at a different thing, guess you meant the make JLI_List JLI_PreprocessArg(const char*) to void JLI_PreprocessArg(JLI_List, const char*) and pass in a list to hold all the arguments.
> 
> That is reasonable. Considered that but didn?t do it eventually because not much benefits and hide the ?expansion? fact. Since now you mentioned this, it probably worth to do it that way.
> 

Now I remember another reason I didn?t do it, because of the wildcard processing in cmdtoargs.c. I don?t want to convert every platform to use StdArg or maintain different version of PreprocesArgs.

I am going to leave it as it.

Cheers,
Henry



From mandy.chung at oracle.com  Mon Aug 17 21:04:21 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 17 Aug 2015 14:04:21 -0700
Subject: RFR v5 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <530BD95D-3B01-4A47-B4D8-7FD9E83C80CD@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
	
	<7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>
	<5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>
	
	<530BD95D-3B01-4A47-B4D8-7FD9E83C80CD@oracle.com>
Message-ID: <55D24C55.60006@oracle.com>



On 08/17/2015 08:00 AM, Henry Jen wrote:
> On Aug 17, 2015, at 7:10 AM, Henry Jen  wrote:
>> I think I may be talking at a different thing, guess you meant the make JLI_List JLI_PreprocessArg(const char*) to void JLI_PreprocessArg(JLI_List, const char*) and pass in a list to hold all the arguments.
>>
>> That is reasonable. Considered that but didn?t do it eventually because not much benefits and hide the ?expansion? fact. Since now you mentioned this, it probably worth to do it that way.
>>
> Now I remember another reason I didn?t do it, because of the wildcard processing in cmdtoargs.c. I don?t want to convert every platform to use StdArg or maintain different version of PreprocesArgs.

My suggestion is to keep JLI_PreprocessArg(const char* arg) is to return 
a non-null JLI_List.  If the given arg is not @argfile, you return a 
static preallocated JLI_List with one single element and element[0] = 
JLI_StringDup(arg).

The change in main.c and cmdtoargs.c add the arguments in either a 
JLI_List or StdArg.  For the non- at argfile case, you need to do 
JLI_StringDup explicitly.  For @argfile case, JLI_StringDup is done 
before it returns JLI_List. I also suggest to add 
JLI_FreeList(JLI_List*, boolean shallow_free) that should special case 
the static preallocated JLI_List to clear the count and element and not 
to free that list.

I think that will simplify the code.

Mandy



From mandy.chung at oracle.com  Tue Aug 18 03:45:12 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 17 Aug 2015 20:45:12 -0700
Subject: RFR v5 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
	
	<7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>
	<5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>
Message-ID: <42494833-F0BF-43BF-AE85-F21D068D19FE@oracle.com>


> On Aug 16, 2015, at 4:51 PM, Henry Jen  wrote:
> 
> 
>> args.c
>> You have #define NOT_FOUND -1 but NOT_FOUND is not used else where.
>> 
> 
> Used right under to initialize firstAppArgIndex, and should be used in following statement you shown.

Please change that.

> 
>> void JLI_InitArgProcessing(jboolean isJava, jboolean disableArgFile) {
>>     // for tools, this value remains 0 all the time.
>>     firstAppArgIndex = isJava ? -1 : 0;
>> 
>> If I understand correctly, firstAppArgIndex set to 0 means that @argfile is disabled.  On the other hand, ENABLE_ARG_FILES is also the flag to enable JDK tools to enable @argfile (disabled by default).  It seems to me that you no longer needs isJava parameter here.
> 
> firstAppArgIndex is the first index of user?s application argument, has nothing to do with disable @argfile. This value remains 0 for launcher-based tools, and returned by JLI_GetAppArgIndex().
> 
> A tools can have ENABLE_ARG_FILES to enable argument expansion, but we still need to know it?s a launcher-based tool.


OK.   firstAppArgIndex is not used in the parsing.


> 
>> Might be killSwitchOn can be replaced with firstAppArgIndex == 0 case (not sure - will let you think about that.)   killSwitchOn is unclear what it means;  maybe renaming it to disableArgFile?
>> 
> 
> As explained earlier, firstAppArgIndex is different. We can rename killSwitchOn, it was clear as we discussed kill switch, the -X:disable- at files option. disableArgFile is used as the function argument, thus I left them as is.
> 

It?s better to rename killSwitchOn to match what it means.

>> You may have to try building one tool with ENABLE_ARG_FILES to verify the change.
> 
> java is built with the flag. Others are not. I tested with javac before the flag is reversed, so we know the flag is working.

That?s good.  I re-read that piece of code and that looks fine.


> 
>> It might be useful to add a few negative tests to sanity check especially on the quotation.
>> 
> 
> Make sense. Do you mean test cases that will fail launch of java?

Yes.

Mandy



From henry.jen at oracle.com  Tue Aug 18 04:15:27 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Mon, 17 Aug 2015 21:15:27 -0700
Subject: RFR v6 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <42494833-F0BF-43BF-AE85-F21D068D19FE@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
	
	<7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>
	<5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>
	<42494833-F0BF-43BF-AE85-F21D068D19FE@oracle.com>
Message-ID: <525D3FA5-0CB4-4E0E-8D42-FA5CA4809073@oracle.com>


> On Aug 17, 2015, at 8:45 PM, Mandy Chung  wrote:
> 
> OK.   firstAppArgIndex is not used in the parsing.

It is set in args.c:127, and stop expansion on line 369.

v6 is available at 

http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v6/webrev/

Changes based on Mandy?s comment,

- add a new test, basCases, which not escaping backslash properly and cause an open quote and failed java in ArgFileSyntac.java
- rename killSwitchOn to stopExpansion in args.c
- change to use NOT_FOUND at args.c:87
- fix indentation at  ArgFileSyntax.java line 167-170

Cheers,
Henry




From alexander.v.stepanov at oracle.com  Tue Aug 18 11:50:24 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Tue, 18 Aug 2015 14:50:24 +0300
Subject: RFR [9] 8132478: [tidy] three new warnings from java docs (java.net, 
	javax.annotation)
Message-ID: <55D31C00.202@oracle.com>

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8132478/jdk.00/index.html
http://cr.openjdk.java.net/~avstepan/8132478/jaxws.00/index.html
for
https://bugs.openjdk.java.net/browse/JDK-8132478

Just a minor fix for docs (a few tidy warnings + some invalid tags).

Thanks,
Alexander


From lance.andersen at oracle.com  Tue Aug 18 11:56:54 2015
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Tue, 18 Aug 2015 07:56:54 -0400
Subject: RFR [9] 8132478: [tidy] three new warnings from java docs
	(java.net, javax.annotation)
In-Reply-To: <55D31C00.202@oracle.com>
References: <55D31C00.202@oracle.com>
Message-ID: 

Hi Alexander 

Looks ok but you will need to make sure the jaxws changes get pushed to the standalone project as well

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
Sent from my iPad

> On Aug 18, 2015, at 7:50 AM, Alexander Stepanov  wrote:
> 
> Hello,
> 
> Could you please review the following fix
> http://cr.openjdk.java.net/~avstepan/8132478/jdk.00/index.html
> http://cr.openjdk.java.net/~avstepan/8132478/jaxws.00/index.html
> for
> https://bugs.openjdk.java.net/browse/JDK-8132478
> 
> Just a minor fix for docs (a few tidy warnings + some invalid tags).
> 
> Thanks,
> Alexander


From alexander.v.stepanov at oracle.com  Tue Aug 18 12:37:58 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Tue, 18 Aug 2015 15:37:58 +0300
Subject: RFR [9] 8132478: [tidy] three new warnings from java docs
	(java.net, javax.annotation)
In-Reply-To: 
References: <55D31C00.202@oracle.com>
	
Message-ID: <55D32726.2070306@oracle.com>

Hello Lance,

Thanks!

Regards,
Alexander

On 8/18/2015 2:56 PM, Lance @ Oracle wrote:
> Hi Alexander
>
> Looks ok but you will need to make sure the jaxws changes get pushed 
> to the standalone project as well
>
> 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 
> Sent from my iPad
>
> On Aug 18, 2015, at 7:50 AM, Alexander Stepanov 
>  > wrote:
>
>> Hello,
>>
>> Could you please review the following fix
>> http://cr.openjdk.java.net/~avstepan/8132478/jdk.00/index.html 
>> 
>> http://cr.openjdk.java.net/~avstepan/8132478/jaxws.00/index.html 
>> 
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8132478
>>
>> Just a minor fix for docs (a few tidy warnings + some invalid tags).
>>
>> Thanks,
>> Alexander



From kumar.x.srinivasan at oracle.com  Tue Aug 18 14:58:54 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 18 Aug 2015 07:58:54 -0700
Subject: RFR v6 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <525D3FA5-0CB4-4E0E-8D42-FA5CA4809073@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
	
	<7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>
	<5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>
	<42494833-F0BF-43BF-AE85-F21D068D19FE@oracle.com>
	<525D3FA5-0CB4-4E0E-8D42-FA5CA4809073@oracle.com>
Message-ID: <55D3482E.2000305@oracle.com>


I think using StdArg across all platforms will make the JLI_List management
neater, and solve other issues, but that is an orthogonal fix.

Kumar

>> On Aug 17, 2015, at 8:45 PM, Mandy Chung  wrote:
>>
>> OK.   firstAppArgIndex is not used in the parsing.
> It is set in args.c:127, and stop expansion on line 369.
>
> v6 is available at
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v6/webrev/
>
> Changes based on Mandy?s comment,
>
> - add a new test, basCases, which not escaping backslash properly and cause an open quote and failed java in ArgFileSyntac.java
> - rename killSwitchOn to stopExpansion in args.c
> - change to use NOT_FOUND at args.c:87
> - fix indentation at  ArgFileSyntax.java line 167-170
>
> Cheers,
> Henry
>
>



From mandy.chung at oracle.com  Tue Aug 18 18:00:53 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 18 Aug 2015 11:00:53 -0700
Subject: RFR v6 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <525D3FA5-0CB4-4E0E-8D42-FA5CA4809073@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
	
	<7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>
	<5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>
	<42494833-F0BF-43BF-AE85-F21D068D19FE@oracle.com>
	<525D3FA5-0CB4-4E0E-8D42-FA5CA4809073@oracle.com>
Message-ID: <55D372D5.5030907@oracle.com>



On 08/17/2015 09:15 PM, Henry Jen wrote:
> v6 is available at
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v6/webrev/

Thanks for the update.  Looks fine.

Mandy


From joe.darcy at oracle.com  Tue Aug 18 18:39:31 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 18 Aug 2015 11:39:31 -0700
Subject: JDK 9 RFR of JDK-8133808: Place java/lang/ProcessHandle/InfoTest.java
	on the Problem List
Message-ID: <55D37BE3.6070602@oracle.com>

Hello,

The test

      java/lang/ProcessHandle/InfoTest.java

has been observed to fail intermittent and now with greater frequency on 
some system with the current HotSpot changes.

While the underlying issues are being sorted out (JDK-8133552), it would 
be helpful to mark the test as intermittently failing and to place it on 
the problem list:

diff -r 0940ce86c614 test/ProblemList.txt
--- a/test/ProblemList.txt    Thu Aug 13 21:46:05 2015 -0700
+++ b/test/ProblemList.txt    Tue Aug 18 11:37:58 2015 -0700
@@ -129,6 +129,9 @@
  # 8029891
  java/lang/ClassLoader/deadlock/GetResource.java generic-all

+# 8133552
+java/lang/ProcessHandle/InfoTest.java generic-all
+
  ############################################################################

  # jdk_instrument
diff -r 0940ce86c614 test/java/lang/ProcessHandle/InfoTest.java
--- a/test/java/lang/ProcessHandle/InfoTest.java    Thu Aug 13 21:46:05 
2015 -0700
+++ b/test/java/lang/ProcessHandle/InfoTest.java    Tue Aug 18 11:37:58 
2015 -0700
@@ -49,10 +49,12 @@

  /*
   * @test
+ * @bug 8077350 8081566 8081567 8098852
   * @build jdk.testlibrary.*
   * @library /lib/testlibrary
   * @summary Functions of ProcessHandle.Info
   * @author Roger Riggs
+ * @key intermittent
   */

  public class InfoTest {

Thanks,

-Joe


From lance.andersen at oracle.com  Tue Aug 18 18:41:54 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 18 Aug 2015 14:41:54 -0400
Subject: JDK 9 RFR of JDK-8133808: Place
	java/lang/ProcessHandle/InfoTest.java on the Problem List
In-Reply-To: <55D37BE3.6070602@oracle.com>
References: <55D37BE3.6070602@oracle.com>
Message-ID: <6D344153-0651-4C82-9D9F-2F155FB78387@oracle.com>

makes sense to me
On Aug 18, 2015, at 2:39 PM, joe darcy  wrote:

> Hello,
> 
> The test
> 
>     java/lang/ProcessHandle/InfoTest.java
> 
> has been observed to fail intermittent and now with greater frequency on some system with the current HotSpot changes.
> 
> While the underlying issues are being sorted out (JDK-8133552), it would be helpful to mark the test as intermittently failing and to place it on the problem list:
> 
> diff -r 0940ce86c614 test/ProblemList.txt
> --- a/test/ProblemList.txt    Thu Aug 13 21:46:05 2015 -0700
> +++ b/test/ProblemList.txt    Tue Aug 18 11:37:58 2015 -0700
> @@ -129,6 +129,9 @@
> # 8029891
> java/lang/ClassLoader/deadlock/GetResource.java generic-all
> 
> +# 8133552
> +java/lang/ProcessHandle/InfoTest.java generic-all
> +
> ############################################################################
> 
> # jdk_instrument
> diff -r 0940ce86c614 test/java/lang/ProcessHandle/InfoTest.java
> --- a/test/java/lang/ProcessHandle/InfoTest.java    Thu Aug 13 21:46:05 2015 -0700
> +++ b/test/java/lang/ProcessHandle/InfoTest.java    Tue Aug 18 11:37:58 2015 -0700
> @@ -49,10 +49,12 @@
> 
> /*
>  * @test
> + * @bug 8077350 8081566 8081567 8098852
>  * @build jdk.testlibrary.*
>  * @library /lib/testlibrary
>  * @summary Functions of ProcessHandle.Info
>  * @author Roger Riggs
> + * @key intermittent
>  */
> 
> public class InfoTest {
> 
> Thanks,
> 
> -Joe



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





From mandy.chung at oracle.com  Wed Aug 19 02:26:44 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 18 Aug 2015 19:26:44 -0700
Subject: Review request: 8132944: test
	java/lang/ClassLoader/GetSystemPackage.java writes stuff to
	Agent stdout
Message-ID: <75504BCC-2E04-4B06-9EF0-A624702CEFD5@oracle.com>

A trivial one - this takes out the unnecessary debug statement to clean up the test output.

diff --git a/test/java/lang/ClassLoader/GetSystemPackage.java b/test/java/lang/ClassLoader/GetSystemPackage.java
--- a/test/java/lang/ClassLoader/GetSystemPackage.java
+++ b/test/java/lang/ClassLoader/GetSystemPackage.java
@@ -181,7 +181,6 @@
     private static Package findPackage(String name) {
         Package[] packages = Package.getPackages();
         for (Package p : packages) {
-            System.out.println(p);
             if (p.getName().equals(name)) {
                 return p;
             }

Mandy

From david.holmes at oracle.com  Wed Aug 19 03:03:42 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 19 Aug 2015 13:03:42 +1000
Subject: Review request: 8132944: test
	java/lang/ClassLoader/GetSystemPackage.java writes stuff to Agent
	stdout
In-Reply-To: <75504BCC-2E04-4B06-9EF0-A624702CEFD5@oracle.com>
References: <75504BCC-2E04-4B06-9EF0-A624702CEFD5@oracle.com>
Message-ID: <55D3F20E.3050804@oracle.com>

Looks fine Mandy!

Thanks,
David

On 19/08/2015 12:26 PM, Mandy Chung wrote:
> A trivial one - this takes out the unnecessary debug statement to clean up the test output.
>
> diff --git a/test/java/lang/ClassLoader/GetSystemPackage.java b/test/java/lang/ClassLoader/GetSystemPackage.java
> --- a/test/java/lang/ClassLoader/GetSystemPackage.java
> +++ b/test/java/lang/ClassLoader/GetSystemPackage.java
> @@ -181,7 +181,6 @@
>       private static Package findPackage(String name) {
>           Package[] packages = Package.getPackages();
>           for (Package p : packages) {
> -            System.out.println(p);
>               if (p.getName().equals(name)) {
>                   return p;
>               }
>
> Mandy
>


From ivan.gerasimov at oracle.com  Wed Aug 19 14:57:58 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 19 Aug 2015 17:57:58 +0300
Subject: RFR/RFA (8u-dev) 8133253: [TESTBUG]
	java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java
	fails on compact profile
Message-ID: <55D49976.20908@oracle.com>

Hi!

The test FieldSetAccessibleTest.java fails when testing with compact3 
even after fixing JDK-8080524.
The reason is that the test tries to access classes which are only 
available in full jdk.

The proposed fix is to include the test in the corresponding group in 
TEST.groups file.
Would you please help review the fix and approve pushing it into 
jdk8u-dev repo?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8133253
WEBREV: http://cr.openjdk.java.net/~igerasim/8133253/00/webrev/

Sincerely yours,
Ivan


From miroslav.kos at oracle.com  Wed Aug 19 15:37:47 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Wed, 19 Aug 2015 17:37:47 +0200
Subject: [9] Review request JDK-8131667: JAX-WS Plugability Layer: using
	java.util.ServiceLoader
Message-ID: <55D4A2CB.70900@oracle.com>

Hi everybody,

I am sending changes for review.

CCC: http://ccc.us.oracle.com/8131667
JBS: https://bugs.openjdk.java.net/browse/JDK-8131667
webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.01/

It's about migrating to standard java.util.ServiceLoader. This part of 
service discovery was implemented previously "own" way. There are some 
changes in javadoc and implementation has been refactored in order to 
use same code as is in JAX-B and SAAJ.

Testing - I run JAX-WS unit tests (JAX-WS standalone repo), JCK9 + new 
tests specificaly developed for testing service discovery in JAX-WS.

Thanks
Miran




From Sergey.Bylokhov at oracle.com  Wed Aug 19 15:38:03 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 19 Aug 2015 18:38:03 +0300
Subject: LittleEndian in DataInputStream
Message-ID: <55D4A2DB.1060001@oracle.com>

Hello,
Does anybody know, do we plan to add LittleEndian support to the 
DataInputStream or probably to some other InputStream?

-- 
Best regards, Sergey.



From rob.mckenna at oracle.com  Wed Aug 19 17:33:27 2015
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 19 Aug 2015 18:33:27 +0100
Subject: RFR/RFA (8u-dev) 8133253: [TESTBUG]
	java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java
	fails on compact profile
In-Reply-To: <55D49976.20908@oracle.com>
References: <55D49976.20908@oracle.com>
Message-ID: <55D4BDE7.2080506@oracle.com>

Approved pending positive codrereview.

	-Rob

On 19/08/15 15:57, Ivan Gerasimov wrote:
> Hi!
>
> The test FieldSetAccessibleTest.java fails when testing with compact3
> even after fixing JDK-8080524.
> The reason is that the test tries to access classes which are only
> available in full jdk.
>
> The proposed fix is to include the test in the corresponding group in
> TEST.groups file.
> Would you please help review the fix and approve pushing it into
> jdk8u-dev repo?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8133253
> WEBREV: http://cr.openjdk.java.net/~igerasim/8133253/00/webrev/
>
> Sincerely yours,
> Ivan


From c.artho at aist.go.jp  Tue Aug 11 04:13:29 2015
From: c.artho at aist.go.jp (Cyrille Artho)
Date: Tue, 11 Aug 2015 13:13:29 +0900
Subject: Reponse to bug report (spurious
	ConcurrentModificationException in ArrayList)
Message-ID: <55C97669.3000203@aist.go.jp>

Dear all,
I'd like to write a response to my bug report at
https://bugs.openjdk.java.net/browse/JDK-8114832
but I didn't get an OpenJDK login when I submitted the report.

In this particular case, it should be noted that my test was minimal. If 
one has at least one element in the list before the iterator is created, 
then it.next() throws no exception when used on any collection except 
ArrayList/Stack/Vector.

This means that ArrayList and its legacy brethren are the only classes 
that generate a spurious exception, and only after list.remove(-1) was 
called before using the iterator. The spurious exception prevents future 
access to data where other containers work as expected.

Currently it is being considered to keep the current (faulty) behavior, 
but based on the new test case, I strongly advise correcting this bug.

With the new test case, the information about the bug becomes:

EXPECTED -
it.next() returns 42
ACTUAL -
ConcurrentModificationException

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.ArrayList;
import java.util.LinkedList;
import java.util.ConcurrentModificationException;
import java.util.Iterator;
import java.util.NoSuchElementException;

public class iterator_test {
    public static void main(String[] argv) {
      /* BUG: Sequence of arrayList.iterator,
         arrayList.add(new Integer(1)),
         arrayList.remove(-1),
         iterator.next
         produces ConcurrentModificationException. */
      ArrayList testArrayList = new ArrayList();
      testArrayList.add(new Integer(42));
      Iterator it = testArrayList.iterator();
      try {
        testArrayList.remove(-1);
      } catch (IndexOutOfBoundsException e) {
      }
      try {
        Integer result = it.next();
        assert(result == 42);
      } catch (ConcurrentModificationException e) {
        System.err.println("Should be 42!");
      }
    }
}

---------- END SOURCE ----------
-- 
Regards,
Cyrille Artho - http://artho.com/
Those who will not reason, are bigots, those who cannot,
are fools, and those who dare not, are slaves.
		-- George Gordon Noel Byron


From bhorstman at mimsoftware.com  Wed Aug 12 15:29:46 2015
From: bhorstman at mimsoftware.com (Ben Horstman)
Date: Wed, 12 Aug 2015 11:29:46 -0400 (EDT)
Subject: Documentation nit for JDK-8023862
Message-ID: <830328362.4117015.1439393386453.JavaMail.zimbra@mimsoftware.com>

According to JDK-8023862, system property "java.rmi.server.disableHttp" is true in Java 8 (i.e., proxy is disabled by default).  

However, the java.rmi properties page still lists the value as false: http://docs.oracle.com/javase/8/docs/technotes/guides/rmi/javarmiproperties.html .  I think that page should be updated to indicate the new default value of true.

Regards,
~benjamin

************************
Benjamin Philip Horstman
Software Lead - Rho Team
MIM Software Inc.


From withoutpointk at gmail.com  Sat Aug 15 17:27:47 2015
From: withoutpointk at gmail.com (Adrian)
Date: Sat, 15 Aug 2015 13:27:47 -0400
Subject: Unneeded size/fstat system call in
	sun.nio.ch.FileChannelImpl#transferTo for linux?
Message-ID: 

Hello,

I was looking at FileChannelImpl#transferTo, and noticed there were
always two system calls - fstat and sendfile.
Looking the source code (e.g.
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/sun/nio/ch/FileChannelImpl.java#FileChannelImpl.transferTo%28long%2Clong%2Cjava.nio.channels.WritableByteChannel%29),
the JVM checks that the position is not past the end of the file to
read.

On Linux, the size translates to a fstat system call, and the native
function transferTo0 translates to a sendfile system call, and I
believe sendfile already checks the offsets and will only read as many
bytes as available, similar to the read system call.

As of linux 2.6.23, sendfile is implemented using splice.
Just following the latest source for example:
- sendfile (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/fs/read_write.c?id=HEAD)
- do_sendfile
- do_splice_direct
(http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/fs/splice.c?id=HEAD)
- splice_direct_to_actor
- do_splice_to
- default_file_splice_read
- kernel_readv
- vfs_readv (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/fs/read_write.c?id=HEAD)

Which is the same vfs_readv used when defining the read system call
I didn't find the exact code where it checks the position and length,
as vfs_readv calls file->f_op->read, but:
- the read system call (which also uses vfs_readv) is documented as
"attempting to read up to count bytes"
- all the code uses the return value as the "actual length", not the
parameter passed in
- the man page for splice says it returns "the number of bytes spliced
to/from the pipe"

Manually testing this on linux and OSX seems to confirm the behaviour
(that manually checking the position/length is unnecessary because
sendfile/splice will only return how many bytes it managed to
read/write) - by calling sendfile with an offset beyond EOF (returns
0) or with a count size larger than the size of the file (returns
number of bytes left).

I also looked at the JVM windows source, which uses the TransmitFile API.
I didn't look into this in detail - the docs are unclear, but it seems
you will only get an error if the number of bytes to send is greater
than 2 ^ 31 - 1

Doing some benchmarks with a 64KB buffer/transfer size (compiling
minimally modified JDK), FileChannelImpl#size averaged ~12us, and
FileChannelImpl#transferToDirectly averaged ~33us.
The whole FileChannelImpl#transferTo took ~48us.
I know microbenchmarks need to be done very carefully, but I think it
gives a general idea of the performance impact for something that
should be (?) unecessary

Of course, I could be wrong, or more needs to be considered, but I
thought it was worth bringing up and get some feedback.
Maybe someone could confirm the behaviour of sendfile/splice, or
explain the reasoning for checking the size in the JVM?

Thank you for your time!

Best regards,
Adrian


From david.holmes at oracle.com  Thu Aug 20 05:02:00 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 Aug 2015 15:02:00 +1000
Subject: Reponse to bug report (spurious ConcurrentModificationException
	in ArrayList)
In-Reply-To: <55C97669.3000203@aist.go.jp>
References: <55C97669.3000203@aist.go.jp>
Message-ID: <55D55F48.5030605@oracle.com>

Hi,

I've added the information below to the bug report for you.

David

On 11/08/2015 2:13 PM, Cyrille Artho wrote:
> Dear all,
> I'd like to write a response to my bug report at
> https://bugs.openjdk.java.net/browse/JDK-8114832
> but I didn't get an OpenJDK login when I submitted the report.
>
> In this particular case, it should be noted that my test was minimal. If
> one has at least one element in the list before the iterator is created,
> then it.next() throws no exception when used on any collection except
> ArrayList/Stack/Vector.
>
> This means that ArrayList and its legacy brethren are the only classes
> that generate a spurious exception, and only after list.remove(-1) was
> called before using the iterator. The spurious exception prevents future
> access to data where other containers work as expected.
>
> Currently it is being considered to keep the current (faulty) behavior,
> but based on the new test case, I strongly advise correcting this bug.
>
> With the new test case, the information about the bug becomes:
>
> EXPECTED -
> it.next() returns 42
> ACTUAL -
> ConcurrentModificationException
>
> REPRODUCIBILITY :
> This bug can be reproduced always.
>
> ---------- BEGIN SOURCE ----------
> import java.util.ArrayList;
> import java.util.LinkedList;
> import java.util.ConcurrentModificationException;
> import java.util.Iterator;
> import java.util.NoSuchElementException;
>
> public class iterator_test {
>     public static void main(String[] argv) {
>       /* BUG: Sequence of arrayList.iterator,
>          arrayList.add(new Integer(1)),
>          arrayList.remove(-1),
>          iterator.next
>          produces ConcurrentModificationException. */
>       ArrayList testArrayList = new ArrayList();
>       testArrayList.add(new Integer(42));
>       Iterator it = testArrayList.iterator();
>       try {
>         testArrayList.remove(-1);
>       } catch (IndexOutOfBoundsException e) {
>       }
>       try {
>         Integer result = it.next();
>         assert(result == 42);
>       } catch (ConcurrentModificationException e) {
>         System.err.println("Should be 42!");
>       }
>     }
> }
>
> ---------- END SOURCE ----------


From david.holmes at oracle.com  Thu Aug 20 05:11:32 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 Aug 2015 15:11:32 +1000
Subject: RFR/RFA (8u-dev) 8133253: [TESTBUG]
	java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on
	compact profile
In-Reply-To: <55D49976.20908@oracle.com>
References: <55D49976.20908@oracle.com>
Message-ID: <55D56184.5040502@oracle.com>

On 20/08/2015 12:57 AM, Ivan Gerasimov wrote:
> Hi!
>
> The test FieldSetAccessibleTest.java fails when testing with compact3
> even after fixing JDK-8080524.

Why wasn't that determined at the time?

> The reason is that the test tries to access classes which are only
> available in full jdk.
>
> The proposed fix is to include the test in the corresponding group in
> TEST.groups file.

Fix seems fine.

Thanks,
David

> Would you please help review the fix and approve pushing it into
> jdk8u-dev repo?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8133253
> WEBREV: http://cr.openjdk.java.net/~igerasim/8133253/00/webrev/
>
> Sincerely yours,
> Ivan


From david.holmes at oracle.com  Thu Aug 20 05:14:21 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 Aug 2015 15:14:21 +1000
Subject: Unneeded size/fstat system call in
	sun.nio.ch.FileChannelImpl#transferTo for linux?
In-Reply-To: 
References: 
Message-ID: <55D5622D.9060102@oracle.com>

Redirecting to NIO-dev

david

On 16/08/2015 3:27 AM, Adrian wrote:
> Hello,
>
> I was looking at FileChannelImpl#transferTo, and noticed there were
> always two system calls - fstat and sendfile.
> Looking the source code (e.g.
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/sun/nio/ch/FileChannelImpl.java#FileChannelImpl.transferTo%28long%2Clong%2Cjava.nio.channels.WritableByteChannel%29),
> the JVM checks that the position is not past the end of the file to
> read.
>
> On Linux, the size translates to a fstat system call, and the native
> function transferTo0 translates to a sendfile system call, and I
> believe sendfile already checks the offsets and will only read as many
> bytes as available, similar to the read system call.
>
> As of linux 2.6.23, sendfile is implemented using splice.
> Just following the latest source for example:
> - sendfile (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/fs/read_write.c?id=HEAD)
> - do_sendfile
> - do_splice_direct
> (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/fs/splice.c?id=HEAD)
> - splice_direct_to_actor
> - do_splice_to
> - default_file_splice_read
> - kernel_readv
> - vfs_readv (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/fs/read_write.c?id=HEAD)
>
> Which is the same vfs_readv used when defining the read system call
> I didn't find the exact code where it checks the position and length,
> as vfs_readv calls file->f_op->read, but:
> - the read system call (which also uses vfs_readv) is documented as
> "attempting to read up to count bytes"
> - all the code uses the return value as the "actual length", not the
> parameter passed in
> - the man page for splice says it returns "the number of bytes spliced
> to/from the pipe"
>
> Manually testing this on linux and OSX seems to confirm the behaviour
> (that manually checking the position/length is unnecessary because
> sendfile/splice will only return how many bytes it managed to
> read/write) - by calling sendfile with an offset beyond EOF (returns
> 0) or with a count size larger than the size of the file (returns
> number of bytes left).
>
> I also looked at the JVM windows source, which uses the TransmitFile API.
> I didn't look into this in detail - the docs are unclear, but it seems
> you will only get an error if the number of bytes to send is greater
> than 2 ^ 31 - 1
>
> Doing some benchmarks with a 64KB buffer/transfer size (compiling
> minimally modified JDK), FileChannelImpl#size averaged ~12us, and
> FileChannelImpl#transferToDirectly averaged ~33us.
> The whole FileChannelImpl#transferTo took ~48us.
> I know microbenchmarks need to be done very carefully, but I think it
> gives a general idea of the performance impact for something that
> should be (?) unecessary
>
> Of course, I could be wrong, or more needs to be considered, but I
> thought it was worth bringing up and get some feedback.
> Maybe someone could confirm the behaviour of sendfile/splice, or
> explain the reasoning for checking the size in the JVM?
>
> Thank you for your time!
>
> Best regards,
> Adrian
>


From Alan.Bateman at oracle.com  Thu Aug 20 06:11:26 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 20 Aug 2015 07:11:26 +0100
Subject: RFR/RFA (8u-dev) 8133253: [TESTBUG]
	java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java
	fails on compact profile
In-Reply-To: <55D56184.5040502@oracle.com>
References: <55D49976.20908@oracle.com> <55D56184.5040502@oracle.com>
Message-ID: <55D56F8E.3030803@oracle.com>



On 20/08/2015 06:11, David Holmes wrote:
> On 20/08/2015 12:57 AM, Ivan Gerasimov wrote:
>> Hi!
>>
>> The test FieldSetAccessibleTest.java fails when testing with compact3
>> even after fixing JDK-8080524.
>
> Why wasn't that determined at the time?
I think the general issue is that this section of TEST.groups is not 
easy to maintain. New tests are added or being changed all the time and 
if the tests aren't also run continuously on compact profile builds then 
it might be some time before anyone notices. Hopefully we will soon be 
at the point where we can completely remove this section from the 
TEST.groups file and use the jtreg @modules support.

-Alan


From christoph.langer at sap.com  Thu Aug 20 10:21:35 2015
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 20 Aug 2015 10:21:35 +0000
Subject: RFR(XS): 8133830: [solaris] Fix for potential memory leak in
	TimeZone_md.c, function findJavaTZ_md()
Message-ID: <0DFD2E72402C9243A8630A7759B27E4338EF1721@DEWDFEMB12B.global.corp.sap>

Hi all,

as per the discussion in thread "Fix for small leak in TimeZone_md.c" in jdk9-dev, I would like to get the following tiny change reviewed:

Bug: https://bugs.openjdk.java.net/browse/JDK-8133830
Webrev: http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/

I also need a sponsor since I can't commit yet.

Thanks
Christoph



From thomas.stuefe at gmail.com  Thu Aug 20 11:20:29 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 20 Aug 2015 13:20:29 +0200
Subject: RFR(XS): 8133830: [solaris] Fix for potential memory leak in
	TimeZone_md.c, function findJavaTZ_md()
In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338EF1721@DEWDFEMB12B.global.corp.sap>
References: <0DFD2E72402C9243A8630A7759B27E4338EF1721@DEWDFEMB12B.global.corp.sap>
Message-ID: 

Looks good. Thumbs up.

.. Thomas

On Thu, Aug 20, 2015 at 12:21 PM, Langer, Christoph <
christoph.langer at sap.com> wrote:

> Hi all,
>
> as per the discussion in thread "Fix for small leak in TimeZone_md.c" in
> jdk9-dev, I would like to get the following tiny change reviewed:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8133830
> Webrev: http://cr.openjdk.java.net/~asiebenborn/christoph/webrev/
>
> I also need a sponsor since I can't commit yet.
>
> Thanks
> Christoph
>
>


From Alan.Bateman at oracle.com  Thu Aug 20 17:18:12 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 20 Aug 2015 18:18:12 +0100
Subject: [9] Review request JDK-8131667: JAX-WS Plugability Layer: using
	java.util.ServiceLoader
In-Reply-To: <55D4A2CB.70900@oracle.com>
References: <55D4A2CB.70900@oracle.com>
Message-ID: <55D60BD4.4090901@oracle.com>

On 19/08/2015 16:37, Miroslav Kos wrote:
> Hi everybody,
>
> I am sending changes for review.
>
> CCC: http://ccc.us.oracle.com/8131667
> JBS: https://bugs.openjdk.java.net/browse/JDK-8131667
> webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.01/
>
> It's about migrating to standard java.util.ServiceLoader. This part of 
> service discovery was implemented previously "own" way. There are some 
> changes in javadoc and implementation has been refactored in order to 
> use same code as is in JAX-B and SAAJ.
I skimmed through this and it mostly looks okay. One thing that probably 
should be re-examined is the catch Exception in fromJDKProperties as an 
exception accessing or parsing jaxws.properties will be difficult to 
diagnose with the code as it is.

-Alan


From miroslav.kos at oracle.com  Fri Aug 21 10:12:09 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Fri, 21 Aug 2015 12:12:09 +0200
Subject: [9] Review request JDK-8131667: JAX-WS Plugability Layer: using
	java.util.ServiceLoader
In-Reply-To: <55D60BD4.4090901@oracle.com>
References: <55D4A2CB.70900@oracle.com> <55D60BD4.4090901@oracle.com>
Message-ID: <55D6F979.5090600@oracle.com>

Hi Alan,
yes, I know the error/exception handling is really bad here - it isn't 
anywhere defined properly. In addition, although the code in JAX-B / 
JAX-WS / SAAJ was most probably "developed" using cut&paste, it isn't 
very consistent.

I tried to improve it a little bit, but I am not sure how much may I 
change the behavior because of backwards compatibility. I would prefer 
fail fast if configuration is wrong, but may I? Maybe Georgiy (added) 
could advise on that?

Anyway even if we don't change it, there should be added some logging.

Thanks
Miran


On 20/08/15 19:18, Alan Bateman wrote:
> On 19/08/2015 16:37, Miroslav Kos wrote:
>> Hi everybody,
>>
>> I am sending changes for review.
>>
>> CCC: http://ccc.us.oracle.com/8131667
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8131667
>> webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.01/
>>
>> It's about migrating to standard java.util.ServiceLoader. This part 
>> of service discovery was implemented previously "own" way. There are 
>> some changes in javadoc and implementation has been refactored in 
>> order to use same code as is in JAX-B and SAAJ.
> I skimmed through this and it mostly looks okay. One thing that 
> probably should be re-examined is the catch Exception in 
> fromJDKProperties as an exception accessing or parsing 
> jaxws.properties will be difficult to diagnose with the code as it is.
>
> -Alan



From lance.andersen at oracle.com  Fri Aug 21 12:43:51 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 21 Aug 2015 08:43:51 -0400
Subject: RFR 8133939:  javadoc clarification for java.sql.Date.toLocalDate()
Message-ID: <09644C77-74A7-4762-8748-8E8A09E76F14@oracle.com>

Hi,

Here is a minor javadoc update for java.sql.Date.toLocalDate().  The ccc has been approved.

Best
Lance

 hg diff Date.java 
diff -r 562b349a85da src/java.sql/share/classes/java/sql/Date.java
--- a/src/java.sql/share/classes/java/sql/Date.java	Tue Aug 18 20:30:15 2015 -0700
+++ b/src/java.sql/share/classes/java/sql/Date.java	Wed Aug 19 10:03:58 2015 -0400
@@ -295,11 +295,8 @@
     }
 
     /**
-     * Converts this {@code Date} object to a {@code LocalDate}
-     * 

-     * The conversion creates a {@code LocalDate} that represents the same
-     * date value as this {@code Date} in local time zone
-     *
+     * Creates a {@code LocalDate} instance using the year, month and day
+     * from this {@code Date} object.
      * @return a {@code LocalDate} object representing the same date value
      *
      * @since 1.8



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





From lance.andersen at oracle.com  Fri Aug 21 12:48:37 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 21 Aug 2015 08:48:37 -0400
Subject: RFR 8133939:  javadoc clarification for java.sql.Date.toLocalDate()
Message-ID: 

Hi,

Here is a minor javadoc update for java.sql.Date.toLocalDate().  The ccc has been approved.

Best
Lance

 hg diff Date.java 
diff -r 562b349a85da src/java.sql/share/classes/java/sql/Date.java
--- a/src/java.sql/share/classes/java/sql/Date.java	Tue Aug 18 20:30:15 2015 -0700
+++ b/src/java.sql/share/classes/java/sql/Date.java	Wed Aug 19 10:03:58 2015 -0400
@@ -295,11 +295,8 @@
     }
 
     /**
-     * Converts this {@code Date} object to a {@code LocalDate}
-     * 

-     * The conversion creates a {@code LocalDate} that represents the same
-     * date value as this {@code Date} in local time zone
-     *
+     * Creates a {@code LocalDate} instance using the year, month and day
+     * from this {@code Date} object.
      * @return a {@code LocalDate} object representing the same date value
      *
      * @since 1.8



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





From huizhe.wang at oracle.com  Fri Aug 21 17:04:11 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 21 Aug 2015 10:04:11 -0700
Subject: RFR 8133939: javadoc clarification for java.sql.Date.toLocalDate()
In-Reply-To: 
References: 
Message-ID: <55D75A0B.7050209@oracle.com>

Looks good, Lance.

Best,
Joe

On 8/21/2015 5:48 AM, Lance Andersen wrote:
> Hi,
>
> Here is a minor javadoc update for java.sql.Date.toLocalDate().  The ccc has been approved.
>
> Best
> Lance
>
>   hg diff Date.java
> diff -r 562b349a85da src/java.sql/share/classes/java/sql/Date.java
> --- a/src/java.sql/share/classes/java/sql/Date.java	Tue Aug 18 20:30:15 2015 -0700
> +++ b/src/java.sql/share/classes/java/sql/Date.java	Wed Aug 19 10:03:58 2015 -0400
> @@ -295,11 +295,8 @@
>       }
>   
>       /**
> -     * Converts this {@code Date} object to a {@code LocalDate}
> -     * 

> -     * The conversion creates a {@code LocalDate} that represents the same
> -     * date value as this {@code Date} in local time zone
> -     *
> +     * Creates a {@code LocalDate} instance using the year, month and day
> +     * from this {@code Date} object.
>        * @return a {@code LocalDate} object representing the same date value
>        *
>        * @since 1.8
>
>
>
> 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 henry.jen at oracle.com  Fri Aug 21 22:46:38 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 21 Aug 2015 15:46:38 -0700
Subject: RFR v6 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <55D372D5.5030907@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
	
	<7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>
	<5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>
	<42494833-F0BF-43BF-AE85-F21D068D19FE@oracle.com>
	<525D3FA5-0CB4-4E0E-8D42-FA5CA4809073@oracle.com>
	<55D372D5.5030907@oracle.com>
Message-ID: <9EC26561-3D39-47D2-9D55-9E52B9516E54@oracle.com>

v7 is up, changes are

- Add formfeed character(\u000c) as while space character
- Support escape \f for formfeed character in quote
- Update java help output to include @ and -Xdisable- at files

http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v7/webrev/

Cheers,
Henry


> On Aug 18, 2015, at 11:00 AM, Mandy Chung  wrote:
> 
> 
> 
> On 08/17/2015 09:15 PM, Henry Jen wrote:
>> v6 is available at
>> 
>> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v6/webrev/
> 
> Thanks for the update.  Looks fine.
> 
> Mandy



From joe.darcy at oracle.com  Fri Aug 21 23:12:18 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 21 Aug 2015 16:12:18 -0700
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <0107D848-B42D-4E50-B782-FB314313BB4E@oracle.com>
References: <9D775E0E-16CA-43C9-AC30-A691AE7CCC0F@oracle.com>					<54EE4A87.8050807@oracle.com>	<19E11AB6-1504-4278-8256-154A61D7CBD9@oracle.com>	<54EF4B2C.3000002@oracle.com>
	<54EF8FC0.9060501@gmail.com>	<54EF91A8.4050303@gmail.com>	<915E482B-4BE9-4BB1-AF9B-712C5FF12A3F@oracle.com>	<54F041C2.7040701@gmail.com>
	<0107D848-B42D-4E50-B782-FB314313BB4E@oracle.com>
Message-ID: <55D7B052.9010203@oracle.com>

Belatedly, the

     http://cr.openjdk.java.net/~jfranck/8073056/webrev.02/

webrev looks fine other than a missing space in a line of 
AnnotationSuport.java:

     208                 }catch (Throwable t) { // from 
InvocationHandler::invoke

Thanks,

-Joe

On 3/28/2015 3:24 AM, Joel Borggr?n-Franck wrote:
> Hi,
>
>> On 27 Feb 2015, at 11:06, Peter Levart  wrote:
>> On 02/27/2015 10:27 AM, Joel Borggr?n-Franck wrote:
>>>> On 26 feb 2015, at 22:35, Peter Levart 
>>>>   wrote:
>>>> On 02/26/2015 10:27 PM, Peter Levart wrote:
>>>>
>>>>> The m.setAccessible(true) for the methods is needed to access methods of non-public annotations, right? This call could be moved to AnnotationType constructor as there it will be performed only once per Method object.
>>>>>
>>>> ...which will have the added benefit in that it will guarantee that only one MethodAccessor object per Method will ever be constructed instead of two?
>>>>
>>>>
>>> I don?t see this. setAccessible sets override in AccessibleObject, I don?t see a new MethodAccessor being generated here.
>> My fault! I was mistakenly thinking of Field objects in the context of setAccessible(boolean). If you use a Field object in two modes it will create and retain two different FieldAccessors (because they are different implementations in case field is final).
>>
>>> But I agree with you, and setting it as accessible in the AnnotationType constructor should arguably be more secure since then we know it isn?t shared since we just got our copy fresh from getDeclaredMethods().
>> That's a good point from maintainability perspective, yes, if someone some time decides to "optimize" the AnnotationType. I think it would be nice if AnnotationType documents that members() method returns Method objects that are pre-conditioned with setAccessible(true) and that users should not change this flag.
>>
> I don?t want to do this in AnnotationType without a bigger overhaul that may be slightly incompatible and therefor should be 9 only. I do want to backport this fix to 8 however, so here is an alternative solution that should be safe and correct at the cost of extra allocation in the path for custom implementations of annotations (that should be rare).
>
> New webrev:
>
> http://cr.openjdk.java.net/~jfranck/8073056/webrev.02/
>
> cheers
> /Joel



From tristan.yan at oracle.com  Sat Aug 22 00:14:53 2015
From: tristan.yan at oracle.com (Tristan Yan)
Date: Fri, 21 Aug 2015 17:14:53 -0700
Subject: Where is Tristan
Message-ID: <55D7BEFD.1070302@oracle.com>

I will be OOO from Aug 24th to Sept 7th. I will be checking Email 
intermittently but I won't be online. Drop me a mail if you need 
something from me.

Tristan


From mandy.chung at oracle.com  Sat Aug 22 02:56:14 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 21 Aug 2015 19:56:14 -0700
Subject: RFR v6 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <9EC26561-3D39-47D2-9D55-9E52B9516E54@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
	
	<7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>
	<5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>
	<42494833-F0BF-43BF-AE85-F21D068D19FE@oracle.com>
	<525D3FA5-0CB4-4E0E-8D42-FA5CA4809073@oracle.com>
	<55D372D5.5030907@oracle.com>
	<9EC26561-3D39-47D2-9D55-9E52B9516E54@oracle.com>
Message-ID: 


> On Aug 21, 2015, at 3:46 PM, Henry Jen  wrote:
> 
> v7 is up, changes are
> 
> - Add formfeed character(\u000c) as while space character
> - Support escape \f for formfeed character in quote
> - Update java help output to include @ and -Xdisable- at files
> 
> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v7/webrev/

The diff you sent in another mail is useful for just reviewing the delta change.  That looks fine.

launcher.properties 
   @ following -splash seems a little awk but it's consistent with javac -help and that?s okay.

Thanks
Mandy

From amaembo at gmail.com  Sat Aug 22 09:17:28 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Sat, 22 Aug 2015 15:17:28 +0600
Subject: [PATCH] Re: Custom spliterator for Collections.nCopies(n,
	obj).stream()
In-Reply-To: <79644D3C-5570-4555-940C-4F8384129877@oracle.com>
References: <1767952446.20150728143738@gmail.com> 
	<9B7C4E11-5FA7-4EEC-9A5F-929AF1DAAE9D@oracle.com>
	<1503382816.20150730120805@gmail.com>
	<79644D3C-5570-4555-940C-4F8384129877@oracle.com>
Message-ID: <1579202822.20150822151728@gmail.com>

Hello!

PS> With reuse it becomes more compelling :-) In both cases of
PS> singleton/nCopies the spliterator characteristics can be the same
PS> and that of the already existing singleton spliterator implementation.

The only difference is the DISTINCT characteristic. I think it's good
to report it based on the list size, so
Collections.nCopies(1, obj).spliterator() can report DISTINCT as well.

PS> I would be happy to accept a patch (with tests, if existing tests
PS> do not cover this already, i suspect they might but we still need
PS> to check). Have you signed the OCA [1]. If so i can accept a patch
PS> from you and publish as a webrev for review.

Here's my patch to the Collections class. Implementation of the
ConstantSpliterator is added, singletonSpliterator method now uses it
as well as CopiesList::spliterator. CopiesList::stream and
CopiesList::parallelStream methods are removed as unnecessary.

The resulting bytecode is roughly 750 bytes less after applying my
patch.

As for tests, it seems that
test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
covers both singletonSpliterator and nCopies().spliterator() pretty
well. I checked that these tests succeed with my changes while failed
when some mistake in ConstantSpliterator is introduced. If you think
that  more  tests are necessary, please suggest what exactly should be
tested and where to put them.

With best regards,
Tagir Valeev.

From amaembo at gmail.com  Sat Aug 22 14:27:01 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Sat, 22 Aug 2015 20:27:01 +0600
Subject: [PATCH] Re: Custom spliterator for Collections.nCopies(n,
	obj).stream()
In-Reply-To: <1579202822.20150822151728@gmail.com>
References: <1767952446.20150728143738@gmail.com>  
	<9B7C4E11-5FA7-4EEC-9A5F-929AF1DAAE9D@oracle.com>
	<1503382816.20150730120805@gmail.com>
	<79644D3C-5570-4555-940C-4F8384129877@oracle.com>
	<1579202822.20150822151728@gmail.com>
Message-ID: <38310015.20150822202701@gmail.com>

Seems that the patch attachment was filtered out. Just for the case
here it is:

diff --git a/src/java.base/share/classes/java/util/Collections.java b/src/java.base/share/classes/java/util/Collections.java
--- a/src/java.base/share/classes/java/util/Collections.java
+++ b/src/java.base/share/classes/java/util/Collections.java
@@ -4702,43 +4702,7 @@
      * @return A singleton {@code Spliterator}
      */
     static  Spliterator singletonSpliterator(final T element) {
-        return new Spliterator() {
-            long est = 1;
-
-            @Override
-            public Spliterator trySplit() {
-                return null;
-            }
-
-            @Override
-            public boolean tryAdvance(Consumer consumer) {
-                Objects.requireNonNull(consumer);
-                if (est > 0) {
-                    est--;
-                    consumer.accept(element);
-                    return true;
-                }
-                return false;
-            }
-
-            @Override
-            public void forEachRemaining(Consumer consumer) {
-                tryAdvance(consumer);
-            }
-
-            @Override
-            public long estimateSize() {
-                return est;
-            }
-
-            @Override
-            public int characteristics() {
-                int value = (element != null) ? Spliterator.NONNULL : 0;
-
-                return value | Spliterator.SIZED | Spliterator.SUBSIZED | Spliterator.IMMUTABLE |
-                       Spliterator.DISTINCT | Spliterator.ORDERED;
-            }
-        };
+        return new ConstantSpliterator<>(1, element);
     }
 
     /**
@@ -5061,20 +5025,64 @@
             return new CopiesList<>(toIndex - fromIndex, element);
         }
 
-        // Override default methods in Collection
-        @Override
-        public Stream stream() {
-            return IntStream.range(0, n).mapToObj(i -> element);
-        }
-
-        @Override
-        public Stream parallelStream() {
-            return IntStream.range(0, n).parallel().mapToObj(i -> element);
-        }
-
         @Override
         public Spliterator spliterator() {
-            return stream().spliterator();
+            return new ConstantSpliterator<>(n, element);
+        }
+    }
+    
+    private static final class ConstantSpliterator implements Spliterator {
+        long est;
+        T element;
+
+        public ConstantSpliterator(long est, T element) {
+            this.est = est;
+            this.element = element;
+        }
+
+        @Override
+        public Spliterator trySplit() {
+            long est = this.est;
+            if (est >= 2) {
+                est >>= 1;
+                Spliterator prefix = new ConstantSpliterator<>(est, element);
+                this.est -= est;
+                return prefix;
+            }
+            return null;
+        }
+
+        @Override
+        public boolean tryAdvance(Consumer action) {
+            Objects.requireNonNull(action);
+            if (est <= 0)
+                return false;
+            action.accept(element);
+            est--;
+            return true;
+        }
+
+        @Override
+        public void forEachRemaining(Consumer action) {
+            Objects.requireNonNull(action);
+            T element = this.element;
+            for (long r = est; r > 0; r--) {
+                action.accept(element);
+            }
+            est = 0;
+        }
+        
+        @Override
+        public long estimateSize() {
+            return est;
+        }
+
+        @Override
+        public int characteristics() {
+            int nonNull = (element != null) ? NONNULL : 0;
+            int distinct = (est <= 1) ? DISTINCT : 0; 
+
+            return SIZED | SUBSIZED | IMMUTABLE | ORDERED | nonNull | distinct;
         }
     }
 

With best regards,
Tagir Valeev.


TFV> Hello!

PS>> With reuse it becomes more compelling :-) In both cases of
PS>> singleton/nCopies the spliterator characteristics can be the same
PS>> and that of the already existing singleton spliterator implementation.

TFV> The only difference is the DISTINCT characteristic. I think it's good
TFV> to report it based on the list size, so
TFV> Collections.nCopies(1, obj).spliterator() can report DISTINCT as well.

PS>> I would be happy to accept a patch (with tests, if existing tests
PS>> do not cover this already, i suspect they might but we still need
PS>> to check). Have you signed the OCA [1]. If so i can accept a patch
PS>> from you and publish as a webrev for review.

TFV> Here's my patch to the Collections class. Implementation of the
TFV> ConstantSpliterator is added, singletonSpliterator method now uses it
TFV> as well as CopiesList::spliterator. CopiesList::stream and
TFV> CopiesList::parallelStream methods are removed as unnecessary.

TFV> The resulting bytecode is roughly 750 bytes less after applying my
TFV> patch.

TFV> As for tests, it seems that
TFV> test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
TFV> covers both singletonSpliterator and nCopies().spliterator() pretty
TFV> well. I checked that these tests succeed with my changes while failed
TFV> when some mistake in ConstantSpliterator is introduced. If you think
TFV> that  more  tests are necessary, please suggest what exactly should be
TFV> tested and where to put them.

TFV> With best regards,
TFV> Tagir Valeev.



From kumar.x.srinivasan at oracle.com  Sat Aug 22 19:42:16 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Sat, 22 Aug 2015 12:42:16 -0700
Subject: RFR v6 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <9EC26561-3D39-47D2-9D55-9E52B9516E54@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
	
	<7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>
	<5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>
	<42494833-F0BF-43BF-AE85-F21D068D19FE@oracle.com>
	<525D3FA5-0CB4-4E0E-8D42-FA5CA4809073@oracle.com>
	<55D372D5.5030907@oracle.com>
	<9EC26561-3D39-47D2-9D55-9E52B9516E54@oracle.com>
Message-ID: <55D8D098.7080104@oracle.com>

Henry,

Looks good, and thank you for taking this on.

Kumar

On 8/21/2015 3:46 PM, Henry Jen wrote:
> v7 is up, changes are
>
> - Add formfeed character(\u000c) as while space character
> - Support escape \f for formfeed character in quote
> - Update java help output to include @ and -Xdisable- at files
>
> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v7/webrev/
>
> Cheers,
> Henry
>
>
>> On Aug 18, 2015, at 11:00 AM, Mandy Chung  wrote:
>>
>>
>>
>> On 08/17/2015 09:15 PM, Henry Jen wrote:
>>> v6 is available at
>>>
>>> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v6/webrev/
>> Thanks for the update.  Looks fine.
>>
>> Mandy



From henry.jen at oracle.com  Sun Aug 23 03:22:15 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Sat, 22 Aug 2015 20:22:15 -0700
Subject: RFR v6 - 8027634: Support @argfiles for java command-line tool
In-Reply-To: <55D8D098.7080104@oracle.com>
References: 
	
	
	
	<55CB5E51.1040608@oracle.com>
	<5DDE3BDE-0200-4192-A3F8-15F4709DE27F@oracle.com>
	<55CCC7F1.8070902@oracle.com>
	<71B2AAB3-809F-4670-9EBB-576012212EBF@oracle.com>
	
	<7DDA9950-255C-4A18-9EF4-6CE43E19F2EF@oracle.com>
	<5F9B5314-63A1-4546-B3CD-030B17211C62@oracle.com>
	<42494833-F0BF-43BF-AE85-F21D068D19FE@oracle.com>
	<525D3FA5-0CB4-4E0E-8D42-FA5CA4809073@oracle.com>
	<55D372D5.5030907@oracle.com>
	<9EC26561-3D39-47D2-9D55-9E52B9516E54@oracle.com>
	<55D8D098.7080104@oracle.com>
Message-ID: 

Kumar, Mandy,

Thanks for reviewing.

Cheers,
Henry


> On Aug 22, 2015, at 12:42 PM, Kumar Srinivasan  wrote:
> 
> Henry,
> 
> Looks good, and thank you for taking this on.
> 
> Kumar
> 
> On 8/21/2015 3:46 PM, Henry Jen wrote:
>> v7 is up, changes are
>> 
>> - Add formfeed character(\u000c) as while space character
>> - Support escape \f for formfeed character in quote
>> - Update java help output to include @ and -Xdisable- at files
>> 
>> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v7/webrev/
>> 
>> Cheers,
>> Henry
>> 
>> 
>>> On Aug 18, 2015, at 11:00 AM, Mandy Chung  wrote:
>>> 
>>> 
>>> 
>>> On 08/17/2015 09:15 PM, Henry Jen wrote:
>>>> v6 is available at
>>>> 
>>>> http://cr.openjdk.java.net/~henryjen/jdk9/8027634/v6/webrev/
>>> Thanks for the update.  Looks fine.
>>> 
>>> Mandy
> 



From joel.franck at oracle.com  Mon Aug 24 09:18:03 2015
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Mon, 24 Aug 2015 11:18:03 +0200
Subject: RFR 8073056: Repeating annotations throws
	java.security.AccessControlException with a SecurityManager
In-Reply-To: <55D7B052.9010203@oracle.com>
References: <9D775E0E-16CA-43C9-AC30-A691AE7CCC0F@oracle.com>
	
	
	
	
	<54EE4A87.8050807@oracle.com>
	<19E11AB6-1504-4278-8256-154A61D7CBD9@oracle.com>
	<54EF4B2C.3000002@oracle.com> <54EF8FC0.9060501@gmail.com>
	<54EF91A8.4050303@gmail.com>
	<915E482B-4BE9-4BB1-AF9B-712C5FF12A3F@oracle.com>
	<54F041C2.7040701@gmail.com>
	<0107D848-B42D-4E50-B782-FB314313BB4E@oracle.com>
	<55D7B052.9010203@oracle.com>
Message-ID: <0BB92D38-B823-4B8E-86EB-6C8844B90747@oracle.com>

Thanks for the review Joe, I added a space and pushed.

cheers
/Joel

> On 22 aug 2015, at 01:12, Joseph D. Darcy  wrote:
> 
> Belatedly, the
> 
>    http://cr.openjdk.java.net/~jfranck/8073056/webrev.02/
> 
> webrev looks fine other than a missing space in a line of AnnotationSuport.java:
> 
>    208                 }catch (Throwable t) { // from InvocationHandler::invoke
> 
> Thanks,
> 
> -Joe
> 
> On 3/28/2015 3:24 AM, Joel Borggr?n-Franck wrote:
>> Hi,
>> 
>>> On 27 Feb 2015, at 11:06, Peter Levart  wrote:
>>> On 02/27/2015 10:27 AM, Joel Borggr?n-Franck wrote:
>>>>> On 26 feb 2015, at 22:35, Peter Levart 
>>>>>  wrote:
>>>>> On 02/26/2015 10:27 PM, Peter Levart wrote:
>>>>> 
>>>>>> The m.setAccessible(true) for the methods is needed to access methods of non-public annotations, right? This call could be moved to AnnotationType constructor as there it will be performed only once per Method object.
>>>>>> 
>>>>> ...which will have the added benefit in that it will guarantee that only one MethodAccessor object per Method will ever be constructed instead of two?
>>>>> 
>>>>> 
>>>> I don?t see this. setAccessible sets override in AccessibleObject, I don?t see a new MethodAccessor being generated here.
>>> My fault! I was mistakenly thinking of Field objects in the context of setAccessible(boolean). If you use a Field object in two modes it will create and retain two different FieldAccessors (because they are different implementations in case field is final).
>>> 
>>>> But I agree with you, and setting it as accessible in the AnnotationType constructor should arguably be more secure since then we know it isn?t shared since we just got our copy fresh from getDeclaredMethods().
>>> That's a good point from maintainability perspective, yes, if someone some time decides to "optimize" the AnnotationType. I think it would be nice if AnnotationType documents that members() method returns Method objects that are pre-conditioned with setAccessible(true) and that users should not change this flag.
>>> 
>> I don?t want to do this in AnnotationType without a bigger overhaul that may be slightly incompatible and therefor should be 9 only. I do want to backport this fix to 8 however, so here is an alternative solution that should be safe and correct at the cost of extra allocation in the path for custom implementations of annotations (that should be rare).
>> 
>> New webrev:
>> 
>> http://cr.openjdk.java.net/~jfranck/8073056/webrev.02/
>> 
>> cheers
>> /Joel
> 



From ivan.gerasimov at oracle.com  Mon Aug 24 20:30:58 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 24 Aug 2015 23:30:58 +0300
Subject: RFR [XXS] 8134356: {@code} tag contains < and > sequences
Message-ID: <55DB7F02.7010405@oracle.com>

Hi!

In a few places {@code } block contains < and > sequences, which 
are displayed verbatim in the doc.
Would you please help review the trivial cleanup?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134356
WEBREV: http://cr.openjdk.java.net/~igerasim/8134356/00/webrev/

Sincerely yours,
Ivan


From martinrb at google.com  Mon Aug 24 20:49:51 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 24 Aug 2015 13:49:51 -0700
Subject: RFR [XXS] 8134356: {@code} tag contains < and > sequences
In-Reply-To: <55DB7F02.7010405@oracle.com>
References: <55DB7F02.7010405@oracle.com>
Message-ID: 

Thanks for doing this.

The code sample in SwitchPoint.java should be reformatted for consistency
with other javadoc - insert "  * " before every line.

Did you check for & as well?

The code below needs another {@code as previously in the same javadoc.

+     * The name {@code } will be parsed into { '<', "init", '>'}}



On Mon, Aug 24, 2015 at 1:30 PM, Ivan Gerasimov 
wrote:

> Hi!
>
> In a few places {@code } block contains < and > sequences, which are
> displayed verbatim in the doc.
> Would you please help review the trivial cleanup?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134356
> WEBREV: http://cr.openjdk.java.net/~igerasim/8134356/00/webrev/
>
> Sincerely yours,
> Ivan
>


From ivan.gerasimov at oracle.com  Tue Aug 25 07:47:10 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 25 Aug 2015 10:47:10 +0300
Subject: RFR [XXS] 8134356: {@code} tag contains < and > sequences
In-Reply-To: 
References: <55DB7F02.7010405@oracle.com>
	
Message-ID: <55DC1D7E.7060607@oracle.com>

Thank you Martin for reviewing!

On 24.08.2015 23:49, Martin Buchholz wrote:
> Thanks for doing this.
>
> The code sample in SwitchPoint.java should be reformatted for 
> consistency with other javadoc - insert "  * " before every line.
>
Done.

> Did you check for & as well?
>
No &, but grep found one   in Character.
I wasn't sure how to specify   in {@code}, so just replaced it with 
a regular space.
The resulting html seems to look Okay.

> The code below needs another {@code as previously in the same javadoc.
> +     * The name {@code } will be parsed into { '<', "init", '>'}}
>
Done.

Would you please take a look at the updated webrev?

http://cr.openjdk.java.net/~igerasim/8134356/01/webrev/

Sincerely yours,
Ivan


From frank.yuan at oracle.com  Tue Aug 25 09:43:12 2015
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 25 Aug 2015 17:43:12 +0800
Subject: Review request for JDK-8133924: NPE may be thrown when xsltc select a
	non-existing node after JDK-8062518
Message-ID: <024901d0df1a$77160560$65421020$@oracle.com>

Hi, Joe and all

 

Would you like to have a review for bug
https://bugs.openjdk.java.net/browse/JDK-8133924?

 

The webrev is at: http://cr.openjdk.java.net/~fyuan/8133924/webrev.00/.

 

I have verified this fix, the corresponding test(it will be pushed with
another test suite) and jaxp test are passed in JPRT.

 

Thanks,

 

Frank

 



From maurizio.cimadamore at oracle.com  Tue Aug 25 11:14:57 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 25 Aug 2015 12:14:57 +0100
Subject: jtreg test failure
Message-ID: <55DC4E31.8080101@oracle.com>

Hi,
the test for:

https://bugs.openjdk.java.net/browse/JDK-8134250

Which has been recently pushed is failing for me:

java.lang.RuntimeException: FULL date format of Islamic Um-Alqura calendar in en_US is incorrect. Got: Tuesday 12 Safar 1400 AH, expected: Tuesday, Safar 12, 1400 AH
	at Bug8134250.main(Bug8134250.java:68)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:519)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
	at java.lang.Thread.run(Thread.java:746)

JavaTest Message: Test threw exception: java.lang.RuntimeException: FULL date format of Islamic Um-Alqura calendar in en_US is incorrect. Got: Tuesday 12 Safar 1400 AH, expected: Tuesday, Safar 12, 1400 AH
JavaTest Message: shutting down test


I couldn't find any related entries on JBS. Any thoughts?

Maurizio


From aleksej.efimov at oracle.com  Tue Aug 25 11:17:36 2015
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 25 Aug 2015 14:17:36 +0300
Subject: Review request for JDK-8133924: NPE may be thrown when xsltc
	select a non-existing node after JDK-8062518
In-Reply-To: <024901d0df1a$77160560$65421020$@oracle.com>
References: <024901d0df1a$77160560$65421020$@oracle.com>
Message-ID: <55DC4ED0.1060706@oracle.com>

Hi Frank,
Fix looks good to me (not a reviewer). Did you have a chance to run JCK 
tests with proposed fix?
Also we'll need to backport this change. Do you have a plan to do it? If 
not then I can handle it.

With Best Regards,
Aleksej

On 08/25/2015 12:43 PM, Frank Yuan wrote:
> Hi, Joe and all
>
>   
>
> Would you like to have a review for bug
> https://bugs.openjdk.java.net/browse/JDK-8133924?
>
>   
>
> The webrev is at: http://cr.openjdk.java.net/~fyuan/8133924/webrev.00/.
>
>   
>
> I have verified this fix, the corresponding test(it will be pushed with
> another test suite) and jaxp test are passed in JPRT.
>
>   
>
> Thanks,
>
>   
>
> Frank
>
>   
>



From ivan.gerasimov at oracle.com  Tue Aug 25 07:40:28 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 25 Aug 2015 10:40:28 +0300
Subject: RFR [XXS] 8134356: {@code} tag contains < and > sequences
In-Reply-To: 
References: <55DB7F02.7010405@oracle.com>
	
Message-ID: <55DC1BEC.1010306@oracle.com>

Thank you Martin!

On 24.08.2015 23:49, Martin Buchholz wrote:
> Thanks for doing this.
>
> The code sample in SwitchPoint.java should be reformatted for 
> consistency with other javadoc - insert "  * " before every line.
>
Done.

> Did you check for & as well?
>
No &, but grep found one   in java.lang.Character.java.
I wasn't sure what is the way to specify it in {@code}, so just replaced 
it with a single space.
The resulting html looks Okay.

> The code below needs another {@code as previously in the same javadoc.
> +     * The name {@code } will be parsed into { '<', "init", '>'}}
>
Done.

>
> On Mon, Aug 24, 2015 at 1:30 PM, Ivan Gerasimov 
> > wrote:
>
>     Hi!
>
>     In a few places {@code } block contains < and > sequences,
>     which are displayed verbatim in the doc.
>     Would you please help review the trivial cleanup?
>
>     BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134356
>     WEBREV: http://cr.openjdk.java.net/~igerasim/8134356/00/webrev/
>     
>
>     Sincerely yours,
>     Ivan
>
>



From martinrb at google.com  Tue Aug 25 15:19:36 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 25 Aug 2015 08:19:36 -0700
Subject: RFR [XXS] 8134356: {@code} tag contains < and > sequences
In-Reply-To: <55DC1BEC.1010306@oracle.com>
References: <55DB7F02.7010405@oracle.com>
	
	<55DC1BEC.1010306@oracle.com>
Message-ID: 

Looks good!
You could also get rid of the 
 which is non-standard for code
samples.
I would have preserved the 2-space indent in the code sample, but yeah, the
java standard is 4-space.

On Tue, Aug 25, 2015 at 12:40 AM, Ivan Gerasimov 
wrote:

> Thank you Martin!
>
> On 24.08.2015 23:49, Martin Buchholz wrote:
>
> Thanks for doing this.
>
> The code sample in SwitchPoint.java should be reformatted for consistency
> with other javadoc - insert "  * " before every line.
>
> Done.
>
> Did you check for & as well?
>
> No &, but grep found one   in java.lang.Character.java.
> I wasn't sure what is the way to specify it in {@code}, so just replaced
> it with a single space.
> The resulting html looks Okay.
>
> The code below needs another {@code as previously in the same javadoc.
>
> +     * The name {@code } will be parsed into { '<', "init", '>'}}
>
>
> Done.
>
>
> On Mon, Aug 24, 2015 at 1:30 PM, Ivan Gerasimov  > wrote:
>
>> Hi!
>>
>> In a few places {@code } block contains < and > sequences, which
>> are displayed verbatim in the doc.
>> Would you please help review the trivial cleanup?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134356
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8134356/00/webrev/
>>
>> Sincerely yours,
>> Ivan
>>
>
>
>


From ivan.gerasimov at oracle.com  Tue Aug 25 15:39:18 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 25 Aug 2015 18:39:18 +0300
Subject: RFR [XXS] 8134356: {@code} tag contains < and > sequences
In-Reply-To: 
References: <55DB7F02.7010405@oracle.com>
	
	<55DC1BEC.1010306@oracle.com>
	
Message-ID: <55DC8C26.3060000@oracle.com>

Thanks Martin!

On 25.08.2015 18:19, Martin Buchholz wrote:
> Looks good!
> You could also get rid of the 
 which is non-standard for 
> code samples.
Sure.
I've also done the same with another @code block in the same file.

> I would have preserved the 2-space indent in the code sample, but 
> yeah, the java standard is 4-space.
>
Right. Let's keep it consistent :)

Here's the final webrev:
http://cr.openjdk.java.net/~igerasim/8134356/02/webrev/

Sincerely yours,
Ivan



From lance.andersen at oracle.com  Tue Aug 25 15:53:28 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 25 Aug 2015 11:53:28 -0400
Subject: Review request for JDK-8133924: NPE may be thrown when xsltc
	select a non-existing node after JDK-8062518
In-Reply-To: <024901d0df1a$77160560$65421020$@oracle.com>
References: <024901d0df1a$77160560$65421020$@oracle.com>
Message-ID: 

Hi Frank

This looks OK.  I am assuming you have run the TCK/JCK tests just to validate there are no surprises based on the change prior to pushing ?

Best
Lance
On Aug 25, 2015, at 5:43 AM, Frank Yuan  wrote:

> Hi, Joe and all
> 
> 
> 
> Would you like to have a review for bug
> https://bugs.openjdk.java.net/browse/JDK-8133924?
> 
> 
> 
> The webrev is at: http://cr.openjdk.java.net/~fyuan/8133924/webrev.00/.
> 
> 
> 
> I have verified this fix, the corresponding test(it will be pushed with
> another test suite) and jaxp test are passed in JPRT.
> 
> 
> 
> Thanks,
> 
> 
> 
> Frank
> 
> 
> 



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 martinrb at google.com  Tue Aug 25 16:17:00 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 25 Aug 2015 09:17:00 -0700
Subject: RFR [XXS] 8134356: {@code} tag contains < and > sequences
In-Reply-To: <55DC8C26.3060000@oracle.com>
References: <55DB7F02.7010405@oracle.com>
	
	<55DC1BEC.1010306@oracle.com>
	
	<55DC8C26.3060000@oracle.com>
Message-ID: 

Looks good!

On Tue, Aug 25, 2015 at 8:39 AM, Ivan Gerasimov 
wrote:

> Thanks Martin!
>
> On 25.08.2015 18:19, Martin Buchholz wrote:
>
>> Looks good!
>> You could also get rid of the 
 which is non-standard for code
>> samples.
>>
> Sure.
> I've also done the same with another @code block in the same file.
>
> I would have preserved the 2-space indent in the code sample, but yeah,
>> the java standard is 4-space.
>>
>> Right. Let's keep it consistent :)
>
> Here's the final webrev:
> http://cr.openjdk.java.net/~igerasim/8134356/02/webrev/
>
> Sincerely yours,
> Ivan
>
>


From huizhe.wang at oracle.com  Tue Aug 25 16:29:16 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 25 Aug 2015 09:29:16 -0700
Subject: Review request for JDK-8133924: NPE may be thrown when xsltc
	select a non-existing node after JDK-8062518
In-Reply-To: <024901d0df1a$77160560$65421020$@oracle.com>
References: <024901d0df1a$77160560$65421020$@oracle.com>
Message-ID: <55DC97DC.3060701@oracle.com>

Looks good to me.

Thanks,
Joe

On 8/25/2015 2:43 AM, Frank Yuan wrote:
>
> Hi, Joe and all
>
> Would you like to have a review for bug 
> https://bugs.openjdk.java.net/browse/JDK-8133924?
>
> The webrev is at: http://cr.openjdk.java.net/~fyuan/8133924/webrev.00/ 
> .
>
> I have verified this fix, the corresponding test(it will be pushed 
> with another test suite) and jaxp test are passed in JPRT.
>
> Thanks,
>
> Frank
>



From naoto.sato at oracle.com  Tue Aug 25 17:04:27 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 25 Aug 2015 10:04:27 -0700
Subject: jtreg test failure
In-Reply-To: <55DC4E31.8080101@oracle.com>
References: <55DC4E31.8080101@oracle.com>
Message-ID: <55DCA01B.6020601@oracle.com>

Hi Maurizio,

The test case was added for the following feature:

https://bugs.openjdk.java.net/browse/JDK-8008577

On my environment and JPRT runs, neither had the said failure. Can you 
please elaborate your environment more?

Naoto

On 8/25/15 4:14 AM, Maurizio Cimadamore wrote:
> Hi,
> the test for:
>
> https://bugs.openjdk.java.net/browse/JDK-8134250
>
> Which has been recently pushed is failing for me:
>
> java.lang.RuntimeException: FULL date format of Islamic Um-Alqura
> calendar in en_US is incorrect. Got: Tuesday 12 Safar 1400 AH, expected:
> Tuesday, Safar 12, 1400 AH
>      at Bug8134250.main(Bug8134250.java:68)
>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>      at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
>      at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
>      at java.lang.reflect.Method.invoke(Method.java:519)
>      at
> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
>
>      at java.lang.Thread.run(Thread.java:746)
>
> JavaTest Message: Test threw exception: java.lang.RuntimeException: FULL
> date format of Islamic Um-Alqura calendar in en_US is incorrect. Got:
> Tuesday 12 Safar 1400 AH, expected: Tuesday, Safar 12, 1400 AH
> JavaTest Message: shutting down test
>
>
> I couldn't find any related entries on JBS. Any thoughts?
>
> Maurizio


From maurizio.cimadamore at oracle.com  Tue Aug 25 17:14:47 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 25 Aug 2015 18:14:47 +0100
Subject: jtreg test failure
In-Reply-To: <55DCA01B.6020601@oracle.com>
References: <55DC4E31.8080101@oracle.com> <55DCA01B.6020601@oracle.com>
Message-ID: <55DCA287.8030400@oracle.com>



On 25/08/15 18:04, Naoto Sato wrote:
> Hi Maurizio,
>
> The test case was added for the following feature:
>
> https://bugs.openjdk.java.net/browse/JDK-8008577
>
> On my environment and JPRT runs, neither had the said failure. Can you 
> please elaborate your environment more?
I noted that tests seem to work fine with JPRT/Mach 5.

I'm running JDK tests using the standard make target:

make -C tests java_util

So I guess the weirdness has to do with my locale settings (I'm based in 
Ireland).

Is there's some specific env variable you need?

Maurizio
>
> Naoto
>
> On 8/25/15 4:14 AM, Maurizio Cimadamore wrote:
>> Hi,
>> the test for:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8134250
>>
>> Which has been recently pushed is failing for me:
>>
>> java.lang.RuntimeException: FULL date format of Islamic Um-Alqura
>> calendar in en_US is incorrect. Got: Tuesday 12 Safar 1400 AH, expected:
>> Tuesday, Safar 12, 1400 AH
>>      at Bug8134250.main(Bug8134250.java:68)
>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>      at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
>>
>>
>>      at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
>>
>>
>>      at java.lang.reflect.Method.invoke(Method.java:519)
>>      at
>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) 
>>
>>
>>      at java.lang.Thread.run(Thread.java:746)
>>
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: FULL
>> date format of Islamic Um-Alqura calendar in en_US is incorrect. Got:
>> Tuesday 12 Safar 1400 AH, expected: Tuesday, Safar 12, 1400 AH
>> JavaTest Message: shutting down test
>>
>>
>> I couldn't find any related entries on JBS. Any thoughts?
>>
>> Maurizio



From naoto.sato at oracle.com  Tue Aug 25 17:51:01 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 25 Aug 2015 10:51:01 -0700
Subject: jtreg test failure
In-Reply-To: <55DCA287.8030400@oracle.com>
References: <55DC4E31.8080101@oracle.com> <55DCA01B.6020601@oracle.com>
	<55DCA287.8030400@oracle.com>
Message-ID: <55DCAB05.4070207@oracle.com>

On 8/25/15 10:14 AM, Maurizio Cimadamore wrote:
>
>
> On 25/08/15 18:04, Naoto Sato wrote:
>> Hi Maurizio,
>>
>> The test case was added for the following feature:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8008577
>>
>> On my environment and JPRT runs, neither had the said failure. Can you
>> please elaborate your environment more?
> I noted that tests seem to work fine with JPRT/Mach 5.
>
> I'm running JDK tests using the standard make target:
>
> make -C tests java_util
>
> So I guess the weirdness has to do with my locale settings (I'm based in
> Ireland).
>
> Is there's some specific env variable you need?

No. And the locale should not matter because the test explicitly specify 
en_US. Can you please file an issue for this?

Naoto

>
> Maurizio
>>
>> Naoto
>>
>> On 8/25/15 4:14 AM, Maurizio Cimadamore wrote:
>>> Hi,
>>> the test for:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8134250
>>>
>>> Which has been recently pushed is failing for me:
>>>
>>> java.lang.RuntimeException: FULL date format of Islamic Um-Alqura
>>> calendar in en_US is incorrect. Got: Tuesday 12 Safar 1400 AH, expected:
>>> Tuesday, Safar 12, 1400 AH
>>>      at Bug8134250.main(Bug8134250.java:68)
>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>      at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>
>>>
>>>      at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>
>>>
>>>      at java.lang.reflect.Method.invoke(Method.java:519)
>>>      at
>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
>>>
>>>
>>>      at java.lang.Thread.run(Thread.java:746)
>>>
>>> JavaTest Message: Test threw exception: java.lang.RuntimeException: FULL
>>> date format of Islamic Um-Alqura calendar in en_US is incorrect. Got:
>>> Tuesday 12 Safar 1400 AH, expected: Tuesday, Safar 12, 1400 AH
>>> JavaTest Message: shutting down test
>>>
>>>
>>> I couldn't find any related entries on JBS. Any thoughts?
>>>
>>> Maurizio
>


From lance.andersen at oracle.com  Tue Aug 25 18:29:09 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 25 Aug 2015 14:29:09 -0400
Subject: RFR 8134426: Add serialVersionUID field to relevant javax.transaction
	classes
Message-ID: <19C69AE8-9C19-4007-992D-B9D074D01DA4@oracle.com>

Hi,

Looking for a reviewer for 8134426   This change adds a serialVersionUID field to the required javax.transaction classes as well as some basic tests. 
 
Once approved,  I will work to push the same changes to the relevant JTA project working with the Java EE team

output from serialver:

----------------
jdk 1.6 (OSX)

serialver -classpath classes.jar javax.transaction.InvalidTransactionException
javax.transaction.InvalidTransactionException:    private static final long serialVersionUID = 3597320220337691496L;
ljanders-mac:Classes ljanders$ serialver -classpath classes.jar javax.transaction.TransactionRequiredException
javax.transaction.TransactionRequiredException:    private static final long serialVersionUID = -1898806419937446439L;
ljanders-mac:Classes ljanders$ serialver -classpath classes.jar javax.transaction.TransactionRolledbackException
javax.transaction.TransactionRolledbackException:    private static final long serialVersionUID = -3142798139623020577L;

java ee 6

 serialver -classpath javaee.jar javax.transaction.InvalidTransactionException
javax.transaction.InvalidTransactionException:    private static final long serialVersionUID = 3597320220337691496L;
ljanders-mac:lib ljanders$ serialver -classpath javaee.jar javax.transaction.TransactionRequiredException
javax.transaction.TransactionRequiredException:    private static final long serialVersionUID = -1898806419937446439L;
ljanders-mac:lib ljanders$ serialver -classpath javaee.jar javax.transaction.TransactionRolledbackException
javax.transaction.TransactionRolledbackException:    private static final long serialVersionUID = -3142798139623020577L;
---------------
The webrev can be found at http://cr.openjdk.java.net/~lancea/8134426/webrev/.    

Also waiting on a JPRT run  to complete to verify tests run outside of my environment.

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  Tue Aug 25 18:36:02 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 25 Aug 2015 19:36:02 +0100
Subject: RFR 8134426: Add serialVersionUID field to relevant
	javax.transaction classes
In-Reply-To: <19C69AE8-9C19-4007-992D-B9D074D01DA4@oracle.com>
References: <19C69AE8-9C19-4007-992D-B9D074D01DA4@oracle.com>
Message-ID: <55DCB592.2050808@oracle.com>

On 25/08/2015 19:29, Lance Andersen wrote:
> Hi,
>
> Looking for a reviewer for 8134426   This change adds a serialVersionUID field to the required javax.transaction classes as well as some basic tests.
>   
> Once approved,  I will work to push the same changes to the relevant JTA project working with the Java EE team
>
> output from serialver:
>
> ----------------
> jdk 1.6 (OSX)
>
> serialver -classpath classes.jar javax.transaction.InvalidTransactionException
> javax.transaction.InvalidTransactionException:    private static final long serialVersionUID = 3597320220337691496L;
> ljanders-mac:Classes ljanders$ serialver -classpath classes.jar javax.transaction.TransactionRequiredException
> javax.transaction.TransactionRequiredException:    private static final long serialVersionUID = -1898806419937446439L;
> ljanders-mac:Classes ljanders$ serialver -classpath classes.jar javax.transaction.TransactionRolledbackException
> javax.transaction.TransactionRolledbackException:    private static final long serialVersionUID = -3142798139623020577L;
>
> java ee 6
>
>   serialver -classpath javaee.jar javax.transaction.InvalidTransactionException
> javax.transaction.InvalidTransactionException:    private static final long serialVersionUID = 3597320220337691496L;
> ljanders-mac:lib ljanders$ serialver -classpath javaee.jar javax.transaction.TransactionRequiredException
> javax.transaction.TransactionRequiredException:    private static final long serialVersionUID = -1898806419937446439L;
> ljanders-mac:lib ljanders$ serialver -classpath javaee.jar javax.transaction.TransactionRolledbackException
> javax.transaction.TransactionRolledbackException:    private static final long serialVersionUID = -3142798139623020577L;
> ---------------
> The webrev can be found at http://cr.openjdk.java.net/~lancea/8134426/webrev/.
>
The serialVersionUID update looks okay.

I have not looked at the tests in detail but the new TEST.properties 
looks like it's reaching into the /java/sql tree. Should the tests for 
the JTA not having their own BaseTest that doesn't depend on SQL?

-Alan


From lance.andersen at oracle.com  Tue Aug 25 18:39:51 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 25 Aug 2015 14:39:51 -0400
Subject: RFR 8134426: Add serialVersionUID field to relevant
	javax.transaction classes
In-Reply-To: <55DCB592.2050808@oracle.com>
References: <19C69AE8-9C19-4007-992D-B9D074D01DA4@oracle.com>
	<55DCB592.2050808@oracle.com>
Message-ID: <75DF03DF-3DCB-416B-8B10-D9751B458002@oracle.com>


On Aug 25, 2015, at 2:36 PM, Alan Bateman  wrote:

> On 25/08/2015 19:29, Lance Andersen wrote:
>> Hi,
>> 
>> Looking for a reviewer for 8134426   This change adds a serialVersionUID field to the required javax.transaction classes as well as some basic tests.
>>  Once approved,  I will work to push the same changes to the relevant JTA project working with the Java EE team
>> 
>> output from serialver:
>> 
>> ----------------
>> jdk 1.6 (OSX)
>> 
>> serialver -classpath classes.jar javax.transaction.InvalidTransactionException
>> javax.transaction.InvalidTransactionException:    private static final long serialVersionUID = 3597320220337691496L;
>> ljanders-mac:Classes ljanders$ serialver -classpath classes.jar javax.transaction.TransactionRequiredException
>> javax.transaction.TransactionRequiredException:    private static final long serialVersionUID = -1898806419937446439L;
>> ljanders-mac:Classes ljanders$ serialver -classpath classes.jar javax.transaction.TransactionRolledbackException
>> javax.transaction.TransactionRolledbackException:    private static final long serialVersionUID = -3142798139623020577L;
>> 
>> java ee 6
>> 
>>  serialver -classpath javaee.jar javax.transaction.InvalidTransactionException
>> javax.transaction.InvalidTransactionException:    private static final long serialVersionUID = 3597320220337691496L;
>> ljanders-mac:lib ljanders$ serialver -classpath javaee.jar javax.transaction.TransactionRequiredException
>> javax.transaction.TransactionRequiredException:    private static final long serialVersionUID = -1898806419937446439L;
>> ljanders-mac:lib ljanders$ serialver -classpath javaee.jar javax.transaction.TransactionRolledbackException
>> javax.transaction.TransactionRolledbackException:    private static final long serialVersionUID = -3142798139623020577L;
>> ---------------
>> The webrev can be found at http://cr.openjdk.java.net/~lancea/8134426/webrev/.
>> 
> The serialVersionUID update looks okay.
> 
> I have not looked at the tests in detail but the new TEST.properties looks like it's reaching into the /java/sql tree. Should the tests for the JTA not having their own BaseTest that doesn't depend on SQL?

I could do that, but just tried to keep duplicate code down as it only uses BaseTest.java.  I don't have a real strong preference.  Let me know if you feel strongly that I should do so.
> 
> -Alan



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 Aug 25 19:05:24 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 25 Aug 2015 12:05:24 -0700
Subject: RFR 8134426: Add serialVersionUID field to relevant
	javax.transaction classes
In-Reply-To: <19C69AE8-9C19-4007-992D-B9D074D01DA4@oracle.com>
References: <19C69AE8-9C19-4007-992D-B9D074D01DA4@oracle.com>
Message-ID: <55DCBC74.801@oracle.com>

Hi Lance,

The change looks good.

-Joe

On 8/25/2015 11:29 AM, Lance Andersen wrote:
> Hi,
>
> Looking for a reviewer for 8134426   This change adds a serialVersionUID field to the required javax.transaction classes as well as some basic tests.
>   
> Once approved,  I will work to push the same changes to the relevant JTA project working with the Java EE team
>
> output from serialver:
>
> ----------------
> jdk 1.6 (OSX)
>
> serialver -classpath classes.jar javax.transaction.InvalidTransactionException
> javax.transaction.InvalidTransactionException:    private static final long serialVersionUID = 3597320220337691496L;
> ljanders-mac:Classes ljanders$ serialver -classpath classes.jar javax.transaction.TransactionRequiredException
> javax.transaction.TransactionRequiredException:    private static final long serialVersionUID = -1898806419937446439L;
> ljanders-mac:Classes ljanders$ serialver -classpath classes.jar javax.transaction.TransactionRolledbackException
> javax.transaction.TransactionRolledbackException:    private static final long serialVersionUID = -3142798139623020577L;
>
> java ee 6
>
>   serialver -classpath javaee.jar javax.transaction.InvalidTransactionException
> javax.transaction.InvalidTransactionException:    private static final long serialVersionUID = 3597320220337691496L;
> ljanders-mac:lib ljanders$ serialver -classpath javaee.jar javax.transaction.TransactionRequiredException
> javax.transaction.TransactionRequiredException:    private static final long serialVersionUID = -1898806419937446439L;
> ljanders-mac:lib ljanders$ serialver -classpath javaee.jar javax.transaction.TransactionRolledbackException
> javax.transaction.TransactionRolledbackException:    private static final long serialVersionUID = -3142798139623020577L;
> ---------------
> The webrev can be found at http://cr.openjdk.java.net/~lancea/8134426/webrev/.
>
> Also waiting on a JPRT run  to complete to verify tests run outside of my environment.
>
> 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 Aug 25 19:30:19 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 25 Aug 2015 15:30:19 -0400
Subject: RFR 8134426: Add serialVersionUID field to relevant
	javax.transaction classes
In-Reply-To: <75DF03DF-3DCB-416B-8B10-D9751B458002@oracle.com>
References: <19C69AE8-9C19-4007-992D-B9D074D01DA4@oracle.com>
	<55DCB592.2050808@oracle.com>
	<75DF03DF-3DCB-416B-8B10-D9751B458002@oracle.com>
Message-ID: <17E75D8A-52ED-4D8A-8D48-714701A94991@oracle.com>

Ok, to keep things simple for now, I removed the dependency on the java/sql BaseTest  webrev has been updated

Best
Lance
On Aug 25, 2015, at 2:39 PM, Lance Andersen  wrote:

> 
> On Aug 25, 2015, at 2:36 PM, Alan Bateman  wrote:
> 
>> On 25/08/2015 19:29, Lance Andersen wrote:
>>> Hi,
>>> 
>>> Looking for a reviewer for 8134426   This change adds a serialVersionUID field to the required javax.transaction classes as well as some basic tests.
>>> Once approved,  I will work to push the same changes to the relevant JTA project working with the Java EE team
>>> 
>>> output from serialver:
>>> 
>>> ----------------
>>> jdk 1.6 (OSX)
>>> 
>>> serialver -classpath classes.jar javax.transaction.InvalidTransactionException
>>> javax.transaction.InvalidTransactionException:    private static final long serialVersionUID = 3597320220337691496L;
>>> ljanders-mac:Classes ljanders$ serialver -classpath classes.jar javax.transaction.TransactionRequiredException
>>> javax.transaction.TransactionRequiredException:    private static final long serialVersionUID = -1898806419937446439L;
>>> ljanders-mac:Classes ljanders$ serialver -classpath classes.jar javax.transaction.TransactionRolledbackException
>>> javax.transaction.TransactionRolledbackException:    private static final long serialVersionUID = -3142798139623020577L;
>>> 
>>> java ee 6
>>> 
>>> serialver -classpath javaee.jar javax.transaction.InvalidTransactionException
>>> javax.transaction.InvalidTransactionException:    private static final long serialVersionUID = 3597320220337691496L;
>>> ljanders-mac:lib ljanders$ serialver -classpath javaee.jar javax.transaction.TransactionRequiredException
>>> javax.transaction.TransactionRequiredException:    private static final long serialVersionUID = -1898806419937446439L;
>>> ljanders-mac:lib ljanders$ serialver -classpath javaee.jar javax.transaction.TransactionRolledbackException
>>> javax.transaction.TransactionRolledbackException:    private static final long serialVersionUID = -3142798139623020577L;
>>> ---------------
>>> The webrev can be found at http://cr.openjdk.java.net/~lancea/8134426/webrev/.
>>> 
>> The serialVersionUID update looks okay.
>> 
>> I have not looked at the tests in detail but the new TEST.properties looks like it's reaching into the /java/sql tree. Should the tests for the JTA not having their own BaseTest that doesn't depend on SQL?
> 
> I could do that, but just tried to keep duplicate code down as it only uses BaseTest.java.  I don't have a real strong preference.  Let me know if you feel strongly that I should do so.
>> 
>> -Alan
> 
> 
> 
> 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 frank.yuan at oracle.com  Wed Aug 26 06:57:46 2015
From: frank.yuan at oracle.com (Frank Yuan)
Date: Wed, 26 Aug 2015 14:57:46 +0800
Subject: Review request for JDK-8133924: NPE may be thrown when xsltc
	select a non-existing node after JDK-8062518
In-Reply-To: <55DC4ED0.1060706@oracle.com>
References: <024901d0df1a$77160560$65421020$@oracle.com>
	<55DC4ED0.1060706@oracle.com>
Message-ID: <03ad01d0dfcc$85379840$8fa6c8c0$@oracle.com>

Hi Aleksej and Lance

Many thanks for your reminder!

I have run JCK test today, all xml tests are passed.


To Aleksej

Please help me to handle the backport, thank you very much!

Best Regards
Frank



-----Original Message-----
From: Aleksej Efimov [mailto:aleksej.efimov at oracle.com] 
Sent: Tuesday, August 25, 2015 7:18 PM
To: Frank Yuan 
Cc: 'core-libs-dev' ; 'Joe Wang'

Subject: Re: Review request for JDK-8133924: NPE may be thrown when xsltc
select a non-existing node after JDK-8062518

Hi Frank,
Fix looks good to me (not a reviewer). Did you have a chance to run JCK
tests with proposed fix?
Also we'll need to backport this change. Do you have a plan to do it? If not
then I can handle it.

With Best Regards,
Aleksej

On 08/25/2015 12:43 PM, Frank Yuan wrote:
> Hi, Joe and all
>
>   
>
> Would you like to have a review for bug 
> https://bugs.openjdk.java.net/browse/JDK-8133924?
>
>   
>
> The webrev is at: http://cr.openjdk.java.net/~fyuan/8133924/webrev.00/.
>
>   
>
> I have verified this fix, the corresponding test(it will be pushed 
> with another test suite) and jaxp test are passed in JPRT.
>
>   
>
> Thanks,
>
>   
>
> Frank
>
>   
>




From Alan.Bateman at oracle.com  Wed Aug 26 11:16:26 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 26 Aug 2015 12:16:26 +0100
Subject: RFR 8134426: Add serialVersionUID field to relevant
	javax.transaction classes
In-Reply-To: <17E75D8A-52ED-4D8A-8D48-714701A94991@oracle.com>
References: <19C69AE8-9C19-4007-992D-B9D074D01DA4@oracle.com>
	<55DCB592.2050808@oracle.com>
	<75DF03DF-3DCB-416B-8B10-D9751B458002@oracle.com>
	<17E75D8A-52ED-4D8A-8D48-714701A94991@oracle.com>
Message-ID: <55DDA00A.2020705@oracle.com>



On 25/08/2015 20:30, Lance Andersen wrote:
> Ok, to keep things simple for now, I removed the dependency on the 
> java/sql BaseTest  webrev has been updated
>
>
Okay although my comment about the previous iteration was mostly just 
pointing out that generic infrastructure should be in the sql directory. 
Maybe at some point you can see about moving this to a common place to 
avoid duplicate code.

-Alan


From dl at cs.oswego.edu  Wed Aug 26 14:01:01 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 26 Aug 2015 10:01:01 -0400
Subject: @Finalized
Message-ID: <55DDC69D.5090904@cs.oswego.edu>


In the course of JEP 188/193 related efforts, it has been pointed out
a few times that, as part of these efforts, finally adding method 
reachabilityFence(ref) with tentative spec pasted below should be
the first of two steps in helping developers avoid premature finalization
and reclamation. The second part seems to escape scope of these JEPs:
Supporting an annotation (most likely named @Finalized) that would
enable tools and/or compilers to convert methods of classes in
danger of premature finalization from
   { body }
to
   try { body } finally { Reference.reachabilityFence(this); }

And/or some variants, some of which were explored on the
jmm-dev list mainly in August 2014 -- see archives at
http://mail.openjdk.java.net/pipermail/jmm-dev/2014-August/thread.html

This is an issue of large importance to a small audience,
and is at the moment an orphan. To work out, I think it
requires at least some involvement from compiler and/or IDE
developers. If you are or know of someone who might be interested
in pursuing, please encourage them/yourself to consider it.

-Doug



class java.lang.ref.Reference {
     // add:

     /**
      * Ensures that the object referenced by the given reference
      * remains strongly reachable (as defined in the {@link
      * java.lang.ref} package documentation), regardless of any prior
      * actions of the program that might otherwise cause the object to
      * become unreachable. A reachabilityFence for a given reference
      * happens before the referenced object is reclaimed by garbage
      * collection, finalized, or added to a java.lang.ref queue.
      * Invocation of this method does not itself initiate garbage
      * collection or finalization.
      *
      * @param ref the reference. If null, this method has no effect.
      */
     public static void reachabilityFence(Object ref) {}

}



From aph at redhat.com  Wed Aug 26 14:12:42 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 26 Aug 2015 15:12:42 +0100
Subject: @Finalized
In-Reply-To: <55DDC69D.5090904@cs.oswego.edu>
References: <55DDC69D.5090904@cs.oswego.edu>
Message-ID: <55DDC95A.5000701@redhat.com>

On 08/26/2015 03:01 PM, Doug Lea wrote:
> This is an issue of large importance to a small audience,
> and is at the moment an orphan. To work out, I think it
> requires at least some involvement from compiler and/or IDE
> developers. If you are or know of someone who might be interested
> in pursuing, please encourage them/yourself to consider it.

At the minimum, all this needs is an empty native method.  That's not
the most efficient long-term solution but it is enough.

Andrew.



From forax at univ-mlv.fr  Wed Aug 26 14:34:02 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 26 Aug 2015 16:34:02 +0200 (CEST)
Subject: U60 change makes annotations visible in synthesized methods,
	causes	CDI to see lambdas as observer methods
In-Reply-To: <393833021.596102.1440599327702.JavaMail.zimbra@u-pem.fr>
References: 
	<393833021.596102.1440599327702.JavaMail.zimbra@u-pem.fr>
Message-ID: <1392080638.596845.1440599642169.JavaMail.zimbra@u-pem.fr>

IMO, it seems to be a bug of the CDI implementation,
as you said the method corresponding to the lambda body is synthetized so it should be ignored by the CDI implementation, no ?

BTW, it's the wrong list, lambdas are delivered so you should have use core-lib-dev instead (in CC).

cheers,
R?mi

----- Mail original -----
De: "arjan tijms" 
?: lambda-dev at openjdk.java.net
Envoy?: Mercredi 26 Ao?t 2015 16:04:22
Objet: U60 change makes annotations visible in synthesized methods, causes	CDI to see lambdas as observer methods

Hi,

I'm with the JSF EG/Mojarra team and we're seeing what looks like a
problematic regression in JDK8 u60.

In a CDI extension we have the following observer method:

    public  void processBean(@Observes ProcessBean event,
BeanManager beanManager) {
        getAnnotation(beanManager, event.getAnnotated(), FacesDataModel.class)
           .ifPresent(d ->
               forClassToDataModelClass.put(
                   d.forClass(),
                   (Class>)
event.getBean().getBeanClass()
               )
           );
    }

With u45 and below this will generate the following (decompiled the
class with javap -v -p -s -c)

  private void lambda$processBean$4(javax.enterprise.inject.spi.ProcessBean,
javax.faces.model.FacesDataModel);
    descriptor:
(Ljavax/enterprise/inject/spi/ProcessBean;Ljavax/faces/model/FacesDataModel;)V
    flags: ACC_PRIVATE, ACC_SYNTHETIC
    Code:
      stack=3, locals=3, args_size=3
         0: aload_0
         1: getfield      #4                  // Field
forClassToDataModelClass:Ljava/util/Map;
         4: aload_2
         5: invokeinterface #57,  1           // InterfaceMethod
javax/faces/model/FacesDataModel.forClass:()Ljava/lang/Class;
        10: aload_1
        11: invokeinterface #58,  1           // InterfaceMethod
javax/enterprise/inject/spi/ProcessBean.getBean:()Ljavax/enterprise/inject/spi/Bean;
        16: invokeinterface #59,  1           // InterfaceMethod
javax/enterprise/inject/spi/Bean.getBeanClass:()Ljava/lang/Class;
        21: invokeinterface #55,  3           // InterfaceMethod
java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
        26: checkcast     #45                 // class java/lang/Class
        29: pop
        30: return
      LineNumberTable:
        line 110: 0
        line 111: 5
        line 112: 11
        line 110: 21
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      31     0  this   Lcom/sun/faces/cdi/CdiExtension;
            0      31     2     d   Ljavax/faces/model/FacesDataModel;


U60 however generates the following:

  private void lambda$processBean$4(javax.enterprise.inject.spi.ProcessBean,
javax.faces.model.FacesDataModel);
    descriptor:
(Ljavax/enterprise/inject/spi/ProcessBean;Ljavax/faces/model/FacesDataModel;)V
    flags: ACC_PRIVATE, ACC_SYNTHETIC
    Code:
      stack=3, locals=3, args_size=3
         0: aload_0
         1: getfield      #4                  // Field
forClassToDataModelClass:Ljava/util/Map;
         4: aload_2
         5: invokeinterface #57,  1           // InterfaceMethod
javax/faces/model/FacesDataModel.forClass:()Ljava/lang/Class;
        10: aload_1
        11: invokeinterface #58,  1           // InterfaceMethod
javax/enterprise/inject/spi/ProcessBean.getBean:()Ljavax/enterprise/inject/spi/Bean;
        16: invokeinterface #59,  1           // InterfaceMethod
javax/enterprise/inject/spi/Bean.getBeanClass:()Ljava/lang/Class;
        21: invokeinterface #55,  3           // InterfaceMethod
java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
        26: checkcast     #45                 // class java/lang/Class
        29: pop
        30: return
      LineNumberTable:
        line 110: 0
        line 111: 5
        line 112: 11
        line 110: 21
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      31     0  this   Lcom/sun/faces/cdi/CdiExtension;
            0      31     1 event   Ljavax/enterprise/inject/spi/ProcessBean;
            0      31     2     d   Ljavax/faces/model/FacesDataModel;
    RuntimeVisibleParameterAnnotations:
      parameter 0:
        0: #79()
      parameter 1:

The difference is that the parameter annotation is made visible for
this synthesized method. The result is that CDI subsequently scans
this class and sees the synthesized method for the lambda as an
observer method, which is of course not the intention. In this
particular case it will result in a definition error:

"Error occurred during deployment: Exception while loading the app :

CDI definition failure:

WELD-000409: Observer method for container lifecycle event
[[BackedAnnotatedMethod]

private com.sun.faces.cdi.CdiExtension.lambda$processBean$4(@Observes
ProcessBean, FacesDataModel)] can only inject BeanManager.."

I think that if the synthesized method happened to be a correct
observer method, e.g. for a no-parameter lambda or one that happens to
have the BeanManager as its first and only parameter, then CDI would
silently start to call this method in response to events, which too is
highly undesirable.

Kind regards,
Arjan Tijms



From dl at cs.oswego.edu  Wed Aug 26 15:07:12 2015
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 26 Aug 2015 11:07:12 -0400
Subject: @Finalized
In-Reply-To: <55DDC95A.5000701@redhat.com>
References: <55DDC69D.5090904@cs.oswego.edu> <55DDC95A.5000701@redhat.com>
Message-ID: <55DDD620.2000500@cs.oswego.edu>

On 08/26/2015 10:12 AM, Andrew Haley wrote:
> On 08/26/2015 03:01 PM, Doug Lea wrote:
>> This is an issue of large importance to a small audience,
>> and is at the moment an orphan. To work out, I think it
>> requires at least some involvement from compiler and/or IDE
>> developers. If you are or know of someone who might be interested
>> in pursuing, please encourage them/yourself to consider it.
>
> At the minimum, all this needs is an empty native method.  That's not
> the most efficient long-term solution but it is enough.
>

Right. The reachabilityFence method itself is already in
jdk9/sandbox (thanks to Aleksey). The annotation isn't,
and can't be until compiler and IDE folks discuss whether and
how to support it.

-Doug




From arjan.tijms at gmail.com  Wed Aug 26 14:42:27 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 26 Aug 2015 16:42:27 +0200
Subject: U60 change makes annotations visible in synthesized methods,
	causes CDI to see lambdas as observer methods
In-Reply-To: <393833021.596102.1440599327702.JavaMail.zimbra@u-pem.fr>
References: 
	<393833021.596102.1440599327702.JavaMail.zimbra@u-pem.fr>
Message-ID: 

Hi,

On Wed, Aug 26, 2015 at 4:28 PM, Remi Forax  wrote:
> IMO, it seems to be a bug of the CDI implementation,
> as you said the method corresponding to the lambda body is synthetized so it should be ignored by the CDI implementation, no ?

Yes I agree that might be another possibility. I'll bring this to the
attention of the CDI and/or Weld people as well.

Still, it's a somewhat sudden change and there are many CDI
implementations out there.

> BTW, it's the wrong list, lambdas are delivered so you should have use core-lib-dev instead (in CC).

core-lib-dev, hmm, who would have thought? But I'll keep it in mind
for future messages. Thanks!

Kind regards,
Arjan Tijms

>
> cheers,
> R?mi
>
> ----- Mail original -----
> De: "arjan tijms" 
> ?: lambda-dev at openjdk.java.net
> Envoy?: Mercredi 26 Ao?t 2015 16:04:22
> Objet: U60 change makes annotations visible in synthesized methods, causes      CDI to see lambdas as observer methods
>
> Hi,
>
> I'm with the JSF EG/Mojarra team and we're seeing what looks like a
> problematic regression in JDK8 u60.
>
> In a CDI extension we have the following observer method:
>
>     public  void processBean(@Observes ProcessBean event,
> BeanManager beanManager) {
>         getAnnotation(beanManager, event.getAnnotated(), FacesDataModel.class)
>            .ifPresent(d ->
>                forClassToDataModelClass.put(
>                    d.forClass(),
>                    (Class>)
> event.getBean().getBeanClass()
>                )
>            );
>     }
>
> With u45 and below this will generate the following (decompiled the
> class with javap -v -p -s -c)
>
>   private void lambda$processBean$4(javax.enterprise.inject.spi.ProcessBean,
> javax.faces.model.FacesDataModel);
>     descriptor:
> (Ljavax/enterprise/inject/spi/ProcessBean;Ljavax/faces/model/FacesDataModel;)V
>     flags: ACC_PRIVATE, ACC_SYNTHETIC
>     Code:
>       stack=3, locals=3, args_size=3
>          0: aload_0
>          1: getfield      #4                  // Field
> forClassToDataModelClass:Ljava/util/Map;
>          4: aload_2
>          5: invokeinterface #57,  1           // InterfaceMethod
> javax/faces/model/FacesDataModel.forClass:()Ljava/lang/Class;
>         10: aload_1
>         11: invokeinterface #58,  1           // InterfaceMethod
> javax/enterprise/inject/spi/ProcessBean.getBean:()Ljavax/enterprise/inject/spi/Bean;
>         16: invokeinterface #59,  1           // InterfaceMethod
> javax/enterprise/inject/spi/Bean.getBeanClass:()Ljava/lang/Class;
>         21: invokeinterface #55,  3           // InterfaceMethod
> java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
>         26: checkcast     #45                 // class java/lang/Class
>         29: pop
>         30: return
>       LineNumberTable:
>         line 110: 0
>         line 111: 5
>         line 112: 11
>         line 110: 21
>       LocalVariableTable:
>         Start  Length  Slot  Name   Signature
>             0      31     0  this   Lcom/sun/faces/cdi/CdiExtension;
>             0      31     2     d   Ljavax/faces/model/FacesDataModel;
>
>
> U60 however generates the following:
>
>   private void lambda$processBean$4(javax.enterprise.inject.spi.ProcessBean,
> javax.faces.model.FacesDataModel);
>     descriptor:
> (Ljavax/enterprise/inject/spi/ProcessBean;Ljavax/faces/model/FacesDataModel;)V
>     flags: ACC_PRIVATE, ACC_SYNTHETIC
>     Code:
>       stack=3, locals=3, args_size=3
>          0: aload_0
>          1: getfield      #4                  // Field
> forClassToDataModelClass:Ljava/util/Map;
>          4: aload_2
>          5: invokeinterface #57,  1           // InterfaceMethod
> javax/faces/model/FacesDataModel.forClass:()Ljava/lang/Class;
>         10: aload_1
>         11: invokeinterface #58,  1           // InterfaceMethod
> javax/enterprise/inject/spi/ProcessBean.getBean:()Ljavax/enterprise/inject/spi/Bean;
>         16: invokeinterface #59,  1           // InterfaceMethod
> javax/enterprise/inject/spi/Bean.getBeanClass:()Ljava/lang/Class;
>         21: invokeinterface #55,  3           // InterfaceMethod
> java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
>         26: checkcast     #45                 // class java/lang/Class
>         29: pop
>         30: return
>       LineNumberTable:
>         line 110: 0
>         line 111: 5
>         line 112: 11
>         line 110: 21
>       LocalVariableTable:
>         Start  Length  Slot  Name   Signature
>             0      31     0  this   Lcom/sun/faces/cdi/CdiExtension;
>             0      31     1 event   Ljavax/enterprise/inject/spi/ProcessBean;
>             0      31     2     d   Ljavax/faces/model/FacesDataModel;
>     RuntimeVisibleParameterAnnotations:
>       parameter 0:
>         0: #79()
>       parameter 1:
>
> The difference is that the parameter annotation is made visible for
> this synthesized method. The result is that CDI subsequently scans
> this class and sees the synthesized method for the lambda as an
> observer method, which is of course not the intention. In this
> particular case it will result in a definition error:
>
> "Error occurred during deployment: Exception while loading the app :
>
> CDI definition failure:
>
> WELD-000409: Observer method for container lifecycle event
> [[BackedAnnotatedMethod]
>
> private com.sun.faces.cdi.CdiExtension.lambda$processBean$4(@Observes
> ProcessBean, FacesDataModel)] can only inject BeanManager.."
>
> I think that if the synthesized method happened to be a correct
> observer method, e.g. for a no-parameter lambda or one that happens to
> have the BeanManager as its first and only parameter, then CDI would
> silently start to call this method in response to events, which too is
> highly undesirable.
>
> Kind regards,
> Arjan Tijms
>


From naoto.sato at oracle.com  Wed Aug 26 16:48:17 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 26 Aug 2015 09:48:17 -0700
Subject: jtreg test failure
In-Reply-To: <55DCAB05.4070207@oracle.com>
References: <55DC4E31.8080101@oracle.com> <55DCA01B.6020601@oracle.com>
	<55DCA287.8030400@oracle.com> <55DCAB05.4070207@oracle.com>
Message-ID: <55DDEDD1.90805@oracle.com>

Turned out it was indeed failing in Ireland locale. Filed the following 
bug, and the review request will follow.

https://bugs.openjdk.java.net/browse/JDK-8134520

Naoto

On 8/25/15 10:51 AM, Naoto Sato wrote:
> On 8/25/15 10:14 AM, Maurizio Cimadamore wrote:
>>
>>
>> On 25/08/15 18:04, Naoto Sato wrote:
>>> Hi Maurizio,
>>>
>>> The test case was added for the following feature:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8008577
>>>
>>> On my environment and JPRT runs, neither had the said failure. Can you
>>> please elaborate your environment more?
>> I noted that tests seem to work fine with JPRT/Mach 5.
>>
>> I'm running JDK tests using the standard make target:
>>
>> make -C tests java_util
>>
>> So I guess the weirdness has to do with my locale settings (I'm based in
>> Ireland).
>>
>> Is there's some specific env variable you need?
>
> No. And the locale should not matter because the test explicitly specify
> en_US. Can you please file an issue for this?
>
> Naoto
>
>>
>> Maurizio
>>>
>>> Naoto
>>>
>>> On 8/25/15 4:14 AM, Maurizio Cimadamore wrote:
>>>> Hi,
>>>> the test for:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8134250
>>>>
>>>> Which has been recently pushed is failing for me:
>>>>
>>>> java.lang.RuntimeException: FULL date format of Islamic Um-Alqura
>>>> calendar in en_US is incorrect. Got: Tuesday 12 Safar 1400 AH,
>>>> expected:
>>>> Tuesday, Safar 12, 1400 AH
>>>>      at Bug8134250.main(Bug8134250.java:68)
>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>      at
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>>
>>>>
>>>>
>>>>      at
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>
>>>>
>>>>
>>>>      at java.lang.reflect.Method.invoke(Method.java:519)
>>>>      at
>>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
>>>>
>>>>
>>>>
>>>>      at java.lang.Thread.run(Thread.java:746)
>>>>
>>>> JavaTest Message: Test threw exception: java.lang.RuntimeException:
>>>> FULL
>>>> date format of Islamic Um-Alqura calendar in en_US is incorrect. Got:
>>>> Tuesday 12 Safar 1400 AH, expected: Tuesday, Safar 12, 1400 AH
>>>> JavaTest Message: shutting down test
>>>>
>>>>
>>>> I couldn't find any related entries on JBS. Any thoughts?
>>>>
>>>> Maurizio
>>


From naoto.sato at oracle.com  Wed Aug 26 16:52:20 2015
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 26 Aug 2015 09:52:20 -0700
Subject: [9] RFR: 8134520: Bug8134250 test fails in en_IE locale
Message-ID: <55DDEEC4.9060400@oracle.com>

Hello,

Please review a simple fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8134520

The proposed change is located at:

http://cr.openjdk.java.net/~naoto/8134520/webrev.00/

The fix is to simply set the en_US locale to the formatter.

Naoto


From lance.andersen at oracle.com  Wed Aug 26 17:24:45 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 26 Aug 2015 13:24:45 -0400
Subject: [9] RFR: 8134520: Bug8134250 test fails in en_IE locale
In-Reply-To: <55DDEEC4.9060400@oracle.com>
References: <55DDEEC4.9060400@oracle.com>
Message-ID: 

Looks OK Naoto

Best
Lnace
On Aug 26, 2015, at 12:52 PM, Naoto Sato  wrote:

> Hello,
> 
> Please review a simple fix for the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8134520
> 
> The proposed change is located at:
> 
> http://cr.openjdk.java.net/~naoto/8134520/webrev.00/
> 
> The fix is to simply set the en_US locale to the formatter.
> 
> Naoto



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 maurizio.cimadamore at oracle.com  Wed Aug 26 17:27:21 2015
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 26 Aug 2015 18:27:21 +0100
Subject: jtreg test failure
In-Reply-To: <55DDEDD1.90805@oracle.com>
References: <55DC4E31.8080101@oracle.com> <55DCA01B.6020601@oracle.com>
	<55DCA287.8030400@oracle.com> <55DCAB05.4070207@oracle.com>
	<55DDEDD1.90805@oracle.com>
Message-ID: <55DDF6F9.4000808@oracle.com>

Thanks for investigating this!

Maurizio

On 26/08/15 17:48, Naoto Sato wrote:
> Turned out it was indeed failing in Ireland locale. Filed the 
> following bug, and the review request will follow.
>
> https://bugs.openjdk.java.net/browse/JDK-8134520
>
> Naoto
>
> On 8/25/15 10:51 AM, Naoto Sato wrote:
>> On 8/25/15 10:14 AM, Maurizio Cimadamore wrote:
>>>
>>>
>>> On 25/08/15 18:04, Naoto Sato wrote:
>>>> Hi Maurizio,
>>>>
>>>> The test case was added for the following feature:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8008577
>>>>
>>>> On my environment and JPRT runs, neither had the said failure. Can you
>>>> please elaborate your environment more?
>>> I noted that tests seem to work fine with JPRT/Mach 5.
>>>
>>> I'm running JDK tests using the standard make target:
>>>
>>> make -C tests java_util
>>>
>>> So I guess the weirdness has to do with my locale settings (I'm 
>>> based in
>>> Ireland).
>>>
>>> Is there's some specific env variable you need?
>>
>> No. And the locale should not matter because the test explicitly specify
>> en_US. Can you please file an issue for this?
>>
>> Naoto
>>
>>>
>>> Maurizio
>>>>
>>>> Naoto
>>>>
>>>> On 8/25/15 4:14 AM, Maurizio Cimadamore wrote:
>>>>> Hi,
>>>>> the test for:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8134250
>>>>>
>>>>> Which has been recently pushed is failing for me:
>>>>>
>>>>> java.lang.RuntimeException: FULL date format of Islamic Um-Alqura
>>>>> calendar in en_US is incorrect. Got: Tuesday 12 Safar 1400 AH,
>>>>> expected:
>>>>> Tuesday, Safar 12, 1400 AH
>>>>>      at Bug8134250.main(Bug8134250.java:68)
>>>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>>      at
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>      at
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>      at java.lang.reflect.Method.invoke(Method.java:519)
>>>>>      at
>>>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>      at java.lang.Thread.run(Thread.java:746)
>>>>>
>>>>> JavaTest Message: Test threw exception: java.lang.RuntimeException:
>>>>> FULL
>>>>> date format of Islamic Um-Alqura calendar in en_US is incorrect. Got:
>>>>> Tuesday 12 Safar 1400 AH, expected: Tuesday, Safar 12, 1400 AH
>>>>> JavaTest Message: shutting down test
>>>>>
>>>>>
>>>>> I couldn't find any related entries on JBS. Any thoughts?
>>>>>
>>>>> Maurizio
>>>



From brian.goetz at oracle.com  Wed Aug 26 18:12:17 2015
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 26 Aug 2015 14:12:17 -0400
Subject: U60 change makes annotations visible in synthesized methods,
	causes CDI to see lambdas as observer methods
In-Reply-To: 
References: 
	<393833021.596102.1440599327702.JavaMail.zimbra@u-pem.fr>
	
Message-ID: 

> On Wed, Aug 26, 2015 at 4:28 PM, Remi Forax  wrote:
>> IMO, it seems to be a bug of the CDI implementation,
>> as you said the method corresponding to the lambda body is synthetized so it should be ignored by the CDI implementation, no ?

I concur with Remi?s prescription; CDI should be ignoring synthetic members.  

> 
>> BTW, it's the wrong list, lambdas are delivered so you should have use core-lib-dev instead (in CC).
> 
> core-lib-dev, hmm, who would have thought? But I'll keep it in mind
> for future messages. Thanks!

Actually since you?re asking about changes in compiler behavior, compiler-dev might be the right choice here.  But Remi is correct, lambda-dev is finished, and now lambda-related questions go to the appropriate jdk component list.



From aleksey.shipilev at oracle.com  Wed Aug 26 19:01:53 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 26 Aug 2015 22:01:53 +0300
Subject: @Finalized
In-Reply-To: <55DDD620.2000500@cs.oswego.edu>
References: <55DDC69D.5090904@cs.oswego.edu> <55DDC95A.5000701@redhat.com>
	<55DDD620.2000500@cs.oswego.edu>
Message-ID: <55DE0D21.8050207@oracle.com>

On 08/26/2015 06:07 PM, Doug Lea wrote:
> On 08/26/2015 10:12 AM, Andrew Haley wrote:
>> On 08/26/2015 03:01 PM, Doug Lea wrote:
>>> This is an issue of large importance to a small audience,
>>> and is at the moment an orphan. To work out, I think it
>>> requires at least some involvement from compiler and/or IDE
>>> developers. If you are or know of someone who might be interested
>>> in pursuing, please encourage them/yourself to consider it.
>>
>> At the minimum, all this needs is an empty native method.  That's not
>> the most efficient long-term solution but it is enough.
> 
> Right. The reachabilityFence method itself is already in
> jdk9/sandbox (thanks to Aleksey). 

Well, it's not really pushed anywhere yet:
 https://bugs.openjdk.java.net/browse/JDK-8133348

-Aleksey




From adinn at redhat.com  Wed Aug 26 19:04:56 2015
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 26 Aug 2015 20:04:56 +0100
Subject: @Finalized
In-Reply-To: <55DE0D21.8050207@oracle.com>
References: <55DDC69D.5090904@cs.oswego.edu> <55DDC95A.5000701@redhat.com>
	<55DDD620.2000500@cs.oswego.edu> <55DE0D21.8050207@oracle.com>
Message-ID: <55DE0DD8.9060901@redhat.com>

On 26/08/15 20:01, Aleksey Shipilev wrote:
> On 08/26/2015 06:07 PM, Doug Lea wrote:
>> On 08/26/2015 10:12 AM, Andrew Haley wrote:
>>> On 08/26/2015 03:01 PM, Doug Lea wrote:
>>>> This is an issue of large importance to a small audience,
>>>> and is at the moment an orphan. To work out, I think it
>>>> requires at least some involvement from compiler and/or IDE
>>>> developers. If you are or know of someone who might be interested
>>>> in pursuing, please encourage them/yourself to consider it.
>>>
>>> At the minimum, all this needs is an empty native method.  That's not
>>> the most efficient long-term solution but it is enough.
>>
>> Right. The reachabilityFence method itself is already in
>> jdk9/sandbox (thanks to Aleksey). 
> 
> Well, it's not really pushed anywhere yet:
>  https://bugs.openjdk.java.net/browse/JDK-8133348

Well, that was easy. What did you do in the afternoon?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)


From miroslav.kos at oracle.com  Thu Aug 27 18:26:30 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Thu, 27 Aug 2015 20:26:30 +0200
Subject: [9] Review request JDK-8131667: JAX-WS Plugability Layer: using
	java.util.ServiceLoader
In-Reply-To: <55D60BD4.4090901@oracle.com>
References: <55D4A2CB.70900@oracle.com> <55D60BD4.4090901@oracle.com>
Message-ID: <55DF5656.9040606@oracle.com>

On 20/08/15 19:18, Alan Bateman wrote:
> On 19/08/2015 16:37, Miroslav Kos wrote:
>> Hi everybody,
>>
>> I am sending changes for review.
>>
>> CCC: http://ccc.us.oracle.com/8131667
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8131667
>> webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.01/
>>
>> It's about migrating to standard java.util.ServiceLoader. This part 
>> of service discovery was implemented previously "own" way. There are 
>> some changes in javadoc and implementation has been refactored in 
>> order to use same code as is in JAX-B and SAAJ.
> I skimmed through this and it mostly looks okay. One thing that 
> probably should be re-examined is the catch Exception in 
> fromJDKProperties as an exception accessing or parsing 
> jaxws.properties will be difficult to diagnose with the code as it is.
>
> -Alan
Hi Alan,
I added logging (at least for now) - would it work for you?
updated webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.02/

If you think the exception shouldn't be ignored I suggest to solve this 
in separate issue (and maybe revisit all similar cases in SAAJ/JAX-*)

Thanks
Miran


From scolebourne at joda.org  Thu Aug 27 23:07:59 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 28 Aug 2015 00:07:59 +0100
Subject: RFR JDK-8133079 LocalDate/LocalTime ofInstant()
Message-ID: 

External question sites indicate that users have difficulty converting
between java.util.Date and LocalDate, and also between Instant and
LocalDate/LocalTime. This user difficulty can be resolved with some
additional methods.

Currently, the following methods exist:

 ZonedDateTime.ofInstant(Instant, ZoneId);
 OffsetDateTime.ofInstant(Instant, ZoneId);
 LocalDateTime.ofInstant(Instant, ZoneId);
 OffsetTime.ofInstant(Instant, ZoneId);

This enhancement proposes to add the same method to LocalDate and
LocalTime. It can reasonably be argued this was a simple oversight in
the original development.

Diff attached to the JIRA:

https://bugs.openjdk.java.net/browse/JDK-8133079

Would also appreciate a reviewer to ensure that the code and tests
pass OK (as opposed to my best efforts on a very dubious
Windows/Eclipse/JDK8 setup)

Stephen


From weijun.wang at oracle.com  Fri Aug 28 00:35:40 2015
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 28 Aug 2015 08:35:40 +0800
Subject: How to write test requiring a specific locale?
Message-ID: <55DFACDC.3080203@oracle.com>

Hi All

In https://bugs.openjdk.java.net/browse/JDK-8133910, the test tries to 
grep certain text from tool output, but when the default locale is not 
"en_US" it might fail.

I don't want to rewrite the test to check localized text so there are 
only 2 ways:

1. Force the text to run with "en_US". In Unix, seems setting LANG or 
LC_ALL to "en_US.UTF-8" (these are script tests), but it does not work 
on Windows. I can only think of adding "-J-Duser.language=en 
-J-Duser.country=US" into TESTTOOLVMOPTS.

2. Ignore the text when locale is not en_US. The @requires tag does not 
support user.encoding. Shall I check $LANG or $LC_ALL? Should they 
contain "en_US" on most test machines? Or it's "C"?

Thanks
Max


From joe.darcy at oracle.com  Fri Aug 28 14:40:45 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 28 Aug 2015 07:40:45 -0700
Subject: JDK 9 RFR of JDK-8134678: Problem list
	SecurityManager/CheckPackageAccess.java
Message-ID: <55E072ED.5040209@oracle.com>

Hello,

Please review the patch below to problem list

     java/lang/SecurityManager/CheckPackageMatching.java

while a fix for

         JDK-8134677: SecurityManager/CheckPackageAccess.java still 
failing on windows

is worked on.

Thanks,

-Joe

diff -r 3142555a4a1a test/ProblemList.txt
--- a/test/ProblemList.txt    Thu Aug 27 18:12:45 2015 -0700
+++ b/test/ProblemList.txt    Fri Aug 28 07:38:12 2015 -0700
@@ -136,6 +136,9 @@
  # 8133552
  java/lang/ProcessHandle/InfoTest.java generic-all

+# 8134677
+java/lang/SecurityManager/CheckPackageMatching.java windows-all
+
  ############################################################################

  # jdk_instrument



From lance.andersen at oracle.com  Fri Aug 28 14:48:10 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 28 Aug 2015 10:48:10 -0400
Subject: JDK 9 RFR of JDK-8134678: Problem list
	SecurityManager/CheckPackageAccess.java
In-Reply-To: <55E072ED.5040209@oracle.com>
References: <55E072ED.5040209@oracle.com>
Message-ID: <4D057F02-53A9-47E1-AD6D-06C3E4B7E989@oracle.com>

+1
On Aug 28, 2015, at 10:40 AM, joe darcy  wrote:

> 8134677



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 yoonforh at gmail.com  Sat Aug 29 08:56:59 2015
From: yoonforh at gmail.com (Kyung Koo Yoon)
Date: Sat, 29 Aug 2015 17:56:59 +0900
Subject: JAVADOC clarification needed in Class.getMethod
Message-ID: <52528F0A-2C71-49B8-8CB3-92967B517BD6@gmail.com>

Hi, all.

The javadoc comment of java.lang.Class.getMethod API has following clause.

@CallerSensitive
    public Method getMethod(String name, Class... parameterTypes)
        throws NoSuchMethodException, SecurityException


"The {@code parameterTypes} parameter is an array of {@code Class} 
objects that identify the method's formal parameter types, in declared
 order. If {@code parameterTypes} is {@code null}, it is
 treated as if it were an empty array."

As you know the method signature changed to use varargs since JDK 1.5,
if parameterTypes is given null, the compiler will interpret the parameter with ?new Class[] { null }?.

So, the javadoc comment can?t be happen and inaccurate in the view of the code.

I think it can be safely changed as below. or even better just remove the clause ;

If {@code parameterTypes} is missing, it is treated as if it were an empty array.

Regards,
  Yoon Kyung Koo

-- 
--------------------
 Software Innovation Driver yoonforh at gmail dot com
 Analyze, Reason, Reshape the Question
 PGP  http://www.javadom.com/personal/yoonforhatgmaildotcom.asc 


From yoonforh at gmail.com  Sat Aug 29 13:40:53 2015
From: yoonforh at gmail.com (Kyung Koo Yoon)
Date: Sat, 29 Aug 2015 22:40:53 +0900
Subject: JAVADOC clarification needed in Class.getMethod
In-Reply-To: <55E1AD3D.1060001@gmx.org>
References: <52528F0A-2C71-49B8-8CB3-92967B517BD6@gmail.com>
	<55E1AD3D.1060001@gmx.org>
Message-ID: <4E86E587-82B7-42E8-A1E0-312FF4561D36@gmail.com>

Hi, Jochen.

-- 
--------------------
 Software Innovation Driver yoonforh at gmail dot com
 Analyze, Reason, Reshape the Question
 PGP  http://www.javadom.com/personal/yoonforhatgmaildotcom.asc 
> 2015. 8. 29., ?? 10:01, Jochen Theodorou  ??:
> 
> Am 29.08.2015 10:56, schrieb Kyung Koo Yoon:
>> Hi, all.
>> 
>> The javadoc comment of java.lang.Class.getMethod API has following clause.
>> 
>> @CallerSensitive
>>     public Method getMethod(String name, Class... parameterTypes)
>>         throws NoSuchMethodException, SecurityException
>> 
>> 
>> "The {@code parameterTypes} parameter is an array of {@code Class}
>> objects that identify the method's formal parameter types, in declared
>>  order. If {@code parameterTypes} is {@code null}, it is
>>  treated as if it were an empty array."
>> 
>> As you know the method signature changed to use varargs since JDK 1.5,
>> if parameterTypes is given null, the compiler will interpret the parameter with ?new Class[] { null }?.
> 
> you are making a wrong assumption here. If null is given there will be
> no wrapping in an array.  varargs are defined that there is no wrapping
> if the given argument type is compatible. For Class[] this is Class[]
> and of course null. Even if you had been right, you could still give
> produce a call with null by reflection or using the MethodHandles API

You can check by simply decompiling the generated byte codes.
vararg is not a JVM feature so the compiler pre-processes and the compiler handles the given null as array?s first element.

Originally class.getMethod(?methodName?, null) should have meant a static method, but with vararg, it?s not.

> 
> bye blackdrag
> 
> -- 
> Jochen "blackdrag" Theodorou
> blog: http://blackdragsview.blogspot.com/ 


From yoonforh at gmail.com  Sat Aug 29 13:44:58 2015
From: yoonforh at gmail.com (Kyung Koo Yoon)
Date: Sat, 29 Aug 2015 22:44:58 +0900
Subject: JAVADOC clarification needed in Class.getMethod
In-Reply-To: <4E86E587-82B7-42E8-A1E0-312FF4561D36@gmail.com>
References: <52528F0A-2C71-49B8-8CB3-92967B517BD6@gmail.com>
	<55E1AD3D.1060001@gmx.org>
	<4E86E587-82B7-42E8-A1E0-312FF4561D36@gmail.com>
Message-ID: <964D26CF-0C10-4521-A8AE-D1D0FF06FFAA@gmail.com>


> 2015. 8. 29., ?? 10:40, Kyung Koo Yoon  ??:
> 
> Hi, Jochen.
> 
> -- 
> --------------------
>  Software Innovation Driver yoonforh at gmail dot com
>  Analyze, Reason, Reshape the Question
>  PGP  http://www.javadom.com/personal/yoonforhatgmaildotcom.asc 
>> 2015. 8. 29., ?? 10:01, Jochen Theodorou > ??:
>> 
>> Am 29.08.2015 10:56, schrieb Kyung Koo Yoon:
>>> Hi, all.
>>> 
>>> The javadoc comment of java.lang.Class.getMethod API has following clause.
>>> 
>>> @CallerSensitive
>>>     public Method getMethod(String name, Class... parameterTypes)
>>>         throws NoSuchMethodException, SecurityException
>>> 
>>> 
>>> "The {@code parameterTypes} parameter is an array of {@code Class}
>>> objects that identify the method's formal parameter types, in declared
>>>  order. If {@code parameterTypes} is {@code null}, it is
>>>  treated as if it were an empty array."
>>> 
>>> As you know the method signature changed to use varargs since JDK 1.5,
>>> if parameterTypes is given null, the compiler will interpret the parameter with ?new Class[] { null }?.
>> 
>> you are making a wrong assumption here. If null is given there will be
>> no wrapping in an array.  varargs are defined that there is no wrapping
>> if the given argument type is compatible. For Class[] this is Class[]
>> and of course null. Even if you had been right, you could still give
>> produce a call with null by reflection or using the MethodHandles API
> 
> You can check by simply decompiling the generated byte codes.
> vararg is not a JVM feature so the compiler pre-processes and the compiler handles the given null as array?s first element.
> 
> Originally class.getMethod(?methodName?, null) should have meant a static method, but with vararg, it?s not.

Sorry, static is not correct. should have meant a void method.

> 
>> 
>> bye blackdrag
>> 
>> -- 
>> Jochen "blackdrag" Theodorou
>> blog: http://blackdragsview.blogspot.com/ 


From blackdrag at gmx.org  Sat Aug 29 14:53:14 2015
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Sat, 29 Aug 2015 16:53:14 +0200
Subject: JAVADOC clarification needed in Class.getMethod
In-Reply-To: <4E86E587-82B7-42E8-A1E0-312FF4561D36@gmail.com>
References: <52528F0A-2C71-49B8-8CB3-92967B517BD6@gmail.com>
	<55E1AD3D.1060001@gmx.org>
	<4E86E587-82B7-42E8-A1E0-312FF4561D36@gmail.com>
Message-ID: <55E1C75A.70609@gmx.org>

yeah, you are right, I made a mistake. supplying a null argument t a
method call to call a Class varargs taking method is ambiguous. The
compiler will want you to cast to either Class, in which case the null
would be wrapped, or to Class[], in which case there will be no
wrapping. Example:

public class Foo {
  static void test(Class... params) { System.out.println(params==null);}
  public static void main(String[] args) {test((Class[])null);}
}

javap -c will show for the main method:

>   public static void main(java.lang.String[]);
>     Code:
>        0: aconst_null
>        1: checkcast     #4                  // class "[Ljava/lang/Class;"
>        4: invokestatic  #5                  // Method test:([Ljava/lang/Class;)V
>        7: return

which means no wrapping in an array. But you can bypass the cast through
a different method as well:

public class Foo {
  static void test(Class... params) { System.out.println(params==null);}
  static void bar(Class[] params) {test(params);}
  public static void main(String[] args){bar(null);}
}

since bar already supplies a Class[], it will be directly taken.

But maybe I did misunderstand the intention of your post. In that cae,
sorry for the noise

Am 29.08.2015 15:40, schrieb Kyung Koo Yoon:
> Hi, Jochen.
> 
> -- 
> --------------------
>   Software Innovation Driver yoonforh at gmail dot com
> Analyze, Reason, Reshape the Question
>   PGP http://www.javadom.com/personal/yoonforhatgmaildotcom.asc
> 
>> 2015. 8. 29., ?? 10:01, Jochen Theodorou > > ??:
>>
>> Am 29.08.2015 10:56, schrieb Kyung Koo Yoon:
>>> Hi, all.
>>>
>>> The javadoc comment of java.lang.Class.getMethod API has following 
>>> clause.
>>>
>>> @CallerSensitive
>>>     public Method getMethod(String name, Class... parameterTypes)
>>>         throws NoSuchMethodException, SecurityException
>>>
>>>
>>> "The {@code parameterTypes} parameter is an array of {@code Class}
>>> objects that identify the method's formal parameter types, in declared
>>>  order. If {@code parameterTypes} is {@code null}, it is
>>>  treated as if it were an empty array."
>>>
>>> As you know the method signature changed to use varargs since JDK 1.5,
>>> if parameterTypes is given null, the compiler will interpret the 
>>> parameter with ?new Class[] { null }?.
>>
>> you are making a wrong assumption here. If null is given there will be
>> no wrapping in an array.  varargs are defined that there is no wrapping
>> if the given argument type is compatible. For Class[] this is Class[]
>> and of course null. Even if you had been right, you could still give
>> produce a call with null by reflection or using the MethodHandles API
> 
> You can check by simply decompiling the generated byte codes.
> vararg is not a JVM feature so the compiler pre-processes and the 
> compiler handles the given null as array?s first element.
> 
> Originally class.getMethod(?methodName?, null) should have meant a 
> static method, but with vararg, it?s not.
> 
>>
>> bye blackdrag
>>
>> --
>> Jochen "blackdrag" Theodorou
>> blog:http://blackdragsview.blogspot.com/
> 


-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/



From withoutpointk at gmail.com  Sun Aug 30 22:19:15 2015
From: withoutpointk at gmail.com (Adrian)
Date: Sun, 30 Aug 2015 18:19:15 -0400
Subject: Cache which java classes are in a jar when opening jar the first time
	during classloading
Message-ID: 

Hello,

I have been looking through the JVM source related to class loading.
URLClassLoader#findClass calls URLClassPath#getResource
URLClassPath creates a "loader" for every entry on the classpath (e.g.
one JarLoader per jar file)

In getResource, it loops through all its loaders in order,
instantiating them lazily.
For example, it will only create a JarLoader and open a jar file
somewhere "farther along" the classpath if it did not find the
resource in all the prior jars

URLClassLoader#findClass and URLClassPath#getResource are doing linear
searches on all the entries on the classpath every time they need to
load a resource

For a jar file, if there is an index in META-INF, at least the
corresponding loader can figure out if the jar contains a class right
away.
If not, it searches an internal array/data structure created from the
zipfile central directory (see
jdk/src/share/native/java/util/zip/zip_util.c ZIP_GetEntry - if you
follow the call hiearchy from URLClassPath$JarLoader#getResource, you
end up at this function)

If the jars on the classpath are optimal (majority of the classes are
in the first few jars), there is not much overhead
However, when classes are located in multiple jars along the
classpath, the JVM spends nontrivial time searching through all of
them

One possible "solution" would be create a map of all resources ->
which jar/jar loader they belong in whenever a jar file is opened.
This can be done by iterating over JarFile#entries(), which just reads
the central directory from the jar/zip file (which is done anyways to
create some additional data structures when opening a jar/zip file)

I implemented this to try it out and for a java program with ~1800
classes, it improved the find class time (taken from
sun.misc.PerfCounter.getFindClassTime()) from ~1.4s to ~1s

I tried to think of reasons why this was not done already; looking
through the code, I believe the semantics of the loaders remain the
same.
There is technically a memory overhead of saving this map of resources
-> jar files/loaders, but improves the algorithm complexity from
O(number of jars on classpath) to O(1)

Would appreciate any feedback/insight as to whether this would be a
good change or why it is the way it currently is.
Thank you!

Best regards,
Adrian


From jawnsy at cpan.org  Mon Aug 31 03:02:38 2015
From: jawnsy at cpan.org (Jonathan Yu)
Date: Mon, 31 Aug 2015 03:02:38 +0000
Subject: Cache which java classes are in a jar when opening jar the first
	time during classloading
In-Reply-To: 
References: 
Message-ID: 

Hi Adrian,

It's possible for jar files to be modified while the JVM is running - is
there some facility for detecting that an archive was modified and thus
invalidating the cache?

Also, I wonder how class data sharing might interact with this, though I'll
admit that I don't know much about HotSpot (I use the IBM JVM).

On Sun, Aug 30, 2015, 18:20 Adrian  wrote:

> Hello,
>
> I have been looking through the JVM source related to class loading.
> URLClassLoader#findClass calls URLClassPath#getResource
> URLClassPath creates a "loader" for every entry on the classpath (e.g.
> one JarLoader per jar file)
>
> In getResource, it loops through all its loaders in order,
> instantiating them lazily.
> For example, it will only create a JarLoader and open a jar file
> somewhere "farther along" the classpath if it did not find the
> resource in all the prior jars
>
> URLClassLoader#findClass and URLClassPath#getResource are doing linear
> searches on all the entries on the classpath every time they need to
> load a resource
>
> For a jar file, if there is an index in META-INF, at least the
> corresponding loader can figure out if the jar contains a class right
> away.
> If not, it searches an internal array/data structure created from the
> zipfile central directory (see
> jdk/src/share/native/java/util/zip/zip_util.c ZIP_GetEntry - if you
> follow the call hiearchy from URLClassPath$JarLoader#getResource, you
> end up at this function)
>
> If the jars on the classpath are optimal (majority of the classes are
> in the first few jars), there is not much overhead
> However, when classes are located in multiple jars along the
> classpath, the JVM spends nontrivial time searching through all of
> them
>
> One possible "solution" would be create a map of all resources ->
> which jar/jar loader they belong in whenever a jar file is opened.
> This can be done by iterating over JarFile#entries(), which just reads
> the central directory from the jar/zip file (which is done anyways to
> create some additional data structures when opening a jar/zip file)
>
> I implemented this to try it out and for a java program with ~1800
> classes, it improved the find class time (taken from
> sun.misc.PerfCounter.getFindClassTime()) from ~1.4s to ~1s
>
> I tried to think of reasons why this was not done already; looking
> through the code, I believe the semantics of the loaders remain the
> same.
> There is technically a memory overhead of saving this map of resources
> -> jar files/loaders, but improves the algorithm complexity from
> O(number of jars on classpath) to O(1)
>
> Would appreciate any feedback/insight as to whether this would be a
> good change or why it is the way it currently is.
> Thank you!
>
> Best regards,
> Adrian
>


From withoutpointk at gmail.com  Mon Aug 31 06:01:26 2015
From: withoutpointk at gmail.com (Adrian)
Date: Mon, 31 Aug 2015 02:01:26 -0400
Subject: Cache which java classes are in a jar when opening jar the first
	time during classloading
In-Reply-To: 
References: 
	
Message-ID: 

Hi Jonathan,

I'm not aware of any specific facilities for detecting that a jar file
was modified
I believe as it is it doesn't update its internal structures (the
jzfile and jzcells and jzentries) if it was modified from an outside
source

If I am wrong about that (I don't see any code in class loading/jar
files related to updating itself when modified from outside, but
assuming it does do that), a class -> jar map could still be used to
figure out what jar to start at - something like:

Loader l = cmap.get(name);
if (l != null) {
    Resource res = l.getResource(name);
    if (res != null) {
        return res;
    } else {
        // invalidate cache
        cmap.remove(name);
    }
}

// existing code
for (int i = 0; (loader = getLoader(i)) != null; i++) {

So it will "lazily" invalidate the cache when it can't actually find
the resource in a jar

If a resource was added to a jar closer to the beginning of the
classpath, you would want to load the file from the earlier jar
Of course I don't know for sure, but I can't really imagine use cases
of doing that
If I understand correctly, classloaders are intended to be extensible
so that people can write their custom classloaders for tricky use
cases - in which case they can implement a classloader whose
getResource doesn't use a cache
However, I think the majority of java applications with long
classpaths would benefit from this - for example, I believe HDFS has
~100 jars on its classpath

Thanks for your reply!
Please let me know what you think of this

Best regards,
Adrian



On Sun, Aug 30, 2015 at 11:02 PM, Jonathan Yu  wrote:
> Hi Adrian,
>
> It's possible for jar files to be modified while the JVM is running - is
> there some facility for detecting that an archive was modified and thus
> invalidating the cache?
>
> Also, I wonder how class data sharing might interact with this, though I'll
> admit that I don't know much about HotSpot (I use the IBM JVM).
>
>
> On Sun, Aug 30, 2015, 18:20 Adrian  wrote:
>>
>> Hello,
>>
>> I have been looking through the JVM source related to class loading.
>> URLClassLoader#findClass calls URLClassPath#getResource
>> URLClassPath creates a "loader" for every entry on the classpath (e.g.
>> one JarLoader per jar file)
>>
>> In getResource, it loops through all its loaders in order,
>> instantiating them lazily.
>> For example, it will only create a JarLoader and open a jar file
>> somewhere "farther along" the classpath if it did not find the
>> resource in all the prior jars
>>
>> URLClassLoader#findClass and URLClassPath#getResource are doing linear
>> searches on all the entries on the classpath every time they need to
>> load a resource
>>
>> For a jar file, if there is an index in META-INF, at least the
>> corresponding loader can figure out if the jar contains a class right
>> away.
>> If not, it searches an internal array/data structure created from the
>> zipfile central directory (see
>> jdk/src/share/native/java/util/zip/zip_util.c ZIP_GetEntry - if you
>> follow the call hiearchy from URLClassPath$JarLoader#getResource, you
>> end up at this function)
>>
>> If the jars on the classpath are optimal (majority of the classes are
>> in the first few jars), there is not much overhead
>> However, when classes are located in multiple jars along the
>> classpath, the JVM spends nontrivial time searching through all of
>> them
>>
>> One possible "solution" would be create a map of all resources ->
>> which jar/jar loader they belong in whenever a jar file is opened.
>> This can be done by iterating over JarFile#entries(), which just reads
>> the central directory from the jar/zip file (which is done anyways to
>> create some additional data structures when opening a jar/zip file)
>>
>> I implemented this to try it out and for a java program with ~1800
>> classes, it improved the find class time (taken from
>> sun.misc.PerfCounter.getFindClassTime()) from ~1.4s to ~1s
>>
>> I tried to think of reasons why this was not done already; looking
>> through the code, I believe the semantics of the loaders remain the
>> same.
>> There is technically a memory overhead of saving this map of resources
>> -> jar files/loaders, but improves the algorithm complexity from
>> O(number of jars on classpath) to O(1)
>>
>> Would appreciate any feedback/insight as to whether this would be a
>> good change or why it is the way it currently is.
>> Thank you!
>>
>> Best regards,
>> Adrian


From david.holmes at oracle.com  Mon Aug 31 06:31:44 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 31 Aug 2015 16:31:44 +1000
Subject: Cache which java classes are in a jar when opening jar the first
	time during classloading
In-Reply-To: 
References: 
	
	
Message-ID: <55E3F4D0.1000201@oracle.com>

On 31/08/2015 4:01 PM, Adrian wrote:
> Hi Jonathan,
>
> I'm not aware of any specific facilities for detecting that a jar file
> was modified
> I believe as it is it doesn't update its internal structures (the
> jzfile and jzcells and jzentries) if it was modified from an outside
> source
>
> If I am wrong about that (I don't see any code in class loading/jar
> files related to updating itself when modified from outside, but
> assuming it does do that), a class -> jar map could still be used to
> figure out what jar to start at - something like:
>
> Loader l = cmap.get(name);
> if (l != null) {
>      Resource res = l.getResource(name);
>      if (res != null) {
>          return res;
>      } else {
>          // invalidate cache
>          cmap.remove(name);
>      }
> }
>
> // existing code
> for (int i = 0; (loader = getLoader(i)) != null; i++) {
>
> So it will "lazily" invalidate the cache when it can't actually find
> the resource in a jar
>
> If a resource was added to a jar closer to the beginning of the
> classpath, you would want to load the file from the earlier jar
> Of course I don't know for sure, but I can't really imagine use cases
> of doing that

Such behaviour is not prohibited though so any caching mechanism would 
have to allow for this - and I don't see how it could effectively do so.

> If I understand correctly, classloaders are intended to be extensible
> so that people can write their custom classloaders for tricky use
> cases - in which case they can implement a classloader whose
> getResource doesn't use a cache

I think this would have to be the other way around. If your classloader 
constrains dynamic changes to how it locates classes then it can 
implement a cache.

I believe the upcoming module system would address this issue to some 
extent.

David
-----


> However, I think the majority of java applications with long
> classpaths would benefit from this - for example, I believe HDFS has
> ~100 jars on its classpath
>
> Thanks for your reply!
> Please let me know what you think of this
>
> Best regards,
> Adrian
>
>
>
> On Sun, Aug 30, 2015 at 11:02 PM, Jonathan Yu  wrote:
>> Hi Adrian,
>>
>> It's possible for jar files to be modified while the JVM is running - is
>> there some facility for detecting that an archive was modified and thus
>> invalidating the cache?
>>
>> Also, I wonder how class data sharing might interact with this, though I'll
>> admit that I don't know much about HotSpot (I use the IBM JVM).
>>
>>
>> On Sun, Aug 30, 2015, 18:20 Adrian  wrote:
>>>
>>> Hello,
>>>
>>> I have been looking through the JVM source related to class loading.
>>> URLClassLoader#findClass calls URLClassPath#getResource
>>> URLClassPath creates a "loader" for every entry on the classpath (e.g.
>>> one JarLoader per jar file)
>>>
>>> In getResource, it loops through all its loaders in order,
>>> instantiating them lazily.
>>> For example, it will only create a JarLoader and open a jar file
>>> somewhere "farther along" the classpath if it did not find the
>>> resource in all the prior jars
>>>
>>> URLClassLoader#findClass and URLClassPath#getResource are doing linear
>>> searches on all the entries on the classpath every time they need to
>>> load a resource
>>>
>>> For a jar file, if there is an index in META-INF, at least the
>>> corresponding loader can figure out if the jar contains a class right
>>> away.
>>> If not, it searches an internal array/data structure created from the
>>> zipfile central directory (see
>>> jdk/src/share/native/java/util/zip/zip_util.c ZIP_GetEntry - if you
>>> follow the call hiearchy from URLClassPath$JarLoader#getResource, you
>>> end up at this function)
>>>
>>> If the jars on the classpath are optimal (majority of the classes are
>>> in the first few jars), there is not much overhead
>>> However, when classes are located in multiple jars along the
>>> classpath, the JVM spends nontrivial time searching through all of
>>> them
>>>
>>> One possible "solution" would be create a map of all resources ->
>>> which jar/jar loader they belong in whenever a jar file is opened.
>>> This can be done by iterating over JarFile#entries(), which just reads
>>> the central directory from the jar/zip file (which is done anyways to
>>> create some additional data structures when opening a jar/zip file)
>>>
>>> I implemented this to try it out and for a java program with ~1800
>>> classes, it improved the find class time (taken from
>>> sun.misc.PerfCounter.getFindClassTime()) from ~1.4s to ~1s
>>>
>>> I tried to think of reasons why this was not done already; looking
>>> through the code, I believe the semantics of the loaders remain the
>>> same.
>>> There is technically a memory overhead of saving this map of resources
>>> -> jar files/loaders, but improves the algorithm complexity from
>>> O(number of jars on classpath) to O(1)
>>>
>>> Would appreciate any feedback/insight as to whether this would be a
>>> good change or why it is the way it currently is.
>>> Thank you!
>>>
>>> Best regards,
>>> Adrian


From Alan.Bateman at oracle.com  Mon Aug 31 10:07:28 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 31 Aug 2015 11:07:28 +0100
Subject: Cache which java classes are in a jar when opening jar the first
	time during classloading
In-Reply-To: 
References: 
	
Message-ID: <55E42760.3090109@oracle.com>



On 31/08/2015 04:02, Jonathan Yu wrote:
> Hi Adrian,
>
> It's possible for jar files to be modified while the JVM is running - is
> there some facility for detecting that an archive was modified and thus
> invalidating the cache?
>
Modifying a JAR file that is in use leads to unpredictable behavior and 
can even cause crashes too (when JAR/zip files are memory mapped). That 
said, the class path can extend over time, the most obvious being when 
JAR files have the Class-Path attribute. It is possible to construct a 
cache at run-time that is package name -> the first JAR file containing 
that package but at the cost of scanning the contents of JAR files 
(probably on open). There was a lot of experiments and prototypes in the 
past along these lines.

-Alan.


From pavel.rappo at oracle.com  Mon Aug 31 15:23:47 2015
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Mon, 31 Aug 2015 16:23:47 +0100
Subject: WebSocket client API
Message-ID: <2937E2CD-B7CC-4348-8BCA-A7380BB02ADA@oracle.com>

Hi,

If anybody is interested in discussing WebSocket client API proposed for JDK 9,
you could participate on net-dev mailing list here:

   http://mail.openjdk.java.net/pipermail/net-dev/2015-August/009077.html

I'd be happy to gather as much feedback on it as possible. Thanks.

-Pavel




From Roger.Riggs at Oracle.com  Mon Aug 31 19:42:32 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 31 Aug 2015 15:42:32 -0400
Subject: LittleEndian in DataInputStream
In-Reply-To: <55D4A2DB.1060001@oracle.com>
References: <55D4A2DB.1060001@oracle.com>
Message-ID: <55E4AE28.50709@Oracle.com>

Hi Sergey,

In case this did not get answered...

DataInputStream has a specified encoding of the primitive types.
There are no plans modify its specificaiton.

If you need buffers with byte ordering control, see java.nio.ByteBuffer 
.

Roger


On 8/19/15 11:38 AM, Sergey Bylokhov wrote:
> Hello,
> Does anybody know, do we plan to add LittleEndian support to the 
> DataInputStream or probably to some other InputStream?
>