From aph at redhat.com  Sat Apr  1 08:55:22 2017
From: aph at redhat.com (Andrew Haley)
Date: Sat, 1 Apr 2017 09:55:22 +0100
Subject: RFR 9: 8165641 : Deprecate Object.finalize
In-Reply-To: <CAMOCf+iAT-29E0wu8WFcNiZq1di1xCq=-kSwjdfhkq2cEA1iJA@mail.gmail.com>
References: <c7893765-1c5b-18e3-c5f3-a9ccf9b05094@Oracle.com>
 <96fe9ae0-993a-aea6-cabf-f079450dc128@Oracle.com>
 <49eb0b85-130a-b74d-e760-120674de6ebc@oracle.com>
 <CAMOCf+iAT-29E0wu8WFcNiZq1di1xCq=-kSwjdfhkq2cEA1iJA@mail.gmail.com>
Message-ID: <f25ac4e3-cfba-ea53-2827-775a18d508ad@redhat.com>

On 31/03/17 19:56, Hans Boehm wrote:
> This method should be used when cleanup actions (finalize() calls, or
> Reference enqueuing, Cleaner invocation) could otherwise be triggered while
> a resource under control of the object is still in use. This method should
> normally be called when these cleanup facilities are used to perform
> actions other than simply issuing a warning.

It's still pretty confusing.  It would be simpler to say that
reachabilityFence should be used at the end of every method of a class
which has cleanup actions if you don't want those cleanup actions to
be run before the end of that method.  In that case, reachabilityFence
only makes any difference in cases where otherwise you'd have a bug.

Andrew.

From hboehm at google.com  Sat Apr  1 17:19:05 2017
From: hboehm at google.com (Hans Boehm)
Date: Sat, 1 Apr 2017 10:19:05 -0700
Subject: RFR 9: 8165641 : Deprecate Object.finalize
In-Reply-To: <f25ac4e3-cfba-ea53-2827-775a18d508ad@redhat.com>
References: <c7893765-1c5b-18e3-c5f3-a9ccf9b05094@Oracle.com>
 <96fe9ae0-993a-aea6-cabf-f079450dc128@Oracle.com>
 <49eb0b85-130a-b74d-e760-120674de6ebc@oracle.com>
 <CAMOCf+iAT-29E0wu8WFcNiZq1di1xCq=-kSwjdfhkq2cEA1iJA@mail.gmail.com>
 <f25ac4e3-cfba-ea53-2827-775a18d508ad@redhat.com>
Message-ID: <CAMOCf+j8k5kiTP0_Ue6yO3+68iNUKJvVZLostKZEJoudkDRd2A@mail.gmail.com>

That also sounds fine to me.

The difficulty with applying this, especially in the JNI case, is that you
may need several reachability fences at the end of each method, guarding
parameters and temporaries, not all of which may be naturally in scope at
the end. But we're not going to be able to include a full discussion here.

In the interest of full disclosure, we currently, at least temporarily,
dodge this issue by inhibiting dead variable elimination for references.


On Apr 1, 2017 01:55, "Andrew Haley" <aph at redhat.com> wrote:

On 31/03/17 19:56, Hans Boehm wrote:
> This method should be used when cleanup actions (finalize() calls, or
> Reference enqueuing, Cleaner invocation) could otherwise be triggered
while
> a resource under control of the object is still in use. This method should
> normally be called when these cleanup facilities are used to perform
> actions other than simply issuing a warning.

It's still pretty confusing.  It would be simpler to say that
reachabilityFence should be used at the end of every method of a class
which has cleanup actions if you don't want those cleanup actions to
be run before the end of that method.  In that case, reachabilityFence
only makes any difference in cases where otherwise you'd have a bug.

Andrew.

From claes.redestad at oracle.com  Mon Apr  3 14:31:35 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 3 Apr 2017 16:31:35 +0200
Subject: [10] RFR: 8177631: Outdated performance advice in StringCoding
Message-ID: <7241b6b2-a43b-1b1d-4e6b-8a24f9268b0b@oracle.com>

Hi,

Class.getClassLoader0 was once an expensive native operation, but since 
JDK-6642881
was fixed it is now a simple getter, retrieving a final field injected 
during class load.
Thus the advice in StringCoding that getClass().getClassLoader0 is 
expensive should be
removed.

Webrev: http://cr.openjdk.java.net/~redestad/8177631/jdk.01/
Bugs: https://bugs.openjdk.java.net/browse/JDK-8177631

Thanks!

/Claes

From Roger.Riggs at Oracle.com  Mon Apr  3 14:44:16 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 3 Apr 2017 10:44:16 -0400
Subject: RFR 9: 8165641 : Deprecate Object.finalize
In-Reply-To: <31a37a8c-e3fd-96cf-00a4-090d65c21cff@Oracle.com>
References: <c7893765-1c5b-18e3-c5f3-a9ccf9b05094@Oracle.com>
 <96fe9ae0-993a-aea6-cabf-f079450dc128@Oracle.com>
 <49eb0b85-130a-b74d-e760-120674de6ebc@oracle.com>
 <CAMOCf+iAT-29E0wu8WFcNiZq1di1xCq=-kSwjdfhkq2cEA1iJA@mail.gmail.com>
 <31a37a8c-e3fd-96cf-00a4-090d65c21cff@Oracle.com>
Message-ID: <78e0fb3c-0850-4aa9-9f73-e319e8a8e7b9@Oracle.com>

The api note for Object.finalize is not an optimal location for this 
more general advice,
but is good as far as it can go in relation to the current changes to 
deprecate Object.finalize().

The webrev[1] is updated to add a paragraph to the apiNote[2]:

      * @apiNote
      * Classes that embed non-heap resources have a number of options
      * for cleanup of those resources. The class must ensure that the
      * lifetime of each instance is longer than that of any resource it 
embeds.
      * {@link java.lang.ref.Reference#reachabilityFence} can be used to 
ensure that
      * objects remain reachable while resources embedded in the object 
are in use.

Regards, Roger

[1] http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641
[2] 
http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641/src/java.base/share/classes/java/lang/Object.java.sdiff.html 


From xueming.shen at oracle.com  Mon Apr  3 15:29:27 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 03 Apr 2017 08:29:27 -0700
Subject: [10] RFR: 8177631: Outdated performance advice in StringCoding
In-Reply-To: <7241b6b2-a43b-1b1d-4e6b-8a24f9268b0b@oracle.com>
References: <7241b6b2-a43b-1b1d-4e6b-8a24f9268b0b@oracle.com>
Message-ID: <58E26A57.2020005@oracle.com>

+1

On 4/3/17, 7:31 AM, Claes Redestad wrote:
> Hi,
>
> Class.getClassLoader0 was once an expensive native operation, but 
> since JDK-6642881
> was fixed it is now a simple getter, retrieving a final field injected 
> during class load.
> Thus the advice in StringCoding that getClass().getClassLoader0 is 
> expensive should be
> removed.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8177631/jdk.01/
> Bugs: https://bugs.openjdk.java.net/browse/JDK-8177631
>
> Thanks!
>
> /Claes


From weijun.wang at oracle.com  Mon Apr  3 15:30:34 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 3 Apr 2017 23:30:34 +0800
Subject: [9] RFR 8177969: Faster FilePermission::implies by avoiding the use
 of Path::relativize
Message-ID: <4f1e0c02-a11d-2694-84ad-cf8804021f3c@oracle.com>

http://cr.openjdk.java.net/~weijun/8177969/webrev.00/

This new implementation of containsPath(Path,Path) uses the logic of 
Path::relativize without directly calling it, which is much faster now.

Thanks
Max

From claes.redestad at oracle.com  Mon Apr  3 15:29:26 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 3 Apr 2017 17:29:26 +0200
Subject: [10] RFR: 8177631: Outdated performance advice in StringCoding
In-Reply-To: <58E26A57.2020005@oracle.com>
References: <7241b6b2-a43b-1b1d-4e6b-8a24f9268b0b@oracle.com>
 <58E26A57.2020005@oracle.com>
Message-ID: <edd27c92-08c8-baa6-3ec0-55d4b8992d75@oracle.com>


On 04/03/2017 05:29 PM, Xueming Shen wrote:
> +1

Thanks Sherman!

/Claes

From hboehm at google.com  Mon Apr  3 17:34:17 2017
From: hboehm at google.com (Hans Boehm)
Date: Mon, 3 Apr 2017 10:34:17 -0700
Subject: RFR 9: 8165641 : Deprecate Object.finalize
In-Reply-To: <78e0fb3c-0850-4aa9-9f73-e319e8a8e7b9@Oracle.com>
References: <c7893765-1c5b-18e3-c5f3-a9ccf9b05094@Oracle.com>
 <96fe9ae0-993a-aea6-cabf-f079450dc128@Oracle.com>
 <49eb0b85-130a-b74d-e760-120674de6ebc@oracle.com>
 <CAMOCf+iAT-29E0wu8WFcNiZq1di1xCq=-kSwjdfhkq2cEA1iJA@mail.gmail.com>
 <31a37a8c-e3fd-96cf-00a4-090d65c21cff@Oracle.com>
 <78e0fb3c-0850-4aa9-9f73-e319e8a8e7b9@Oracle.com>
Message-ID: <CAMOCf+i8q43nr7vbTJKqxVATy1ryVEqxtujtWWWMvgwR06UWbw@mail.gmail.com>

Thanks!

I think that helps a lot.


On Mon, Apr 3, 2017 at 7:44 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> The api note for Object.finalize is not an optimal location for this more
> general advice,
> but is good as far as it can go in relation to the current changes to
> deprecate Object.finalize().
>
> The webrev[1] is updated to add a paragraph to the apiNote[2]:
>
>      * @apiNote
>      * Classes that embed non-heap resources have a number of options
>      * for cleanup of those resources. The class must ensure that the
>      * lifetime of each instance is longer than that of any resource it
> embeds.
>      * {@link java.lang.ref.Reference#reachabilityFence} can be used to
> ensure that
>      * objects remain reachable while resources embedded in the object are
> in use.
>
> Regards, Roger
>
> [1] http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641
> [2] http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate
> -8165641/src/java.base/share/classes/java/lang/Object.java.sdiff.html
>

From paul.sandoz at oracle.com  Mon Apr  3 19:39:28 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 3 Apr 2017 12:39:28 -0700
Subject: RFR [9] 8177738: Runtime.Version must be a value-based class
In-Reply-To: <F30BD3B5-723E-4688-81AB-7A30BD8C8474@oracle.com>
References: <F30BD3B5-723E-4688-81AB-7A30BD8C8474@oracle.com>
Message-ID: <FB9AF92C-FA60-4E00-A68B-8DBE55910C33@oracle.com>

Hi,

962 * [1-9][0-9]*((\.0)*\.[1-9][0-9]*)*

You removed the initial ?^? which is still mentioned in JDK-8148822

< `^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$`. The sequence may be of arbitrary
---
> `^[1-9][0-9]*((\.0)*\.[1-9][0-9]*)*$`. The sequence may be of arbitrary

JEP 223 is still using the former. Which is correct?

Since Version is now value based i think you need to check where it?s identity is used and replace with equals (which means ensuring that equals is efficient and could use identity under the covers). See usages in JarFile.

?

Separately i wish we could avoid using List<Integer> as the internal representation, it?s very inefficient, int[] is much better, the cost is then on the version() method but it?s easy to create an immutable List wrapping the array. (I logged an issue for that, but cannot remember the number.)

You patch gets us closer to that, especially with the change to parseVersionNumbers method.

Paul.



> On 30 Mar 2017, at 10:04, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> Hello,
> 
> Please review the following change:
> 
>    http://cr.openjdk.java.net/~prappo/8177738/webrev.00/
> 
> This is an attempt to resolve a group of issues related to Version-String API
> and its implementation:
> 
>    8177738: Runtime.Version must be a value-based class
>    8148822: (spec) Regex in Runtime.Version and JEP 223 should match
>    8160954: (spec) Runtime.Version regex and $PRE/$OPT issues
>    8148877: (spec) Specify when an empty '+' is required in a version string
> 
> A good amount of work has been already done here and we just need to finish it.
> Let me explain what this patch does starting from the most trivial changes.
> 
> - Fixes certain javadoc issues [a] (e.g. dangling html tags, overly qualified
> symbol references in @link tags, etc.)
> 
> - Refactors Basic.java test, making it a little bit easier to read/modify this
> test in the future.
> 
> - Addresses [2] in Runtime.java:963,1050. In addition I've rephrased Runtime.java:951
> to reflect the fact a version string contains only the mentioned components and
> nothing else. In other words, $VSTR *matches* a valid version-string rather than
> *finds* itself somewhere in this version-string.
> 
> - Makes Runtime.Version a value-based class [1][5]. The class has gotten `final`
> modifier, the only constructor has become private and the usual (in this case)
> verbiage has been added to the javadoc. Before that, Runtime.Version had ticked
> all other the boxes in the value-based class checklist already.
> 
> - Improves $VNUM list mechanics in VersionProps.java.template and Runtime.java:1149-1153
> by providing immutable list instead of unmodifiable. This change has become
> possible due to the fact Runtime.Version constructor has become private and,
> thus, all the callers are known and trusted.
> 
> - Removes redundant/explicit javadoc declarations in `hashCode`, `equals` and
> `compareTo` methods. These methods are documented needlessly explicit. The only
> truly justified comment sits inside `compareToIgnoreOptional` method.
> Since `compareToIgnoreOptional` and `equalsIgnoreOptional` are not inherited,
> I marked the "consistent-with" relationship between them explicitly [c].
> 
> - Now a few words about a not-so-pleasant part which addresses [3][4]. In a
> nutshell the regex-style format ($VSTR) which is used in the spec to define the
> version-string, matches all valid version strings and *some more*.
> 
> Here's the format:
> 
>    $VNUM(-$PRE)?(\+($BUILD)?(-$OPT)?)?
> 
> If we expand all optional elements we will get the following 8 possibilities:
> 
>  ##     $VSTR                      $PRE $BUILD $OPT    EXAMPLE
> --------------------------------------------------------------------------------
>  1      $VNUM                         0      0    0    9.0.1
>  2      $VNUM+-$OPT                   0      0    1    9.0.1+-longcat.dev
>  3      $VNUM+$BUILD                  0      1    0    9.0.1+256
>  4      $VNUM+$BUILD-$OPT             0      1    1    9.0.1+256-longcat.dev
>  5      $VNUM-$PRE                    1      0    0    9.0.1-ea
> * 6      $VNUM-$PRE+-$OPT              1      0    1    9.0.1-ea+-longcat.dev
>  7      $VNUM-$PRE+$BUILD             1      1    0    9.0.1-ea+256
>  8      $VNUM-$PRE+$BUILD-$OPT        1      1    1    9.0.1-ea+256-longcat.dev
> 
> Now, ##6 was disallowed by design. In the case when $BUILD is not present, but
> both $PRE and $OPT are, the $VSTR will instead look like this:
> 
>  6      $VNUM-$PRE-$OPT               1      0    1    9.0.1-ea-longcat.dev
> 
> (i.e. without the "+" separator).
> 
> This is a problem because it means that in addition to the format it needs a
> clear description of exceptional cases which are to be subtracted from the set
> of matched version-strings. Such a description has been proposed in [6] (you can
> have a look at the webrev that thread refers to):
> 
>    * <p> If the build number is unset, then {@code '+'} may only be present
>    * when {@code $OPT} is present and {@code $PRE} is not.
> 
> It indeed may be a satisfactory solution. However I would argue that it's
> probably not the best one. I suspect spec readers will jump straight to the
> format completely missing "the special case" paragraph simply because the format
> attracts attention and neatly defines the version-string. Neatly but wrongly.
> 
> Another option would be to split the $VSTR format into a minimal number of
> sub-cases (e.g. Runtime:1032-1034). This will require no extra "special case"
> paragraph and will draw reader's attention to all the subtleties on the spot.
> 
>  #                                       ##
> --------------------------------------------------------------------------------
>  1      $VNUM(-$PRE)?\+$BUILD(-$OPT)?    3, 4, 7, 8
>  2      $VNUM-$PRE(-$OPT)?               5, 6
>  3      $VNUM(+-$OPT)?                   1, 2
> 
> One more option would be to require "+" to be there in the case where any
> component to the right from $PRE is present (i.e. $BUILD or $OPT or both).
> This will greatly simplify the rules and allow the $VSTR to stay as it is today.
> 
> This option would affect only the case ##6:
> 
>  6      $VNUM-$PRE+-$OPT              1      0    1    9.0.1-ea+-longcat.dev
>                   ^^
> Yes, it looks a bit ugly, but we already have this ugliness in case 2 (and we
> can't get rid of it because of [3]):
> 
>  2      $VNUM+-$OPT                   0      0    1    9.0.1+-longcat.dev
>              ^^
> I suspect both 2 and 6 will be pretty rare anyway as it would mean optional
> build information is there, but the build number is not.
> Sounds like a corner case to me.
> 
> Thanks,
> -Pavel
> 
> --------------------------------------------------------------------------------
> [1] https://bugs.openjdk.java.net/browse/JDK-8177738
> [2] https://bugs.openjdk.java.net/browse/JDK-8148822
> [3] https://bugs.openjdk.java.net/browse/JDK-8148877
> [4] https://bugs.openjdk.java.net/browse/JDK-8160954
> [5] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046813.html
> [6] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-October/044277.html
> 
> [a] If you build locally or use promoted builds, please keep in mind there's a
>    known issue with rendering documentation for Runtime.Version in
>    some browsers: https://bugs.openjdk.java.net/browse/JDK-8177727
> [b] Startup time/memory footprint might benefit as well (it will definitely
>    require some benchmarking to determine if it is the case)
> [c] Even though I'm fully aware I do not have the full knowledge the design
>    decisions were based upon, I must say I fail to see why equalsIgnoreOptional
>    and compareToIgnoreOptional methods have been introduced from the day 1.
>    It looks like something that could be neatly solved by providing a custom
>    Comparator if needed.
> 


From paul.sandoz at oracle.com  Mon Apr  3 20:05:12 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 3 Apr 2017 13:05:12 -0700
Subject: RFR: jsr166 jdk10 integration wave 1
In-Reply-To: <CA+kOe08uSpzDZM7Shxf2NDM0GhzK3A9dNf5s0=UcvuhEGN3hjw@mail.gmail.com>
References: <CA+kOe0-0fDs7w=Pt95Rc6LKPJOFCdcGfuAh2BZoQm6A9-jdWmw@mail.gmail.com>
 <CA+kOe08=CkCFAhD03dO53WB29N4i5t2V2ErerZ9T+7e2C2bPOg@mail.gmail.com>
 <CA+kOe08uSpzDZM7Shxf2NDM0GhzK3A9dNf5s0=UcvuhEGN3hjw@mail.gmail.com>
Message-ID: <F3FBAB56-C286-44C9-9FC2-6C34FC6FFCC8@oracle.com>

Hi,

Looks good.

It?s trivial but we probably require a CCC for ScheduledThreadPoolExecutor calling out the NPE for null unit argument values, to clarify pool sizes of TPE, and to clarify that AbortPolicy default handler for TPE *and* STPE. We are not quite there yet with the CCC being open (soon i hope!), so i can create the CCC for you.

Paul.


> On 30 Mar 2017, at 14:38, Martin Buchholz <martinrb at google.com> wrote:
> 
> OK, this wave is open for review again.
> 
> On Wed, Mar 29, 2017 at 12:57 PM, Martin Buchholz <martinrb at google.com> wrote:
> Oops.  Martin forgot to check ScheduledExecutorService, and there's some overlap in specs, which requires some rework.
> 
> On Wed, Mar 29, 2017 at 11:43 AM, Martin Buchholz <martinrb at google.com> wrote:
> First jdk10 integration
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/
> 
> Mostly focused on thread pools.
> 
> 


From pavel.rappo at oracle.com  Mon Apr  3 23:40:30 2017
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 4 Apr 2017 00:40:30 +0100
Subject: RFR [9] 8177738: Runtime.Version must be a value-based class
In-Reply-To: <FB9AF92C-FA60-4E00-A68B-8DBE55910C33@oracle.com>
References: <F30BD3B5-723E-4688-81AB-7A30BD8C8474@oracle.com>
 <FB9AF92C-FA60-4E00-A68B-8DBE55910C33@oracle.com>
Message-ID: <23774589-8C1C-4BA1-B5E8-4A25BCF58560@oracle.com>


> On 3 Apr 2017, at 20:39, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> 962 * [1-9][0-9]*((\.0)*\.[1-9][0-9]*)*
> 
> You removed the initial ?^? which is still mentioned in JDK-8148822
> 
> < `^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$`. The sequence may be of arbitrary
> ---
>> `^[1-9][0-9]*((\.0)*\.[1-9][0-9]*)*$`. The sequence may be of arbitrary
> 
> JEP 223 is still using the former. Which is correct?

The patch from the thread [1] I referred to in my previous email removes ^ and $. 
So in this case I simply reused the patch and, once again [2], I do agree this
is an odd place to use boundary matchers, given $VNUM is only a prefix in $VSTR
and not the whole regex.

As for the JEP question, it's more for original designers/authors. If we agree
on it I will update the JEP.

> Since Version is now value based i think you need to check where it?s identity is used and replace with equals (which means ensuring that equals is efficient and could use identity under the covers). See usages in JarFile.

Will do, thanks!

> ?
> 
> Separately i wish we could avoid using List<Integer> as the internal representation, it?s very inefficient, int[] is much better, the cost is then on the version() method but it?s easy to create an immutable List wrapping the array. (I logged an issue for that, but cannot remember the number.)

What are you concerns specifically? 
The startup time? 
The amount of simultaneously existing Version objects at runtime?
The use of `Integer` wrapper?

--------------------------------------------------------------------------------
[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-October/044277.html
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046941.html



From paul.sandoz at oracle.com  Mon Apr  3 23:50:47 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 3 Apr 2017 16:50:47 -0700
Subject: RFR [9] 8177738: Runtime.Version must be a value-based class
In-Reply-To: <23774589-8C1C-4BA1-B5E8-4A25BCF58560@oracle.com>
References: <F30BD3B5-723E-4688-81AB-7A30BD8C8474@oracle.com>
 <FB9AF92C-FA60-4E00-A68B-8DBE55910C33@oracle.com>
 <23774589-8C1C-4BA1-B5E8-4A25BCF58560@oracle.com>
Message-ID: <4547C274-290D-442F-BBD6-AB7E7837936A@oracle.com>


> On 3 Apr 2017, at 16:40, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> 
>> On 3 Apr 2017, at 20:39, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>> Hi,
>> 
>> 962 * [1-9][0-9]*((\.0)*\.[1-9][0-9]*)*
>> 
>> You removed the initial ?^? which is still mentioned in JDK-8148822
>> 
>> < `^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$`. The sequence may be of arbitrary
>> ---
>>> `^[1-9][0-9]*((\.0)*\.[1-9][0-9]*)*$`. The sequence may be of arbitrary
>> 
>> JEP 223 is still using the former. Which is correct?
> 
> The patch from the thread [1] I referred to in my previous email removes ^ and $.
> So in this case I simply reused the patch and, once again [2], I do agree this
> is an odd place to use boundary matchers, given $VNUM is only a prefix in $VSTR
> and not the whole regex.
> 
> As for the JEP question, it's more for original designers/authors. If we agree
> on it I will update the JEP.
> 

Ok, no objections, i was just unsure as to which was the proposed authoritative answer. Perhaps for the record you should also update the description of JDK-8148822?


>> Since Version is now value based i think you need to check where it?s identity is used and replace with equals (which means ensuring that equals is efficient and could use identity under the covers). See usages in JarFile.
> 
> Will do, thanks!
> 
>> ?
>> 
>> Separately i wish we could avoid using List<Integer> as the internal representation, it?s very inefficient, int[] is much better, the cost is then on the version() method but it?s easy to create an immutable List wrapping the array. (I logged an issue for that, but cannot remember the number.)
> 
> What are you concerns specifically?

It?s just not particularly efficient to box int to Integer into a List on the heap esp for the expected number of version components, and i suspect the version() method probably not something that will often be called, so taking a hit there with a AbstractList wrapper is fine. It?s quite a simple change, esp. with the the foundation you have set up, so seems worthwhile (separate issue, not this one).

Paul.


> 
> The startup time?
> The amount of simultaneously existing Version objects at runtime?
> The use of `Integer` wrapper?
> 
> --------------------------------------------------------------------------------
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-October/044277.html
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046941.html
> 
> 


From martinrb at google.com  Tue Apr  4 02:51:10 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 3 Apr 2017 19:51:10 -0700
Subject: RFR: jsr166 jdk10 integration wave 1
In-Reply-To: <F3FBAB56-C286-44C9-9FC2-6C34FC6FFCC8@oracle.com>
References: <CA+kOe0-0fDs7w=Pt95Rc6LKPJOFCdcGfuAh2BZoQm6A9-jdWmw@mail.gmail.com>
 <CA+kOe08=CkCFAhD03dO53WB29N4i5t2V2ErerZ9T+7e2C2bPOg@mail.gmail.com>
 <CA+kOe08uSpzDZM7Shxf2NDM0GhzK3A9dNf5s0=UcvuhEGN3hjw@mail.gmail.com>
 <F3FBAB56-C286-44C9-9FC2-6C34FC6FFCC8@oracle.com>
Message-ID: <CA+kOe09yVTUQVzdLkxqwMwEZmGB9P2GZdF=8iEeZ6U9wcCCvQw@mail.gmail.com>

Thanks!

On Mon, Apr 3, 2017 at 1:05 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> Looks good.
>
> It?s trivial but we probably require a CCC for ScheduledThreadPoolExecutor
> calling out the NPE for null unit argument values, to clarify pool sizes of
> TPE, and to clarify that AbortPolicy default handler for TPE *and* STPE. We
> are not quite there yet with the CCC being open (soon i hope!), so i can
> create the CCC for you.
>
> Paul.
>
>
> > On 30 Mar 2017, at 14:38, Martin Buchholz <martinrb at google.com> wrote:
> >
> > OK, this wave is open for review again.
> >
> > On Wed, Mar 29, 2017 at 12:57 PM, Martin Buchholz <martinrb at google.com>
> wrote:
> > Oops.  Martin forgot to check ScheduledExecutorService, and there's some
> overlap in specs, which requires some rework.
> >
> > On Wed, Mar 29, 2017 at 11:43 AM, Martin Buchholz <martinrb at google.com>
> wrote:
> > First jdk10 integration
> >
> > http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/
> >
> > Mostly focused on thread pools.
> >
> >
>
>

From claes.redestad at oracle.com  Tue Apr  4 13:51:48 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 4 Apr 2017 15:51:48 +0200
Subject: Bytestacks: bytecode level diagnostic tool for JVM startup analysis
Message-ID: <b754cb98-acde-7845-35eb-ad769df45572@oracle.com>

Hi core-libs,

some might be aware that I've been working on startup performance, 
sometimes finding a thing or
two in the JDK core libraries that can be improved...

Initially this was mostly guess-work based on changes that were found to 
have caused regressions,
but I've also been experimenting with a tool to more systematically 
visualize and analyze what's going
on during startup, bytecode-by-bytecode.

This has turned out to be very useful at pinpointing sources of startup 
regressions, and I've now cleaned
it up enough to publish a first version of it:

http://cr.openjdk.java.net/~redestad/bytestacks/bytecode-startup-analysis.html

I hope someone here will find this useful, and if there's interest in 
seeing this developed further then I hope
I can find it a home in some more formalized (codetools?) project.

Thanks!

/Claes


From joe.darcy at oracle.com  Tue Apr  4 17:53:30 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 4 Apr 2017 10:53:30 -0700
Subject: JDK 9 RFR of JDK-8177949: @link tag arguments need correction for
 ElementType documentation
Message-ID: <a76d0810-f31f-4ba6-c987-7b3472083b61@oracle.com>

Hello,

Please review the innocuous doc-only patch below to fix

     JDK-8177949: @link tag arguments need correction for ElementType 
documentation

Thanks,

-Joe


diff -r 1a8997b4292d 
src/java.base/share/classes/java/lang/annotation/ElementType.java
--- a/src/java.base/share/classes/java/lang/annotation/ElementType.java 
Tue Apr 04 08:10:13 2017 -0700
+++ b/src/java.base/share/classes/java/lang/annotation/ElementType.java 
Tue Apr 04 10:51:16 2017 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2003, 2017, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -28,7 +28,7 @@
  /**
   * The constants of this enumerated type provide a simple 
classification of the
   * syntactic locations where annotations may appear in a Java program. 
These
- * constants are used in {@link Target java.lang.annotation.Target}
+ * constants are used in {@link java.lang.annotation.Target Target}
   * meta-annotations to specify where it is legal to write annotations of a
   * given type.
   *


From lance.andersen at oracle.com  Tue Apr  4 17:55:15 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 4 Apr 2017 13:55:15 -0400
Subject: JDK 9 RFR of JDK-8177949: @link tag arguments need correction for
 ElementType documentation
In-Reply-To: <a76d0810-f31f-4ba6-c987-7b3472083b61@oracle.com>
References: <a76d0810-f31f-4ba6-c987-7b3472083b61@oracle.com>
Message-ID: <CC60647C-CB0B-4D73-AAF2-0FF3B38787E2@oracle.com>

+1
> On Apr 4, 2017, at 1:53 PM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Please review the innocuous doc-only patch below to fix
> 
>    JDK-8177949: @link tag arguments need correction for ElementType documentation
> 
> Thanks,
> 
> -Joe
> 
> 
> diff -r 1a8997b4292d src/java.base/share/classes/java/lang/annotation/ElementType.java
> --- a/src/java.base/share/classes/java/lang/annotation/ElementType.java Tue Apr 04 08:10:13 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/annotation/ElementType.java Tue Apr 04 10:51:16 2017 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2013, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2017, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -28,7 +28,7 @@
> /**
>  * The constants of this enumerated type provide a simple classification of the
>  * syntactic locations where annotations may appear in a Java program. These
> - * constants are used in {@link Target java.lang.annotation.Target}
> + * constants are used in {@link java.lang.annotation.Target Target}
>  * meta-annotations to specify where it is legal to write annotations of a
>  * given type.
>  *
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From stuart.marks at oracle.com  Tue Apr  4 19:52:44 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 4 Apr 2017 12:52:44 -0700
Subject: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()
 regardingpossible infinite streams
In-Reply-To: <cc200e33-24dc-df27-1c56-dc11bf695c36@oracle.com>
References: <ca6ee328-1121-ed95-48ca-92cf5be02c0e@oracle.com>
 <58DC7E53.6040603@oracle.com> <58dd2aba.298fdf0a.86cca.3418@mx.google.com>
 <cc200e33-24dc-df27-1c56-dc11bf695c36@oracle.com>
Message-ID: <fc36e657-a196-6f3e-bd42-fb1bdc741205@oracle.com>

Anything further on this?

I'd at least like to add the API note I proposed in order to document this 
issue. I'm reluctant to start tinkering with the behavior of this method at this 
late stage in the release.

BTW I used Scanner.findAll() in a little programming exercise I worked on the 
other day. It worked perfectly. :-)

s'marks

On 3/30/17 2:19 PM, Stuart Marks wrote:
> Hi Timo, Sherman,
>
> Thanks for looking at this.
>
> Sherman wrote:
>
>> This might practically put the api itself almost useless? it might be an easy
>> task to spot
>> whether or not it's a 0-width-match-possible regex when the regex is simple,
>> but it gets
>> harder and harder, if not impossible when the regex gets complicated,
>> especially consider
>> the possible use scenario that the use site is embedded deeply inside a
>> library implementation.
>
> Well, not "useless", but perhaps less useful than one might like. :-)
>
> I think this is potentially surprising behavior, which is why I at least wanted
> to add the note. It's not clear to me whether we should try to fix this by
> changing Scanner though.
>
> Essentially, findAll() is defined in terms of findWithinHorizon(pattern, 0). So
> if one were to write a loop like so:
>
>     String str;
>     while ((str = scanner.findWithinHorizon(pattern, 0)) != null) {
>         System.out.println(str);
>     }
>
> then this loop would have the same problem if pattern were to match zero
> characters.
>
>> The alternative is to "fix" it, maybe as what Matcher.find() does, if the
>> previous match is
>> zero-width-match (the fist==last), we step one to the next cursor before next
>> try. I know
>
> Interesting, I didn't know Matcher.find() advances the cursor like this. But
> Scanner.findWithinHorizon() apparently doesn't, so that's why an infinite loop
> can occur.
>
>> Scanner.findPatternInBuffer() is setting new region set every time it is
>> invoked which makes
>> it complicated, but I would assume it might be still worth a trying? for
>> example, utilize the
>> "hasNextResult"/matcher.end(). I'm not sure without looking into the code, does
>>
>> while (hasNext(pattern)) {
>>     next(pattern);
>> }
>>
>> have the same issue, when pattern matches 0-width?
>
> No, this doesn't have the problem, because hasNext(pat) and next(pat) match
> delimited tokens. Each call to next() implicitly advances past the next
> delimiter to reach the subsequent token, if any.
>
>
> On 3/30/17 8:56 AM, Timo Kinnunen wrote:
>> I guess this somewhat contrived example also wouldn?t work?
>>
>>         String s = "\\b\\w+|\\G|\\B";
>>         String t = "Matcher m = Pattern.compile(s).matcher(t);\n";
>>         Matcher m = Pattern.compile(s).matcher(t);
>>         while(m.find()) {
>>             System.out.println("'" + m.group() + "'");
>>         }
>
> Right, so if you rewrote this loop to use Scanner.findWithinHorizon() instead of
> Matcher,
>
>     Scanner sc = new Scanner(t);
>     String str;
>     while ((str = sc.findWithinHorizon(s, 0)) != null) {
>         System.out.println("'" + str + "'");
>     }
>
> you'd get an infinite loop with str being continually assigned the empty string.
> As Sherman mentioned, the Matcher.find() will advance the cursor if it gets a
> zero-width match, avoiding this problem.
>
> * * *
>
> This didn't come up in the code review thread, which was mostly about concurrent
> modification and late-binding of the spliterator:
>
>   http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035034.html
>
> I remember noting this phenomenon a while back, which is why I had filed the bug
> to add a note. I seem to remember discussing it, though, but it might have been
> in a meeting or in a hallway conversation.
>
> This bug (JDK-8150488) does note that an infinite stream might be unexpected or
> surprising, but it's not a fatal problem. It can be terminated with limit(). It
> can also be terminated with takeWhile(), also added in JDK 9. Maybe I could
> mention these in the API note.
>
> I guess we could also consider changing the implicit findWithinHorizon() loop
> that findAll() does, perhaps by having it terminate on a zero-width match. Or we
> could even change findWithinHorizon's behavior if it gets a zero-width match,
> siilar to what Matcher.find() does. But I'm quite reluctant to start making such
> changes at this point.
>
> s'marks
>
>
>
>>         // Outputs:
>>         // 'Matcher'
>>         // ''
>>         // 'm'
>>         // ''
>>         // ''
>>         // ''
>>         // 'Pattern'
>>         // ''
>>         // 'compile'
>>         // ''
>>         // 's'
>>         // ''
>>         // ''
>>         // 'matcher'
>>         // ''
>>         // 't'
>>         // ''
>>         // ''
>>         // ''
>>         // ''
>>
>>
>>
>> Sent from Mail for Windows 10
>>
>> From: Xueming Shen
>> Sent: Thursday, March 30, 2017 05:41
>> To: core-libs-dev at openjdk.java.net
>> Subject: Re: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()
>> regardingpossible infinite streams
>>
>> On 3/29/17, 5:56 PM, Stuart Marks wrote:
>>> Hi all,
>>>
>>> Please review these non-normative textual additions to the
>>> Scanner.findAll() method docs. These methods were added earlier in JDK
>>> 9; there's a small pitfall if the regex can match zero characters.
>>>
>> Stuart,
>>
>> This might practically put the api itself almost useless? it might be an
>> easy task to spot
>> whether or not it's a 0-width-match-possible regex when the regex is
>> simple, but it gets
>> harder and harder, if not impossible when the regex gets complicated,
>> especially consider
>> the possible use scenario that the use site is embedded deeply inside a
>> library implementation.
>>
>> The alternative is to "fix" it, maybe as what Matcher.find() does, if
>> the previous match is
>> zero-width-match (the fist==last), we step one to the next cursor before
>> next try. I know
>> Scanner.findPatternInBuffer() is setting new region set every time it is
>> invoked which makes
>> it complicated, but I would assume it might be still worth a trying? for
>> example, utilize the
>> "hasNextResult"/matcher.end(). I'm not sure without looking into the
>> code, does
>>
>> while (hasNext(pattern)) {
>>      next(pattern);
>> }
>>
>> have the same issue, when pattern matches 0-width?
>>
>> Thanks!
>> -Sherman
>>
>>
>>
>>
>>> Thanks,
>>>
>>> s'marks
>>>
>>>
>>> # HG changeset patch
>>> # User smarks
>>> # Date 1490749958 25200
>>> #      Tue Mar 28 18:12:38 2017 -0700
>>> # Node ID 6b43c4698752779793d58813f46d3687c17dde75
>>> # Parent  fb54b256d751ae3191e9cef42ff9f5630931f047
>>> 8150488: add note to Scanner.findAll() regarding possible infinite
>>> streams
>>> Reviewed-by: XXX
>>>
>>> diff -r fb54b256d751 -r 6b43c4698752
>>> src/java.base/share/classes/java/util/Scanner.java
>>> --- a/src/java.base/share/classes/java/util/Scanner.java    Mon Mar 27
>>> 15:12:01 2017 -0700
>>> +++ b/src/java.base/share/classes/java/util/Scanner.java    Tue Mar 28
>>> 18:12:38 2017 -0700
>>> @@ -2808,6 +2808,10 @@
>>>       * }
>>>       * }</pre>
>>>       *
>>> +     * <p>The pattern must always match at least one character. If
>>> the pattern
>>> +     * can match zero characters, the result will be an infinite stream
>>> +     * of empty matches.
>>> +     *
>>>       * @param pattern the pattern to be matched
>>>       * @return a sequential stream of match results
>>>       * @throws NullPointerException if pattern is null
>>> @@ -2829,6 +2833,11 @@
>>>       *     scanner.findAll(Pattern.compile(patString))
>>>       * }</pre>
>>>       *
>>> +     * @apiNote
>>> +     * The pattern must always match at least one character. If the
>>> pattern
>>> +     * can match zero characters, the result will be an infinite stream
>>> +     * of empty matches.
>>> +     *
>>>       * @param patString the pattern string
>>>       * @return a sequential stream of match results
>>>       * @throws NullPointerException if patString is null
>>
>>

From xueming.shen at oracle.com  Tue Apr  4 23:10:32 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 04 Apr 2017 16:10:32 -0700
Subject: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()
 regardingpossible infinite streams
In-Reply-To: <fc36e657-a196-6f3e-bd42-fb1bdc741205@oracle.com>
References: <ca6ee328-1121-ed95-48ca-92cf5be02c0e@oracle.com>
 <58DC7E53.6040603@oracle.com> <58dd2aba.298fdf0a.86cca.3418@mx.google.com>
 <cc200e33-24dc-df27-1c56-dc11bf695c36@oracle.com>
 <fc36e657-a196-6f3e-bd42-fb1bdc741205@oracle.com>
Message-ID: <58E427E8.2020901@oracle.com>

On 4/4/17, 12:52 PM, Stuart Marks wrote:
> Anything further on this?
>
> I'd at least like to add the API note I proposed in order to document 
> this issue. I'm reluctant to start tinkering with the behavior of this 
> method at this late stage in the release.
>
> BTW I used Scanner.findAll() in a little programming exercise I worked 
> on the other day. It worked perfectly. :-)

H Stuart,

The word "useless" was definitely exaggerate :-) Really meant to say the 
note might make the api less
useful/popular.

Personally I think the use scenario and the expected resulting behavior 
of Stream<MR>finaAll(ptn)
should be more equivalent/similar to the use case  of while 
(s.hasNext(p)) {   s.next(p); }, or while
(m.find()) { }, therefor it is probably desired it can be used without 
worrying the possibility of getting
into an infinite loop. That said, I agree it might be hard to argue to 
fix it in jdk9. The question is if
we are going to fix it in 9u sometime in the further, is it still worth 
putting down the note in the
API now. I'm fine if you believe a note will help at least make the 
issue a known/documented usage
limitation, for JDK9.

Yes, I think we did chat about this one at the hallway some time when 
either you or something
ran into the loop by using the method ...

Thanks,
Sherman


>
> s'marks
>
> On 3/30/17 2:19 PM, Stuart Marks wrote:
>> Hi Timo, Sherman,
>>
>> Thanks for looking at this.
>>
>> Sherman wrote:
>>
>>> This might practically put the api itself almost useless? it might 
>>> be an easy
>>> task to spot
>>> whether or not it's a 0-width-match-possible regex when the regex is 
>>> simple,
>>> but it gets
>>> harder and harder, if not impossible when the regex gets complicated,
>>> especially consider
>>> the possible use scenario that the use site is embedded deeply inside a
>>> library implementation.
>>
>> Well, not "useless", but perhaps less useful than one might like. :-)
>>
>> I think this is potentially surprising behavior, which is why I at 
>> least wanted
>> to add the note. It's not clear to me whether we should try to fix 
>> this by
>> changing Scanner though.
>>
>> Essentially, findAll() is defined in terms of 
>> findWithinHorizon(pattern, 0). So
>> if one were to write a loop like so:
>>
>>     String str;
>>     while ((str = scanner.findWithinHorizon(pattern, 0)) != null) {
>>         System.out.println(str);
>>     }
>>
>> then this loop would have the same problem if pattern were to match zero
>> characters.
>>
>>> The alternative is to "fix" it, maybe as what Matcher.find() does, 
>>> if the
>>> previous match is
>>> zero-width-match (the fist==last), we step one to the next cursor 
>>> before next
>>> try. I know
>>
>> Interesting, I didn't know Matcher.find() advances the cursor like 
>> this. But
>> Scanner.findWithinHorizon() apparently doesn't, so that's why an 
>> infinite loop
>> can occur.
>>
>>> Scanner.findPatternInBuffer() is setting new region set every time 
>>> it is
>>> invoked which makes
>>> it complicated, but I would assume it might be still worth a trying? 
>>> for
>>> example, utilize the
>>> "hasNextResult"/matcher.end(). I'm not sure without looking into the 
>>> code, does
>>>
>>> while (hasNext(pattern)) {
>>>     next(pattern);
>>> }
>>>
>>> have the same issue, when pattern matches 0-width?
>>
>> No, this doesn't have the problem, because hasNext(pat) and next(pat) 
>> match
>> delimited tokens. Each call to next() implicitly advances past the next
>> delimiter to reach the subsequent token, if any.
>>
>>
>> On 3/30/17 8:56 AM, Timo Kinnunen wrote:
>>> I guess this somewhat contrived example also wouldn?t work?
>>>
>>>         String s = "\\b\\w+|\\G|\\B";
>>>         String t = "Matcher m = Pattern.compile(s).matcher(t);\n";
>>>         Matcher m = Pattern.compile(s).matcher(t);
>>>         while(m.find()) {
>>>             System.out.println("'" + m.group() + "'");
>>>         }
>>
>> Right, so if you rewrote this loop to use Scanner.findWithinHorizon() 
>> instead of
>> Matcher,
>>
>>     Scanner sc = new Scanner(t);
>>     String str;
>>     while ((str = sc.findWithinHorizon(s, 0)) != null) {
>>         System.out.println("'" + str + "'");
>>     }
>>
>> you'd get an infinite loop with str being continually assigned the 
>> empty string.
>> As Sherman mentioned, the Matcher.find() will advance the cursor if 
>> it gets a
>> zero-width match, avoiding this problem.
>>
>> * * *
>>
>> This didn't come up in the code review thread, which was mostly about 
>> concurrent
>> modification and late-binding of the spliterator:
>>
>>   
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035034.html
>>
>> I remember noting this phenomenon a while back, which is why I had 
>> filed the bug
>> to add a note. I seem to remember discussing it, though, but it might 
>> have been
>> in a meeting or in a hallway conversation.
>>
>> This bug (JDK-8150488) does note that an infinite stream might be 
>> unexpected or
>> surprising, but it's not a fatal problem. It can be terminated with 
>> limit(). It
>> can also be terminated with takeWhile(), also added in JDK 9. Maybe I 
>> could
>> mention these in the API note.
>>
>> I guess we could also consider changing the implicit 
>> findWithinHorizon() loop
>> that findAll() does, perhaps by having it terminate on a zero-width 
>> match. Or we
>> could even change findWithinHorizon's behavior if it gets a 
>> zero-width match,
>> siilar to what Matcher.find() does. But I'm quite reluctant to start 
>> making such
>> changes at this point.
>>
>> s'marks
>>
>>
>>
>>>         // Outputs:
>>>         // 'Matcher'
>>>         // ''
>>>         // 'm'
>>>         // ''
>>>         // ''
>>>         // ''
>>>         // 'Pattern'
>>>         // ''
>>>         // 'compile'
>>>         // ''
>>>         // 's'
>>>         // ''
>>>         // ''
>>>         // 'matcher'
>>>         // ''
>>>         // 't'
>>>         // ''
>>>         // ''
>>>         // ''
>>>         // ''
>>>
>>>
>>>
>>> Sent from Mail for Windows 10
>>>
>>> From: Xueming Shen
>>> Sent: Thursday, March 30, 2017 05:41
>>> To: core-libs-dev at openjdk.java.net
>>> Subject: Re: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()
>>> regardingpossible infinite streams
>>>
>>> On 3/29/17, 5:56 PM, Stuart Marks wrote:
>>>> Hi all,
>>>>
>>>> Please review these non-normative textual additions to the
>>>> Scanner.findAll() method docs. These methods were added earlier in JDK
>>>> 9; there's a small pitfall if the regex can match zero characters.
>>>>
>>> Stuart,
>>>
>>> This might practically put the api itself almost useless? it might 
>>> be an
>>> easy task to spot
>>> whether or not it's a 0-width-match-possible regex when the regex is
>>> simple, but it gets
>>> harder and harder, if not impossible when the regex gets complicated,
>>> especially consider
>>> the possible use scenario that the use site is embedded deeply inside a
>>> library implementation.
>>>
>>> The alternative is to "fix" it, maybe as what Matcher.find() does, if
>>> the previous match is
>>> zero-width-match (the fist==last), we step one to the next cursor 
>>> before
>>> next try. I know
>>> Scanner.findPatternInBuffer() is setting new region set every time 
>>> it is
>>> invoked which makes
>>> it complicated, but I would assume it might be still worth a trying? 
>>> for
>>> example, utilize the
>>> "hasNextResult"/matcher.end(). I'm not sure without looking into the
>>> code, does
>>>
>>> while (hasNext(pattern)) {
>>>      next(pattern);
>>> }
>>>
>>> have the same issue, when pattern matches 0-width?
>>>
>>> Thanks!
>>> -Sherman
>>>
>>>
>>>
>>>
>>>> Thanks,
>>>>
>>>> s'marks
>>>>
>>>>
>>>> # HG changeset patch
>>>> # User smarks
>>>> # Date 1490749958 25200
>>>> #      Tue Mar 28 18:12:38 2017 -0700
>>>> # Node ID 6b43c4698752779793d58813f46d3687c17dde75
>>>> # Parent  fb54b256d751ae3191e9cef42ff9f5630931f047
>>>> 8150488: add note to Scanner.findAll() regarding possible infinite
>>>> streams
>>>> Reviewed-by: XXX
>>>>
>>>> diff -r fb54b256d751 -r 6b43c4698752
>>>> src/java.base/share/classes/java/util/Scanner.java
>>>> --- a/src/java.base/share/classes/java/util/Scanner.java    Mon Mar 27
>>>> 15:12:01 2017 -0700
>>>> +++ b/src/java.base/share/classes/java/util/Scanner.java    Tue Mar 28
>>>> 18:12:38 2017 -0700
>>>> @@ -2808,6 +2808,10 @@
>>>>       * }
>>>>       * }</pre>
>>>>       *
>>>> +     * <p>The pattern must always match at least one character. If
>>>> the pattern
>>>> +     * can match zero characters, the result will be an infinite 
>>>> stream
>>>> +     * of empty matches.
>>>> +     *
>>>>       * @param pattern the pattern to be matched
>>>>       * @return a sequential stream of match results
>>>>       * @throws NullPointerException if pattern is null
>>>> @@ -2829,6 +2833,11 @@
>>>>       *     scanner.findAll(Pattern.compile(patString))
>>>>       * }</pre>
>>>>       *
>>>> +     * @apiNote
>>>> +     * The pattern must always match at least one character. If the
>>>> pattern
>>>> +     * can match zero characters, the result will be an infinite 
>>>> stream
>>>> +     * of empty matches.
>>>> +     *
>>>>       * @param patString the pattern string
>>>>       * @return a sequential stream of match results
>>>>       * @throws NullPointerException if patString is null
>>>
>>>


From kumar.x.srinivasan at oracle.com  Wed Apr  5 00:18:12 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 04 Apr 2017 17:18:12 -0700
Subject: JDK 9 RFR(s): JDK-8065825: Make the java -help consistent with the
 man page
Message-ID: <58E437C4.1080306@oracle.com>

Hello,

Please review: http://cr.openjdk.java.net/~ksrini/8065825/webrev.00/

This adds a few things to the java -help and some minor cleanup.

Thanks
Kumar


From timo.kinnunen at gmail.com  Wed Apr  5 00:33:35 2017
From: timo.kinnunen at gmail.com (Timo Kinnunen)
Date: Wed, 5 Apr 2017 02:33:35 +0200
Subject: JDK 9 RFR(s): 8150488: add note to
 Scanner.findAll()regardingpossible infinite streams
In-Reply-To: <58E427E8.2020901@oracle.com>
References: <ca6ee328-1121-ed95-48ca-92cf5be02c0e@oracle.com>
 <58DC7E53.6040603@oracle.com> <58dd2aba.298fdf0a.86cca.3418@mx.google.com>
 <cc200e33-24dc-df27-1c56-dc11bf695c36@oracle.com>
 <fc36e657-a196-6f3e-bd42-fb1bdc741205@oracle.com>
 <58E427E8.2020901@oracle.com>
Message-ID: <58e43b5f.86ba1c0a.175c5.80a8@mx.google.com>

Hi, 

I agree, the behavior should change to work like Matcher.find() which is probably the better known API. E.g. http://www.regular-expressions.info/continue.html describes Java?s Matcher?s behavior on empty matches but doesn?t mention any other APIs beside that.

If we say a regex engine?s task is to find non-overlapping matches in a given input then it repeatedly returning the same empty match at the same location could even be considered a bug.



Sent from Mail for Windows 10

From: Xueming Shen
Sent: Wednesday, April 5, 2017 01:11
To: Stuart Marks
Cc: Timo Kinnunen; core-libs-dev at openjdk.java.net
Subject: Re: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()regardingpossible infinite streams

On 4/4/17, 12:52 PM, Stuart Marks wrote:
> Anything further on this?
>
> I'd at least like to add the API note I proposed in order to document 
> this issue. I'm reluctant to start tinkering with the behavior of this 
> method at this late stage in the release.
>
> BTW I used Scanner.findAll() in a little programming exercise I worked 
> on the other day. It worked perfectly. :-)

H Stuart,

The word "useless" was definitely exaggerate :-) Really meant to say the 
note might make the api less
useful/popular.

Personally I think the use scenario and the expected resulting behavior 
of Stream<MR>finaAll(ptn)
should be more equivalent/similar to the use case  of while 
(s.hasNext(p)) {   s.next(p); }, or while
(m.find()) { }, therefor it is probably desired it can be used without 
worrying the possibility of getting
into an infinite loop. That said, I agree it might be hard to argue to 
fix it in jdk9. The question is if
we are going to fix it in 9u sometime in the further, is it still worth 
putting down the note in the
API now. I'm fine if you believe a note will help at least make the 
issue a known/documented usage
limitation, for JDK9.

Yes, I think we did chat about this one at the hallway some time when 
either you or something
ran into the loop by using the method ...

Thanks,
Sherman


>
> s'marks
>
> On 3/30/17 2:19 PM, Stuart Marks wrote:
>> Hi Timo, Sherman,
>>
>> Thanks for looking at this.
>>
>> Sherman wrote:
>>
>>> This might practically put the api itself almost useless? it might 
>>> be an easy
>>> task to spot
>>> whether or not it's a 0-width-match-possible regex when the regex is 
>>> simple,
>>> but it gets
>>> harder and harder, if not impossible when the regex gets complicated,
>>> especially consider
>>> the possible use scenario that the use site is embedded deeply inside a
>>> library implementation.
>>
>> Well, not "useless", but perhaps less useful than one might like. :-)
>>
>> I think this is potentially surprising behavior, which is why I at 
>> least wanted
>> to add the note. It's not clear to me whether we should try to fix 
>> this by
>> changing Scanner though.
>>
>> Essentially, findAll() is defined in terms of 
>> findWithinHorizon(pattern, 0). So
>> if one were to write a loop like so:
>>
>>     String str;
>>     while ((str = scanner.findWithinHorizon(pattern, 0)) != null) {
>>         System.out.println(str);
>>     }
>>
>> then this loop would have the same problem if pattern were to match zero
>> characters.
>>
>>> The alternative is to "fix" it, maybe as what Matcher.find() does, 
>>> if the
>>> previous match is
>>> zero-width-match (the fist==last), we step one to the next cursor 
>>> before next
>>> try. I know
>>
>> Interesting, I didn't know Matcher.find() advances the cursor like 
>> this. But
>> Scanner.findWithinHorizon() apparently doesn't, so that's why an 
>> infinite loop
>> can occur.
>>
>>> Scanner.findPatternInBuffer() is setting new region set every time 
>>> it is
>>> invoked which makes
>>> it complicated, but I would assume it might be still worth a trying? 
>>> for
>>> example, utilize the
>>> "hasNextResult"/matcher.end(). I'm not sure without looking into the 
>>> code, does
>>>
>>> while (hasNext(pattern)) {
>>>     next(pattern);
>>> }
>>>
>>> have the same issue, when pattern matches 0-width?
>>
>> No, this doesn't have the problem, because hasNext(pat) and next(pat) 
>> match
>> delimited tokens. Each call to next() implicitly advances past the next
>> delimiter to reach the subsequent token, if any.
>>
>>
>> On 3/30/17 8:56 AM, Timo Kinnunen wrote:
>>> I guess this somewhat contrived example also wouldn?t work?
>>>
>>>         String s = "\\b\\w+|\\G|\\B";
>>>         String t = "Matcher m = Pattern.compile(s).matcher(t);\n";
>>>         Matcher m = Pattern.compile(s).matcher(t);
>>>         while(m.find()) {
>>>             System.out.println("'" + m.group() + "'");
>>>         }
>>
>> Right, so if you rewrote this loop to use Scanner.findWithinHorizon() 
>> instead of
>> Matcher,
>>
>>     Scanner sc = new Scanner(t);
>>     String str;
>>     while ((str = sc.findWithinHorizon(s, 0)) != null) {
>>         System.out.println("'" + str + "'");
>>     }
>>
>> you'd get an infinite loop with str being continually assigned the 
>> empty string.
>> As Sherman mentioned, the Matcher.find() will advance the cursor if 
>> it gets a
>> zero-width match, avoiding this problem.
>>
>> * * *
>>
>> This didn't come up in the code review thread, which was mostly about 
>> concurrent
>> modification and late-binding of the spliterator:
>>
>>   
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035034.html
>>
>> I remember noting this phenomenon a while back, which is why I had 
>> filed the bug
>> to add a note. I seem to remember discussing it, though, but it might 
>> have been
>> in a meeting or in a hallway conversation.
>>
>> This bug (JDK-8150488) does note that an infinite stream might be 
>> unexpected or
>> surprising, but it's not a fatal problem. It can be terminated with 
>> limit(). It
>> can also be terminated with takeWhile(), also added in JDK 9. Maybe I 
>> could
>> mention these in the API note.
>>
>> I guess we could also consider changing the implicit 
>> findWithinHorizon() loop
>> that findAll() does, perhaps by having it terminate on a zero-width 
>> match. Or we
>> could even change findWithinHorizon's behavior if it gets a 
>> zero-width match,
>> siilar to what Matcher.find() does. But I'm quite reluctant to start 
>> making such
>> changes at this point.
>>
>> s'marks
>>
>>
>>
>>>         // Outputs:
>>>         // 'Matcher'
>>>         // ''
>>>         // 'm'
>>>         // ''
>>>         // ''
>>>         // ''
>>>         // 'Pattern'
>>>         // ''
>>>         // 'compile'
>>>         // ''
>>>         // 's'
>>>         // ''
>>>         // ''
>>>         // 'matcher'
>>>         // ''
>>>         // 't'
>>>         // ''
>>>         // ''
>>>         // ''
>>>         // ''
>>>
>>>
>>>
>>> Sent from Mail for Windows 10
>>>
>>> From: Xueming Shen
>>> Sent: Thursday, March 30, 2017 05:41
>>> To: core-libs-dev at openjdk.java.net
>>> Subject: Re: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()
>>> regardingpossible infinite streams
>>>
>>> On 3/29/17, 5:56 PM, Stuart Marks wrote:
>>>> Hi all,
>>>>
>>>> Please review these non-normative textual additions to the
>>>> Scanner.findAll() method docs. These methods were added earlier in JDK
>>>> 9; there's a small pitfall if the regex can match zero characters.
>>>>
>>> Stuart,
>>>
>>> This might practically put the api itself almost useless? it might 
>>> be an
>>> easy task to spot
>>> whether or not it's a 0-width-match-possible regex when the regex is
>>> simple, but it gets
>>> harder and harder, if not impossible when the regex gets complicated,
>>> especially consider
>>> the possible use scenario that the use site is embedded deeply inside a
>>> library implementation.
>>>
>>> The alternative is to "fix" it, maybe as what Matcher.find() does, if
>>> the previous match is
>>> zero-width-match (the fist==last), we step one to the next cursor 
>>> before
>>> next try. I know
>>> Scanner.findPatternInBuffer() is setting new region set every time 
>>> it is
>>> invoked which makes
>>> it complicated, but I would assume it might be still worth a trying? 
>>> for
>>> example, utilize the
>>> "hasNextResult"/matcher.end(). I'm not sure without looking into the
>>> code, does
>>>
>>> while (hasNext(pattern)) {
>>>      next(pattern);
>>> }
>>>
>>> have the same issue, when pattern matches 0-width?
>>>
>>> Thanks!
>>> -Sherman
>>>
>>>
>>>
>>>
>>>> Thanks,
>>>>
>>>> s'marks
>>>>
>>>>
>>>> # HG changeset patch
>>>> # User smarks
>>>> # Date 1490749958 25200
>>>> #      Tue Mar 28 18:12:38 2017 -0700
>>>> # Node ID 6b43c4698752779793d58813f46d3687c17dde75
>>>> # Parent  fb54b256d751ae3191e9cef42ff9f5630931f047
>>>> 8150488: add note to Scanner.findAll() regarding possible infinite
>>>> streams
>>>> Reviewed-by: XXX
>>>>
>>>> diff -r fb54b256d751 -r 6b43c4698752
>>>> src/java.base/share/classes/java/util/Scanner.java
>>>> --- a/src/java.base/share/classes/java/util/Scanner.java    Mon Mar 27
>>>> 15:12:01 2017 -0700
>>>> +++ b/src/java.base/share/classes/java/util/Scanner.java    Tue Mar 28
>>>> 18:12:38 2017 -0700
>>>> @@ -2808,6 +2808,10 @@
>>>>       * }
>>>>       * }</pre>
>>>>       *
>>>> +     * <p>The pattern must always match at least one character. If
>>>> the pattern
>>>> +     * can match zero characters, the result will be an infinite 
>>>> stream
>>>> +     * of empty matches.
>>>> +     *
>>>>       * @param pattern the pattern to be matched
>>>>       * @return a sequential stream of match results
>>>>       * @throws NullPointerException if pattern is null
>>>> @@ -2829,6 +2833,11 @@
>>>>       *     scanner.findAll(Pattern.compile(patString))
>>>>       * }</pre>
>>>>       *
>>>> +     * @apiNote
>>>> +     * The pattern must always match at least one character. If the
>>>> pattern
>>>> +     * can match zero characters, the result will be an infinite 
>>>> stream
>>>> +     * of empty matches.
>>>> +     *
>>>>       * @param patString the pattern string
>>>>       * @return a sequential stream of match results
>>>>       * @throws NullPointerException if patString is null
>>>
>>>



From amy.lu at oracle.com  Wed Apr  5 05:31:46 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 5 Apr 2017 13:31:46 +0800
Subject: JDK 9 RFR of JDK-8177640:
 jdk/internal/util/jar/TestVersionedStream.java fails on Windows
Message-ID: <bf1fd9d2-ac2a-4346-e30b-0ceb449f68e3@oracle.com>

Please review this test-only change.

jdk/internal/util/jar/TestVersionedStream.java

This test fails on Windows platforms. Test tries to create and write 
something to the files (in test preparation method 'createFiles') for 
later comparison (in test method 'test'). The content write to the new 
created file contains path and line separator,but test does not take 
into account the platform difference.

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

Thanks,
Amy



From stuart.marks at oracle.com  Wed Apr  5 05:48:53 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 4 Apr 2017 22:48:53 -0700
Subject: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()
 regardingpossible infinite streams
In-Reply-To: <58E427E8.2020901@oracle.com>
References: <ca6ee328-1121-ed95-48ca-92cf5be02c0e@oracle.com>
 <58DC7E53.6040603@oracle.com> <58dd2aba.298fdf0a.86cca.3418@mx.google.com>
 <cc200e33-24dc-df27-1c56-dc11bf695c36@oracle.com>
 <fc36e657-a196-6f3e-bd42-fb1bdc741205@oracle.com>
 <58E427E8.2020901@oracle.com>
Message-ID: <89d5129f-faff-20cb-eb86-6d3bb4151958@oracle.com>



On 4/4/17 4:10 PM, Xueming Shen wrote:
> On 4/4/17, 12:52 PM, Stuart Marks wrote:
>> I'd at least like to add the API note I proposed in order to document this
>> issue. I'm reluctant to start tinkering with the behavior of this method at
>> this late stage in the release.
>>
>> BTW I used Scanner.findAll() in a little programming exercise I worked on the
>> other day. It worked perfectly. :-)
>
> The word "useless" was definitely exaggerate :-) Really meant to say the
> note might make the api less useful/popular.


> Personally I think the use scenario and the expected resulting behavior of
> Stream<MR>finaAll(ptn) should be more equivalent/similar to the use case  of
> while (s.hasNext(p)) { s.next(p); }, or while (m.find()) { }, therefor it is
> probably desired it can be used without worrying the possibility of getting
> into an infinite loop.

The Scanner.tokens() API, also added in Java 9, provides a stream of delimited 
tokens (strings) that's more-or-less equivalent of a hasNext()/next() loop.

Just as findWithinHorizon() is a distinct use case from hasNext()/next() 
delimited tokens, findAll() provides for distinct uses from tokens().

> That said, I agree it might be hard to argue to fix it in jdk9. The question
> is if we are going to fix it in 9u sometime in the further, is it still worth
> putting down the note in the API now. I'm fine if you believe a note will
> help at least make the issue a known/documented usage limitation, for JDK9.
>
> Yes, I think we did chat about this one at the hallway some time when either
> you or something ran into the loop by using the method ...

There are already a couple ways you can get unexpected behavior with Scanner if 
you're not careful. For example, see the warnings in findWithinHorizon() and 
skip() about the possibility of buffering up the entire input. These methods are 
useful, but if you're not careful with the regex you provide, things can go 
wrong. The findAll() method seems to be in the same situation. It's not clear to 
me that any of these are bugs for which there's a reasonable fix.

So yes, I think the note is necessary. I could also add something about 
terminating such streams with limit() or takeWhile().

s'marks

>
> Thanks,
> Sherman
>
>
>>
>> s'marks
>>
>> On 3/30/17 2:19 PM, Stuart Marks wrote:
>>> Hi Timo, Sherman,
>>>
>>> Thanks for looking at this.
>>>
>>> Sherman wrote:
>>>
>>>> This might practically put the api itself almost useless? it might be an easy
>>>> task to spot
>>>> whether or not it's a 0-width-match-possible regex when the regex is simple,
>>>> but it gets
>>>> harder and harder, if not impossible when the regex gets complicated,
>>>> especially consider
>>>> the possible use scenario that the use site is embedded deeply inside a
>>>> library implementation.
>>>
>>> Well, not "useless", but perhaps less useful than one might like. :-)
>>>
>>> I think this is potentially surprising behavior, which is why I at least wanted
>>> to add the note. It's not clear to me whether we should try to fix this by
>>> changing Scanner though.
>>>
>>> Essentially, findAll() is defined in terms of findWithinHorizon(pattern, 0). So
>>> if one were to write a loop like so:
>>>
>>>     String str;
>>>     while ((str = scanner.findWithinHorizon(pattern, 0)) != null) {
>>>         System.out.println(str);
>>>     }
>>>
>>> then this loop would have the same problem if pattern were to match zero
>>> characters.
>>>
>>>> The alternative is to "fix" it, maybe as what Matcher.find() does, if the
>>>> previous match is
>>>> zero-width-match (the fist==last), we step one to the next cursor before next
>>>> try. I know
>>>
>>> Interesting, I didn't know Matcher.find() advances the cursor like this. But
>>> Scanner.findWithinHorizon() apparently doesn't, so that's why an infinite loop
>>> can occur.
>>>
>>>> Scanner.findPatternInBuffer() is setting new region set every time it is
>>>> invoked which makes
>>>> it complicated, but I would assume it might be still worth a trying? for
>>>> example, utilize the
>>>> "hasNextResult"/matcher.end(). I'm not sure without looking into the code, does
>>>>
>>>> while (hasNext(pattern)) {
>>>>     next(pattern);
>>>> }
>>>>
>>>> have the same issue, when pattern matches 0-width?
>>>
>>> No, this doesn't have the problem, because hasNext(pat) and next(pat) match
>>> delimited tokens. Each call to next() implicitly advances past the next
>>> delimiter to reach the subsequent token, if any.
>>>
>>>
>>> On 3/30/17 8:56 AM, Timo Kinnunen wrote:
>>>> I guess this somewhat contrived example also wouldn?t work?
>>>>
>>>>         String s = "\\b\\w+|\\G|\\B";
>>>>         String t = "Matcher m = Pattern.compile(s).matcher(t);\n";
>>>>         Matcher m = Pattern.compile(s).matcher(t);
>>>>         while(m.find()) {
>>>>             System.out.println("'" + m.group() + "'");
>>>>         }
>>>
>>> Right, so if you rewrote this loop to use Scanner.findWithinHorizon() instead of
>>> Matcher,
>>>
>>>     Scanner sc = new Scanner(t);
>>>     String str;
>>>     while ((str = sc.findWithinHorizon(s, 0)) != null) {
>>>         System.out.println("'" + str + "'");
>>>     }
>>>
>>> you'd get an infinite loop with str being continually assigned the empty string.
>>> As Sherman mentioned, the Matcher.find() will advance the cursor if it gets a
>>> zero-width match, avoiding this problem.
>>>
>>> * * *
>>>
>>> This didn't come up in the code review thread, which was mostly about concurrent
>>> modification and late-binding of the spliterator:
>>>
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035034.html
>>>
>>> I remember noting this phenomenon a while back, which is why I had filed the bug
>>> to add a note. I seem to remember discussing it, though, but it might have been
>>> in a meeting or in a hallway conversation.
>>>
>>> This bug (JDK-8150488) does note that an infinite stream might be unexpected or
>>> surprising, but it's not a fatal problem. It can be terminated with limit(). It
>>> can also be terminated with takeWhile(), also added in JDK 9. Maybe I could
>>> mention these in the API note.
>>>
>>> I guess we could also consider changing the implicit findWithinHorizon() loop
>>> that findAll() does, perhaps by having it terminate on a zero-width match. Or we
>>> could even change findWithinHorizon's behavior if it gets a zero-width match,
>>> siilar to what Matcher.find() does. But I'm quite reluctant to start making such
>>> changes at this point.
>>>
>>> s'marks
>>>
>>>
>>>
>>>>         // Outputs:
>>>>         // 'Matcher'
>>>>         // ''
>>>>         // 'm'
>>>>         // ''
>>>>         // ''
>>>>         // ''
>>>>         // 'Pattern'
>>>>         // ''
>>>>         // 'compile'
>>>>         // ''
>>>>         // 's'
>>>>         // ''
>>>>         // ''
>>>>         // 'matcher'
>>>>         // ''
>>>>         // 't'
>>>>         // ''
>>>>         // ''
>>>>         // ''
>>>>         // ''
>>>>
>>>>
>>>>
>>>> Sent from Mail for Windows 10
>>>>
>>>> From: Xueming Shen
>>>> Sent: Thursday, March 30, 2017 05:41
>>>> To: core-libs-dev at openjdk.java.net
>>>> Subject: Re: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()
>>>> regardingpossible infinite streams
>>>>
>>>> On 3/29/17, 5:56 PM, Stuart Marks wrote:
>>>>> Hi all,
>>>>>
>>>>> Please review these non-normative textual additions to the
>>>>> Scanner.findAll() method docs. These methods were added earlier in JDK
>>>>> 9; there's a small pitfall if the regex can match zero characters.
>>>>>
>>>> Stuart,
>>>>
>>>> This might practically put the api itself almost useless? it might be an
>>>> easy task to spot
>>>> whether or not it's a 0-width-match-possible regex when the regex is
>>>> simple, but it gets
>>>> harder and harder, if not impossible when the regex gets complicated,
>>>> especially consider
>>>> the possible use scenario that the use site is embedded deeply inside a
>>>> library implementation.
>>>>
>>>> The alternative is to "fix" it, maybe as what Matcher.find() does, if
>>>> the previous match is
>>>> zero-width-match (the fist==last), we step one to the next cursor before
>>>> next try. I know
>>>> Scanner.findPatternInBuffer() is setting new region set every time it is
>>>> invoked which makes
>>>> it complicated, but I would assume it might be still worth a trying? for
>>>> example, utilize the
>>>> "hasNextResult"/matcher.end(). I'm not sure without looking into the
>>>> code, does
>>>>
>>>> while (hasNext(pattern)) {
>>>>      next(pattern);
>>>> }
>>>>
>>>> have the same issue, when pattern matches 0-width?
>>>>
>>>> Thanks!
>>>> -Sherman
>>>>
>>>>
>>>>
>>>>
>>>>> Thanks,
>>>>>
>>>>> s'marks
>>>>>
>>>>>
>>>>> # HG changeset patch
>>>>> # User smarks
>>>>> # Date 1490749958 25200
>>>>> #      Tue Mar 28 18:12:38 2017 -0700
>>>>> # Node ID 6b43c4698752779793d58813f46d3687c17dde75
>>>>> # Parent  fb54b256d751ae3191e9cef42ff9f5630931f047
>>>>> 8150488: add note to Scanner.findAll() regarding possible infinite
>>>>> streams
>>>>> Reviewed-by: XXX
>>>>>
>>>>> diff -r fb54b256d751 -r 6b43c4698752
>>>>> src/java.base/share/classes/java/util/Scanner.java
>>>>> --- a/src/java.base/share/classes/java/util/Scanner.java    Mon Mar 27
>>>>> 15:12:01 2017 -0700
>>>>> +++ b/src/java.base/share/classes/java/util/Scanner.java    Tue Mar 28
>>>>> 18:12:38 2017 -0700
>>>>> @@ -2808,6 +2808,10 @@
>>>>>       * }
>>>>>       * }</pre>
>>>>>       *
>>>>> +     * <p>The pattern must always match at least one character. If
>>>>> the pattern
>>>>> +     * can match zero characters, the result will be an infinite stream
>>>>> +     * of empty matches.
>>>>> +     *
>>>>>       * @param pattern the pattern to be matched
>>>>>       * @return a sequential stream of match results
>>>>>       * @throws NullPointerException if pattern is null
>>>>> @@ -2829,6 +2833,11 @@
>>>>>       *     scanner.findAll(Pattern.compile(patString))
>>>>>       * }</pre>
>>>>>       *
>>>>> +     * @apiNote
>>>>> +     * The pattern must always match at least one character. If the
>>>>> pattern
>>>>> +     * can match zero characters, the result will be an infinite stream
>>>>> +     * of empty matches.
>>>>> +     *
>>>>>       * @param patString the pattern string
>>>>>       * @return a sequential stream of match results
>>>>>       * @throws NullPointerException if patString is null
>>>>
>>>>
>

From stuart.marks at oracle.com  Wed Apr  5 05:50:41 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 4 Apr 2017 22:50:41 -0700
Subject: JDK 9 RFR(s): 8150488: add note to
 Scanner.findAll()regardingpossible infinite streams
In-Reply-To: <58e43b5f.86ba1c0a.175c5.80a8@mx.google.com>
References: <ca6ee328-1121-ed95-48ca-92cf5be02c0e@oracle.com>
 <58DC7E53.6040603@oracle.com> <58dd2aba.298fdf0a.86cca.3418@mx.google.com>
 <cc200e33-24dc-df27-1c56-dc11bf695c36@oracle.com>
 <fc36e657-a196-6f3e-bd42-fb1bdc741205@oracle.com>
 <58E427E8.2020901@oracle.com> <58e43b5f.86ba1c0a.175c5.80a8@mx.google.com>
Message-ID: <d41277e5-2eae-03f1-d1d5-d177ac324498@oracle.com>



On 4/4/17 5:33 PM, Timo Kinnunen wrote:
>
> Hi,
>
> I agree, the behavior should change to work like Matcher.find() which is 
> probably the better known API. E.g. 
> http://www.regular-expressions.info/continue.html describes Java?s Matcher?s 
> behavior on empty matches but doesn?t mention any other APIs beside that.
>
I don't think Sherman was suggesting that.

In any case this would be a change to findWithinHorizon(), which isn't in scope.

s'marks
>
> If we say a regex engine?s task is to find non-overlapping matches in a given 
> input then it repeatedly returning the same empty match at the same location 
> could even be considered a bug.
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>
> *From: *Xueming Shen <mailto:xueming.shen at oracle.com>
> *Sent: *Wednesday, April 5, 2017 01:11
> *To: *Stuart Marks <mailto:stuart.marks at oracle.com>
> *Cc: *Timo Kinnunen <mailto:timo.kinnunen at gmail.com>; 
> core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>
> *Subject: *Re: JDK 9 RFR(s): 8150488: add note to 
> Scanner.findAll()regardingpossible infinite streams
>
> On 4/4/17, 12:52 PM, Stuart Marks wrote:
>
> > Anything further on this?
>
> >
>
> > I'd at least like to add the API note I proposed in order to document
>
> > this issue. I'm reluctant to start tinkering with the behavior of this
>
> > method at this late stage in the release.
>
> >
>
> > BTW I used Scanner.findAll() in a little programming exercise I worked
>
> > on the other day. It worked perfectly. :-)
>
> H Stuart,
>
> The word "useless" was definitely exaggerate :-) Really meant to say the
>
> note might make the api less
>
> useful/popular.
>
> Personally I think the use scenario and the expected resulting behavior
>
> of Stream<MR>finaAll(ptn)
>
> should be more equivalent/similar to the use case  of while
>
> (s.hasNext(p)) {   s.next(p); }, or while
>
> (m.find()) { }, therefor it is probably desired it can be used without
>
> worrying the possibility of getting
>
> into an infinite loop. That said, I agree it might be hard to argue to
>
> fix it in jdk9. The question is if
>
> we are going to fix it in 9u sometime in the further, is it still worth
>
> putting down the note in the
>
> API now. I'm fine if you believe a note will help at least make the
>
> issue a known/documented usage
>
> limitation, for JDK9.
>
> Yes, I think we did chat about this one at the hallway some time when
>
> either you or something
>
> ran into the loop by using the method ...
>
> Thanks,
>
> Sherman
>
> >
>
> > s'marks
>
> >
>
> > On 3/30/17 2:19 PM, Stuart Marks wrote:
>
> >> Hi Timo, Sherman,
>
> >>
>
> >> Thanks for looking at this.
>
> >>
>
> >> Sherman wrote:
>
> >>
>
> >>> This might practically put the api itself almost useless? it might
>
> >>> be an easy
>
> >>> task to spot
>
> >>> whether or not it's a 0-width-match-possible regex when the regex is
>
> >>> simple,
>
> >>> but it gets
>
> >>> harder and harder, if not impossible when the regex gets complicated,
>
> >>> especially consider
>
> >>> the possible use scenario that the use site is embedded deeply inside a
>
> >>> library implementation.
>
> >>
>
> >> Well, not "useless", but perhaps less useful than one might like. :-)
>
> >>
>
> >> I think this is potentially surprising behavior, which is why I at
>
> >> least wanted
>
> >> to add the note. It's not clear to me whether we should try to fix
>
> >> this by
>
> >> changing Scanner though.
>
> >>
>
> >> Essentially, findAll() is defined in terms of
>
> >> findWithinHorizon(pattern, 0). So
>
> >> if one were to write a loop like so:
>
> >>
>
> >>     String str;
>
> >>     while ((str = scanner.findWithinHorizon(pattern, 0)) != null) {
>
> >>         System.out.println(str);
>
> >>     }
>
> >>
>
> >> then this loop would have the same problem if pattern were to match zero
>
> >> characters.
>
> >>
>
> >>> The alternative is to "fix" it, maybe as what Matcher.find() does,
>
> >>> if the
>
> >>> previous match is
>
> >>> zero-width-match (the fist==last), we step one to the next cursor
>
> >>> before next
>
> >>> try. I know
>
> >>
>
> >> Interesting, I didn't know Matcher.find() advances the cursor like
>
> >> this. But
>
> >> Scanner.findWithinHorizon() apparently doesn't, so that's why an
>
> >> infinite loop
>
> >> can occur.
>
> >>
>
> >>> Scanner.findPatternInBuffer() is setting new region set every time
>
> >>> it is
>
> >>> invoked which makes
>
> >>> it complicated, but I would assume it might be still worth a trying?
>
> >>> for
>
> >>> example, utilize the
>
> >>> "hasNextResult"/matcher.end(). I'm not sure without looking into the
>
> >>> code, does
>
> >>>
>
> >>> while (hasNext(pattern)) {
>
> >>>     next(pattern);
>
> >>> }
>
> >>>
>
> >>> have the same issue, when pattern matches 0-width?
>
> >>
>
> >> No, this doesn't have the problem, because hasNext(pat) and next(pat)
>
> >> match
>
> >> delimited tokens. Each call to next() implicitly advances past the next
>
> >> delimiter to reach the subsequent token, if any.
>
> >>
>
> >>
>
> >> On 3/30/17 8:56 AM, Timo Kinnunen wrote:
>
> >>> I guess this somewhat contrived example also wouldn?t work?
>
> >>>
>
> >>>         String s = "\\b\\w+|\\G|\\B";
>
> >>>         String t = "Matcher m = Pattern.compile(s).matcher(t);\n";
>
> >>>         Matcher m = Pattern.compile(s).matcher(t);
>
> >>>         while(m.find()) {
>
> >>> System.out.println("'" + m.group() + "'");
>
> >>>         }
>
> >>
>
> >> Right, so if you rewrote this loop to use Scanner.findWithinHorizon()
>
> >> instead of
>
> >> Matcher,
>
> >>
>
> >>     Scanner sc = new Scanner(t);
>
> >>     String str;
>
> >>     while ((str = sc.findWithinHorizon(s, 0)) != null) {
>
> >>         System.out.println("'" + str + "'");
>
> >>     }
>
> >>
>
> >> you'd get an infinite loop with str being continually assigned the
>
> >> empty string.
>
> >> As Sherman mentioned, the Matcher.find() will advance the cursor if
>
> >> it gets a
>
> >> zero-width match, avoiding this problem.
>
> >>
>
> >> * * *
>
> >>
>
> >> This didn't come up in the code review thread, which was mostly about
>
> >> concurrent
>
> >> modification and late-binding of the spliterator:
>
> >>
>
> >>
>
> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035034.html
>
> >>
>
> >> I remember noting this phenomenon a while back, which is why I had
>
> >> filed the bug
>
> >> to add a note. I seem to remember discussing it, though, but it might
>
> >> have been
>
> >> in a meeting or in a hallway conversation.
>
> >>
>
> >> This bug (JDK-8150488) does note that an infinite stream might be
>
> >> unexpected or
>
> >> surprising, but it's not a fatal problem. It can be terminated with
>
> >> limit(). It
>
> >> can also be terminated with takeWhile(), also added in JDK 9. Maybe I
>
> >> could
>
> >> mention these in the API note.
>
> >>
>
> >> I guess we could also consider changing the implicit
>
> >> findWithinHorizon() loop
>
> >> that findAll() does, perhaps by having it terminate on a zero-width
>
> >> match. Or we
>
> >> could even change findWithinHorizon's behavior if it gets a
>
> >> zero-width match,
>
> >> siilar to what Matcher.find() does. But I'm quite reluctant to start
>
> >> making such
>
> >> changes at this point.
>
> >>
>
> >> s'marks
>
> >>
>
> >>
>
> >>
>
> >>>         // Outputs:
>
> >>>         // 'Matcher'
>
> >>>         // ''
>
> >>>         // 'm'
>
> >>>         // ''
>
> >>>         // ''
>
> >>>         // ''
>
> >>>         // 'Pattern'
>
> >>>         // ''
>
> >>>         // 'compile'
>
> >>>         // ''
>
> >>>         // 's'
>
> >>>         // ''
>
> >>>         // ''
>
> >>>         // 'matcher'
>
> >>>         // ''
>
> >>>         // 't'
>
> >>>         // ''
>
> >>>         // ''
>
> >>>         // ''
>
> >>>         // ''
>
> >>>
>
> >>>
>
> >>>
>
> >>> Sent from Mail for Windows 10
>
> >>>
>
> >>> From: Xueming Shen
>
> >>> Sent: Thursday, March 30, 2017 05:41
>
> >>> To: core-libs-dev at openjdk.java.net
>
> >>> Subject: Re: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()
>
> >>> regardingpossible infinite streams
>
> >>>
>
> >>> On 3/29/17, 5:56 PM, Stuart Marks wrote:
>
> >>>> Hi all,
>
> >>>>
>
> >>>> Please review these non-normative textual additions to the
>
> >>>> Scanner.findAll() method docs. These methods were added earlier in JDK
>
> >>>> 9; there's a small pitfall if the regex can match zero characters.
>
> >>>>
>
> >>> Stuart,
>
> >>>
>
> >>> This might practically put the api itself almost useless? it might
>
> >>> be an
>
> >>> easy task to spot
>
> >>> whether or not it's a 0-width-match-possible regex when the regex is
>
> >>> simple, but it gets
>
> >>> harder and harder, if not impossible when the regex gets complicated,
>
> >>> especially consider
>
> >>> the possible use scenario that the use site is embedded deeply inside a
>
> >>> library implementation.
>
> >>>
>
> >>> The alternative is to "fix" it, maybe as what Matcher.find() does, if
>
> >>> the previous match is
>
> >>> zero-width-match (the fist==last), we step one to the next cursor
>
> >>> before
>
> >>> next try. I know
>
> >>> Scanner.findPatternInBuffer() is setting new region set every time
>
> >>> it is
>
> >>> invoked which makes
>
> >>> it complicated, but I would assume it might be still worth a trying?
>
> >>> for
>
> >>> example, utilize the
>
> >>> "hasNextResult"/matcher.end(). I'm not sure without looking into the
>
> >>> code, does
>
> >>>
>
> >>> while (hasNext(pattern)) {
>
> >>>      next(pattern);
>
> >>> }
>
> >>>
>
> >>> have the same issue, when pattern matches 0-width?
>
> >>>
>
> >>> Thanks!
>
> >>> -Sherman
>
> >>>
>
> >>>
>
> >>>
>
> >>>
>
> >>>> Thanks,
>
> >>>>
>
> >>>> s'marks
>
> >>>>
>
> >>>>
>
> >>>> # HG changeset patch
>
> >>>> # User smarks
>
> >>>> # Date 1490749958 25200
>
> >>>> #      Tue Mar 28 18:12:38 2017 -0700
>
> >>>> # Node ID 6b43c4698752779793d58813f46d3687c17dde75
>
> >>>> # Parent fb54b256d751ae3191e9cef42ff9f5630931f047
>
> >>>> 8150488: add note to Scanner.findAll() regarding possible infinite
>
> >>>> streams
>
> >>>> Reviewed-by: XXX
>
> >>>>
>
> >>>> diff -r fb54b256d751 -r 6b43c4698752
>
> >>>> src/java.base/share/classes/java/util/Scanner.java
>
> >>>> --- a/src/java.base/share/classes/java/util/Scanner.java    Mon Mar 27
>
> >>>> 15:12:01 2017 -0700
>
> >>>> +++ b/src/java.base/share/classes/java/util/Scanner.java    Tue Mar 28
>
> >>>> 18:12:38 2017 -0700
>
> >>>> @@ -2808,6 +2808,10 @@
>
> >>>>       * }
>
> >>>>       * }</pre>
>
> >>>>       *
>
> >>>> +     * <p>The pattern must always match at least one character. If
>
> >>>> the pattern
>
> >>>> +     * can match zero characters, the result will be an infinite
>
> >>>> stream
>
> >>>> +     * of empty matches.
>
> >>>> +     *
>
> >>>>       * @param pattern the pattern to be matched
>
> >>>>       * @return a sequential stream of match results
>
> >>>>       * @throws NullPointerException if pattern is null
>
> >>>> @@ -2829,6 +2833,11 @@
>
> >>>>       * scanner.findAll(Pattern.compile(patString))
>
> >>>>       * }</pre>
>
> >>>>       *
>
> >>>> +     * @apiNote
>
> >>>> +     * The pattern must always match at least one character. If the
>
> >>>> pattern
>
> >>>> +     * can match zero characters, the result will be an infinite
>
> >>>> stream
>
> >>>> +     * of empty matches.
>
> >>>> +     *
>
> >>>>       * @param patString the pattern string
>
> >>>>       * @return a sequential stream of match results
>
> >>>>       * @throws NullPointerException if patString is null
>
> >>>
>
> >>>
>


From timo.kinnunen at gmail.com  Wed Apr  5 06:31:06 2017
From: timo.kinnunen at gmail.com (Timo Kinnunen)
Date: Wed, 5 Apr 2017 08:31:06 +0200
Subject: JDK 9 RFR(s): 8150488: add note
 toScanner.findAll()regardingpossible infinite streams
In-Reply-To: <d41277e5-2eae-03f1-d1d5-d177ac324498@oracle.com>
References: <ca6ee328-1121-ed95-48ca-92cf5be02c0e@oracle.com>
 <58DC7E53.6040603@oracle.com> <58dd2aba.298fdf0a.86cca.3418@mx.google.com>
 <cc200e33-24dc-df27-1c56-dc11bf695c36@oracle.com>
 <fc36e657-a196-6f3e-bd42-fb1bdc741205@oracle.com>
 <58E427E8.2020901@oracle.com> <58e43b5f.86ba1c0a.175c5.80a8@mx.google.com>
 <d41277e5-2eae-03f1-d1d5-d177ac324498@oracle.com>
Message-ID: <58e48f2a.7896df0a.d993.25c7@mx.google.com>

Then Scanner.findAll() should be specified not in terms of findWithinHorizon() but something else, maybe Matcher.find(). If it?s specified using findWithinHorizon() this would require implementations of its backing regex engine to be inferior or even broken in this respect when compared to other regex engines. If a regex engine chosen for an implementation didn?t have infinite looping then that would have to be emulated!






Sent from Mail for Windows 10

From: Stuart Marks
Sent: Wednesday, April 5, 2017 07:50
To: Timo Kinnunen
Cc: Xueming Shen; core-libs-dev at openjdk.java.net
Subject: Re: JDK 9 RFR(s): 8150488: add note toScanner.findAll()regardingpossible infinite streams



On 4/4/17 5:33 PM, Timo Kinnunen wrote:
Hi, 
?
I agree, the behavior should change to work like Matcher.find() which is probably the better known API. E.g. http://www.regular-expressions.info/continue.html describes Java?s Matcher?s behavior on empty matches but doesn?t mention any other APIs beside that.
I don't think Sherman was suggesting that.

In any case this would be a change to findWithinHorizon(), which isn't in scope.

s'marks

?
If we say a regex engine?s task is to find non-overlapping matches in a given input then it repeatedly returning the same empty match at the same location could even be considered a bug.
?
?
?
Sent from Mail for Windows 10
?
From: Xueming Shen
Sent: Wednesday, April 5, 2017 01:11
To: Stuart Marks
Cc: Timo Kinnunen; core-libs-dev at openjdk.java.net
Subject: Re: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()regardingpossible infinite streams
?
On 4/4/17, 12:52 PM, Stuart Marks wrote:
> Anything further on this?
>?
> I'd at least like to add the API note I proposed in order to document 
> this issue. I'm reluctant to start tinkering with the behavior of this 
> method at this late stage in the release.
>?
> BTW I used Scanner.findAll() in a little programming exercise I worked 
> on the other day. It worked perfectly. :-)
?
H Stuart,
?
The word "useless" was definitely exaggerate :-) Really meant to say the 
note might make the api less
useful/popular.
?
Personally I think the use scenario and the expected resulting behavior 
of Stream<MR>finaAll(ptn)
should be more equivalent/similar to the use case? of while 
(s.hasNext(p)) {?? s.next(p); }, or while
(m.find()) { }, therefor it is probably desired it can be used without 
worrying the possibility of getting
into an infinite loop. That said, I agree it might be hard to argue to 
fix it in jdk9. The question is if
we are going to fix it in 9u sometime in the further, is it still worth 
putting down the note in the
API now. I'm fine if you believe a note will help at least make the 
issue a known/documented usage
limitation, for JDK9.
?
Yes, I think we did chat about this one at the hallway some time when 
either you or something
ran into the loop by using the method ...
?
Thanks,
Sherman
?
?
>?
> s'marks
>?
> On 3/30/17 2:19 PM, Stuart Marks wrote:
>> Hi Timo, Sherman,
>>?
>> Thanks for looking at this.
>>?
>> Sherman wrote:
>>?
>>> This might practically put the api itself almost useless? it might 
>>> be an easy
>>> task to spot
>>> whether or not it's a 0-width-match-possible regex when the regex is 
>>> simple,
>>> but it gets
>>> harder and harder, if not impossible when the regex gets complicated,
>>> especially consider
>>> the possible use scenario that the use site is embedded deeply inside a
>>> library implementation.
>>?
>> Well, not "useless", but perhaps less useful than one might like. :-)
>>?
>> I think this is potentially surprising behavior, which is why I at 
>> least wanted
>> to add the note. It's not clear to me whether we should try to fix 
>> this by
>> changing Scanner though.
>>?
>> Essentially, findAll() is defined in terms of 
>> findWithinHorizon(pattern, 0). So
>> if one were to write a loop like so:
>>?
>>???? String str;
>>???? while ((str = scanner.findWithinHorizon(pattern, 0)) != null) {
>>???????? System.out.println(str);
>>???? }
>>?
>> then this loop would have the same problem if pattern were to match zero
>> characters.
>>?
>>> The alternative is to "fix" it, maybe as what Matcher.find() does, 
>>> if the
>>> previous match is
>>> zero-width-match (the fist==last), we step one to the next cursor 
>>> before next
>>> try. I know
>>?
>> Interesting, I didn't know Matcher.find() advances the cursor like 
>> this. But
>> Scanner.findWithinHorizon() apparently doesn't, so that's why an 
>> infinite loop
>> can occur.
>>?
>>> Scanner.findPatternInBuffer() is setting new region set every time 
>>> it is
>>> invoked which makes
>>> it complicated, but I would assume it might be still worth a trying? 
>>> for
>>> example, utilize the
>>> "hasNextResult"/matcher.end(). I'm not sure without looking into the 
>>> code, does
>>>?
>>> while (hasNext(pattern)) {
>>>???? next(pattern);
>>> }
>>>?
>>> have the same issue, when pattern matches 0-width?
>>?
>> No, this doesn't have the problem, because hasNext(pat) and next(pat) 
>> match
>> delimited tokens. Each call to next() implicitly advances past the next
>> delimiter to reach the subsequent token, if any.
>>?
>>?
>> On 3/30/17 8:56 AM, Timo Kinnunen wrote:
>>> I guess this somewhat contrived example also wouldn?t work?
>>>?
>>>???????? String s = "\\b\\w+|\\G|\\B";
>>>???????? String t = "Matcher m = Pattern.compile(s).matcher(t);\n";
>>>???????? Matcher m = Pattern.compile(s).matcher(t);
>>>???????? while(m.find()) {
>>>???????????? System.out.println("'" + m.group() + "'");
>>>???????? }
>>?
>> Right, so if you rewrote this loop to use Scanner.findWithinHorizon() 
>> instead of
>> Matcher,
>>?
>>???? Scanner sc = new Scanner(t);
>>???? String str;
>>???? while ((str = sc.findWithinHorizon(s, 0)) != null) {
>>???????? System.out.println("'" + str + "'");
>>???? }
>>?
>> you'd get an infinite loop with str being continually assigned the 
>> empty string.
>> As Sherman mentioned, the Matcher.find() will advance the cursor if 
>> it gets a
>> zero-width match, avoiding this problem.
>>?
>> * * *
>>?
>> This didn't come up in the code review thread, which was mostly about 
>> concurrent
>> modification and late-binding of the spliterator:
>>?
>>?? 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035034.html
>>?
>> I remember noting this phenomenon a while back, which is why I had 
>> filed the bug
>> to add a note. I seem to remember discussing it, though, but it might 
>> have been
>> in a meeting or in a hallway conversation.
>>?
>> This bug (JDK-8150488) does note that an infinite stream might be 
>> unexpected or
>> surprising, but it's not a fatal problem. It can be terminated with 
>> limit(). It
>> can also be terminated with takeWhile(), also added in JDK 9. Maybe I 
>> could
>> mention these in the API note.
>>?
>> I guess we could also consider changing the implicit 
>> findWithinHorizon() loop
>> that findAll() does, perhaps by having it terminate on a zero-width 
>> match. Or we
>> could even change findWithinHorizon's behavior if it gets a 
>> zero-width match,
>> siilar to what Matcher.find() does. But I'm quite reluctant to start 
>> making such
>> changes at this point.
>>?
>> s'marks
>>?
>>?
>>?
>>>???????? // Outputs:
>>>???????? // 'Matcher'
>>>???????? // ''
>>>???????? // 'm'
>>>???????? // ''
>>>???????? // ''
>>>???????? // ''
>>>???????? // 'Pattern'
>>>???????? // ''
>>>???????? // 'compile'
>>>???????? // ''
>>>???????? // 's'
>>>???????? // ''
>>>???????? // ''
>>>???????? // 'matcher'
>>>???????? // ''
>>>???????? // 't'
>>>???????? // ''
>>>???????? // ''
>>>???????? // ''
>>>???????? // ''
>>>?
>>>?
>>>?
>>> Sent from Mail for Windows 10
>>>?
>>> From: Xueming Shen
>>> Sent: Thursday, March 30, 2017 05:41
>>> To: core-libs-dev at openjdk.java.net
>>> Subject: Re: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()
>>> regardingpossible infinite streams
>>>?
>>> On 3/29/17, 5:56 PM, Stuart Marks wrote:
>>>> Hi all,
>>>>?
>>>> Please review these non-normative textual additions to the
>>>> Scanner.findAll() method docs. These methods were added earlier in JDK
>>>> 9; there's a small pitfall if the regex can match zero characters.
>>>>?
>>> Stuart,
>>>?
>>> This might practically put the api itself almost useless? it might 
>>> be an
>>> easy task to spot
>>> whether or not it's a 0-width-match-possible regex when the regex is
>>> simple, but it gets
>>> harder and harder, if not impossible when the regex gets complicated,
>>> especially consider
>>> the possible use scenario that the use site is embedded deeply inside a
>>> library implementation.
>>>?
>>> The alternative is to "fix" it, maybe as what Matcher.find() does, if
>>> the previous match is
>>> zero-width-match (the fist==last), we step one to the next cursor 
>>> before
>>> next try. I know
>>> Scanner.findPatternInBuffer() is setting new region set every time 
>>> it is
>>> invoked which makes
>>> it complicated, but I would assume it might be still worth a trying? 
>>> for
>>> example, utilize the
>>> "hasNextResult"/matcher.end(). I'm not sure without looking into the
>>> code, does
>>>?
>>> while (hasNext(pattern)) {
>>>????? next(pattern);
>>> }
>>>?
>>> have the same issue, when pattern matches 0-width?
>>>?
>>> Thanks!
>>> -Sherman
>>>?
>>>?
>>>?
>>>?
>>>> Thanks,
>>>>?
>>>> s'marks
>>>>?
>>>>?
>>>> # HG changeset patch
>>>> # User smarks
>>>> # Date 1490749958 25200
>>>> #????? Tue Mar 28 18:12:38 2017 -0700
>>>> # Node ID 6b43c4698752779793d58813f46d3687c17dde75
>>>> # Parent? fb54b256d751ae3191e9cef42ff9f5630931f047
>>>> 8150488: add note to Scanner.findAll() regarding possible infinite
>>>> streams
>>>> Reviewed-by: XXX
>>>>?
>>>> diff -r fb54b256d751 -r 6b43c4698752
>>>> src/java.base/share/classes/java/util/Scanner.java
>>>> --- a/src/java.base/share/classes/java/util/Scanner.java??? Mon Mar 27
>>>> 15:12:01 2017 -0700
>>>> +++ b/src/java.base/share/classes/java/util/Scanner.java??? Tue Mar 28
>>>> 18:12:38 2017 -0700
>>>> @@ -2808,6 +2808,10 @@
>>>>?????? * }
>>>>?????? * }</pre>
>>>>?????? *
>>>> +???? * <p>The pattern must always match at least one character. If
>>>> the pattern
>>>> +???? * can match zero characters, the result will be an infinite 
>>>> stream
>>>> +???? * of empty matches.
>>>> +???? *
>>>> ??????* @param pattern the pattern to be matched
>>>>?????? * @return a sequential stream of match results
>>>>?????? * @throws NullPointerException if pattern is null
>>>> @@ -2829,6 +2833,11 @@
>>>>?????? *???? scanner.findAll(Pattern.compile(patString))
>>>>?????? * }</pre>
>>>>?????? *
>>>> +???? * @apiNote
>>>> +???? * The pattern must always match at least one character. If the
>>>> pattern
>>>> +???? * can match zero characters, the result will be an infinite 
>>>> stream
>>>> +???? * of empty matches.
>>>> +???? *
>>>>?????? * @param patString the pattern string
>>>>?????? * @return a sequential stream of match results
>>>>?????? * @throws NullPointerException if patString is null
>>>?
>>>?
?
?



From chris.hegarty at oracle.com  Wed Apr  5 09:08:29 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 5 Apr 2017 10:08:29 +0100
Subject: RFR [9] 8178101: Migrate the thread deprecation technote to javadoc
 doc-files
Message-ID: <719568AA-F367-4DBF-AC90-E710A50C5B09@oracle.com>

As part of the ongoing doc cleanup effort, we should move the existing
longstanding note on "Thread Primitive Deprecation" into the JDK
repository, say under jdk/src/java.base/share/classes/java/lang/doc-files,
and update the links from the Thread javadoc.

http://cr.openjdk.java.net/~chegar/8178101/

The actual document has only been minimally modified, e.g. stylesheet
link, etc, from the current version [1].

-Chris.

[1] https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html

From Alan.Bateman at oracle.com  Wed Apr  5 11:19:18 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 5 Apr 2017 12:19:18 +0100
Subject: JDK 9 RFR(s): JDK-8065825: Make the java -help consistent with
 the man page
In-Reply-To: <58E437C4.1080306@oracle.com>
References: <58E437C4.1080306@oracle.com>
Message-ID: <4637585f-c00e-2cfb-7b05-36f883aeb597@oracle.com>

On 05/04/2017 01:18, Kumar Srinivasan wrote:

> Hello,
>
> Please review: http://cr.openjdk.java.net/~ksrini/8065825/webrev.00/
>
> This adds a few things to the java -help and some minor cleanup.
Changing @<filepath> to @argument in the options list looks fine.

I'm sure sure why @argument-files is being added to the main usage as it 
makes it look like an exclusive alternative (when it can be of course be 
used in conjunction with options).

-Alan.

From dawid.weiss at gmail.com  Wed Apr  5 12:05:58 2017
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Wed, 5 Apr 2017 14:05:58 +0200
Subject: RFR [9] 8178101: Migrate the thread deprecation technote to
 javadoc doc-files
In-Reply-To: <719568AA-F367-4DBF-AC90-E710A50C5B09@oracle.com>
References: <719568AA-F367-4DBF-AC90-E710A50C5B09@oracle.com>
Message-ID: <CAM21Rt9+DsNxtUh10NfNbQfoPyM=EMYwjg=X4-Tp02gX3-7trA@mail.gmail.com>

While applying this patch, you could probably piggyback a fix to this
typo as well:

"Cleanup would have to [be] repeated"

Dawid

On Wed, Apr 5, 2017 at 11:08 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> As part of the ongoing doc cleanup effort, we should move the existing
> longstanding note on "Thread Primitive Deprecation" into the JDK
> repository, say under jdk/src/java.base/share/classes/java/lang/doc-files,
> and update the links from the Thread javadoc.
>
> http://cr.openjdk.java.net/~chegar/8178101/
>
> The actual document has only been minimally modified, e.g. stylesheet
> link, etc, from the current version [1].
>
> -Chris.
>
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html

From chris.hegarty at oracle.com  Wed Apr  5 12:23:33 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 5 Apr 2017 13:23:33 +0100
Subject: RFR [9] 8178101: Migrate the thread deprecation technote to
 javadoc doc-files
In-Reply-To: <CAM21Rt9+DsNxtUh10NfNbQfoPyM=EMYwjg=X4-Tp02gX3-7trA@mail.gmail.com>
References: <719568AA-F367-4DBF-AC90-E710A50C5B09@oracle.com>
 <CAM21Rt9+DsNxtUh10NfNbQfoPyM=EMYwjg=X4-Tp02gX3-7trA@mail.gmail.com>
Message-ID: <4C9F2D1B-3B95-4D1E-BD25-6EE9AAE9A1D7@oracle.com>

On 5 Apr 2017, at 13:05, Dawid Weiss <dawid.weiss at gmail.com> wrote:
> 
> While applying this patch, you could probably piggyback a fix to this
> typo as well:
> 
> "Cleanup would have to [be] repeated?

Sure, will do.

-Chris.

> Dawid
> 
> On Wed, Apr 5, 2017 at 11:08 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> As part of the ongoing doc cleanup effort, we should move the existing
>> longstanding note on "Thread Primitive Deprecation" into the JDK
>> repository, say under jdk/src/java.base/share/classes/java/lang/doc-files,
>> and update the links from the Thread javadoc.
>> 
>> http://cr.openjdk.java.net/~chegar/8178101/
>> 
>> The actual document has only been minimally modified, e.g. stylesheet
>> link, etc, from the current version [1].
>> 
>> -Chris.
>> 
>> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html


From david.holmes at oracle.com  Wed Apr  5 12:26:29 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 5 Apr 2017 22:26:29 +1000
Subject: RFR [9] 8178101: Migrate the thread deprecation technote to
 javadoc doc-files
In-Reply-To: <719568AA-F367-4DBF-AC90-E710A50C5B09@oracle.com>
References: <719568AA-F367-4DBF-AC90-E710A50C5B09@oracle.com>
Message-ID: <44d342b7-e98a-c0a7-d392-bdc2cb9560b7@oracle.com>

On 5/04/2017 7:08 PM, Chris Hegarty wrote:
> As part of the ongoing doc cleanup effort, we should move the existing
> longstanding note on "Thread Primitive Deprecation" into the JDK
> repository, say under jdk/src/java.base/share/classes/java/lang/doc-files,
> and update the links from the Thread javadoc.
>
> http://cr.openjdk.java.net/~chegar/8178101/

Looks good Chris!

> The actual document has only been minimally modified, e.g. stylesheet
> link, etc, from the current version [1].

Been years since I've read that :)

Thanks,
David
-----

> -Chris.
>
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html
>

From david.holmes at oracle.com  Wed Apr  5 12:29:34 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 5 Apr 2017 22:29:34 +1000
Subject: RFR [9] 8178101: Migrate the thread deprecation technote to
 javadoc doc-files
In-Reply-To: <44d342b7-e98a-c0a7-d392-bdc2cb9560b7@oracle.com>
References: <719568AA-F367-4DBF-AC90-E710A50C5B09@oracle.com>
 <44d342b7-e98a-c0a7-d392-bdc2cb9560b7@oracle.com>
Message-ID: <464c139d-3334-18af-9840-ddb18e8ab52f@oracle.com>

Forgot to say, doesn't the html file need a copyright notice added 
before we add it?

David

On 5/04/2017 10:26 PM, David Holmes wrote:
> On 5/04/2017 7:08 PM, Chris Hegarty wrote:
>> As part of the ongoing doc cleanup effort, we should move the existing
>> longstanding note on "Thread Primitive Deprecation" into the JDK
>> repository, say under
>> jdk/src/java.base/share/classes/java/lang/doc-files,
>> and update the links from the Thread javadoc.
>>
>> http://cr.openjdk.java.net/~chegar/8178101/
>
> Looks good Chris!
>
>> The actual document has only been minimally modified, e.g. stylesheet
>> link, etc, from the current version [1].
>
> Been years since I've read that :)
>
> Thanks,
> David
> -----
>
>> -Chris.
>>
>> [1]
>> https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html
>>
>>

From chris.hegarty at oracle.com  Wed Apr  5 12:42:07 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 5 Apr 2017 13:42:07 +0100
Subject: RFR [9] 8178101: Migrate the thread deprecation technote to
 javadoc doc-files
In-Reply-To: <464c139d-3334-18af-9840-ddb18e8ab52f@oracle.com>
References: <719568AA-F367-4DBF-AC90-E710A50C5B09@oracle.com>
 <44d342b7-e98a-c0a7-d392-bdc2cb9560b7@oracle.com>
 <464c139d-3334-18af-9840-ddb18e8ab52f@oracle.com>
Message-ID: <F67ED32E-CC23-4A64-A4A8-5C3247EF32E2@oracle.com>


> On 5 Apr 2017, at 13:29, David Holmes <david.holmes at oracle.com> wrote:
> 
> Forgot to say, doesn't the html file need a copyright notice added before we add it?

Sure, that makes sense. The earliest reference I can find is 2005, but
I?m sure that it was probably around before that!

http://cr.openjdk.java.net/~chegar/8178101_inc/src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html.udiff.html

-Chris.


From chris.w.dennis at gmail.com  Wed Apr  5 12:57:58 2017
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Wed, 5 Apr 2017 08:57:58 -0400
Subject: Java 9 and IntSummaryStatistics et al.
In-Reply-To: <bc52afc5-6e7e-27af-c502-a24822c0c122@gmail.com>
References: <4420BF94-E1FB-4C24-9236-B29AF0E1B773@gmail.com>
 <2060281512.1263209.1490783571858.JavaMail.zimbra@u-pem.fr>
 <14AE3491-15A8-4823-9476-3E986E4F685D@oracle.com>
 <DA9DA117-7C04-48C7-AFDF-B5CAF6655AB4@gmail.com>
 <6fa9a53c-b23e-7639-eb9a-eae36b3856b4@gmail.com>
 <23871708-D1B7-41FB-8AC4-488A4EE40459@gmail.com>
 <bc52afc5-6e7e-27af-c502-a24822c0c122@gmail.com>
Message-ID: <2C5102D0-0405-4648-8BE8-5744B40FEE80@gmail.com>

Taking from this conversation that there is consensus (at least amongst those on this thread) that this is an issue that should be fixed, what should my next steps be in order to help move this forward?

> On Mar 30, 2017, at 10:01 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> 
> 
> On 03/30/2017 03:14 PM, Chris Dennis wrote:
>> This is indeed nice? but I presume that we all agree that the best solution here would be to allow instantiation of an IntSummaryStatistics object in a specific state.
> 
> Of course. I just couldn't resist the challenge of R?mi's nice math exercise...
> 
> Regards, Peter
> 
>> 
>>> On Mar 29, 2017, at 2:43 PM, Peter Levart <peter.levart at gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On 03/29/2017 06:06 PM, Chris Dennis wrote:
>>>> Remi: I really have to squint pretty hard to see that as anything other than ?brute-force? - it?s still an O(N) calculation.
>>> Here's O(log2(N)):
>>> 
>>>    static IntSummaryStatistics create(long count, long sum, int min, int max) {
>>>        if (count < 2 || min == max) {
>>>            return combineProduct(new IntSummaryStatistics(), count, min);
>>>        } else {
>>>            long minCnt = (count * max - sum) / (max - min);
>>>            long maxCnt = count - minCnt - 1;
>>>            long minSum = minCnt * min;
>>>            long maxSum = maxCnt * max;
>>>            long minMaxSum = minSum + maxSum;
>>>            int mid = (int) (sum - minMaxSum);
>>>            IntSummaryStatistics stats = new IntSummaryStatistics();
>>>            combineProduct(stats, minCnt, min);
>>>            combineProduct(stats, maxCnt, max);
>>>            stats.accept(mid);
>>>            return stats;
>>>        }
>>>    }
>>> 
>>>    static IntSummaryStatistics combineProduct(IntSummaryStatistics stats, long count, int value) {
>>>        IntSummaryStatistics pow2 = null;
>>>        while (count > 0) {
>>>            if (pow2 == null) {
>>>                pow2 = new IntSummaryStatistics();
>>>                pow2.accept(value);
>>>            } else {
>>>                pow2.combine(pow2);
>>>            }
>>>            if ((count & 1L) == 1L) {
>>>                stats.combine(pow2);
>>>            }
>>>            count >>>= 1;
>>>        }
>>>        return stats;
>>>    }
>>> 
>>> 
>>> Regards, Peter
>>> 
> 


From Roger.Riggs at Oracle.com  Wed Apr  5 14:13:30 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 5 Apr 2017 10:13:30 -0400
Subject: [9] RFR 8177969: Faster FilePermission::implies by avoiding the
 use of Path::relativize
In-Reply-To: <4f1e0c02-a11d-2694-84ad-cf8804021f3c@oracle.com>
References: <4f1e0c02-a11d-2694-84ad-cf8804021f3c@oracle.com>
Message-ID: <9f96ed4d-9282-d776-f767-d3fe060ba895@Oracle.com>

Hi Max,

The code looks ok.

How much faster does it make FilePermission compares?

I assume if it is not accepted to be fixed in JDK 9, you will push it to 
JDK 10.

Roger


On 4/3/2017 11:30 AM, Weijun Wang wrote:
> http://cr.openjdk.java.net/~weijun/8177969/webrev.00/
>
> This new implementation of containsPath(Path,Path) uses the logic of 
> Path::relativize without directly calling it, which is much faster now.
>
> Thanks
> Max


From paul.sandoz at oracle.com  Wed Apr  5 16:22:49 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 5 Apr 2017 09:22:49 -0700
Subject: JDK 9 RFR of JDK-8177640:
 jdk/internal/util/jar/TestVersionedStream.java fails on Windows
In-Reply-To: <bf1fd9d2-ac2a-4346-e30b-0ceb449f68e3@oracle.com>
References: <bf1fd9d2-ac2a-4346-e30b-0ceb449f68e3@oracle.com>
Message-ID: <A1313D1C-C7B9-42F8-A3DF-538AD5D1546A@oracle.com>


> On 4 Apr 2017, at 22:31, Amy Lu <amy.lu at oracle.com> wrote:
> 
> Please review this test-only change.
> 
> jdk/internal/util/jar/TestVersionedStream.java
> 
> This test fails on Windows platforms. Test tries to create and write something to the files (in test preparation method 'createFiles') for later comparison (in test method 'test'). The content write to the new created file contains path and line separator,but test does not take into account the platform difference.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8177640
> webrev: http://cr.openjdk.java.net/~amlu/8177640/webrev.00/
> 

+1

Paul.

From paul.sandoz at oracle.com  Wed Apr  5 16:30:57 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 5 Apr 2017 09:30:57 -0700
Subject: Java 9 and IntSummaryStatistics et al.
In-Reply-To: <2C5102D0-0405-4648-8BE8-5744B40FEE80@gmail.com>
References: <4420BF94-E1FB-4C24-9236-B29AF0E1B773@gmail.com>
 <2060281512.1263209.1490783571858.JavaMail.zimbra@u-pem.fr>
 <14AE3491-15A8-4823-9476-3E986E4F685D@oracle.com>
 <DA9DA117-7C04-48C7-AFDF-B5CAF6655AB4@gmail.com>
 <6fa9a53c-b23e-7639-eb9a-eae36b3856b4@gmail.com>
 <23871708-D1B7-41FB-8AC4-488A4EE40459@gmail.com>
 <bc52afc5-6e7e-27af-c502-a24822c0c122@gmail.com>
 <2C5102D0-0405-4648-8BE8-5744B40FEE80@gmail.com>
Message-ID: <F225937C-A832-4073-8872-C3F5602F0F93@oracle.com>

Hi Chris,

I logged this issue:

  https://bugs.openjdk.java.net/browse/JDK-8178117 <https://bugs.openjdk.java.net/browse/JDK-8178117>

Do you want to provide a patch?

I can help guide you through the process. See here if not already familiar:

  http://openjdk.java.net/contribute/ <http://openjdk.java.net/contribute/>

Thanks,
Paul.

From kumar.x.srinivasan at oracle.com  Wed Apr  5 16:31:38 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 05 Apr 2017 09:31:38 -0700
Subject: JDK 9 RFR(s): JDK-8065825: Make the java -help consistent with
 the man page
In-Reply-To: <4637585f-c00e-2cfb-7b05-36f883aeb597@oracle.com>
References: <58E437C4.1080306@oracle.com>
 <4637585f-c00e-2cfb-7b05-36f883aeb597@oracle.com>
Message-ID: <58E51BEA.2060808@oracle.com>

Ok I removed it from the main usage, yes the existing
explanation for @argfile should suffice.

Is the information accurate with respect to all the new module options ?
I have checked them, but would help to another pair of "jigsaw" eyes on it.
Since the L10N freeze is coming up shortly.

http://cr.openjdk.java.net/~ksrini/8065825/webrev.01/

Kumar



> On 05/04/2017 01:18, Kumar Srinivasan wrote:
>
>> Hello,
>>
>> Please review: http://cr.openjdk.java.net/~ksrini/8065825/webrev.00/
>>
>> This adds a few things to the java -help and some minor cleanup.
> Changing @<filepath> to @argument in the options list looks fine.
>
> I'm sure sure why @argument-files is being added to the main usage as 
> it makes it look like an exclusive alternative (when it can be of 
> course be used in conjunction with options).
>
> -Alan.


From stuart.marks at oracle.com  Wed Apr  5 16:49:31 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 5 Apr 2017 09:49:31 -0700
Subject: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()
 regardingpossible infinite streams
In-Reply-To: <89d5129f-faff-20cb-eb86-6d3bb4151958@oracle.com>
References: <ca6ee328-1121-ed95-48ca-92cf5be02c0e@oracle.com>
 <58DC7E53.6040603@oracle.com> <58dd2aba.298fdf0a.86cca.3418@mx.google.com>
 <cc200e33-24dc-df27-1c56-dc11bf695c36@oracle.com>
 <fc36e657-a196-6f3e-bd42-fb1bdc741205@oracle.com>
 <58E427E8.2020901@oracle.com>
 <89d5129f-faff-20cb-eb86-6d3bb4151958@oracle.com>
Message-ID: <f3dd4c6e-6774-777c-cebd-539fe51b88a1@oracle.com>



On 4/4/17 10:48 PM, Stuart Marks wrote:
>
>
> On 4/4/17 4:10 PM, Xueming Shen wrote:
>> Personally I think the use scenario and the expected resulting behavior of
>> Stream<MR>finaAll(ptn) should be more equivalent/similar to the use case  of
>> while (s.hasNext(p)) { s.next(p); }, or while (m.find()) { }, therefor it is
>> probably desired it can be used without worrying the possibility of getting
>> into an infinite loop.
>
> The Scanner.tokens() API, also added in Java 9, provides a stream of delimited
> tokens (strings) that's more-or-less equivalent of a hasNext()/next() loop.
>
> Just as findWithinHorizon() is a distinct use case from hasNext()/next()
> delimited tokens, findAll() provides for distinct uses from tokens().
>
>> That said, I agree it might be hard to argue to fix it in jdk9. The question
>> is if we are going to fix it in 9u sometime in the further, is it still worth
>> putting down the note in the API now. I'm fine if you believe a note will
>> help at least make the issue a known/documented usage limitation, for JDK9.

I've thought about this some more... fundamentally the behavior is odd, since 
Scanner.findWithinHorizon() is *based on* Matcher.find(). So why does 
Matcher.find() "work" and S.findWithinHorizon() produce an infinite loop?

If you look in findPatternInBuffer, upon which findWithinHorizon and findAll are 
based, it essentially resets the matcher every time, which cases the 
Matcher.find() special case to be bypassed. So I think this could be considered 
a bug in findPatternInBuffer, which causes misbehavior to be visible in 
findWithinHorizon and findAll.

I've filed:

JDK-8178116 scanner.findWithinHorizon doesn't advance after matching zero characters

This is certainly too subtle to be trying to fix right now.

I guess the question is, if we believe this is a bug that will be fixed at some 
point, do we add a note to findAll() -- and maybe even findWithinHorizon() -- to 
document this? Historically we haven't documented bugs like this, so maybe not.

Note also that this behavior of findWithinHorizon has been there since JDK 6, 
which is the earliest release I had conveniently at hand.

s'marks


>>
>> Yes, I think we did chat about this one at the hallway some time when either
>> you or something ran into the loop by using the method ...
>
> There are already a couple ways you can get unexpected behavior with Scanner if
> you're not careful. For example, see the warnings in findWithinHorizon() and
> skip() about the possibility of buffering up the entire input. These methods are
> useful, but if you're not careful with the regex you provide, things can go
> wrong. The findAll() method seems to be in the same situation. It's not clear to
> me that any of these are bugs for which there's a reasonable fix.
>
> So yes, I think the note is necessary. I could also add something about
> terminating such streams with limit() or takeWhile().
>
> s'marks
>
>>
>> Thanks,
>> Sherman
>>
>>
>>>
>>> s'marks
>>>
>>> On 3/30/17 2:19 PM, Stuart Marks wrote:
>>>> Hi Timo, Sherman,
>>>>
>>>> Thanks for looking at this.
>>>>
>>>> Sherman wrote:
>>>>
>>>>> This might practically put the api itself almost useless? it might be an easy
>>>>> task to spot
>>>>> whether or not it's a 0-width-match-possible regex when the regex is simple,
>>>>> but it gets
>>>>> harder and harder, if not impossible when the regex gets complicated,
>>>>> especially consider
>>>>> the possible use scenario that the use site is embedded deeply inside a
>>>>> library implementation.
>>>>
>>>> Well, not "useless", but perhaps less useful than one might like. :-)
>>>>
>>>> I think this is potentially surprising behavior, which is why I at least wanted
>>>> to add the note. It's not clear to me whether we should try to fix this by
>>>> changing Scanner though.
>>>>
>>>> Essentially, findAll() is defined in terms of findWithinHorizon(pattern, 0). So
>>>> if one were to write a loop like so:
>>>>
>>>>     String str;
>>>>     while ((str = scanner.findWithinHorizon(pattern, 0)) != null) {
>>>>         System.out.println(str);
>>>>     }
>>>>
>>>> then this loop would have the same problem if pattern were to match zero
>>>> characters.
>>>>
>>>>> The alternative is to "fix" it, maybe as what Matcher.find() does, if the
>>>>> previous match is
>>>>> zero-width-match (the fist==last), we step one to the next cursor before next
>>>>> try. I know
>>>>
>>>> Interesting, I didn't know Matcher.find() advances the cursor like this. But
>>>> Scanner.findWithinHorizon() apparently doesn't, so that's why an infinite loop
>>>> can occur.
>>>>
>>>>> Scanner.findPatternInBuffer() is setting new region set every time it is
>>>>> invoked which makes
>>>>> it complicated, but I would assume it might be still worth a trying? for
>>>>> example, utilize the
>>>>> "hasNextResult"/matcher.end(). I'm not sure without looking into the code,
>>>>> does
>>>>>
>>>>> while (hasNext(pattern)) {
>>>>>     next(pattern);
>>>>> }
>>>>>
>>>>> have the same issue, when pattern matches 0-width?
>>>>
>>>> No, this doesn't have the problem, because hasNext(pat) and next(pat) match
>>>> delimited tokens. Each call to next() implicitly advances past the next
>>>> delimiter to reach the subsequent token, if any.
>>>>
>>>>
>>>> On 3/30/17 8:56 AM, Timo Kinnunen wrote:
>>>>> I guess this somewhat contrived example also wouldn?t work?
>>>>>
>>>>>         String s = "\\b\\w+|\\G|\\B";
>>>>>         String t = "Matcher m = Pattern.compile(s).matcher(t);\n";
>>>>>         Matcher m = Pattern.compile(s).matcher(t);
>>>>>         while(m.find()) {
>>>>>             System.out.println("'" + m.group() + "'");
>>>>>         }
>>>>
>>>> Right, so if you rewrote this loop to use Scanner.findWithinHorizon()
>>>> instead of
>>>> Matcher,
>>>>
>>>>     Scanner sc = new Scanner(t);
>>>>     String str;
>>>>     while ((str = sc.findWithinHorizon(s, 0)) != null) {
>>>>         System.out.println("'" + str + "'");
>>>>     }
>>>>
>>>> you'd get an infinite loop with str being continually assigned the empty
>>>> string.
>>>> As Sherman mentioned, the Matcher.find() will advance the cursor if it gets a
>>>> zero-width match, avoiding this problem.
>>>>
>>>> * * *
>>>>
>>>> This didn't come up in the code review thread, which was mostly about
>>>> concurrent
>>>> modification and late-binding of the spliterator:
>>>>
>>>>
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035034.html
>>>>
>>>> I remember noting this phenomenon a while back, which is why I had filed the
>>>> bug
>>>> to add a note. I seem to remember discussing it, though, but it might have been
>>>> in a meeting or in a hallway conversation.
>>>>
>>>> This bug (JDK-8150488) does note that an infinite stream might be unexpected or
>>>> surprising, but it's not a fatal problem. It can be terminated with limit(). It
>>>> can also be terminated with takeWhile(), also added in JDK 9. Maybe I could
>>>> mention these in the API note.
>>>>
>>>> I guess we could also consider changing the implicit findWithinHorizon() loop
>>>> that findAll() does, perhaps by having it terminate on a zero-width match.
>>>> Or we
>>>> could even change findWithinHorizon's behavior if it gets a zero-width match,
>>>> siilar to what Matcher.find() does. But I'm quite reluctant to start making
>>>> such
>>>> changes at this point.
>>>>
>>>> s'marks
>>>>
>>>>
>>>>
>>>>>         // Outputs:
>>>>>         // 'Matcher'
>>>>>         // ''
>>>>>         // 'm'
>>>>>         // ''
>>>>>         // ''
>>>>>         // ''
>>>>>         // 'Pattern'
>>>>>         // ''
>>>>>         // 'compile'
>>>>>         // ''
>>>>>         // 's'
>>>>>         // ''
>>>>>         // ''
>>>>>         // 'matcher'
>>>>>         // ''
>>>>>         // 't'
>>>>>         // ''
>>>>>         // ''
>>>>>         // ''
>>>>>         // ''
>>>>>
>>>>>
>>>>>
>>>>> Sent from Mail for Windows 10
>>>>>
>>>>> From: Xueming Shen
>>>>> Sent: Thursday, March 30, 2017 05:41
>>>>> To: core-libs-dev at openjdk.java.net
>>>>> Subject: Re: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()
>>>>> regardingpossible infinite streams
>>>>>
>>>>> On 3/29/17, 5:56 PM, Stuart Marks wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Please review these non-normative textual additions to the
>>>>>> Scanner.findAll() method docs. These methods were added earlier in JDK
>>>>>> 9; there's a small pitfall if the regex can match zero characters.
>>>>>>
>>>>> Stuart,
>>>>>
>>>>> This might practically put the api itself almost useless? it might be an
>>>>> easy task to spot
>>>>> whether or not it's a 0-width-match-possible regex when the regex is
>>>>> simple, but it gets
>>>>> harder and harder, if not impossible when the regex gets complicated,
>>>>> especially consider
>>>>> the possible use scenario that the use site is embedded deeply inside a
>>>>> library implementation.
>>>>>
>>>>> The alternative is to "fix" it, maybe as what Matcher.find() does, if
>>>>> the previous match is
>>>>> zero-width-match (the fist==last), we step one to the next cursor before
>>>>> next try. I know
>>>>> Scanner.findPatternInBuffer() is setting new region set every time it is
>>>>> invoked which makes
>>>>> it complicated, but I would assume it might be still worth a trying? for
>>>>> example, utilize the
>>>>> "hasNextResult"/matcher.end(). I'm not sure without looking into the
>>>>> code, does
>>>>>
>>>>> while (hasNext(pattern)) {
>>>>>      next(pattern);
>>>>> }
>>>>>
>>>>> have the same issue, when pattern matches 0-width?
>>>>>
>>>>> Thanks!
>>>>> -Sherman
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> s'marks
>>>>>>
>>>>>>
>>>>>> # HG changeset patch
>>>>>> # User smarks
>>>>>> # Date 1490749958 25200
>>>>>> #      Tue Mar 28 18:12:38 2017 -0700
>>>>>> # Node ID 6b43c4698752779793d58813f46d3687c17dde75
>>>>>> # Parent  fb54b256d751ae3191e9cef42ff9f5630931f047
>>>>>> 8150488: add note to Scanner.findAll() regarding possible infinite
>>>>>> streams
>>>>>> Reviewed-by: XXX
>>>>>>
>>>>>> diff -r fb54b256d751 -r 6b43c4698752
>>>>>> src/java.base/share/classes/java/util/Scanner.java
>>>>>> --- a/src/java.base/share/classes/java/util/Scanner.java    Mon Mar 27
>>>>>> 15:12:01 2017 -0700
>>>>>> +++ b/src/java.base/share/classes/java/util/Scanner.java    Tue Mar 28
>>>>>> 18:12:38 2017 -0700
>>>>>> @@ -2808,6 +2808,10 @@
>>>>>>       * }
>>>>>>       * }</pre>
>>>>>>       *
>>>>>> +     * <p>The pattern must always match at least one character. If
>>>>>> the pattern
>>>>>> +     * can match zero characters, the result will be an infinite stream
>>>>>> +     * of empty matches.
>>>>>> +     *
>>>>>>       * @param pattern the pattern to be matched
>>>>>>       * @return a sequential stream of match results
>>>>>>       * @throws NullPointerException if pattern is null
>>>>>> @@ -2829,6 +2833,11 @@
>>>>>>       *     scanner.findAll(Pattern.compile(patString))
>>>>>>       * }</pre>
>>>>>>       *
>>>>>> +     * @apiNote
>>>>>> +     * The pattern must always match at least one character. If the
>>>>>> pattern
>>>>>> +     * can match zero characters, the result will be an infinite stream
>>>>>> +     * of empty matches.
>>>>>> +     *
>>>>>>       * @param patString the pattern string
>>>>>>       * @return a sequential stream of match results
>>>>>>       * @throws NullPointerException if patString is null
>>>>>
>>>>>
>>

From brian.goetz at oracle.com  Wed Apr  5 18:13:50 2017
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 5 Apr 2017 14:13:50 -0400
Subject: Java 9 and IntSummaryStatistics et al.
In-Reply-To: <2C5102D0-0405-4648-8BE8-5744B40FEE80@gmail.com>
References: <4420BF94-E1FB-4C24-9236-B29AF0E1B773@gmail.com>
 <2060281512.1263209.1490783571858.JavaMail.zimbra@u-pem.fr>
 <14AE3491-15A8-4823-9476-3E986E4F685D@oracle.com>
 <DA9DA117-7C04-48C7-AFDF-B5CAF6655AB4@gmail.com>
 <6fa9a53c-b23e-7639-eb9a-eae36b3856b4@gmail.com>
 <23871708-D1B7-41FB-8AC4-488A4EE40459@gmail.com>
 <bc52afc5-6e7e-27af-c502-a24822c0c122@gmail.com>
 <2C5102D0-0405-4648-8BE8-5744B40FEE80@gmail.com>
Message-ID: <19db4e4f-6fa3-e6ea-0e95-6493b6d74514@oracle.com>

Adding a new public ctor to initialize the state to a known value seems 
reasonable to me.

On 4/5/2017 8:57 AM, Chris Dennis wrote:
> Taking from this conversation that there is consensus (at least amongst those on this thread) that this is an issue that should be fixed, what should my next steps be in order to help move this forward?


From chris.w.dennis at gmail.com  Wed Apr  5 18:30:50 2017
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Wed, 5 Apr 2017 14:30:50 -0400
Subject: Java 9 and IntSummaryStatistics et al.
In-Reply-To: <F225937C-A832-4073-8872-C3F5602F0F93@oracle.com>
References: <4420BF94-E1FB-4C24-9236-B29AF0E1B773@gmail.com>
 <2060281512.1263209.1490783571858.JavaMail.zimbra@u-pem.fr>
 <14AE3491-15A8-4823-9476-3E986E4F685D@oracle.com>
 <DA9DA117-7C04-48C7-AFDF-B5CAF6655AB4@gmail.com>
 <6fa9a53c-b23e-7639-eb9a-eae36b3856b4@gmail.com>
 <23871708-D1B7-41FB-8AC4-488A4EE40459@gmail.com>
 <bc52afc5-6e7e-27af-c502-a24822c0c122@gmail.com>
 <2C5102D0-0405-4648-8BE8-5744B40FEE80@gmail.com>
 <F225937C-A832-4073-8872-C3F5602F0F93@oracle.com>
Message-ID: <D14EA4D1-C88F-44E2-B1B2-1A396902A6D4@gmail.com>

I can do that. I?ve done this before a couple of times, so it should be reasonably familiar. Will attempt to whip something up in the next couple of days.

Thanks,

Chris

> On Apr 5, 2017, at 12:30 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi Chris,
> 
> I logged this issue:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8178117 <https://bugs.openjdk.java.net/browse/JDK-8178117>
> 
> Do you want to provide a patch?
> 
> I can help guide you through the process. See here if not already familiar:
> 
>  http://openjdk.java.net/contribute/ <http://openjdk.java.net/contribute/>
> 
> Thanks,
> Paul.


From Alan.Bateman at oracle.com  Wed Apr  5 19:06:08 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 5 Apr 2017 20:06:08 +0100
Subject: JDK 9 RFR(s): JDK-8065825: Make the java -help consistent with
 the man page
In-Reply-To: <58E51BEA.2060808@oracle.com>
References: <58E437C4.1080306@oracle.com>
 <4637585f-c00e-2cfb-7b05-36f883aeb597@oracle.com>
 <58E51BEA.2060808@oracle.com>
Message-ID: <7cea4146-78db-a9e1-4c11-38616bd0620a@oracle.com>

On 05/04/2017 17:31, Kumar Srinivasan wrote:

> Ok I removed it from the main usage, yes the existing
> explanation for @argfile should suffice.
>
> Is the information accurate with respect to all the new module options ?
> I have checked them, but would help to another pair of "jigsaw" eyes 
> on it.
> Since the L10N freeze is coming up shortly.
>
> http://cr.openjdk.java.net/~ksrini/8065825/webrev.01/
The updated webrev looks good to me.

-Alan

From naoto.sato at oracle.com  Wed Apr  5 21:14:55 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 5 Apr 2017 14:14:55 -0700
Subject: [8u] RFR: 8177776: Create an equivalent test case for JDK9's
 SupplementalJapaneseEraTest
In-Reply-To: <69774039-1980-882f-2f89-fac194fd7fa7@oracle.com>
References: <69774039-1980-882f-2f89-fac194fd7fa7@oracle.com>
Message-ID: <d424dc05-691c-c9a2-8b45-4d73c2a70375@oracle.com>

I revised the test case not to rely on shell script. Please review.

http://cr.openjdk.java.net/~naoto/8177776/webrev.01/

Naoto

On 3/30/17 2:10 PM, Naoto Sato wrote:
> Hello,
>
> Please review the changes to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8177776
>
> The proposed change is located at:
>
> http://cr.openjdk.java.net/~naoto/8177776/webrev.00/
>
> This is for backporting fixes for JapaneseEra related issues (8054214,
> 8173423). The original fixes in JDK9 included a test case,
> SupplementalJapaneseEraTest which is intended for the system property
> testing. The above proposed fix intends to adapt that test case into
> JDK8, where calendars.properties file is used instead of the system
> property. The test is pretty much identical to JDK9's. The difference is
> to deal with the calendars.properties file and removed some
> non-applicable cases in JDK8.
>
> Naoto

From mandy.chung at oracle.com  Wed Apr  5 22:15:09 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 5 Apr 2017 15:15:09 -0700
Subject: RFR 9: 8165641 : Deprecate Object.finalize
In-Reply-To: <78e0fb3c-0850-4aa9-9f73-e319e8a8e7b9@Oracle.com>
References: <c7893765-1c5b-18e3-c5f3-a9ccf9b05094@Oracle.com>
 <96fe9ae0-993a-aea6-cabf-f079450dc128@Oracle.com>
 <49eb0b85-130a-b74d-e760-120674de6ebc@oracle.com>
 <CAMOCf+iAT-29E0wu8WFcNiZq1di1xCq=-kSwjdfhkq2cEA1iJA@mail.gmail.com>
 <31a37a8c-e3fd-96cf-00a4-090d65c21cff@Oracle.com>
 <78e0fb3c-0850-4aa9-9f73-e319e8a8e7b9@Oracle.com>
Message-ID: <CB9A7D8E-87FE-4B5D-BEFF-27696B302D15@oracle.com>


> On Apr 3, 2017, at 7:44 AM, Roger Riggs <roger.riggs at oracle.com> wrote:
> 
> [1] http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641


Typo: s/an finalizable/a finalizable/

+     * The {@code finalize} method might be called on an finalizable object

Otherwise, looks good.  No need for a new webrev.

Mandy

From martinrb at google.com  Wed Apr  5 22:27:46 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 5 Apr 2017 15:27:46 -0700
Subject: RFR 9: 8165641 : Deprecate Object.finalize
In-Reply-To: <78e0fb3c-0850-4aa9-9f73-e319e8a8e7b9@Oracle.com>
References: <c7893765-1c5b-18e3-c5f3-a9ccf9b05094@Oracle.com>
 <96fe9ae0-993a-aea6-cabf-f079450dc128@Oracle.com>
 <49eb0b85-130a-b74d-e760-120674de6ebc@oracle.com>
 <CAMOCf+iAT-29E0wu8WFcNiZq1di1xCq=-kSwjdfhkq2cEA1iJA@mail.gmail.com>
 <31a37a8c-e3fd-96cf-00a4-090d65c21cff@Oracle.com>
 <78e0fb3c-0850-4aa9-9f73-e319e8a8e7b9@Oracle.com>
Message-ID: <CA+kOe08wu2NuhFVRKaO9wM3yGXuagLL+mJYLj8hpdi8UEZRB_g@mail.gmail.com>

(I would not have deprecated finalize; I don't think we have a good enough
answer for what to use instead.  But) Looks good.

Typo:

an finalizable object

From stuart.marks at oracle.com  Thu Apr  6 00:44:22 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 5 Apr 2017 17:44:22 -0700
Subject: JDK 9 RFR(m): 8177788 migrate collections docs into jdk doc-files
Message-ID: <a2c151fa-4586-31c3-cc1e-03dfc1860255@oracle.com>

Hi all,

Here's another step in the docs cleanup: migration of the collections 
technotes/guides into the JDK's javadoc doc-files. This is a webrev containing 
two changesets:

JDK-8177787 copy collections technotes/guides html files into jdk doc-files
JDK-8177788 fix links, minor editing, add Java SE 9 changes to collections docs

The main way to reach these pages will now be a link from the java.util package 
documentation.

There are a bunch of places around the javadoc that point to the obsolete 
location of the collections docs. These are typically within sentences of the 
form "This class is a member of the Java Collections Framework." The next step 
will be to change all those links to point to the docs in their new location.

Here's the webrev:

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

Thanks,

s'marks

From mandy.chung at oracle.com  Thu Apr  6 00:54:53 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 5 Apr 2017 17:54:53 -0700
Subject: JDK 9 RFR(m): 8177788 migrate collections docs into jdk doc-files
In-Reply-To: <a2c151fa-4586-31c3-cc1e-03dfc1860255@oracle.com>
References: <a2c151fa-4586-31c3-cc1e-03dfc1860255@oracle.com>
Message-ID: <E8A4BB53-E9DE-4C87-A2CA-5F88F15BA387@oracle.com>


> On Apr 5, 2017, at 5:44 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi all,
> 
> Here's another step in the docs cleanup: migration of the collections technotes/guides into the JDK's javadoc doc-files. This is a webrev containing two changesets:
> 
> JDK-8177787 copy collections technotes/guides html files into jdk doc-files
> JDK-8177788 fix links, minor editing, add Java SE 9 changes to collections docs
> 
> The main way to reach these pages will now be a link from the java.util package documentation.
> 
> There are a bunch of places around the javadoc that point to the obsolete location of the collections docs. These are typically within sentences of the form "This class is a member of the Java Collections Framework." The next step will be to change all those links to point to the docs in their new location.
> 
> Here's the webrev:
> 
> http://cr.openjdk.java.net/~smarks/reviews/8177788/webrev.0/

Other than designfaq.html, these html files such as changes[3-9].html,
index.html, overview.html, and reference.html seem not worthing 
to be retained.

Since the links need to be fixed anyway, perhaps we should get rid
of those links instead unless it references some useful documents.

Mandy


From stuart.marks at oracle.com  Thu Apr  6 01:46:27 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 5 Apr 2017 18:46:27 -0700
Subject: JDK 9 RFR(m): 8177788 migrate collections docs into jdk doc-files
In-Reply-To: <E8A4BB53-E9DE-4C87-A2CA-5F88F15BA387@oracle.com>
References: <a2c151fa-4586-31c3-cc1e-03dfc1860255@oracle.com>
 <E8A4BB53-E9DE-4C87-A2CA-5F88F15BA387@oracle.com>
Message-ID: <7cef5084-4d6d-9694-68aa-02b84b06ecb6@oracle.com>



On 4/5/17 5:54 PM, Mandy Chung wrote:
>
>> On Apr 5, 2017, at 5:44 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
>>
>> http://cr.openjdk.java.net/~smarks/reviews/8177788/webrev.0/
>
> Other than designfaq.html, these html files such as changes[3-9].html,
> index.html, overview.html, and reference.html seem not worthing
> to be retained.

The overview and reference are arguably redundant with the tutorial, but the 
tutorial isn't as comprehensive as these are. Some of the material could be 
dropped, rearranged, or merged into designfaq, but that's more editing than I 
want to do at this point.

I rather like having the version history around. It's much easier than digging 
through release notes, or looking through documentation pages of a succession of 
historical JDK releases.

> Since the links need to be fixed anyway, perhaps we should get rid
> of those links instead unless it references some useful documents.

You mean, the links from all the various collections classes, where they say 
"This class is a member of the Java Collections Framework" ? Fixing them isn't 
really a problem; it's basically a global replace.

I'd rather not remove these links; they provide some cohesion to what otherwise 
would be random class files scattered across the JDK.

s'marks

From claes.redestad at oracle.com  Thu Apr  6 10:45:49 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 6 Apr 2017 12:45:49 +0200
Subject: JDK 10 RFR of 8176894: Provide specialized implementation for
 default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute in
 TreeMap
In-Reply-To: <75959b26-9023-c662-bfda-87860a614a2c@oracle.com>
References: <048a8a8d-20ac-4d32-1b49-244e85afdfd5@oracle.com>
 <CA+kOe0-6r+e74UxYZKX=q_DYYEKQpyMtn53dxqj=3UWBCfm4FQ@mail.gmail.com>
 <507d83cf-2334-303a-1ae3-2bb8b1e9bd4c@oracle.com>
 <75959b26-9023-c662-bfda-87860a614a2c@oracle.com>
Message-ID: <ff8b4577-8999-9afe-4597-19bba3ff2568@oracle.com>

Hi Sergey,

this looks good to me*, but I can't help wonder if the modCount checking 
is something that should be done separately as a bug fix (with a higher 
priority) and be backported to 8 and 9? Alternatively re-categorize this 
fix as such.

Thanks!

/Claes

* I wouldn't mind seeing the cleanup Martin suggested, i.e., write the 
remapValue as:

     private V remapValue(Entry<K, V> t, K key, BiFunction<? super K, ? 
super V, ? extends V> remappingFunction) {
         V newValue = remappingFunction.apply(key, t.value);
         if (newValue == null) {
             deleteEntry(t);
         } else {
             // replace old mapping
             t.value = newValue;
         }
         return newValue;
      }

On 2017-03-28 21:22, Sergey Kuksenko wrote:
> Friendly reminder.
>
> Have you have chance to review the latest version?
>
>
> On 03/17/2017 12:45 PM, Sergey Kuksenko wrote:
>> Hi, All.
>>
>> I realized (thanks Tagir V.) that if we don't check modCount after 
>> calling mapping function we may get corrupted tree structure.
>> new webrev for review:
>> http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.01/
>>
>> On 03/17/2017 11:29 AM, Martin Buchholz wrote:
>>> Thanks!  This looks pretty good.  I have a similar effort in 
>>> progress to improve bulk collection operations, most of which made 
>>> it into jdk9.
>>>
>>> ---
>>>
>>> Please use standard java.util whitespace, as Aleksey suggested.
>>>
>>> ---
>>>
>>> Below (and in compute) I wpuld simply
>>> return newValue;
>>> saving a line of code and making it clearer that we are returning 
>>> the result of the remappingFunction
>>>
>>>  676     private V remapValue(Entry<K, V> t, K key, BiFunction<? 
>>> super K, ? super V, ? extends V> remappingFunction) {
>>>  677         V newValue = remappingFunction.apply(key, t.value);
>>>  678         if (newValue == null) {
>>>  679             deleteEntry(t);
>>>  680             return null;
>>>  681         } else {
>>>  682             // replace old mapping
>>>  683             t.value = newValue;
>>>  684             return newValue;
>>>  685         }
>>>  686     }
>>> ---
>>>
>>> This code is surely tested but testing could also surely be 
>>> improved.  That's probably not your job though (it may be mine!)
>>>
>>> I would probably try hand-injecting some bugs into a copy of the 
>>> code and seeing if our jtreg tests catch it, to increase coverage 
>>> confidence.
>>>
>>>
>>> On Thu, Mar 16, 2017 at 12:04 PM, Sergey Kuksenko 
>>> <sergey.kuksenko at oracle.com <mailto:sergey.kuksenko at oracle.com>> wrote:
>>>
>>>     Hi All,
>>>
>>>     Please, review:
>>>     https://bugs.openjdk.java.net/browse/JDK-8176894
>>>     <https://bugs.openjdk.java.net/browse/JDK-8176894>
>>> http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.00/
>>> <http://cr.openjdk.java.net/%7Eskuksenko/corelibs/utils/8176894/webrev.00/> 
>>>
>>>
>>>     The issue was created for JDK10 in order to don't disturb JDK9
>>>     before launch.
>>>
>>>     --     Best regards,
>>>     Sergey Kuksenko
>>>
>>>
>>
>


From daniel.fuchs at oracle.com  Thu Apr  6 11:00:39 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 6 Apr 2017 12:00:39 +0100
Subject: 9 RFR: 8178139: Minor typo in API documentation of
 java.util.logging.Logger
Message-ID: <188ce296-1735-ef1f-7e57-845ef9eb7fdc@oracle.com>

Hi,

Please find below a trivial change to fix
8178139: Minor typo in API documentation of java.util.logging.Logger
https://bugs.openjdk.java.net/browse/JDK-8178139

    will configured => will be configured
    (appears twice)

This is a minor typo doc fix so AFAIU RDP2 approval is not needed.

best regards,

-- daniel

diff --git 
a/src/java.logging/share/classes/java/util/logging/Logger.java 
b/src/java.logging/share/classes/java/util/logging/Logger.java
--- a/src/java.logging/share/classes/java/util/logging/Logger.java
+++ b/src/java.logging/share/classes/java/util/logging/Logger.java
@@ -664,7 +664,7 @@
       * a new logger is created.
       * <p>
       * If a new logger is created its log level will be configured
-     * based on the LogManager configuration and it will configured
+     * based on the LogManager configuration and it will be configured
       * to also send logging output to its parent's Handlers.  It will
       * be registered in the LogManager global namespace.
       * <p>
@@ -726,7 +726,7 @@
       *
       * <p>
       * If a new logger is created its log level will be configured
-     * based on the LogManager and it will configured to also send logging
+     * based on the LogManager and it will be configured to also send 
logging
       * output to its parent's Handlers.  It will be registered in
       * the LogManager global namespace.
       * <p>

From lance.andersen at oracle.com  Thu Apr  6 11:02:40 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 6 Apr 2017 07:02:40 -0400
Subject: 9 RFR: 8178139: Minor typo in API documentation of
 java.util.logging.Logger
In-Reply-To: <188ce296-1735-ef1f-7e57-845ef9eb7fdc@oracle.com>
References: <188ce296-1735-ef1f-7e57-845ef9eb7fdc@oracle.com>
Message-ID: <9D076F56-E45E-4C02-8D61-6CC0283058D3@oracle.com>

looks fine Daniel
> On Apr 6, 2017, at 7:00 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a trivial change to fix
> 8178139: Minor typo in API documentation of java.util.logging.Logger
> https://bugs.openjdk.java.net/browse/JDK-8178139
> 
>   will configured => will be configured
>   (appears twice)
> 
> This is a minor typo doc fix so AFAIU RDP2 approval is not needed.
> 
> best regards,
> 
> -- daniel
> 
> diff --git a/src/java.logging/share/classes/java/util/logging/Logger.java b/src/java.logging/share/classes/java/util/logging/Logger.java
> --- a/src/java.logging/share/classes/java/util/logging/Logger.java
> +++ b/src/java.logging/share/classes/java/util/logging/Logger.java
> @@ -664,7 +664,7 @@
>      * a new logger is created.
>      * <p>
>      * If a new logger is created its log level will be configured
> -     * based on the LogManager configuration and it will configured
> +     * based on the LogManager configuration and it will be configured
>      * to also send logging output to its parent's Handlers.  It will
>      * be registered in the LogManager global namespace.
>      * <p>
> @@ -726,7 +726,7 @@
>      *
>      * <p>
>      * If a new logger is created its log level will be configured
> -     * based on the LogManager and it will configured to also send logging
> +     * based on the LogManager and it will be configured to also send logging
>      * output to its parent's Handlers.  It will be registered in
>      * the LogManager global namespace.
>      * <p>

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From timo.kinnunen at gmail.com  Thu Apr  6 13:38:45 2017
From: timo.kinnunen at gmail.com (Timo Kinnunen)
Date: Thu, 6 Apr 2017 15:38:45 +0200
Subject: JDK 9 RFR(s): 8150488: add note to
 Scanner.findAll()regardingpossible infinite streams
In-Reply-To: <f3dd4c6e-6774-777c-cebd-539fe51b88a1@oracle.com>
References: <ca6ee328-1121-ed95-48ca-92cf5be02c0e@oracle.com>
 <58DC7E53.6040603@oracle.com> <58dd2aba.298fdf0a.86cca.3418@mx.google.com>
 <cc200e33-24dc-df27-1c56-dc11bf695c36@oracle.com>
 <fc36e657-a196-6f3e-bd42-fb1bdc741205@oracle.com>
 <58E427E8.2020901@oracle.com>
 <89d5129f-faff-20cb-eb86-6d3bb4151958@oracle.com>
 <f3dd4c6e-6774-777c-cebd-539fe51b88a1@oracle.com>
Message-ID: <58e644e8.6585df0a.cb334.d1ae@mx.google.com>

IMHO there should be a notice added in findAll which excludes the behavior of the stream after an empty match from any compatibility requirements while the notice remains in place. This would be to ensure that findAll and the stream it returns can be changed independently from the other methods which also have this issue. Just in case.



Sent from Mail for Windows 10

From: Stuart Marks
Sent: Wednesday, April 5, 2017 18:49
To: Xueming Shen
Cc: core-libs-dev at openjdk.java.net
Subject: Re: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()regardingpossible infinite streams



On 4/4/17 10:48 PM, Stuart Marks wrote:
>
>
> On 4/4/17 4:10 PM, Xueming Shen wrote:
>> Personally I think the use scenario and the expected resulting behavior of
>> Stream<MR>finaAll(ptn) should be more equivalent/similar to the use case  of
>> while (s.hasNext(p)) { s.next(p); }, or while (m.find()) { }, therefor it is
>> probably desired it can be used without worrying the possibility of getting
>> into an infinite loop.
>
> The Scanner.tokens() API, also added in Java 9, provides a stream of delimited
> tokens (strings) that's more-or-less equivalent of a hasNext()/next() loop.
>
> Just as findWithinHorizon() is a distinct use case from hasNext()/next()
> delimited tokens, findAll() provides for distinct uses from tokens().
>
>> That said, I agree it might be hard to argue to fix it in jdk9. The question
>> is if we are going to fix it in 9u sometime in the further, is it still worth
>> putting down the note in the API now. I'm fine if you believe a note will
>> help at least make the issue a known/documented usage limitation, for JDK9.

I've thought about this some more... fundamentally the behavior is odd, since 
Scanner.findWithinHorizon() is *based on* Matcher.find(). So why does 
Matcher.find() "work" and S.findWithinHorizon() produce an infinite loop?

If you look in findPatternInBuffer, upon which findWithinHorizon and findAll are 
based, it essentially resets the matcher every time, which cases the 
Matcher.find() special case to be bypassed. So I think this could be considered 
a bug in findPatternInBuffer, which causes misbehavior to be visible in 
findWithinHorizon and findAll.

I've filed:

JDK-8178116 scanner.findWithinHorizon doesn't advance after matching zero characters

This is certainly too subtle to be trying to fix right now.

I guess the question is, if we believe this is a bug that will be fixed at some 
point, do we add a note to findAll() -- and maybe even findWithinHorizon() -- to 
document this? Historically we haven't documented bugs like this, so maybe not.

Note also that this behavior of findWithinHorizon has been there since JDK 6, 
which is the earliest release I had conveniently at hand.

s'marks


>>
>> Yes, I think we did chat about this one at the hallway some time when either
>> you or something ran into the loop by using the method ...
>
> There are already a couple ways you can get unexpected behavior with Scanner if
> you're not careful. For example, see the warnings in findWithinHorizon() and
> skip() about the possibility of buffering up the entire input. These methods are
> useful, but if you're not careful with the regex you provide, things can go
> wrong. The findAll() method seems to be in the same situation. It's not clear to
> me that any of these are bugs for which there's a reasonable fix.
>
> So yes, I think the note is necessary. I could also add something about
> terminating such streams with limit() or takeWhile().
>
> s'marks
>
>>
>> Thanks,
>> Sherman
>>
>>
>>>
>>> s'marks
>>>
>>> On 3/30/17 2:19 PM, Stuart Marks wrote:
>>>> Hi Timo, Sherman,
>>>>
>>>> Thanks for looking at this.
>>>>
>>>> Sherman wrote:
>>>>
>>>>> This might practically put the api itself almost useless? it might be an easy
>>>>> task to spot
>>>>> whether or not it's a 0-width-match-possible regex when the regex is simple,
>>>>> but it gets
>>>>> harder and harder, if not impossible when the regex gets complicated,
>>>>> especially consider
>>>>> the possible use scenario that the use site is embedded deeply inside a
>>>>> library implementation.
>>>>
>>>> Well, not "useless", but perhaps less useful than one might like. :-)
>>>>
>>>> I think this is potentially surprising behavior, which is why I at least wanted
>>>> to add the note. It's not clear to me whether we should try to fix this by
>>>> changing Scanner though.
>>>>
>>>> Essentially, findAll() is defined in terms of findWithinHorizon(pattern, 0). So
>>>> if one were to write a loop like so:
>>>>
>>>>     String str;
>>>>     while ((str = scanner.findWithinHorizon(pattern, 0)) != null) {
>>>>         System.out.println(str);
>>>>     }
>>>>
>>>> then this loop would have the same problem if pattern were to match zero
>>>> characters.
>>>>
>>>>> The alternative is to "fix" it, maybe as what Matcher.find() does, if the
>>>>> previous match is
>>>>> zero-width-match (the fist==last), we step one to the next cursor before next
>>>>> try. I know
>>>>
>>>> Interesting, I didn't know Matcher.find() advances the cursor like this. But
>>>> Scanner.findWithinHorizon() apparently doesn't, so that's why an infinite loop
>>>> can occur.
>>>>
>>>>> Scanner.findPatternInBuffer() is setting new region set every time it is
>>>>> invoked which makes
>>>>> it complicated, but I would assume it might be still worth a trying? for
>>>>> example, utilize the
>>>>> "hasNextResult"/matcher.end(). I'm not sure without looking into the code,
>>>>> does
>>>>>
>>>>> while (hasNext(pattern)) {
>>>>>     next(pattern);
>>>>> }
>>>>>
>>>>> have the same issue, when pattern matches 0-width?
>>>>
>>>> No, this doesn't have the problem, because hasNext(pat) and next(pat) match
>>>> delimited tokens. Each call to next() implicitly advances past the next
>>>> delimiter to reach the subsequent token, if any.
>>>>
>>>>
>>>> On 3/30/17 8:56 AM, Timo Kinnunen wrote:
>>>>> I guess this somewhat contrived example also wouldn?t work?
>>>>>
>>>>>         String s = "\\b\\w+|\\G|\\B";
>>>>>         String t = "Matcher m = Pattern.compile(s).matcher(t);\n";
>>>>>         Matcher m = Pattern.compile(s).matcher(t);
>>>>>         while(m.find()) {
>>>>>             System.out.println("'" + m.group() + "'");
>>>>>         }
>>>>
>>>> Right, so if you rewrote this loop to use Scanner.findWithinHorizon()
>>>> instead of
>>>> Matcher,
>>>>
>>>>     Scanner sc = new Scanner(t);
>>>>     String str;
>>>>     while ((str = sc.findWithinHorizon(s, 0)) != null) {
>>>>         System.out.println("'" + str + "'");
>>>>     }
>>>>
>>>> you'd get an infinite loop with str being continually assigned the empty
>>>> string.
>>>> As Sherman mentioned, the Matcher.find() will advance the cursor if it gets a
>>>> zero-width match, avoiding this problem.
>>>>
>>>> * * *
>>>>
>>>> This didn't come up in the code review thread, which was mostly about
>>>> concurrent
>>>> modification and late-binding of the spliterator:
>>>>
>>>>
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035034.html
>>>>
>>>> I remember noting this phenomenon a while back, which is why I had filed the
>>>> bug
>>>> to add a note. I seem to remember discussing it, though, but it might have been
>>>> in a meeting or in a hallway conversation.
>>>>
>>>> This bug (JDK-8150488) does note that an infinite stream might be unexpected or
>>>> surprising, but it's not a fatal problem. It can be terminated with limit(). It
>>>> can also be terminated with takeWhile(), also added in JDK 9. Maybe I could
>>>> mention these in the API note.
>>>>
>>>> I guess we could also consider changing the implicit findWithinHorizon() loop
>>>> that findAll() does, perhaps by having it terminate on a zero-width match.
>>>> Or we
>>>> could even change findWithinHorizon's behavior if it gets a zero-width match,
>>>> siilar to what Matcher.find() does. But I'm quite reluctant to start making
>>>> such
>>>> changes at this point.
>>>>
>>>> s'marks
>>>>
>>>>
>>>>
>>>>>         // Outputs:
>>>>>         // 'Matcher'
>>>>>         // ''
>>>>>         // 'm'
>>>>>         // ''
>>>>>         // ''
>>>>>         // ''
>>>>>         // 'Pattern'
>>>>>         // ''
>>>>>         // 'compile'
>>>>>         // ''
>>>>>         // 's'
>>>>>         // ''
>>>>>         // ''
>>>>>         // 'matcher'
>>>>>         // ''
>>>>>         // 't'
>>>>>         // ''
>>>>>         // ''
>>>>>         // ''
>>>>>         // ''
>>>>>
>>>>>
>>>>>
>>>>> Sent from Mail for Windows 10
>>>>>
>>>>> From: Xueming Shen
>>>>> Sent: Thursday, March 30, 2017 05:41
>>>>> To: core-libs-dev at openjdk.java.net
>>>>> Subject: Re: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()
>>>>> regardingpossible infinite streams
>>>>>
>>>>> On 3/29/17, 5:56 PM, Stuart Marks wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Please review these non-normative textual additions to the
>>>>>> Scanner.findAll() method docs. These methods were added earlier in JDK
>>>>>> 9; there's a small pitfall if the regex can match zero characters.
>>>>>>
>>>>> Stuart,
>>>>>
>>>>> This might practically put the api itself almost useless? it might be an
>>>>> easy task to spot
>>>>> whether or not it's a 0-width-match-possible regex when the regex is
>>>>> simple, but it gets
>>>>> harder and harder, if not impossible when the regex gets complicated,
>>>>> especially consider
>>>>> the possible use scenario that the use site is embedded deeply inside a
>>>>> library implementation.
>>>>>
>>>>> The alternative is to "fix" it, maybe as what Matcher.find() does, if
>>>>> the previous match is
>>>>> zero-width-match (the fist==last), we step one to the next cursor before
>>>>> next try. I know
>>>>> Scanner.findPatternInBuffer() is setting new region set every time it is
>>>>> invoked which makes
>>>>> it complicated, but I would assume it might be still worth a trying? for
>>>>> example, utilize the
>>>>> "hasNextResult"/matcher.end(). I'm not sure without looking into the
>>>>> code, does
>>>>>
>>>>> while (hasNext(pattern)) {
>>>>>      next(pattern);
>>>>> }
>>>>>
>>>>> have the same issue, when pattern matches 0-width?
>>>>>
>>>>> Thanks!
>>>>> -Sherman
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> s'marks
>>>>>>
>>>>>>
>>>>>> # HG changeset patch
>>>>>> # User smarks
>>>>>> # Date 1490749958 25200
>>>>>> #      Tue Mar 28 18:12:38 2017 -0700
>>>>>> # Node ID 6b43c4698752779793d58813f46d3687c17dde75
>>>>>> # Parent  fb54b256d751ae3191e9cef42ff9f5630931f047
>>>>>> 8150488: add note to Scanner.findAll() regarding possible infinite
>>>>>> streams
>>>>>> Reviewed-by: XXX
>>>>>>
>>>>>> diff -r fb54b256d751 -r 6b43c4698752
>>>>>> src/java.base/share/classes/java/util/Scanner.java
>>>>>> --- a/src/java.base/share/classes/java/util/Scanner.java    Mon Mar 27
>>>>>> 15:12:01 2017 -0700
>>>>>> +++ b/src/java.base/share/classes/java/util/Scanner.java    Tue Mar 28
>>>>>> 18:12:38 2017 -0700
>>>>>> @@ -2808,6 +2808,10 @@
>>>>>>       * }
>>>>>>       * }</pre>
>>>>>>       *
>>>>>> +     * <p>The pattern must always match at least one character. If
>>>>>> the pattern
>>>>>> +     * can match zero characters, the result will be an infinite stream
>>>>>> +     * of empty matches.
>>>>>> +     *
>>>>>>       * @param pattern the pattern to be matched
>>>>>>       * @return a sequential stream of match results
>>>>>>       * @throws NullPointerException if pattern is null
>>>>>> @@ -2829,6 +2833,11 @@
>>>>>>       *     scanner.findAll(Pattern.compile(patString))
>>>>>>       * }</pre>
>>>>>>       *
>>>>>> +     * @apiNote
>>>>>> +     * The pattern must always match at least one character. If the
>>>>>> pattern
>>>>>> +     * can match zero characters, the result will be an infinite stream
>>>>>> +     * of empty matches.
>>>>>> +     *
>>>>>>       * @param patString the pattern string
>>>>>>       * @return a sequential stream of match results
>>>>>>       * @throws NullPointerException if patString is null
>>>>>
>>>>>
>>


From daniel.fuchs at oracle.com  Thu Apr  6 13:50:18 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 6 Apr 2017 14:50:18 +0100
Subject: 9 RFR: 8178139: Minor typo in API documentation of
 java.util.logging.Logger
In-Reply-To: <9D076F56-E45E-4C02-8D61-6CC0283058D3@oracle.com>
References: <188ce296-1735-ef1f-7e57-845ef9eb7fdc@oracle.com>
 <9D076F56-E45E-4C02-8D61-6CC0283058D3@oracle.com>
Message-ID: <9f4bb6a5-72f1-7dba-9940-015528d4f8fd@oracle.com>

On 06/04/2017 12:02, Lance Andersen wrote:
> looks fine Daniel

Thanks Lance. Pushed.

-- daniel

>> On Apr 6, 2017, at 7:00 AM, Daniel Fuchs <daniel.fuchs at oracle.com
>> <mailto:daniel.fuchs at oracle.com>> wrote:
>>
>> Hi,
>>
>> Please find below a trivial change to fix
>> 8178139: Minor typo in API documentation of java.util.logging.Logger
>> https://bugs.openjdk.java.net/browse/JDK-8178139
>>
>>   will configured => will be configured
>>   (appears twice)
>>
>> This is a minor typo doc fix so AFAIU RDP2 approval is not needed.
>>
>> best regards,
>>
>> -- daniel
>>
>> diff --git
>> a/src/java.logging/share/classes/java/util/logging/Logger.java
>> b/src/java.logging/share/classes/java/util/logging/Logger.java
>> --- a/src/java.logging/share/classes/java/util/logging/Logger.java
>> +++ b/src/java.logging/share/classes/java/util/logging/Logger.java
>> @@ -664,7 +664,7 @@
>>      * a new logger is created.
>>      * <p>
>>      * If a new logger is created its log level will be configured
>> -     * based on the LogManager configuration and it will configured
>> +     * based on the LogManager configuration and it will be configured
>>      * to also send logging output to its parent's Handlers.  It will
>>      * be registered in the LogManager global namespace.
>>      * <p>
>> @@ -726,7 +726,7 @@
>>      *
>>      * <p>
>>      * If a new logger is created its log level will be configured
>> -     * based on the LogManager and it will configured to also send
>> logging
>> +     * based on the LogManager and it will be configured to also send
>> logging
>>      * output to its parent's Handlers.  It will be registered in
>>      * the LogManager global namespace.
>>      * <p>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>


From chris.w.dennis at gmail.com  Thu Apr  6 14:08:48 2017
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Thu, 6 Apr 2017 10:08:48 -0400
Subject: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
Message-ID: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>

Hi Paul (et al)

Like all things API there are wrinkles here when it comes to implementing.

This patch isn?t final, there appears to be no existing test coverage for these classes beyond testing the compensating summation used in the double implementation, and I left off adding any until it was decided how much parameter validation we want (since that?s the only testing that can really occur here).

The wrinkles relate to the issues around instances that have suffered overflow in count and/or sum which the existing implementation doesn?t defend against:

 * I chose to ignore all parameters if 'count == 0? and just leave the instance empty. I held off from validating min, max and count however. This obviously 'breaks things? (beyond how broken they would already be) if count == 0 only due to overflow.
 * I chose to fail if count is negative.
 * I chose to enforce that max and min are logically consistent with count and sum, this can break the moment either one of the overflows as well (I?m also pretty sure that the FPU logic is going to suffer here too - there might be some magic I can do with a pessimistic bit of rounding on the FPU multiplication result).

I intentionally went with the most aggressive parameter validation here to establish one end of what could be implemented.  There are arguments for this and also arguments for the other extreme (no validation at all).  Personally I?m in favor of the current version where the creation will fail if the inputs are only possible through overflow (modulo fixing the FPU precision issues above) even though it?s at odds with approach of the existing implementation.

Would appreciate thoughts/feedback.  Thanks.

Chris


P.S. I presume tests would be required for the parameter checking (once it is finalized)?


From jbluettduncan at gmail.com  Thu Apr  6 14:32:48 2017
From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan)
Date: Thu, 6 Apr 2017 15:32:48 +0100
Subject: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
Message-ID: <CAPMys84UbqJw3x2NXeMD9VZvgbgUcqg++ji3Yzza+3omCxffig@mail.gmail.com>

Hi Chris,

Unfortunately the patch you sent (in what I presume was an attachment) is
missing. I believe the OpenJDK mailing list servers intentionally strip out
attachments in all emails, which seems to be at odds with the advice given
in http://openjdk.java.net/contribute/. (Either the contribution advice or
the servers should be changed, ideally!)

I understand that one can host patches somewhere official, but I've
forgotten the details of the process.

Can anyone help?

Jonathan


On 6 April 2017 at 15:08, Chris Dennis <chris.w.dennis at gmail.com> wrote:

> Hi Paul (et al)
>
> Like all things API there are wrinkles here when it comes to implementing.
>
> This patch isn?t final, there appears to be no existing test coverage for
> these classes beyond testing the compensating summation used in the double
> implementation, and I left off adding any until it was decided how much
> parameter validation we want (since that?s the only testing that can really
> occur here).
>
> The wrinkles relate to the issues around instances that have suffered
> overflow in count and/or sum which the existing implementation doesn?t
> defend against:
>
>  * I chose to ignore all parameters if 'count == 0? and just leave the
> instance empty. I held off from validating min, max and count however. This
> obviously 'breaks things? (beyond how broken they would already be) if
> count == 0 only due to overflow.
>  * I chose to fail if count is negative.
>  * I chose to enforce that max and min are logically consistent with count
> and sum, this can break the moment either one of the overflows as well (I?m
> also pretty sure that the FPU logic is going to suffer here too - there
> might be some magic I can do with a pessimistic bit of rounding on the FPU
> multiplication result).
>
> I intentionally went with the most aggressive parameter validation here to
> establish one end of what could be implemented.  There are arguments for
> this and also arguments for the other extreme (no validation at all).
> Personally I?m in favor of the current version where the creation will fail
> if the inputs are only possible through overflow (modulo fixing the FPU
> precision issues above) even though it?s at odds with approach of the
> existing implementation.
>
> Would appreciate thoughts/feedback.  Thanks.
>
> Chris
>
>
> P.S. I presume tests would be required for the parameter checking (once it
> is finalized)?
>
>

From chris.w.dennis at gmail.com  Thu Apr  6 14:42:42 2017
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Thu, 6 Apr 2017 10:42:42 -0400
Subject: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <CAPMys84UbqJw3x2NXeMD9VZvgbgUcqg++ji3Yzza+3omCxffig@mail.gmail.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <CAPMys84UbqJw3x2NXeMD9VZvgbgUcqg++ji3Yzza+3omCxffig@mail.gmail.com>
Message-ID: <B75E341A-5CCC-4004-8DB3-6C522F2075AC@gmail.com>

# HG changeset patch
# User chris_dennis
# Date 1491485015 14400
#      Thu Apr 06 09:23:35 2017 -0400
# Node ID d789970b8393032457885e739d76919f714bbd50
# Parent  c0aecf84349c97f4241eab01f7bbfb7660d51be1
8178117: Add public state constructors for Int/Long/DoubleSummaryStatistics

diff --git a/src/java.base/share/classes/java/util/DoubleSummaryStatistics.java b/src/java.base/share/classes/java/util/DoubleSummaryStatistics.java
--- a/src/java.base/share/classes/java/util/DoubleSummaryStatistics.java
+++ b/src/java.base/share/classes/java/util/DoubleSummaryStatistics.java
@@ -76,6 +76,47 @@
     public DoubleSummaryStatistics() { }
 
     /**
+     * Construct a non-empty instance with the supplied min, max, count, and sum.
+     *
+     * <p>If {@code count} is zero then the remaining parameters are ignored
+     * and an empty instance is constructed.
+     * <p>If the arguments are inconsistent then an {@code IllegalArgumentException}
+     * is thrown.  The necessary consistent argument conditions are:
+     * <ul>
+     *   <li>{@code count} &ge 0</li>
+     *   <li>{@code min} &le {@code max}</li>
+     *   <li>({@code count} &times {@code max}) &ge {@code sum}</li>
+     *   <li>({@code count} &times {@code min}) &le {@code sum}</li>
+     * </ul>
+     * This enforcement of argument consistency means that the retrieved set of
+     * values from a {@code DoubleSummaryStatistics} instance may not be a legal
+     * set of arguments for this constructor due to arithmetic overflow in the
+     * original instance.
+     *
+     * @param min the minimum value
+     * @param max the maximum value
+     * @param count the count of values
+     * @param sum the sum of all values
+     * @throws IllegalArgumentException if the arguments are inconsistent
+     */
+    public DoubleSummaryStatistics(double min, double max, long count, double sum) throws IllegalArgumentException {
+        if (count < 0L) {
+            throw new IllegalArgumentException("Negative count value");
+        } else if (count > 0L) {
+            if (min > max) throw new IllegalArgumentException("Minimum greater than maximum");
+            if (count * max < sum) throw new IllegalArgumentException("Maximum inconsistent with sum and count");
+            if (count * min > sum) throw new IllegalArgumentException("Minimum inconsistent with sum and count");
+
+            this.count = count;
+            this.sum = sum;
+            this.simpleSum = sum;
+            this.sumCompensation = 0.0d;
+            this.min = min;
+            this.max = max;
+        }
+    }
+
+    /**
      * Records another value into the summary information.
      *
      * @param value the input value
diff --git a/src/java.base/share/classes/java/util/IntSummaryStatistics.java b/src/java.base/share/classes/java/util/IntSummaryStatistics.java
--- a/src/java.base/share/classes/java/util/IntSummaryStatistics.java
+++ b/src/java.base/share/classes/java/util/IntSummaryStatistics.java
@@ -27,6 +27,9 @@
 import java.util.function.IntConsumer;
 import java.util.stream.Collector;
 
+import static java.lang.Math.multiplyExact;
+import static java.lang.Math.multiplyFull;
+
 /**
  * A state object for collecting statistics such as count, min, max, sum, and
  * average.
@@ -76,6 +79,49 @@
     public IntSummaryStatistics() { }
 
     /**
+     * Construct a non-empty instance with the supplied min, max, count, and sum.
+     *
+     * <p>If {@code count} is zero then the remaining parameters are ignored
+     * and an empty instance is constructed.
+     * <p>If the arguments are inconsistent then an {@code IllegalArgumentException}
+     * is thrown.  The necessary consistent argument conditions are:
+     * <ul>
+     *   <li>{@code count} &ge 0</li>
+     *   <li>{@code min} &le {@code max}</li>
+     *   <li>({@code count} &times {@code max}) &ge {@code sum}</li>
+     *   <li>({@code count} &times {@code min}) &le {@code sum}</li>
+     * </ul>
+     * This enforcement of argument consistency means that the retrieved set of
+     * values from an {@code IntSummaryStatistics} instance may not be a legal
+     * set of arguments for this constructor due to arithmetic overflow in the
+     * original instance.
+     *
+     * @param min the minimum value
+     * @param max the maximum value
+     * @param count the count of values
+     * @param sum the sum of all values
+     * @throws IllegalArgumentException if the arguments are inconsistent
+     */
+    public IntSummaryStatistics(int min, int max, long count, long sum) throws IllegalArgumentException {
+        if (count < 0L) {
+            throw new IllegalArgumentException("Negative count value");
+        } else if (count > 0L) {
+            if (min > max) throw new IllegalArgumentException("Minimum greater than maximum");
+            try {
+                if (multiplyExact(count, max) < sum) throw new IllegalArgumentException("Maximum inconsistent with sum and count");
+            } catch (ArithmeticException e) {}
+            try {
+                if (multiplyExact(count, min) > sum) throw new IllegalArgumentException("Minimum inconsistent with sum and count");
+            } catch (ArithmeticException e) {}
+
+            this.count = count;
+            this.sum = sum;
+            this.min = min;
+            this.max = max;
+        }
+    }
+
+    /**
      * Records a new value into the summary information
      *
      * @param value the input value
diff --git a/src/java.base/share/classes/java/util/LongSummaryStatistics.java b/src/java.base/share/classes/java/util/LongSummaryStatistics.java
--- a/src/java.base/share/classes/java/util/LongSummaryStatistics.java
+++ b/src/java.base/share/classes/java/util/LongSummaryStatistics.java
@@ -28,6 +28,8 @@
 import java.util.function.LongConsumer;
 import java.util.stream.Collector;
 
+import static java.lang.Math.multiplyExact;
+
 /**
  * A state object for collecting statistics such as count, min, max, sum, and
  * average.
@@ -77,6 +79,49 @@
     public LongSummaryStatistics() { }
 
     /**
+     * Construct a non-empty instance with the supplied min, max, count, and sum.
+     *
+     * <p>If {@code count} is zero then the remaining parameters are ignored
+     * and an empty instance is constructed.
+     * <p>If the arguments are inconsistent then an {@code IllegalArgumentException}
+     * is thrown.  The necessary consistent argument conditions are:
+     * <ul>
+     *   <li>{@code count} &ge 0</li>
+     *   <li>{@code min} &le {@code max}</li>
+     *   <li>({@code count} &times {@code max}) &ge {@code sum}</li>
+     *   <li>({@code count} &times {@code min}) &le {@code sum}</li>
+     * </ul>
+     * This enforcement of argument consistency means that the retrieved set of
+     * values from a {@code LongSummaryStatistics} instance may not be a legal
+     * set of arguments for this constructor due to arithmetic overflow in the
+     * original instance.
+     *
+     * @param min the minimum value
+     * @param max the maximum value
+     * @param count the count of values
+     * @param sum the sum of all values
+     * @throws IllegalArgumentException if the arguments are inconsistent
+     */
+    public LongSummaryStatistics(long min, long max, long count, long sum) throws IllegalArgumentException {
+        if (count < 0L) {
+            throw new IllegalArgumentException("Negative count value");
+        } else if (count > 0L) {
+            if (min > max) throw new IllegalArgumentException("Minimum greater than maximum");
+            try {
+                if (multiplyExact(count, max) < sum) throw new IllegalArgumentException("Maximum inconsistent with sum and count");
+            } catch (ArithmeticException e) {}
+            try {
+                if (multiplyExact(count, min) > sum) throw new IllegalArgumentException("Minimum inconsistent with sum and count");
+            } catch (ArithmeticException e) {}
+
+            this.count = count;
+            this.sum = sum;
+            this.min = min;
+            this.max = max;
+        }
+    }
+
+    /**
      * Records a new {@code int} value into the summary information.
      *
      * @param value the input value


> On Apr 6, 2017, at 10:32 AM, Jonathan Bluett-Duncan <jbluettduncan at gmail.com> wrote:
> 
> Hi Chris,
> 
> Unfortunately the patch you sent (in what I presume was an attachment) is missing. I believe the OpenJDK mailing list servers intentionally strip out attachments in all emails, which seems to be at odds with the advice given in http://openjdk.java.net/contribute/. (Either the contribution advice or the servers should be changed, ideally!)
> 
> I understand that one can host patches somewhere official, but I've forgotten the details of the process.
> 
> Can anyone help?
> 
> Jonathan
> 
> 
> On 6 April 2017 at 15:08, Chris Dennis <chris.w.dennis at gmail.com> wrote:
> Hi Paul (et al)
> 
> Like all things API there are wrinkles here when it comes to implementing.
> 
> This patch isn?t final, there appears to be no existing test coverage for these classes beyond testing the compensating summation used in the double implementation, and I left off adding any until it was decided how much parameter validation we want (since that?s the only testing that can really occur here).
> 
> The wrinkles relate to the issues around instances that have suffered overflow in count and/or sum which the existing implementation doesn?t defend against:
> 
>  * I chose to ignore all parameters if 'count == 0? and just leave the instance empty. I held off from validating min, max and count however. This obviously 'breaks things? (beyond how broken they would already be) if count == 0 only due to overflow.
>  * I chose to fail if count is negative.
>  * I chose to enforce that max and min are logically consistent with count and sum, this can break the moment either one of the overflows as well (I?m also pretty sure that the FPU logic is going to suffer here too - there might be some magic I can do with a pessimistic bit of rounding on the FPU multiplication result).
> 
> I intentionally went with the most aggressive parameter validation here to establish one end of what could be implemented.  There are arguments for this and also arguments for the other extreme (no validation at all).  Personally I?m in favor of the current version where the creation will fail if the inputs are only possible through overflow (modulo fixing the FPU precision issues above) even though it?s at odds with approach of the existing implementation.
> 
> Would appreciate thoughts/feedback.  Thanks.
> 
> Chris
> 
> 
> P.S. I presume tests would be required for the parameter checking (once it is finalized)?
> 
> 


From Roger.Riggs at Oracle.com  Thu Apr  6 14:44:51 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 6 Apr 2017 10:44:51 -0400
Subject: RFR 9: 8165641 : Deprecate Object.finalize
In-Reply-To: <CB9A7D8E-87FE-4B5D-BEFF-27696B302D15@oracle.com>
References: <c7893765-1c5b-18e3-c5f3-a9ccf9b05094@Oracle.com>
 <96fe9ae0-993a-aea6-cabf-f079450dc128@Oracle.com>
 <49eb0b85-130a-b74d-e760-120674de6ebc@oracle.com>
 <CAMOCf+iAT-29E0wu8WFcNiZq1di1xCq=-kSwjdfhkq2cEA1iJA@mail.gmail.com>
 <31a37a8c-e3fd-96cf-00a4-090d65c21cff@Oracle.com>
 <78e0fb3c-0850-4aa9-9f73-e319e8a8e7b9@Oracle.com>
 <CB9A7D8E-87FE-4B5D-BEFF-27696B302D15@oracle.com>
Message-ID: <58fb68d2-db1c-72ea-4b3a-f2fa580eb410@Oracle.com>

Thanks Mandy,  I'll put you down as a reviewer for the fix. (8165641 was 
pushed)


diff --git a/src/java.base/share/classes/java/lang/Object.java 
b/src/java.base/share/classes/java/lang/Object.java
--- a/src/java.base/share/classes/java/lang/Object.java
+++ b/src/java.base/share/classes/java/lang/Object.java
@@ -593,7 +593,7 @@ public class Object {
       * finalization if it is no longer necessary; and no ordering is 
specified
       * among calls to {@code finalize} methods of different objects.
       * Furthermore, there are no guarantees regarding the timing of 
finalization.
-     * The {@code finalize} method might be called on an finalizable object
+     * The {@code finalize} method might be called on a finalizable object
       * only after an indefinite delay, if at all.
       *
       * Classes whose instances hold non-heap resources should provide 
a method



[1] https://bugs.openjdk.java.net/browse/JDK-8178154



On 4/5/2017 6:15 PM, Mandy Chung wrote:
>> On Apr 3, 2017, at 7:44 AM, Roger Riggs <roger.riggs at oracle.com> wrote:
>>
>> [1] http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641
>
> Typo: s/an finalizable/a finalizable/
>
> +     * The {@code finalize} method might be called on an finalizable object
>
> Otherwise, looks good.  No need for a new webrev.
>
> Mandy


From mandy.chung at oracle.com  Thu Apr  6 14:45:49 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 6 Apr 2017 07:45:49 -0700
Subject: RFR 9: 8165641 : Deprecate Object.finalize
In-Reply-To: <58fb68d2-db1c-72ea-4b3a-f2fa580eb410@Oracle.com>
References: <c7893765-1c5b-18e3-c5f3-a9ccf9b05094@Oracle.com>
 <96fe9ae0-993a-aea6-cabf-f079450dc128@Oracle.com>
 <49eb0b85-130a-b74d-e760-120674de6ebc@oracle.com>
 <CAMOCf+iAT-29E0wu8WFcNiZq1di1xCq=-kSwjdfhkq2cEA1iJA@mail.gmail.com>
 <31a37a8c-e3fd-96cf-00a4-090d65c21cff@Oracle.com>
 <78e0fb3c-0850-4aa9-9f73-e319e8a8e7b9@Oracle.com>
 <CB9A7D8E-87FE-4B5D-BEFF-27696B302D15@oracle.com>
 <58fb68d2-db1c-72ea-4b3a-f2fa580eb410@Oracle.com>
Message-ID: <D6D3282E-434F-492D-8785-EE662BA9E7B9@oracle.com>

+1

Mandy

> On Apr 6, 2017, at 7:44 AM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:
> 
> Thanks Mandy,  I'll put you down as a reviewer for the fix.  (8165641 was pushed)
> 
> 
> diff --git a/src/java.base/share/classes/java/lang/Object.java b/src/java.base/share/classes/java/lang/Object.java
> --- a/src/java.base/share/classes/java/lang/Object.java
> +++ b/src/java.base/share/classes/java/lang/Object.java
> @@ -593,7 +593,7 @@ public class Object {
>       * finalization if it is no longer necessary; and no ordering is specified
>       * among calls to {@code finalize} methods of different objects.
>       * Furthermore, there are no guarantees regarding the timing of finalization.
> -     * The {@code finalize} method might be called on an finalizable object
> +     * The {@code finalize} method might be called on a finalizable object
>       * only after an indefinite delay, if at all.
>       *
>       * Classes whose instances hold non-heap resources should provide a method
> 
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8178154 <https://bugs.openjdk.java.net/browse/JDK-8178154>
> 
> 
> 
> On 4/5/2017 6:15 PM, Mandy Chung wrote:
>>> On Apr 3, 2017, at 7:44 AM, Roger Riggs <roger.riggs at oracle.com> <mailto:roger.riggs at oracle.com> wrote:
>>> 
>>> [1] http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641 <http://cr.openjdk.java.net/~rriggs/webrev-finalize-deprecate-8165641>
>> 
>> Typo: s/an finalizable/a finalizable/
>> 
>> +     * The {@code finalize} method might be called on an finalizable object
>> 
>> Otherwise, looks good.  No need for a new webrev.
>> 
>> Mandy
> 


From Roger.Riggs at Oracle.com  Thu Apr  6 15:39:35 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 6 Apr 2017 11:39:35 -0400
Subject: [8u] RFR: 8177776: Create an equivalent test case for JDK9's
 SupplementalJapaneseEraTest
In-Reply-To: <d424dc05-691c-c9a2-8b45-4d73c2a70375@oracle.com>
References: <69774039-1980-882f-2f89-fac194fd7fa7@oracle.com>
 <d424dc05-691c-c9a2-8b45-4d73c2a70375@oracle.com>
Message-ID: <4306e4b1-c288-1c76-ff25-0b23f9a67137@Oracle.com>

Hi Naoto,

Thanks for replacing the shell script with Java code.

Given the size of the JDK, I'd suggest removing the copy at the end of 
the test
unless you can rely on jtreg to remove it promptly.

The rest looks fine,  Roger


On 4/5/2017 5:14 PM, Naoto Sato wrote:
> I revised the test case not to rely on shell script. Please review.
>
> http://cr.openjdk.java.net/~naoto/8177776/webrev.01/
>
> Naoto
>
> On 3/30/17 2:10 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8177776
>>
>> The proposed change is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8177776/webrev.00/
>>
>> This is for backporting fixes for JapaneseEra related issues (8054214,
>> 8173423). The original fixes in JDK9 included a test case,
>> SupplementalJapaneseEraTest which is intended for the system property
>> testing. The above proposed fix intends to adapt that test case into
>> JDK8, where calendars.properties file is used instead of the system
>> property. The test is pretty much identical to JDK9's. The difference is
>> to deal with the calendars.properties file and removed some
>> non-applicable cases in JDK8.
>>
>> Naoto


From naoto.sato at oracle.com  Thu Apr  6 15:46:29 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 6 Apr 2017 08:46:29 -0700
Subject: [8u] RFR: 8177776: Create an equivalent test case for JDK9's
 SupplementalJapaneseEraTest
In-Reply-To: <4306e4b1-c288-1c76-ff25-0b23f9a67137@Oracle.com>
References: <69774039-1980-882f-2f89-fac194fd7fa7@oracle.com>
 <d424dc05-691c-c9a2-8b45-4d73c2a70375@oracle.com>
 <4306e4b1-c288-1c76-ff25-0b23f9a67137@Oracle.com>
Message-ID: <e4bc3352-0dfc-b047-76ed-dcf247fb40bd@oracle.com>

Thanks for reviewing, Roger.

On 4/6/17 8:39 AM, Roger Riggs wrote:
> Hi Naoto,
>
> Thanks for replacing the shell script with Java code.
>
> Given the size of the JDK, I'd suggest removing the copy at the end of
> the test
> unless you can rely on jtreg to remove it promptly.

I was thinking about using @AfterTest to do it, but then realized that 
jtreg automatically cleans up the "scratch" directory after the test, 
where the test JDK is copied into. Here is the quote from jtreg's page [1]:

---
jtreg will automatically clean up any files written in the scratch 
directory. In general, you should not clean these files up within the 
test because they may provide infomation useful to diagnose a test 
failure, should that be necessary.
---

Naoto

[1] http://openjdk.java.net/jtreg/writetests.html

>
> The rest looks fine,  Roger
>
>
> On 4/5/2017 5:14 PM, Naoto Sato wrote:
>> I revised the test case not to rely on shell script. Please review.
>>
>> http://cr.openjdk.java.net/~naoto/8177776/webrev.01/
>>
>> Naoto
>>
>> On 3/30/17 2:10 PM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the changes to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8177776
>>>
>>> The proposed change is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8177776/webrev.00/
>>>
>>> This is for backporting fixes for JapaneseEra related issues (8054214,
>>> 8173423). The original fixes in JDK9 included a test case,
>>> SupplementalJapaneseEraTest which is intended for the system property
>>> testing. The above proposed fix intends to adapt that test case into
>>> JDK8, where calendars.properties file is used instead of the system
>>> property. The test is pretty much identical to JDK9's. The difference is
>>> to deal with the calendars.properties file and removed some
>>> non-applicable cases in JDK8.
>>>
>>> Naoto
>

From brent.christian at oracle.com  Thu Apr  6 20:08:23 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 6 Apr 2017 13:08:23 -0700
Subject: [8u] RFR: 8177776: Create an equivalent test case for JDK9's
 SupplementalJapaneseEraTest
In-Reply-To: <d424dc05-691c-c9a2-8b45-4d73c2a70375@oracle.com>
References: <69774039-1980-882f-2f89-fac194fd7fa7@oracle.com>
 <d424dc05-691c-c9a2-8b45-4d73c2a70375@oracle.com>
Message-ID: <5a64d6fc-9cf2-6a04-9f92-fd7d75c957bd@oracle.com>

Hi, Naoto

On 4/5/17 2:14 PM, Naoto Sato wrote:
> I revised the test case not to rely on shell script.

Yay!  Hopefully this can also happen sometime for JDK 9+.

> http://cr.openjdk.java.net/~naoto/8177776/webrev.01/

Looks fine to me, Naoto.  A few comments:

* I presume additional @bug values will be added as other fixes are 
backported (e.g. 8054214).

* On

   73         Path dst = Paths.get("testjava").toAbsolutePath();

This places "dst" within the scratch directory, then?  (I thought there 
was a jtreg system property for the scratch directory, but I can't find 
it so I think I'm mis-remembering).

I agree with letting jtreg take care of cleaning up "scratch".

If anything goes wrong with copying of the JDK (e.g. full disk), 
hopefully it would be easy to diagnose, with an IOException with a full 
stack trace.

* Have you confirmed (if it's practical to do so) that this test fails 
when expected (detects a bug)?

Thanks,
-Brent

> On 3/30/17 2:10 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8177776
>>
>> The proposed change is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8177776/webrev.00/
>>
>> This is for backporting fixes for JapaneseEra related issues (8054214,
>> 8173423). The original fixes in JDK9 included a test case,
>> SupplementalJapaneseEraTest which is intended for the system property
>> testing. The above proposed fix intends to adapt that test case into
>> JDK8, where calendars.properties file is used instead of the system
>> property. The test is pretty much identical to JDK9's. The difference is
>> to deal with the calendars.properties file and removed some
>> non-applicable cases in JDK8.
>>
>> Naoto

From naoto.sato at oracle.com  Thu Apr  6 20:29:01 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 6 Apr 2017 13:29:01 -0700
Subject: [8u] RFR: 8177776: Create an equivalent test case for JDK9's
 SupplementalJapaneseEraTest
In-Reply-To: <5a64d6fc-9cf2-6a04-9f92-fd7d75c957bd@oracle.com>
References: <69774039-1980-882f-2f89-fac194fd7fa7@oracle.com>
 <d424dc05-691c-c9a2-8b45-4d73c2a70375@oracle.com>
 <5a64d6fc-9cf2-6a04-9f92-fd7d75c957bd@oracle.com>
Message-ID: <e90172b1-213b-a463-d24b-2b6f573bba98@oracle.com>

Hi Brent, thank you for the review.

On 4/6/17 1:08 PM, Brent Christian wrote:
> Hi, Naoto
>
> On 4/5/17 2:14 PM, Naoto Sato wrote:
>> I revised the test case not to rely on shell script.
>
> Yay!  Hopefully this can also happen sometime for JDK 9+.

Sure. Will work on it.

>
>> http://cr.openjdk.java.net/~naoto/8177776/webrev.01/
>
> Looks fine to me, Naoto.  A few comments:
>
> * I presume additional @bug values will be added as other fixes are
> backported (e.g. 8054214).

Good point. Will add those bug ids on push.

>
> * On
>
>   73         Path dst = Paths.get("testjava").toAbsolutePath();
>
> This places "dst" within the scratch directory, then?  (I thought there
> was a jtreg system property for the scratch directory, but I can't find
> it so I think I'm mis-remembering).
>
> I agree with letting jtreg take care of cleaning up "scratch".

Yes, "dst" will be "scratch". Not aware of any system property to 
designate the output directory, other than "-w" command option to 
specify the JTwork dir.

>
> If anything goes wrong with copying of the JDK (e.g. full disk),
> hopefully it would be easy to diagnose, with an IOException with a full
> stack trace.
>
> * Have you confirmed (if it's practical to do so) that this test fails
> when expected (detects a bug)?

Yes. Without those backports, the test will fail as expected.

Naoto

>
> Thanks,
> -Brent
>
>> On 3/30/17 2:10 PM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the changes to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8177776
>>>
>>> The proposed change is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8177776/webrev.00/
>>>
>>> This is for backporting fixes for JapaneseEra related issues (8054214,
>>> 8173423). The original fixes in JDK9 included a test case,
>>> SupplementalJapaneseEraTest which is intended for the system property
>>> testing. The above proposed fix intends to adapt that test case into
>>> JDK8, where calendars.properties file is used instead of the system
>>> property. The test is pretty much identical to JDK9's. The difference is
>>> to deal with the calendars.properties file and removed some
>>> non-applicable cases in JDK8.
>>>
>>> Naoto

From stuart.marks at oracle.com  Fri Apr  7 02:09:38 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 6 Apr 2017 19:09:38 -0700
Subject: JDK 9 RFR(s): 8173152: Wrong wording in Comparator.compare() method
 spec
Message-ID: <3c3d08ca-925e-f869-90a8-68286be75a2e@oracle.com>

Hi all,

Please review this small javadoc fix to correct the wording in 
Comparator.compare(). There's a sentence defining the sgn() notation, that says 
"In the foregoing description" but it occurs *before* the actual use of sgn(). 
I've moved this to the end of the method spec.

This also makes the Comparator.compare() method spec very similar to the 
Comparable.compareTo() method spec.

Thanks,

s'marks


# HG changeset patch
# User smarks
# Date 1491530800 25200
#      Thu Apr 06 19:06:40 2017 -0700
# Node ID 1f08b6bc20078e07f7264e449a334234906d46e5
# Parent  7c72114a555820da956c81364ae7ba30698aa799
8173152: Wrong wording in Comparator.compare() method spec
Reviewed-by: XXX

diff -r 7c72114a5558 -r 1f08b6bc2007 
src/java.base/share/classes/java/util/Comparator.java
--- a/src/java.base/share/classes/java/util/Comparator.java	Fri Mar 31 14:21:21 
2017 -0700
+++ b/src/java.base/share/classes/java/util/Comparator.java	Thu Apr 06 19:06:40 
2017 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -112,12 +112,6 @@
       * zero, or a positive integer as the first argument is less than, equal
       * to, or greater than the second.<p>
       *
-     * In the foregoing description, the notation
-     * {@code sgn(}<i>expression</i>{@code )} designates the mathematical
-     * <i>signum</i> function, which is defined to return one of {@code -1},
-     * {@code 0}, or {@code 1} according to whether the value of
-     * <i>expression</i> is negative, zero or positive.<p>
-     *
       * The implementor must ensure that {@code sgn(compare(x, y)) ==
       * -sgn(compare(y, x))} for all {@code x} and {@code y}.  (This
       * implies that {@code compare(x, y)} must throw an exception if and only
@@ -135,7 +129,13 @@
       * {@code (compare(x, y)==0) == (x.equals(y))}.  Generally speaking,
       * any comparator that violates this condition should clearly indicate
       * this fact.  The recommended language is "Note: this comparator
-     * imposes orderings that are inconsistent with equals."
+     * imposes orderings that are inconsistent with equals."<p>
+     *
+     * In the foregoing description, the notation
+     * {@code sgn(}<i>expression</i>{@code )} designates the mathematical
+     * <i>signum</i> function, which is defined to return one of {@code -1},
+     * {@code 0}, or {@code 1} according to whether the value of
+     * <i>expression</i> is negative, zero or positive.
       *
       * @param o1 the first object to be compared.
       * @param o2 the second object to be compared.

From mark.reinhold at oracle.com  Fri Apr  7 14:29:41 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 07 Apr 2017 07:29:41 -0700
Subject: ProcessHandle::getPid
Message-ID: <20170407072941.873070683@eggemoggin.niobe.net>

Playing around with the `ProcessHandle` API the other day, I noticed
that it uses non-Beans accessor names (good!) -- except for `getPid()`.

Is there a reason why that method isn't just `pid()`?

- Mark

From Roger.Riggs at Oracle.com  Fri Apr  7 14:45:38 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 7 Apr 2017 10:45:38 -0400
Subject: ProcessHandle::getPid
In-Reply-To: <20170407072941.873070683@eggemoggin.niobe.net>
References: <20170407072941.873070683@eggemoggin.niobe.net>
Message-ID: <0317d211-2b5c-173d-8b14-6402a432f275@Oracle.com>

Hi Mark,

That's an unfortunate artifact of evolution.
Process.getPid() was added early in 2014 and ProcessHandle a year later.

Several iterations of ProcessHandle API explored Process being a 
subclass of ProcessHandle
so the method names would be the same.  When ProcessHandle was decoupled 
from Process
the method name was retained for consistency.

Roger


On 4/7/2017 10:29 AM, mark.reinhold at oracle.com wrote:
> Playing around with the `ProcessHandle` API the other day, I noticed
> that it uses non-Beans accessor names (good!) -- except for `getPid()`.
>
> Is there a reason why that method isn't just `pid()`?
>
> - Mark


From weijun.wang at oracle.com  Fri Apr  7 14:50:01 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 7 Apr 2017 22:50:01 +0800
Subject: [9] RFR 8177969: Faster FilePermission::implies by avoiding the
 use of Path::relativize
In-Reply-To: <9f96ed4d-9282-d776-f767-d3fe060ba895@Oracle.com>
References: <4f1e0c02-a11d-2694-84ad-cf8804021f3c@oracle.com>
 <9f96ed4d-9282-d776-f767-d3fe060ba895@Oracle.com>
Message-ID: <de22e3da-cca4-5730-607f-5a75f69b9f06@oracle.com>

Webrev updated at

    http://cr.openjdk.java.net/~weijun/8177969/webrev.01/

Changes since webrev.00 [1]

1. Copyright years.

2. Test fix. check() should include Windows drive tests like contains() 
does.

Thanks
Max

[1] 
http://cr.openjdk.java.net/~weijun/8177969/webrev.01/interdiff.patch.html

On 04/05/2017 10:13 PM, Roger Riggs wrote:
> Hi Max,
>
> The code looks ok.
>
> How much faster does it make FilePermission compares?
>
> I assume if it is not accepted to be fixed in JDK 9, you will push it to
> JDK 10.
>
> Roger
>
>
> On 4/3/2017 11:30 AM, Weijun Wang wrote:
>> http://cr.openjdk.java.net/~weijun/8177969/webrev.00/
>>
>> This new implementation of containsPath(Path,Path) uses the logic of
>> Path::relativize without directly calling it, which is much faster now.
>>
>> Thanks
>> Max
>

From mark.reinhold at oracle.com  Fri Apr  7 15:10:43 2017
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 07 Apr 2017 08:10:43 -0700
Subject: ProcessHandle::getPid
In-Reply-To: <0317d211-2b5c-173d-8b14-6402a432f275@Oracle.com>
References: <20170407072941.873070683@eggemoggin.niobe.net>
 <0317d211-2b5c-173d-8b14-6402a432f275@Oracle.com>
Message-ID: <20170407081043.898510106@eggemoggin.niobe.net>

2017/4/7 7:45:38 -0700, roger.riggs at oracle.com:
> That's an unfortunate artifact of evolution.
> Process.getPid() was added early in 2014 and ProcessHandle a year later.
> 
> Several iterations of ProcessHandle API explored Process being a 
> subclass of ProcessHandle
> so the method names would be the same.  When ProcessHandle was decoupled 
> from Process
> the method name was retained for consistency.

I would think local consistency within the new `ProcessHandle` API would
be more important than external consistency with the legacy `Process` API.

Please consider fixing this.

- Mark

From andrey.x.nazarov at oracle.com  Fri Apr  7 15:35:57 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Fri, 7 Apr 2017 18:35:57 +0300
Subject: RFR 8178323: Add negative tests for bind services Jlink feature
Message-ID: <DEABD11B-3BFC-4BE6-81C3-14C1DCE296D7@oracle.com>

Hi, 

Please review 3 negative tests for Jlink which tests new bind-services/suggest-providers feature.

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

webrev: http://cr.openjdk.java.net/~anazarov/8178323/webrev.00/webrev/ <http://cr.openjdk.java.net/~anazarov/8178323/webrev.00/webrev/>

?Andrey

From brian.burkhalter at oracle.com  Fri Apr  7 18:44:20 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 7 Apr 2017 11:44:20 -0700
Subject: JDK 9 RFR(s): 8173152: Wrong wording in Comparator.compare()
 method spec
In-Reply-To: <3c3d08ca-925e-f869-90a8-68286be75a2e@oracle.com>
References: <3c3d08ca-925e-f869-90a8-68286be75a2e@oracle.com>
Message-ID: <A9E6407D-B230-47FC-92C3-1EE84B4A6426@oracle.com>

Hi Stuart,

On Apr 6, 2017, at 7:09 PM, Stuart Marks <stuart.marks at oracle.com> wrote:

> -     * imposes orderings that are inconsistent with equals."
> +     * imposes orderings that are inconsistent with equals."<p>

Picayune question: Would the <p> be better on the line before ?In the foregoing?"

> +     *
> +     * In the foregoing description, the notation
> +     * {@code sgn(}<i>expression</i>{@code )} designates the mathematical
> +     * <i>signum</i> function, which is defined to return one of {@code -1},
> +     * {@code 0}, or {@code 1} according to whether the value of
> +     * <i>expression</i> is negative, zero or positive.

I suggest to put ?, respectively? at the end of the sentence.

Brian

From sean.mullan at oracle.com  Fri Apr  7 20:48:25 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 7 Apr 2017 16:48:25 -0400
Subject: [9] RFR 8177969: Faster FilePermission::implies by avoiding the
 use of Path::relativize
In-Reply-To: <de22e3da-cca4-5730-607f-5a75f69b9f06@oracle.com>
References: <4f1e0c02-a11d-2694-84ad-cf8804021f3c@oracle.com>
 <9f96ed4d-9282-d776-f767-d3fe060ba895@Oracle.com>
 <de22e3da-cca4-5730-607f-5a75f69b9f06@oracle.com>
Message-ID: <b1e4428e-ab5a-af85-e3e9-349fe3476c78@oracle.com>

This fix looks good to me. However, I would suggest adding some 
additional comments to the body of the containsPath method explaining 
what it is doing so that it is easier to understand.

--Sean

On 4/7/17 10:50 AM, Weijun Wang wrote:
> Webrev updated at
>
>    http://cr.openjdk.java.net/~weijun/8177969/webrev.01/
>
> Changes since webrev.00 [1]
>
> 1. Copyright years.
>
> 2. Test fix. check() should include Windows drive tests like contains()
> does.
>
> Thanks
> Max
>
> [1]
> http://cr.openjdk.java.net/~weijun/8177969/webrev.01/interdiff.patch.html
>
> On 04/05/2017 10:13 PM, Roger Riggs wrote:
>> Hi Max,
>>
>> The code looks ok.
>>
>> How much faster does it make FilePermission compares?
>>
>> I assume if it is not accepted to be fixed in JDK 9, you will push it to
>> JDK 10.
>>
>> Roger
>>
>>
>> On 4/3/2017 11:30 AM, Weijun Wang wrote:
>>> http://cr.openjdk.java.net/~weijun/8177969/webrev.00/
>>>
>>> This new implementation of containsPath(Path,Path) uses the logic of
>>> Path::relativize without directly calling it, which is much faster now.
>>>
>>> Thanks
>>> Max
>>

From stuart.marks at oracle.com  Fri Apr  7 20:54:34 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 7 Apr 2017 13:54:34 -0700
Subject: JDK 9 RFR(s): 8173152: Wrong wording in Comparator.compare()
 method spec
In-Reply-To: <A9E6407D-B230-47FC-92C3-1EE84B4A6426@oracle.com>
References: <3c3d08ca-925e-f869-90a8-68286be75a2e@oracle.com>
 <A9E6407D-B230-47FC-92C3-1EE84B4A6426@oracle.com>
Message-ID: <9bbf7217-181d-94bb-b1f6-188f9e02e55a@oracle.com>



On 4/7/17 11:44 AM, Brian Burkhalter wrote:
> On Apr 6, 2017, at 7:09 PM, Stuart Marks <stuart.marks at oracle.com 
> <mailto:stuart.marks at oracle.com>> wrote:
>
>> -     * imposes orderings that are inconsistent with equals."
>> +     * imposes orderings that are inconsistent with equals."<p>
>
> Picayune question: Would the <p> be better on the line before ?In the foregoing?"
The rest of the markup in this method spec has trailing <p> tags, so I just kept 
things consistent with that. This is an odd style but it's not incorrect, as 
every paragraph except for the first has a <p> preceding it.
>
>> +     *
>> +     * In the foregoing description, the notation
>> +     * {@code sgn(}<i>expression</i>{@code )} designates the mathematical
>> +     * <i>signum</i> function, which is defined to return one of {@code -1},
>> +     * {@code 0}, or {@code 1} according to whether the value of
>> +     * <i>expression</i> is negative, zero or positive.
>
> I suggest to put ?, respectively? at the end of the sentence.
Sure, I can do that. I'll also add an Oxford comma as well. I'll make the same 
modifications to the Comparable interface, too.

Revised diffs below.

s'marks

# HG changeset patch
# User smarks
# Date 1491598302 25200
#      Fri Apr 07 13:51:42 2017 -0700
# Node ID 1a623ed5238fa04674b74ee92805ec7a1f036fd9
# Parent  7c72114a555820da956c81364ae7ba30698aa799
8173152: Wrong wording in Comparator.compare() method spec
Reviewed-by: XXX

diff -r 7c72114a5558 -r 1a623ed5238f 
src/java.base/share/classes/java/lang/Comparable.java
--- a/src/java.base/share/classes/java/lang/Comparable.java    Fri Mar 31 
14:21:21 2017 -0700
+++ b/src/java.base/share/classes/java/lang/Comparable.java    Fri Apr 07 
13:51:42 2017 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1997, 2013, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -124,7 +124,7 @@
       * {@code sgn(}<i>expression</i>{@code )} designates the mathematical
       * <i>signum</i> function, which is defined to return one of {@code -1},
       * {@code 0}, or {@code 1} according to whether the value of
-     * <i>expression</i> is negative, zero or positive.
+     * <i>expression</i> is negative, zero, or positive, respectively.
       *
       * @param   o the object to be compared.
       * @return  a negative integer, zero, or a positive integer as this object
diff -r 7c72114a5558 -r 1a623ed5238f 
src/java.base/share/classes/java/util/Comparator.java
--- a/src/java.base/share/classes/java/util/Comparator.java    Fri Mar 31 
14:21:21 2017 -0700
+++ b/src/java.base/share/classes/java/util/Comparator.java    Fri Apr 07 
13:51:42 2017 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -112,12 +112,6 @@
       * zero, or a positive integer as the first argument is less than, equal
       * to, or greater than the second.<p>
       *
-     * In the foregoing description, the notation
-     * {@code sgn(}<i>expression</i>{@code )} designates the mathematical
-     * <i>signum</i> function, which is defined to return one of {@code -1},
-     * {@code 0}, or {@code 1} according to whether the value of
-     * <i>expression</i> is negative, zero or positive.<p>
-     *
       * The implementor must ensure that {@code sgn(compare(x, y)) ==
       * -sgn(compare(y, x))} for all {@code x} and {@code y}.  (This
       * implies that {@code compare(x, y)} must throw an exception if and only
@@ -135,7 +129,13 @@
       * {@code (compare(x, y)==0) == (x.equals(y))}. Generally speaking,
       * any comparator that violates this condition should clearly indicate
       * this fact.  The recommended language is "Note: this comparator
-     * imposes orderings that are inconsistent with equals."
+     * imposes orderings that are inconsistent with equals."<p>
+     *
+     * In the foregoing description, the notation
+     * {@code sgn(}<i>expression</i>{@code )} designates the mathematical
+     * <i>signum</i> function, which is defined to return one of {@code -1},
+     * {@code 0}, or {@code 1} according to whether the value of
+     * <i>expression</i> is negative, zero, or positive, respectively.
       *
       * @param o1 the first object to be compared.
       * @param o2 the second object to be compared.


From lance.andersen at oracle.com  Fri Apr  7 21:11:35 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 7 Apr 2017 17:11:35 -0400
Subject: RFR: 8178130: Minor update to the Connection javadocs
Message-ID: <DB9E7604-DB5B-4532-AC8C-7DFFEF1045B1@oracle.com>

Hi all,

Please review the following minor update to the Connection javadocs.  The CCC has been approved.

??????????
$ hg diff
diff -r 45b226ad2e05 src/java.sql/share/classes/java/sql/Connection.java
--- a/src/java.sql/share/classes/java/sql/Connection.java	Thu Mar 16 16:56:29 2017 -0400
+++ b/src/java.sql/share/classes/java/sql/Connection.java	Fri Apr 07 15:12:08 2017 -0400
@@ -1535,8 +1535,9 @@
      * <li>The connection pool caches {@code PooledConnection} objects</li>
      * <li>Returns a logical connection handle when {@code getConnection} is
      * called by the application</li>
-     * <li>The pool manager calls {@code Connection.close} on the logical connection handle
-     * prior to returning the {@code PooledConnection} back to the cache</li>
+     * <li>The logical {@code Connection} is closed by calling
+     * {@code Connection.close} prior to returning the {@code PooledConnection}
+     * back to the cache.</li>
      * </ul>
      * @throws SQLException if an error occurs
      * @since 9
@@ -1577,8 +1578,9 @@
      * <li>The connection pool caches {@code PooledConnection} objects</li>
      * <li>Returns a logical connection handle when {@code getConnection} is
      * called by the application</li>
-     * <li>The pool manager calls {@code Connection.close} on the logical connection handle
-     * prior to returning the {@code PooledConnection} back to the cache</li>
+     * <li>The logical {@code Connection} is closed by calling
+     * {@code Connection.close} prior to returning the {@code PooledConnection}
+     * back to the cache.</li>
      * </ul>
      * @throws SQLException if an error occurs
      * @since 9
@@ -1590,7 +1592,10 @@
     }
 
     /**
-     * Sets and validates the sharding keys for this connection.
+     * Sets and validates the sharding keys for this connection. A {@code null}
+     * value may be specified for the sharding Key. The validity
+     * of a {@code null} sharding key is vendor specific. Consult your vendors
+     * documentation for additional information.
      * @implSpec
      * The default implementation will throw a
      * {@code SQLFeatureNotSupportedException}.
@@ -1600,7 +1605,8 @@
      * {@code Connection}. The timeout value indicates how long the driver
      * should wait for the {@code Connection} to verify that the sharding key
      * is valid before {@code setShardingKeyIfValid} returns false.
-     * @param shardingKey the sharding key to be validated against this connection
+     * @param shardingKey the sharding key to be validated against this connection.
+     * The sharding key may be {@code null}
      * @param superShardingKey the super sharding key to be validated against this
      * connection. The super sharding key may be {@code null}.
      * @param timeout time in seconds before which the validation process is expected to
@@ -1610,7 +1616,7 @@
      * and set on this connection; false if the sharding keys are not valid or
      * the timeout period expires before the operation completes.
      * @throws SQLException if an error occurs while performing this validation;
-     * the {@code shardingkey} is {@code null}; a {@code superSharedingKey} is specified
+     * a {@code superSharedingKey} is specified
      * without a {@code shardingKey};
      * this method is called on a closed {@code connection}; or
      * the {@code timeout} value is less than 0.
@@ -1626,7 +1632,10 @@
     }
 
     /**
-     * Sets and validates the sharding key for this connection.
+     * Sets and validates the sharding key for this connection. A {@code null}
+     * value may be specified for the sharding Key. The validity
+     * of a {@code null} sharding key is vendor specific. Consult your vendors
+     * documentation for additional information.
      * @implSpec
      * The default implementation will throw a
      * {@code SQLFeatureNotSupportedException}.
@@ -1635,7 +1644,8 @@
      * {@code Connection}. The timeout value indicates how long the driver
      * should wait for the {@code Connection} to verify that the sharding key
      * is valid before {@code setShardingKeyIfValid} returns false.
-     * @param shardingKey the sharding key to be validated against this connection
+     * @param shardingKey the sharding key to be validated against this connection.
+     * The sharding key may be {@code null}
      * @param timeout time in seconds before which the validation process is expected to
      * be completed,else the validation process is aborted. A value of 0 indicates
      * the validation process will not time out.
@@ -1643,8 +1653,8 @@
      * set on this connection; false if the sharding key is not valid or
      * the timeout period expires before the operation completes.
      * @throws SQLException if there is an error while performing this validation;
-     * this method is called on a closed {@code connection}; the {@code shardingkey}
-     * is {@code null}; or the {@code timeout} value is less than 0.
+     * this method is called on a closed {@code connection};
+     * or the {@code timeout} value is less than 0.
      * @throws SQLFeatureNotSupportedException if the driver does not support sharding
      * @since 9
      * @see ShardingKey
@@ -1664,12 +1674,12 @@
      * This method sets the specified sharding keys but does not require a
      * round trip to the database to validate that the sharding keys are valid
      * for the {@code Connection}.
-     * @param shardingKey the sharding key to set on this connection.
+     * @param shardingKey the sharding key to set on this connection. The sharding
+     * key may be {@code null}
      * @param superShardingKey the super sharding key to set on this connection.
      * The super sharding key may be {@code null}
      * @throws SQLException if an error  occurs setting the sharding keys;
-     * this method is called on a closed {@code connection};
-     * the {@code shardingkey} is {@code null}; or
+     * this method is called on a closed {@code connection}; or
      * a {@code superSharedingKey} is specified without a {@code shardingKey}
      * @throws SQLFeatureNotSupportedException if the driver does not support sharding
      * @since 9
@@ -1690,10 +1700,10 @@
      * This method sets the specified sharding key but does not require a
      * round trip to the database to validate that the sharding key is valid
      * for the {@code Connection}.
-     * @param shardingKey the sharding key to set on this connection.
-     * @throws SQLException if an error  occurs setting the sharding key;
-     * this method is called on a closed {@code connection}; or the
-     * {@code shardkingKey} is {@code null}
+     * @param shardingKey the sharding key to set on this connection. The sharding
+     * key may be {@code null}
+     * @throws SQLException if an error occurs setting the sharding key; or
+     * this method is called on a closed {@code connection}
      * @throws SQLFeatureNotSupportedException if the driver does not support sharding
      * @since 9
      * @see ShardingKey
??????????????

Best,
Lance
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From brian.burkhalter at oracle.com  Fri Apr  7 22:24:38 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 7 Apr 2017 15:24:38 -0700
Subject: RFR: 8178130: Minor update to the Connection javadocs
In-Reply-To: <DB9E7604-DB5B-4532-AC8C-7DFFEF1045B1@oracle.com>
References: <DB9E7604-DB5B-4532-AC8C-7DFFEF1045B1@oracle.com>
Message-ID: <7E91DED6-C202-416C-9122-51F804FE28A6@oracle.com>

Hi Lance,

Minor comments inline.

Brian

On Apr 7, 2017, at 2:11 PM, Lance Andersen <lance.andersen at oracle.com> wrote:

> Please review the following minor update to the Connection javadocs.  The CCC has been approved.
> 
> ??????????
> $ hg diff
> diff -r 45b226ad2e05 src/java.sql/share/classes/java/sql/Connection.java
> --- a/src/java.sql/share/classes/java/sql/Connection.java	Thu Mar 16 16:56:29 2017 -0400
> +++ b/src/java.sql/share/classes/java/sql/Connection.java	Fri Apr 07 15:12:08 2017 -0400
> @@ -1535,8 +1535,9 @@
>      * <li>The connection pool caches {@code PooledConnection} objects</li>
>      * <li>Returns a logical connection handle when {@code getConnection} is
>      * called by the application</li>
> -     * <li>The pool manager calls {@code Connection.close} on the logical connection handle
> -     * prior to returning the {@code PooledConnection} back to the cache</li>
> +     * <li>The logical {@code Connection} is closed by calling
> +     * {@code Connection.close} prior to returning the {@code PooledConnection}
> +     * back to the cache.</li>

I would delete ?back? in the previous line.

>      * </ul>
>      * @throws SQLException if an error occurs
>      * @since 9
> @@ -1577,8 +1578,9 @@
>      * <li>The connection pool caches {@code PooledConnection} objects</li>
>      * <li>Returns a logical connection handle when {@code getConnection} is
>      * called by the application</li>
> -     * <li>The pool manager calls {@code Connection.close} on the logical connection handle
> -     * prior to returning the {@code PooledConnection} back to the cache</li>
> +     * <li>The logical {@code Connection} is closed by calling
> +     * {@code Connection.close} prior to returning the {@code PooledConnection}
> +     * back to the cache.</li>

Same here.

>      * </ul>
>      * @throws SQLException if an error occurs
>      * @since 9
> @@ -1590,7 +1592,10 @@
>     }
> 
>     /**
> -     * Sets and validates the sharding keys for this connection.
> +     * Sets and validates the sharding keys for this connection. A {@code null}
> +     * value may be specified for the sharding Key. The validity
> +     * of a {@code null} sharding key is vendor specific. Consult your vendors

I would hyphenate ?vendor-specific? and change ?vendors? to ?vendor?s"

> +     * documentation for additional information.
>      * @implSpec
>      * The default implementation will throw a
>      * {@code SQLFeatureNotSupportedException}.
> @@ -1600,7 +1605,8 @@
>      * {@code Connection}. The timeout value indicates how long the driver
>      * should wait for the {@code Connection} to verify that the sharding key
>      * is valid before {@code setShardingKeyIfValid} returns false.
> -     * @param shardingKey the sharding key to be validated against this connection
> +     * @param shardingKey the sharding key to be validated against this connection.
> +     * The sharding key may be {@code null}
>      * @param superShardingKey the super sharding key to be validated against this
>      * connection. The super sharding key may be {@code null}.
>      * @param timeout time in seconds before which the validation process is expected to
> @@ -1610,7 +1616,7 @@
>      * and set on this connection; false if the sharding keys are not valid or
>      * the timeout period expires before the operation completes.
>      * @throws SQLException if an error occurs while performing this validation;
> -     * the {@code shardingkey} is {@code null}; a {@code superSharedingKey} is specified
> +     * a {@code superSharedingKey} is specified
>      * without a {@code shardingKey};
>      * this method is called on a closed {@code connection}; or
>      * the {@code timeout} value is less than 0.

?less than 0? could be simple ?negative."

> @@ -1626,7 +1632,10 @@
>     }
> 
>     /**
> -     * Sets and validates the sharding key for this connection.
> +     * Sets and validates the sharding key for this connection. A {@code null}
> +     * value may be specified for the sharding Key. The validity
> +     * of a {@code null} sharding key is vendor specific. Consult your vendors

Again I would hyphenate ?vendor-specific? and change ?vendors? to ?vendor?s"

> +     * documentation for additional information.
>      * @implSpec
>      * The default implementation will throw a
>      * {@code SQLFeatureNotSupportedException}.
> @@ -1635,7 +1644,8 @@
>      * {@code Connection}. The timeout value indicates how long the driver
>      * should wait for the {@code Connection} to verify that the sharding key
>      * is valid before {@code setShardingKeyIfValid} returns false.
> -     * @param shardingKey the sharding key to be validated against this connection
> +     * @param shardingKey the sharding key to be validated against this connection.
> +     * The sharding key may be {@code null}
>      * @param timeout time in seconds before which the validation process is expected to
>      * be completed,else the validation process is aborted. A value of 0 indicates
>      * the validation process will not time out.
> @@ -1643,8 +1653,8 @@
>      * set on this connection; false if the sharding key is not valid or
>      * the timeout period expires before the operation completes.
>      * @throws SQLException if there is an error while performing this validation;
> -     * this method is called on a closed {@code connection}; the {@code shardingkey}
> -     * is {@code null}; or the {@code timeout} value is less than 0.
> +     * this method is called on a closed {@code connection};
> +     * or the {@code timeout} value is less than 0.

Again ?less than 0? could be simple ?negative."

>      * @throws SQLFeatureNotSupportedException if the driver does not support sharding
>      * @since 9
>      * @see ShardingKey
> @@ -1664,12 +1674,12 @@
>      * This method sets the specified sharding keys but does not require a
>      * round trip to the database to validate that the sharding keys are valid
>      * for the {@code Connection}.
> -     * @param shardingKey the sharding key to set on this connection.
> +     * @param shardingKey the sharding key to set on this connection. The sharding
> +     * key may be {@code null}
>      * @param superShardingKey the super sharding key to set on this connection.
>      * The super sharding key may be {@code null}
>      * @throws SQLException if an error  occurs setting the sharding keys;
> -     * this method is called on a closed {@code connection};
> -     * the {@code shardingkey} is {@code null}; or
> +     * this method is called on a closed {@code connection}; or
>      * a {@code superSharedingKey} is specified without a {@code shardingKey}
>      * @throws SQLFeatureNotSupportedException if the driver does not support sharding
>      * @since 9
> @@ -1690,10 +1700,10 @@
>      * This method sets the specified sharding key but does not require a
>      * round trip to the database to validate that the sharding key is valid
>      * for the {@code Connection}.
> -     * @param shardingKey the sharding key to set on this connection.
> -     * @throws SQLException if an error  occurs setting the sharding key;
> -     * this method is called on a closed {@code connection}; or the
> -     * {@code shardkingKey} is {@code null}
> +     * @param shardingKey the sharding key to set on this connection. The sharding
> +     * key may be {@code null}
> +     * @throws SQLException if an error occurs setting the sharding key; or
> +     * this method is called on a closed {@code connection}
>      * @throws SQLFeatureNotSupportedException if the driver does not support sharding
>      * @since 9
>      * @see ShardingKey


From brian.burkhalter at oracle.com  Fri Apr  7 22:34:07 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 7 Apr 2017 15:34:07 -0700
Subject: JDK 9 RFR(s): 8173152: Wrong wording in Comparator.compare()
 method spec
In-Reply-To: <9bbf7217-181d-94bb-b1f6-188f9e02e55a@oracle.com>
References: <3c3d08ca-925e-f869-90a8-68286be75a2e@oracle.com>
 <A9E6407D-B230-47FC-92C3-1EE84B4A6426@oracle.com>
 <9bbf7217-181d-94bb-b1f6-188f9e02e55a@oracle.com>
Message-ID: <1F68B310-64C2-410B-BF8B-F7FCCBE21844@oracle.com>

On Apr 7, 2017, at 1:54 PM, Stuart Marks <stuart.marks at oracle.com> wrote:

> On 4/7/17 11:44 AM, Brian Burkhalter wrote:
>> On Apr 6, 2017, at 7:09 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
>> 
>>> -     * imposes orderings that are inconsistent with equals."
>>> +     * imposes orderings that are inconsistent with equals."<p>
>> 
>> Picayune question: Would the <p> be better on the line before ?In the foregoing?"
> The rest of the markup in this method spec has trailing <p> tags, so I just kept things consistent with that. This is an odd style but it's not incorrect, as every paragraph except for the first has a <p> preceding it.

That?s reasonable.

>>> +     *
>>> +     * In the foregoing description, the notation
>>> +     * {@code sgn(}<i>expression</i>{@code )} designates the mathematical
>>> +     * <i>signum</i> function, which is defined to return one of {@code -1},
>>> +     * {@code 0}, or {@code 1} according to whether the value of
>>> +     * <i>expression</i> is negative, zero or positive.
>> 
>> I suggest to put ?, respectively? at the end of the sentence.
> Sure, I can do that. I'll also add an Oxford comma as well.

Good, I prefer that also.

> I'll make the same modifications to the Comparable interface, too.

Sounds good. Reviewed.

Brian

From lance.andersen at oracle.com  Fri Apr  7 22:45:38 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 7 Apr 2017 18:45:38 -0400
Subject: RFR: 8178130: Minor update to the Connection javadocs
In-Reply-To: <7E91DED6-C202-416C-9122-51F804FE28A6@oracle.com>
References: <DB9E7604-DB5B-4532-AC8C-7DFFEF1045B1@oracle.com>
 <7E91DED6-C202-416C-9122-51F804FE28A6@oracle.com>
Message-ID: <72EF7E38-A474-45EC-9E74-B4BB6009F90D@oracle.com>

Hi Brian,

Thank you for your input.  Here is the revised version:

???????
hg diff
diff -r 45b226ad2e05 src/java.sql/share/classes/java/sql/Connection.java
--- a/src/java.sql/share/classes/java/sql/Connection.java	Thu Mar 16 16:56:29 2017 -0400
+++ b/src/java.sql/share/classes/java/sql/Connection.java	Fri Apr 07 18:42:20 2017 -0400
@@ -1535,8 +1535,9 @@
      * <li>The connection pool caches {@code PooledConnection} objects</li>
      * <li>Returns a logical connection handle when {@code getConnection} is
      * called by the application</li>
-     * <li>The pool manager calls {@code Connection.close} on the logical connection handle
-     * prior to returning the {@code PooledConnection} back to the cache</li>
+     * <li>The logical {@code Connection} is closed by calling
+     * {@code Connection.close} prior to returning the {@code PooledConnection}
+     * to the cache.</li>
      * </ul>
      * @throws SQLException if an error occurs
      * @since 9
@@ -1577,8 +1578,9 @@
      * <li>The connection pool caches {@code PooledConnection} objects</li>
      * <li>Returns a logical connection handle when {@code getConnection} is
      * called by the application</li>
-     * <li>The pool manager calls {@code Connection.close} on the logical connection handle
-     * prior to returning the {@code PooledConnection} back to the cache</li>
+     * <li>The logical {@code Connection} is closed by calling
+     * {@code Connection.close} prior to returning the {@code PooledConnection}
+     * to the cache.</li>
      * </ul>
      * @throws SQLException if an error occurs
      * @since 9
@@ -1590,7 +1592,10 @@
     }
 
     /**
-     * Sets and validates the sharding keys for this connection.
+     * Sets and validates the sharding keys for this connection. A {@code null}
+     * value may be specified for the sharding Key. The validity
+     * of a {@code null} sharding key is vendor-specific. Consult your vendor&#39;s
+     * documentation for additional information.
      * @implSpec
      * The default implementation will throw a
      * {@code SQLFeatureNotSupportedException}.
@@ -1600,7 +1605,8 @@
      * {@code Connection}. The timeout value indicates how long the driver
      * should wait for the {@code Connection} to verify that the sharding key
      * is valid before {@code setShardingKeyIfValid} returns false.
-     * @param shardingKey the sharding key to be validated against this connection
+     * @param shardingKey the sharding key to be validated against this connection.
+     * The sharding key may be {@code null}
      * @param superShardingKey the super sharding key to be validated against this
      * connection. The super sharding key may be {@code null}.
      * @param timeout time in seconds before which the validation process is expected to
@@ -1610,10 +1616,10 @@
      * and set on this connection; false if the sharding keys are not valid or
      * the timeout period expires before the operation completes.
      * @throws SQLException if an error occurs while performing this validation;
-     * the {@code shardingkey} is {@code null}; a {@code superSharedingKey} is specified
+     * a {@code superSharedingKey} is specified
      * without a {@code shardingKey};
      * this method is called on a closed {@code connection}; or
-     * the {@code timeout} value is less than 0.
+     * the {@code timeout} value is negative.
      * @throws SQLFeatureNotSupportedException if the driver does not support sharding
      * @since 9
      * @see ShardingKey
@@ -1626,7 +1632,10 @@
     }
 
     /**
-     * Sets and validates the sharding key for this connection.
+     * Sets and validates the sharding key for this connection. A {@code null}
+     * value may be specified for the sharding Key. The validity
+     * of a {@code null} sharding key is vendor-specific. Consult your vendor&#39;s
+     * documentation for additional information.
      * @implSpec
      * The default implementation will throw a
      * {@code SQLFeatureNotSupportedException}.
@@ -1635,7 +1644,8 @@
      * {@code Connection}. The timeout value indicates how long the driver
      * should wait for the {@code Connection} to verify that the sharding key
      * is valid before {@code setShardingKeyIfValid} returns false.
-     * @param shardingKey the sharding key to be validated against this connection
+     * @param shardingKey the sharding key to be validated against this connection.
+     * The sharding key may be {@code null}
      * @param timeout time in seconds before which the validation process is expected to
      * be completed,else the validation process is aborted. A value of 0 indicates
      * the validation process will not time out.
@@ -1643,8 +1653,8 @@
      * set on this connection; false if the sharding key is not valid or
      * the timeout period expires before the operation completes.
      * @throws SQLException if there is an error while performing this validation;
-     * this method is called on a closed {@code connection}; the {@code shardingkey}
-     * is {@code null}; or the {@code timeout} value is less than 0.
+     * this method is called on a closed {@code connection};
+     * or the {@code timeout} value is negative.
      * @throws SQLFeatureNotSupportedException if the driver does not support sharding
      * @since 9
      * @see ShardingKey
@@ -1664,12 +1674,12 @@
      * This method sets the specified sharding keys but does not require a
      * round trip to the database to validate that the sharding keys are valid
      * for the {@code Connection}.
-     * @param shardingKey the sharding key to set on this connection.
+     * @param shardingKey the sharding key to set on this connection. The sharding
+     * key may be {@code null}
      * @param superShardingKey the super sharding key to set on this connection.
      * The super sharding key may be {@code null}
      * @throws SQLException if an error  occurs setting the sharding keys;
-     * this method is called on a closed {@code connection};
-     * the {@code shardingkey} is {@code null}; or
+     * this method is called on a closed {@code connection}; or
      * a {@code superSharedingKey} is specified without a {@code shardingKey}
      * @throws SQLFeatureNotSupportedException if the driver does not support sharding
      * @since 9
@@ -1690,10 +1700,10 @@
      * This method sets the specified sharding key but does not require a
      * round trip to the database to validate that the sharding key is valid
      * for the {@code Connection}.
-     * @param shardingKey the sharding key to set on this connection.
-     * @throws SQLException if an error  occurs setting the sharding key;
-     * this method is called on a closed {@code connection}; or the
-     * {@code shardkingKey} is {@code null}
+     * @param shardingKey the sharding key to set on this connection. The sharding
+     * key may be {@code null}
+     * @throws SQLException if an error occurs setting the sharding key; or
+     * this method is called on a closed {@code connection}
      * @throws SQLFeatureNotSupportedException if the driver does not support sharding
      * @since 9
      * @see ShardingKey
ljanders-mac:sql ljanders$
??????????

Best
Lance
> On Apr 7, 2017, at 6:24 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Hi Lance,
> 
> Minor comments inline.
> 
> Brian
> 
> On Apr 7, 2017, at 2:11 PM, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
> 
>> Please review the following minor update to the Connection javadocs.  The CCC has been approved.
>> 
>> ??????????
>> $ hg diff
>> diff -r 45b226ad2e05 src/java.sql/share/classes/java/sql/Connection.java
>> --- a/src/java.sql/share/classes/java/sql/Connection.java	Thu Mar 16 16:56:29 2017 -0400
>> +++ b/src/java.sql/share/classes/java/sql/Connection.java	Fri Apr 07 15:12:08 2017 -0400
>> @@ -1535,8 +1535,9 @@
>>      * <li>The connection pool caches {@code PooledConnection} objects</li>
>>      * <li>Returns a logical connection handle when {@code getConnection} is
>>      * called by the application</li>
>> -     * <li>The pool manager calls {@code Connection.close} on the logical connection handle
>> -     * prior to returning the {@code PooledConnection} back to the cache</li>
>> +     * <li>The logical {@code Connection} is closed by calling
>> +     * {@code Connection.close} prior to returning the {@code PooledConnection}
>> +     * back to the cache.</li>
> 
> I would delete ?back? in the previous line.
> 
>>      * </ul>
>>      * @throws SQLException if an error occurs
>>      * @since 9
>> @@ -1577,8 +1578,9 @@
>>      * <li>The connection pool caches {@code PooledConnection} objects</li>
>>      * <li>Returns a logical connection handle when {@code getConnection} is
>>      * called by the application</li>
>> -     * <li>The pool manager calls {@code Connection.close} on the logical connection handle
>> -     * prior to returning the {@code PooledConnection} back to the cache</li>
>> +     * <li>The logical {@code Connection} is closed by calling
>> +     * {@code Connection.close} prior to returning the {@code PooledConnection}
>> +     * back to the cache.</li>
> 
> Same here.
> 
>>      * </ul>
>>      * @throws SQLException if an error occurs
>>      * @since 9
>> @@ -1590,7 +1592,10 @@
>>     }
>> 
>>     /**
>> -     * Sets and validates the sharding keys for this connection.
>> +     * Sets and validates the sharding keys for this connection. A {@code null}
>> +     * value may be specified for the sharding Key. The validity
>> +     * of a {@code null} sharding key is vendor specific. Consult your vendors
> 
> I would hyphenate ?vendor-specific? and change ?vendors? to ?vendor?s"
> 
>> +     * documentation for additional information.
>>      * @implSpec
>>      * The default implementation will throw a
>>      * {@code SQLFeatureNotSupportedException}.
>> @@ -1600,7 +1605,8 @@
>>      * {@code Connection}. The timeout value indicates how long the driver
>>      * should wait for the {@code Connection} to verify that the sharding key
>>      * is valid before {@code setShardingKeyIfValid} returns false.
>> -     * @param shardingKey the sharding key to be validated against this connection
>> +     * @param shardingKey the sharding key to be validated against this connection.
>> +     * The sharding key may be {@code null}
>>      * @param superShardingKey the super sharding key to be validated against this
>>      * connection. The super sharding key may be {@code null}.
>>      * @param timeout time in seconds before which the validation process is expected to
>> @@ -1610,7 +1616,7 @@
>>      * and set on this connection; false if the sharding keys are not valid or
>>      * the timeout period expires before the operation completes.
>>      * @throws SQLException if an error occurs while performing this validation;
>> -     * the {@code shardingkey} is {@code null}; a {@code superSharedingKey} is specified
>> +     * a {@code superSharedingKey} is specified
>>      * without a {@code shardingKey};
>>      * this method is called on a closed {@code connection}; or
>>      * the {@code timeout} value is less than 0.
> 
> ?less than 0? could be simple ?negative."
> 
>> @@ -1626,7 +1632,10 @@
>>     }
>> 
>>     /**
>> -     * Sets and validates the sharding key for this connection.
>> +     * Sets and validates the sharding key for this connection. A {@code null}
>> +     * value may be specified for the sharding Key. The validity
>> +     * of a {@code null} sharding key is vendor specific. Consult your vendors
> 
> Again I would hyphenate ?vendor-specific? and change ?vendors? to ?vendor?s"
> 
>> +     * documentation for additional information.
>>      * @implSpec
>>      * The default implementation will throw a
>>      * {@code SQLFeatureNotSupportedException}.
>> @@ -1635,7 +1644,8 @@
>>      * {@code Connection}. The timeout value indicates how long the driver
>>      * should wait for the {@code Connection} to verify that the sharding key
>>      * is valid before {@code setShardingKeyIfValid} returns false.
>> -     * @param shardingKey the sharding key to be validated against this connection
>> +     * @param shardingKey the sharding key to be validated against this connection.
>> +     * The sharding key may be {@code null}
>>      * @param timeout time in seconds before which the validation process is expected to
>>      * be completed,else the validation process is aborted. A value of 0 indicates
>>      * the validation process will not time out.
>> @@ -1643,8 +1653,8 @@
>>      * set on this connection; false if the sharding key is not valid or
>>      * the timeout period expires before the operation completes.
>>      * @throws SQLException if there is an error while performing this validation;
>> -     * this method is called on a closed {@code connection}; the {@code shardingkey}
>> -     * is {@code null}; or the {@code timeout} value is less than 0.
>> +     * this method is called on a closed {@code connection};
>> +     * or the {@code timeout} value is less than 0.
> 
> Again ?less than 0? could be simple ?negative."
> 
>>      * @throws SQLFeatureNotSupportedException if the driver does not support sharding
>>      * @since 9
>>      * @see ShardingKey
>> @@ -1664,12 +1674,12 @@
>>      * This method sets the specified sharding keys but does not require a
>>      * round trip to the database to validate that the sharding keys are valid
>>      * for the {@code Connection}.
>> -     * @param shardingKey the sharding key to set on this connection.
>> +     * @param shardingKey the sharding key to set on this connection. The sharding
>> +     * key may be {@code null}
>>      * @param superShardingKey the super sharding key to set on this connection.
>>      * The super sharding key may be {@code null}
>>      * @throws SQLException if an error  occurs setting the sharding keys;
>> -     * this method is called on a closed {@code connection};
>> -     * the {@code shardingkey} is {@code null}; or
>> +     * this method is called on a closed {@code connection}; or
>>      * a {@code superSharedingKey} is specified without a {@code shardingKey}
>>      * @throws SQLFeatureNotSupportedException if the driver does not support sharding
>>      * @since 9
>> @@ -1690,10 +1700,10 @@
>>      * This method sets the specified sharding key but does not require a
>>      * round trip to the database to validate that the sharding key is valid
>>      * for the {@code Connection}.
>> -     * @param shardingKey the sharding key to set on this connection.
>> -     * @throws SQLException if an error  occurs setting the sharding key;
>> -     * this method is called on a closed {@code connection}; or the
>> -     * {@code shardkingKey} is {@code null}
>> +     * @param shardingKey the sharding key to set on this connection. The sharding
>> +     * key may be {@code null}
>> +     * @throws SQLException if an error occurs setting the sharding key; or
>> +     * this method is called on a closed {@code connection}
>>      * @throws SQLFeatureNotSupportedException if the driver does not support sharding
>>      * @since 9
>>      * @see ShardingKey
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From brian.burkhalter at oracle.com  Fri Apr  7 22:50:19 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 7 Apr 2017 15:50:19 -0700
Subject: RFR: 8178130: Minor update to the Connection javadocs
In-Reply-To: <72EF7E38-A474-45EC-9E74-B4BB6009F90D@oracle.com>
References: <DB9E7604-DB5B-4532-AC8C-7DFFEF1045B1@oracle.com>
 <7E91DED6-C202-416C-9122-51F804FE28A6@oracle.com>
 <72EF7E38-A474-45EC-9E74-B4BB6009F90D@oracle.com>
Message-ID: <3258F920-847C-4223-9ABF-03EBCB75F735@oracle.com>

Looks good!

Brian

On Apr 7, 2017, at 3:45 PM, Lance Andersen <lance.andersen at oracle.com> wrote:

> Thank you for your input.  Here is the revised version:


From stuart.marks at oracle.com  Sat Apr  8 00:22:53 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 7 Apr 2017 17:22:53 -0700
Subject: JDK 9 RFR(s): 8150488: add note to
 Scanner.findAll()regardingpossible infinite streams
In-Reply-To: <58e644e8.6585df0a.cb334.d1ae@mx.google.com>
References: <ca6ee328-1121-ed95-48ca-92cf5be02c0e@oracle.com>
 <58DC7E53.6040603@oracle.com> <58dd2aba.298fdf0a.86cca.3418@mx.google.com>
 <cc200e33-24dc-df27-1c56-dc11bf695c36@oracle.com>
 <fc36e657-a196-6f3e-bd42-fb1bdc741205@oracle.com>
 <58E427E8.2020901@oracle.com>
 <89d5129f-faff-20cb-eb86-6d3bb4151958@oracle.com>
 <f3dd4c6e-6774-777c-cebd-539fe51b88a1@oracle.com>
 <58e644e8.6585df0a.cb334.d1ae@mx.google.com>
Message-ID: <1adc45d8-af7e-9cd2-aed0-a91db14b29de@oracle.com>

On 4/6/17 6:38 AM, Timo Kinnunen wrote:
> IMHO there should be a notice added in findAll which excludes the behavior of
> the stream after an empty match from any compatibility requirements while the
> notice remains in place. This would be to ensure that findAll and the stream it
> returns can be changed independently from the other methods which also have this
> issue. Just in case.

In general we don't use @apiNote to document implementation limits or 
restrictions that might be modified in the future, e.g. by bugfixes. And also 
note that @apiNote is non-normative, so it doesn't affect compatibility.

But also, Sherman came up with a prototype for a fix that we might be able to 
get into 9, so we're pursuing that at the moment.

s'marks

From weijun.wang at oracle.com  Sat Apr  8 00:39:59 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 8 Apr 2017 08:39:59 +0800
Subject: [9] RFR 8177969: Faster FilePermission::implies by avoiding the
 use of Path::relativize
In-Reply-To: <b1e4428e-ab5a-af85-e3e9-349fe3476c78@oracle.com>
References: <4f1e0c02-a11d-2694-84ad-cf8804021f3c@oracle.com>
 <9f96ed4d-9282-d776-f767-d3fe060ba895@Oracle.com>
 <de22e3da-cca4-5730-607f-5a75f69b9f06@oracle.com>
 <b1e4428e-ab5a-af85-e3e9-349fe3476c78@oracle.com>
Message-ID: <769a4646-7f6b-5a17-8671-8333cb7042b1@oracle.com>

Webrev updated at

   http://cr.openjdk.java.net/~weijun/8177969/webrev.02/

Changes since webrev.01:

1. Comments.

2. Another enhancement when I am writing comments. Since we can be sure 
that a path has no ".." by only looking at its head, we can also be sure 
that a path is all ".." by only looking at its tail.

JPRT core+jaxp runs fine. JCK tests run fine.

Now benchmark result (after adjusting the granted permission to 
"../../../../-") is:

Benchmark                         Mode  Cnt       Score       Error  Units
checkReadNewUnfixed  thrpt   15  174963.698 ?  5952.239  ops/s
checkReadNewFixed00  thrpt   15  417692.698 ? 24994.735  ops/s
checkReadNewFixed02  thrpt   15  447824.218 ? 20199.194  ops/s
checkReadOld200      thrpt   15  425353.705 ?  3546.411  ops/s
checkReadOld201      thrpt   15    2045.070 ?    57.287  ops/s

This time checkReadNewFixed02 looks even better than checkReadOld200 
running on jdk8u131. I dare not run it again. :-)

Thanks
Max

On 04/08/2017 04:48 AM, Sean Mullan wrote:
> This fix looks good to me. However, I would suggest adding some
> additional comments to the body of the containsPath method explaining
> what it is doing so that it is easier to understand.
>
> --Sean
>
> On 4/7/17 10:50 AM, Weijun Wang wrote:
>> Webrev updated at
>>
>>    http://cr.openjdk.java.net/~weijun/8177969/webrev.01/
>>
>> Changes since webrev.00 [1]
>>
>> 1. Copyright years.
>>
>> 2. Test fix. check() should include Windows drive tests like contains()
>> does.
>>
>> Thanks
>> Max
>>
>> [1]
>> http://cr.openjdk.java.net/~weijun/8177969/webrev.01/interdiff.patch.html
>>
>> On 04/05/2017 10:13 PM, Roger Riggs wrote:
>>> Hi Max,
>>>
>>> The code looks ok.
>>>
>>> How much faster does it make FilePermission compares?
>>>
>>> I assume if it is not accepted to be fixed in JDK 9, you will push it to
>>> JDK 10.
>>>
>>> Roger
>>>
>>>
>>> On 4/3/2017 11:30 AM, Weijun Wang wrote:
>>>> http://cr.openjdk.java.net/~weijun/8177969/webrev.00/
>>>>
>>>> This new implementation of containsPath(Path,Path) uses the logic of
>>>> Path::relativize without directly calling it, which is much faster now.
>>>>
>>>> Thanks
>>>> Max
>>>

From sean.mullan at oracle.com  Mon Apr 10 14:08:09 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 10 Apr 2017 10:08:09 -0400
Subject: [9] RFR 8177969: Faster FilePermission::implies by avoiding the
 use of Path::relativize
In-Reply-To: <769a4646-7f6b-5a17-8671-8333cb7042b1@oracle.com>
References: <4f1e0c02-a11d-2694-84ad-cf8804021f3c@oracle.com>
 <9f96ed4d-9282-d776-f767-d3fe060ba895@Oracle.com>
 <de22e3da-cca4-5730-607f-5a75f69b9f06@oracle.com>
 <b1e4428e-ab5a-af85-e3e9-349fe3476c78@oracle.com>
 <769a4646-7f6b-5a17-8671-8333cb7042b1@oracle.com>
Message-ID: <bf713720-eec4-d893-65a4-75465a71703a@oracle.com>

The updated webrev looks good.

Thanks,
Sean

On 4/7/17 8:39 PM, Weijun Wang wrote:
> Webrev updated at
>
>   http://cr.openjdk.java.net/~weijun/8177969/webrev.02/
>
> Changes since webrev.01:
>
> 1. Comments.
>
> 2. Another enhancement when I am writing comments. Since we can be sure
> that a path has no ".." by only looking at its head, we can also be sure
> that a path is all ".." by only looking at its tail.
>
> JPRT core+jaxp runs fine. JCK tests run fine.
>
> Now benchmark result (after adjusting the granted permission to
> "../../../../-") is:
>
> Benchmark                         Mode  Cnt       Score       Error  Units
> checkReadNewUnfixed  thrpt   15  174963.698 ?  5952.239  ops/s
> checkReadNewFixed00  thrpt   15  417692.698 ? 24994.735  ops/s
> checkReadNewFixed02  thrpt   15  447824.218 ? 20199.194  ops/s
> checkReadOld200      thrpt   15  425353.705 ?  3546.411  ops/s
> checkReadOld201      thrpt   15    2045.070 ?    57.287  ops/s
>
> This time checkReadNewFixed02 looks even better than checkReadOld200
> running on jdk8u131. I dare not run it again. :-)
>
> Thanks
> Max
>
> On 04/08/2017 04:48 AM, Sean Mullan wrote:
>> This fix looks good to me. However, I would suggest adding some
>> additional comments to the body of the containsPath method explaining
>> what it is doing so that it is easier to understand.
>>
>> --Sean
>>
>> On 4/7/17 10:50 AM, Weijun Wang wrote:
>>> Webrev updated at
>>>
>>>    http://cr.openjdk.java.net/~weijun/8177969/webrev.01/
>>>
>>> Changes since webrev.00 [1]
>>>
>>> 1. Copyright years.
>>>
>>> 2. Test fix. check() should include Windows drive tests like contains()
>>> does.
>>>
>>> Thanks
>>> Max
>>>
>>> [1]
>>> http://cr.openjdk.java.net/~weijun/8177969/webrev.01/interdiff.patch.html
>>>
>>>
>>> On 04/05/2017 10:13 PM, Roger Riggs wrote:
>>>> Hi Max,
>>>>
>>>> The code looks ok.
>>>>
>>>> How much faster does it make FilePermission compares?
>>>>
>>>> I assume if it is not accepted to be fixed in JDK 9, you will push
>>>> it to
>>>> JDK 10.
>>>>
>>>> Roger
>>>>
>>>>
>>>> On 4/3/2017 11:30 AM, Weijun Wang wrote:
>>>>> http://cr.openjdk.java.net/~weijun/8177969/webrev.00/
>>>>>
>>>>> This new implementation of containsPath(Path,Path) uses the logic of
>>>>> Path::relativize without directly calling it, which is much faster
>>>>> now.
>>>>>
>>>>> Thanks
>>>>> Max
>>>>

From claes.redestad at oracle.com  Mon Apr 10 14:09:43 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 10 Apr 2017 16:09:43 +0200
Subject: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers
Message-ID: <ca7be65a-4246-30f0-6051-05a29296cf15@oracle.com>

Hi,

profiling initializers in java.lang.invoke shows we're still doing 
various things during
class initialization which could be done lazily or not at all. The 
proposed patch
reduce bytecode executed, memory churn and retained heap footprint when
initializing java.lang.invoke:

Webrev: http://cr.openjdk.java.net/~redestad/8178384/jdk.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8178384

Testing: java.lang.invoke jtreg tests, sanity performance testing

Thanks!

/Claes

From vladimir.x.ivanov at oracle.com  Mon Apr 10 15:19:12 2017
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 10 Apr 2017 18:19:12 +0300
Subject: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers
In-Reply-To: <ca7be65a-4246-30f0-6051-05a29296cf15@oracle.com>
References: <ca7be65a-4246-30f0-6051-05a29296cf15@oracle.com>
Message-ID: <e1664d96-265f-6b4f-a320-7ea40d42bb08@oracle.com>

Looks good.

One small suggestion [1]

Best regards,
Vladimir Ivanov

[1] diff --git 
a/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java 
b/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
--- a/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
+++ b/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
@@ -456,6 +456,7 @@
          static final String MH       = "java/lang/invoke/MethodHandle";
          static final String MH_SIG   = "L"+MH+";";
          static final String BMH      = 
"java/lang/invoke/BoundMethodHandle";
+        static final String BMH_NAME = 
"java.lang.invoke.BoundMethodHandle";
          static final String BMH_SIG  = "L"+BMH+";";
          static final String SPECIES_DATA     = 
"java/lang/invoke/BoundMethodHandle$SpeciesData";
          static final String SPECIES_DATA_SIG = "L"+SPECIES_DATA+";";
@@ -463,7 +464,7 @@

          static final String SPECIES_PREFIX_NAME = "Species_";
          static final String SPECIES_PREFIX_PATH = BMH + "$" + 
SPECIES_PREFIX_NAME;
-        static final String SPECIES_CLASS_PREFIX = 
SPECIES_PREFIX_PATH.replace('/', '.');
+        static final String SPECIES_CLASS_PREFIX = BMH_NAME + "$" + 
SPECIES_PREFIX_NAME;

          static final String BMHSPECIES_DATA_EWI_SIG = "(B)" + 
SPECIES_DATA_SIG;
          static final String BMHSPECIES_DATA_GFC_SIG = "(" + JLS_SIG + 
JLC_SIG + ")" + SPECIES_DATA_SIG;


On 4/10/17 5:09 PM, Claes Redestad wrote:
> Hi,
>
> profiling initializers in java.lang.invoke shows we're still doing
> various things during
> class initialization which could be done lazily or not at all. The
> proposed patch
> reduce bytecode executed, memory churn and retained heap footprint when
> initializing java.lang.invoke:
>
> Webrev: http://cr.openjdk.java.net/~redestad/8178384/jdk.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178384
>
> Testing: java.lang.invoke jtreg tests, sanity performance testing
>
> Thanks!
>
> /Claes

From claes.redestad at oracle.com  Mon Apr 10 15:20:10 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 10 Apr 2017 17:20:10 +0200
Subject: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers
In-Reply-To: <e1664d96-265f-6b4f-a320-7ea40d42bb08@oracle.com>
References: <ca7be65a-4246-30f0-6051-05a29296cf15@oracle.com>
 <e1664d96-265f-6b4f-a320-7ea40d42bb08@oracle.com>
Message-ID: <6f3d6678-4f14-0987-415d-9e9a68287fbb@oracle.com>


On 04/10/2017 05:19 PM, Vladimir Ivanov wrote:
> Looks good.

Thanks for reviewing!

>
> One small suggestion [1]

Sure, updated in-place.

/Claes

>
> Best regards,
> Vladimir Ivanov
>
> [1] diff --git 
> a/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java 
> b/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
> --- a/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
> +++ b/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
> @@ -456,6 +456,7 @@
>          static final String MH       = "java/lang/invoke/MethodHandle";
>          static final String MH_SIG   = "L"+MH+";";
>          static final String BMH      = 
> "java/lang/invoke/BoundMethodHandle";
> +        static final String BMH_NAME = 
> "java.lang.invoke.BoundMethodHandle";
>          static final String BMH_SIG  = "L"+BMH+";";
>          static final String SPECIES_DATA     = 
> "java/lang/invoke/BoundMethodHandle$SpeciesData";
>          static final String SPECIES_DATA_SIG = "L"+SPECIES_DATA+";";
> @@ -463,7 +464,7 @@
>
>          static final String SPECIES_PREFIX_NAME = "Species_";
>          static final String SPECIES_PREFIX_PATH = BMH + "$" + 
> SPECIES_PREFIX_NAME;
> -        static final String SPECIES_CLASS_PREFIX = 
> SPECIES_PREFIX_PATH.replace('/', '.');
> +        static final String SPECIES_CLASS_PREFIX = BMH_NAME + "$" + 
> SPECIES_PREFIX_NAME;
>
>          static final String BMHSPECIES_DATA_EWI_SIG = "(B)" + 
> SPECIES_DATA_SIG;
>          static final String BMHSPECIES_DATA_GFC_SIG = "(" + JLS_SIG + 
> JLC_SIG + ")" + SPECIES_DATA_SIG;

From claes.redestad at oracle.com  Mon Apr 10 15:37:34 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 10 Apr 2017 17:37:34 +0200
Subject: [10] RFR: 8178387: Reduce memory churn when creating java.lang.invoke
 entities
Message-ID: <415bf1e3-b612-1c34-8b55-21ba9b2b40a4@oracle.com>

Hi,

another startup optimization for java.lang.invoke, this one collecting a 
set of small fixes I've been wanting to get done for a while, including:

- no need to generate the signature strings in 
BoundMethodHandle.makeCbmhCtor
- trusted MethodType lookups could be promoted without constructing new 
objects
- InvokerBytecodeGenerator: creation of className and sourceFile can be 
done lazily, which reduces String allocations in those cases where 
there's a pre-generated form to be found
- MethodType lookup done twice when looking up pregenerated members (oops!)
- A lot of vararg array creation during startup in various places. A 
larger rewrite could be warranted, but we can some startup gain by 
simply constant-izing oft-used constant arguments such as 
MethodType.invokerType

Webrev: http://cr.openjdk.java.net/~redestad/8178387/jdk.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8178387

Test: java.lang.invoke jtreg tests, verified each change in this patch 
(and JDK-8178384) reduces the amount of bytecode executed during lambda 
bootstrap.

Thanks!

/Claes

From paul.sandoz at oracle.com  Mon Apr 10 16:18:07 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 10 Apr 2017 09:18:07 -0700
Subject: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers
In-Reply-To: <ca7be65a-4246-30f0-6051-05a29296cf15@oracle.com>
References: <ca7be65a-4246-30f0-6051-05a29296cf15@oracle.com>
Message-ID: <7C080227-8B26-4FF2-844D-530E9EEF30C6@oracle.com>

+1

These named functions really wanna be LDC?ed but i suspect using constant dynamic + representation in source (when available) might result in it?s own bootstrap issues, still it would be interesting to try when available.

Paul.

> On 10 Apr 2017, at 07:09, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> profiling initializers in java.lang.invoke shows we're still doing various things during
> class initialization which could be done lazily or not at all. The proposed patch
> reduce bytecode executed, memory churn and retained heap footprint when
> initializing java.lang.invoke:
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8178384/jdk.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178384
> 
> Testing: java.lang.invoke jtreg tests, sanity performance testing
> 
> Thanks!
> 
> /Claes


From forax at univ-mlv.fr  Mon Apr 10 16:32:31 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 10 Apr 2017 16:32:31 +0000
Subject: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers
In-Reply-To: <7C080227-8B26-4FF2-844D-530E9EEF30C6@oracle.com>
References: <ca7be65a-4246-30f0-6051-05a29296cf15@oracle.com>
 <7C080227-8B26-4FF2-844D-530E9EEF30C6@oracle.com>
Message-ID: <9B8481A0-3BFF-4F8C-B69C-C293D9D60547@univ-mlv.fr>

Currently playing with a pattern matching representation for Amber, if think we need a form of array constant that does not require a bootstrap method.
Afaik, an array of any existing constants does not need a Java code to construct itself.

R?mi 


On April 10, 2017 6:18:07 PM GMT+02:00, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>+1
>
>These named functions really wanna be LDC?ed but i suspect using
>constant dynamic + representation in source (when available) might
>result in it?s own bootstrap issues, still it would be interesting to
>try when available.
>
>Paul.
>
>> On 10 Apr 2017, at 07:09, Claes Redestad <claes.redestad at oracle.com>
>wrote:
>> 
>> Hi,
>> 
>> profiling initializers in java.lang.invoke shows we're still doing
>various things during
>> class initialization which could be done lazily or not at all. The
>proposed patch
>> reduce bytecode executed, memory churn and retained heap footprint
>when
>> initializing java.lang.invoke:
>> 
>> Webrev: http://cr.openjdk.java.net/~redestad/8178384/jdk.01/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178384
>> 
>> Testing: java.lang.invoke jtreg tests, sanity performance testing
>> 
>> Thanks!
>> 
>> /Claes

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From paul.sandoz at oracle.com  Mon Apr 10 16:48:05 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 10 Apr 2017 09:48:05 -0700
Subject: [10] RFR: 8178387: Reduce memory churn when creating
 java.lang.invoke entities
In-Reply-To: <415bf1e3-b612-1c34-8b55-21ba9b2b40a4@oracle.com>
References: <415bf1e3-b612-1c34-8b55-21ba9b2b40a4@oracle.com>
Message-ID: <11370D0A-7A7D-4E51-A286-13E1265CFE10@oracle.com>

Hi,

Looks good.

LambdaForm.java
--

 851         MethodType invokerType = methodType();
 852         assert(vmentry == null || vmentry.getMethodType().basicType().equals(invokerType));

?

1183             assert(checkArgumentTypes(arguments, methodType()));

?

1201                 assert(checkArgumentTypes(arguments, methodType()));

I am always wary of removing asserts, do you think these are redundant?


?

From this and the last fixes how much have you cut from the start up time?

Paul.

> On 10 Apr 2017, at 08:37, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> another startup optimization for java.lang.invoke, this one collecting a set of small fixes I've been wanting to get done for a while, including:
> 
> - no need to generate the signature strings in BoundMethodHandle.makeCbmhCtor
> - trusted MethodType lookups could be promoted without constructing new objects
> - InvokerBytecodeGenerator: creation of className and sourceFile can be done lazily, which reduces String allocations in those cases where there's a pre-generated form to be found
> - MethodType lookup done twice when looking up pregenerated members (oops!)
> - A lot of vararg array creation during startup in various places. A larger rewrite could be warranted, but we can some startup gain by simply constant-izing oft-used constant arguments such as MethodType.invokerType
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8178387/jdk.01/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178387
> 
> Test: java.lang.invoke jtreg tests, verified each change in this patch (and JDK-8178384) reduces the amount of bytecode executed during lambda bootstrap.
> 
> Thanks!
> 
> /Claes


From mandy.chung at oracle.com  Mon Apr 10 17:22:26 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 10 Apr 2017 10:22:26 -0700
Subject: Review Request: JDK-8177855:  Clean up legal files
Message-ID: <14133C4B-818D-4192-8A6D-09CED6691F4F@oracle.com>

Webrev:
  http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177855/webrev.00/index.html

The patch is trivial:

diff --git a/src/jdk.xml.bind/share/legal/relaxngdatatype.md b/src/jdk.xml.bind/share/legal/relaxngdatatype.md
--- a/src/jdk.xml.bind/share/legal/relaxngdatatype.md
+++ b/src/jdk.xml.bind/share/legal/relaxngdatatype.md
@@ -3,7 +3,7 @@
 ### RelaxNG Datatype License
 <pre>
 
-Copyright (c) 2001, Thai Open Source Software Center Ltd, Sun Microsystems.
+Copyright (c) 2005, 2010 Thai Open Source Software Center Ltd
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without

diff --git a/src/java.desktop/share/legal/jpeg.md b/src/java.desktop/share/legal/jpeg.md
--- a/src/java.desktop/share/legal/jpeg.md
+++ b/src/java.desktop/share/legal/jpeg.md
@@ -1,4 +1,4 @@
-## JPEG release 6b
+## Independent JPEG Group: JPEG release 6b
 
 ### JPEG License
 <pre>
diff --git a/src/jdk.crypto.ec/share/legal/ecc.md b/src/jdk.crypto.ec/share/legal/ecc.md
--- a/src/jdk.crypto.ec/share/legal/ecc.md
+++ b/src/jdk.crypto.ec/share/legal/ecc.md
@@ -6,7 +6,8 @@
 This notice is provided with respect to Elliptic Curve Cryptography,
 which is included with JRE, JDK, and OpenJDK.
 
-You are receiving a copy of the Elliptic Curve Cryptography library in source
+You are receiving a [copy](http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/bd00098fc2d7/src/jdk.crypto.ec/share/native/libsunec/impl)
+of the Elliptic Curve Cryptography library in source
 form with the JDK and OpenJDK source distributions, and as object code in
 the JRE & JDK runtimes.
 



From claes.redestad at oracle.com  Mon Apr 10 17:31:16 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 10 Apr 2017 19:31:16 +0200
Subject: [10] RFR: 8178387: Reduce memory churn when creating
 java.lang.invoke entities
In-Reply-To: <11370D0A-7A7D-4E51-A286-13E1265CFE10@oracle.com>
References: <415bf1e3-b612-1c34-8b55-21ba9b2b40a4@oracle.com>
 <11370D0A-7A7D-4E51-A286-13E1265CFE10@oracle.com>
Message-ID: <6ca9480e-8def-d80b-7de0-2450e3ff9df7@oracle.com>

Hi,


On 2017-04-10 18:48, Paul Sandoz wrote:
> Hi,
>
> Looks good.

Thanks!

>
> LambdaForm.java
> --
>
>   851         MethodType invokerType = methodType();
>   852         assert(vmentry == null || vmentry.getMethodType().basicType().equals(invokerType));

This one was accidentally removed, will put it back (without the local 
invokerType var).

>
> ?
>
> 1183             assert(checkArgumentTypes(arguments, methodType()));
>
> ?
>
> 1201                 assert(checkArgumentTypes(arguments, methodType()));

The checkArgumentTypes method has been shortcutted for quite some time 
(if (true) return true;),
so the asserts aren't doing anything but making -Xcomp tests run slower 
and emit a lot of warnings
in my IDE.

>
> I am always wary of removing asserts, do you think these are redundant?
>
>
> ?
>
>  From this and the last fixes how much have you cut from the start up time?

Don't expect too much! These two add up to about ~60k fewer bytecode 
executed to bootstrap j.l.invoke
and run a trivial lambda, which is about 13% of the total and shows up 
as around or somewhat less than a
millisecond improvement on my machine (out of the ~19-20ms it now takes 
to bootstrap and execute the
first lambda on my machine).

Thanks!

/Claes

>
> Paul.
>
>> On 10 Apr 2017, at 08:37, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Hi,
>>
>> another startup optimization for java.lang.invoke, this one collecting a set of small fixes I've been wanting to get done for a while, including:
>>
>> - no need to generate the signature strings in BoundMethodHandle.makeCbmhCtor
>> - trusted MethodType lookups could be promoted without constructing new objects
>> - InvokerBytecodeGenerator: creation of className and sourceFile can be done lazily, which reduces String allocations in those cases where there's a pre-generated form to be found
>> - MethodType lookup done twice when looking up pregenerated members (oops!)
>> - A lot of vararg array creation during startup in various places. A larger rewrite could be warranted, but we can some startup gain by simply constant-izing oft-used constant arguments such as MethodType.invokerType
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8178387/jdk.01/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178387
>>
>> Test: java.lang.invoke jtreg tests, verified each change in this patch (and JDK-8178384) reduces the amount of bytecode executed during lambda bootstrap.
>>
>> Thanks!
>>
>> /Claes


From paul.sandoz at oracle.com  Mon Apr 10 17:41:31 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 10 Apr 2017 10:41:31 -0700
Subject: [10] RFR: 8178387: Reduce memory churn when creating
 java.lang.invoke entities
In-Reply-To: <6ca9480e-8def-d80b-7de0-2450e3ff9df7@oracle.com>
References: <415bf1e3-b612-1c34-8b55-21ba9b2b40a4@oracle.com>
 <11370D0A-7A7D-4E51-A286-13E1265CFE10@oracle.com>
 <6ca9480e-8def-d80b-7de0-2450e3ff9df7@oracle.com>
Message-ID: <60202B50-73C5-4061-AD2B-CDCC3B31BEF8@oracle.com>


> On 10 Apr 2017, at 10:31, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> 
> On 2017-04-10 18:48, Paul Sandoz wrote:
>> Hi,
>> 
>> Looks good.
> 
> Thanks!
> 
>> 
>> LambdaForm.java
>> --
>> 
>>  851         MethodType invokerType = methodType();
>>  852         assert(vmentry == null || vmentry.getMethodType().basicType().equals(invokerType));
> 
> This one was accidentally removed, will put it back (without the local invokerType var).
> 

Ok.


>> 
>> ?
>> 
>> 1183             assert(checkArgumentTypes(arguments, methodType()));
>> 
>> ?
>> 
>> 1201                 assert(checkArgumentTypes(arguments, methodType()));
> 
> The checkArgumentTypes method has been shortcutted for quite some time (if (true) return true;),
> so the asserts aren't doing anything but making -Xcomp tests run slower and emit a lot of warnings
> in my IDE.
> 

Ok.


>> 
>> I am always wary of removing asserts, do you think these are redundant?
>> 
>> 
>> ?
>> 
>> From this and the last fixes how much have you cut from the start up time?
> 
> Don't expect too much! These two add up to about ~60k fewer bytecode executed to bootstrap j.l.invoke
> and run a trivial lambda, which is about 13% of the total and shows up as around or somewhat less than a
> millisecond improvement on my machine (out of the ~19-20ms it now takes to bootstrap and execute the
> first lambda on my machine).
> 

Keep chipping away, every bit helps :-)

Separately, i am curious how much GC activity occurs at startup before the main method is called. Would it be possible to overlay hotspot activity on the Java flame graph?

Paul.

From Alan.Bateman at oracle.com  Mon Apr 10 17:57:35 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 10 Apr 2017 18:57:35 +0100
Subject: Review Request: JDK-8177855: Clean up legal files
In-Reply-To: <14133C4B-818D-4192-8A6D-09CED6691F4F@oracle.com>
References: <14133C4B-818D-4192-8A6D-09CED6691F4F@oracle.com>
Message-ID: <cf3bfefb-15ec-3215-bebe-18fd699b1412@oracle.com>



On 10/04/2017 18:22, Mandy Chung wrote:
> Webrev:
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177855/webrev.00/index.html
This looks okay to me.

-Alan

From claes.redestad at oracle.com  Mon Apr 10 18:00:39 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 10 Apr 2017 20:00:39 +0200
Subject: [10] RFR: 8178387: Reduce memory churn when creating
 java.lang.invoke entities
In-Reply-To: <60202B50-73C5-4061-AD2B-CDCC3B31BEF8@oracle.com>
References: <415bf1e3-b612-1c34-8b55-21ba9b2b40a4@oracle.com>
 <11370D0A-7A7D-4E51-A286-13E1265CFE10@oracle.com>
 <6ca9480e-8def-d80b-7de0-2450e3ff9df7@oracle.com>
 <60202B50-73C5-4061-AD2B-CDCC3B31BEF8@oracle.com>
Message-ID: <3f9e24fc-0796-dd43-9500-af7b9bee106a@oracle.com>



On 2017-04-10 19:41, Paul Sandoz wrote:
>> On 10 Apr 2017, at 10:31, Claes Redestad <claes.redestad at oracle.com> wrote:
>> Don't expect too much! These two add up to about ~60k fewer bytecode executed to bootstrap j.l.invoke
>> and run a trivial lambda, which is about 13% of the total and shows up as around or somewhat less than a
>> millisecond improvement on my machine (out of the ~19-20ms it now takes to bootstrap and execute the
>> first lambda on my machine).
>>
> Keep chipping away, every bit helps :-)
>
> Separately, i am curious how much GC activity occurs at startup before the main method is called. Would it be possible to overlay hotspot activity on the Java flame graph?

Depends on the GC and initial heap sizes, but on the small tests I'm 
looking at, G1 has typically not even started a concurrent cycle, so choice
of GC doesn't matter that much... (G1 has some minor issues shutting 
down promptly - seeing delays of up to 15ms to get all theads to realize
they should stop what they're doing - which causes some headache though)

... on the other hand I'm seeing a lot of noise on my 2-socket 
workstation when not pinning to a single socket, that appears to come 
from JIT
threads *and* the main java thread spending more time. My best guess 
right now is some interaction between interpreter and JIT threads,
possibly some contention/sharing effects when installing compiled 
methods, and have been starting to ask around for someone who can give
me a tour through that code to investigate deeper... :-)

W.r.t. overlaying native and java flame graphs then it's quite easy to 
generate native-only and java-only startup graphs separately, but 
surprisingly(?)
hard to create something mixed that capture what happens during the 
earliest bootstrap with any precision. There's some wonderful work out 
there
using agents to map JIT disassembly to perf output and such, but I'm not 
sure it's feasible to use that approach to see what's happening during
interpreter-heavy/warmup phases.

Thanks!

/Claes



From joe.darcy at oracle.com  Mon Apr 10 18:03:28 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 10 Apr 2017 11:03:28 -0700
Subject: Review Request: JDK-8177855: Clean up legal files
In-Reply-To: <14133C4B-818D-4192-8A6D-09CED6691F4F@oracle.com>
References: <14133C4B-818D-4192-8A6D-09CED6691F4F@oracle.com>
Message-ID: <02239ed1-ff5e-7445-2cbd-747d0def45ac@oracle.com>

Hello,

Would it be better for the for the URL

(http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/bd00098fc2d7/src/jdk.crypto.ec/share/native/libsunec/impl)

to use "tip"

(http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/jdk.crypto.ec/share/native/libsunec/impl)

Cheers,

-Joe


On 4/10/2017 10:22 AM, Mandy Chung wrote:
> Webrev:
>    http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177855/webrev.00/index.html
>
> The patch is trivial:
>
> diff --git a/src/jdk.xml.bind/share/legal/relaxngdatatype.md b/src/jdk.xml.bind/share/legal/relaxngdatatype.md
> --- a/src/jdk.xml.bind/share/legal/relaxngdatatype.md
> +++ b/src/jdk.xml.bind/share/legal/relaxngdatatype.md
> @@ -3,7 +3,7 @@
>   ### RelaxNG Datatype License
>   <pre>
>   
> -Copyright (c) 2001, Thai Open Source Software Center Ltd, Sun Microsystems.
> +Copyright (c) 2005, 2010 Thai Open Source Software Center Ltd
>   All rights reserved.
>   
>   Redistribution and use in source and binary forms, with or without
>
> diff --git a/src/java.desktop/share/legal/jpeg.md b/src/java.desktop/share/legal/jpeg.md
> --- a/src/java.desktop/share/legal/jpeg.md
> +++ b/src/java.desktop/share/legal/jpeg.md
> @@ -1,4 +1,4 @@
> -## JPEG release 6b
> +## Independent JPEG Group: JPEG release 6b
>   
>   ### JPEG License
>   <pre>
> diff --git a/src/jdk.crypto.ec/share/legal/ecc.md b/src/jdk.crypto.ec/share/legal/ecc.md
> --- a/src/jdk.crypto.ec/share/legal/ecc.md
> +++ b/src/jdk.crypto.ec/share/legal/ecc.md
> @@ -6,7 +6,8 @@
>   This notice is provided with respect to Elliptic Curve Cryptography,
>   which is included with JRE, JDK, and OpenJDK.
>   
> -You are receiving a copy of the Elliptic Curve Cryptography library in source
> +You are receiving a [copy](http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/bd00098fc2d7/src/jdk.crypto.ec/share/native/libsunec/impl)
> +of the Elliptic Curve Cryptography library in source
>   form with the JDK and OpenJDK source distributions, and as object code in
>   the JRE & JDK runtimes.
>   
>
>


From mandy.chung at oracle.com  Mon Apr 10 18:04:34 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 10 Apr 2017 11:04:34 -0700
Subject: Review Request: JDK-8177855: Clean up legal files
In-Reply-To: <02239ed1-ff5e-7445-2cbd-747d0def45ac@oracle.com>
References: <14133C4B-818D-4192-8A6D-09CED6691F4F@oracle.com>
 <02239ed1-ff5e-7445-2cbd-747d0def45ac@oracle.com>
Message-ID: <F9E7FE82-532D-408E-A864-B311680A5DC0@oracle.com>

I think so.  Will fix before push.

Mandy

> On Apr 10, 2017, at 11:03 AM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Would it be better for the for the URL
> 
> (http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/bd00098fc2d7/src/jdk.crypto.ec/share/native/libsunec/impl)
> 
> to use "tip"
> 
> (http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/jdk.crypto.ec/share/native/libsunec/impl)
> 
> Cheers,
> 
> -Joe
> 
> 
> On 4/10/2017 10:22 AM, Mandy Chung wrote:
>> Webrev:
>>   http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177855/webrev.00/index.html
>> 
>> The patch is trivial:
>> 
>> diff --git a/src/jdk.xml.bind/share/legal/relaxngdatatype.md b/src/jdk.xml.bind/share/legal/relaxngdatatype.md
>> --- a/src/jdk.xml.bind/share/legal/relaxngdatatype.md
>> +++ b/src/jdk.xml.bind/share/legal/relaxngdatatype.md
>> @@ -3,7 +3,7 @@
>>  ### RelaxNG Datatype License
>>  <pre>
>>  -Copyright (c) 2001, Thai Open Source Software Center Ltd, Sun Microsystems.
>> +Copyright (c) 2005, 2010 Thai Open Source Software Center Ltd
>>  All rights reserved.
>>    Redistribution and use in source and binary forms, with or without
>> 
>> diff --git a/src/java.desktop/share/legal/jpeg.md b/src/java.desktop/share/legal/jpeg.md
>> --- a/src/java.desktop/share/legal/jpeg.md
>> +++ b/src/java.desktop/share/legal/jpeg.md
>> @@ -1,4 +1,4 @@
>> -## JPEG release 6b
>> +## Independent JPEG Group: JPEG release 6b
>>    ### JPEG License
>>  <pre>
>> diff --git a/src/jdk.crypto.ec/share/legal/ecc.md b/src/jdk.crypto.ec/share/legal/ecc.md
>> --- a/src/jdk.crypto.ec/share/legal/ecc.md
>> +++ b/src/jdk.crypto.ec/share/legal/ecc.md
>> @@ -6,7 +6,8 @@
>>  This notice is provided with respect to Elliptic Curve Cryptography,
>>  which is included with JRE, JDK, and OpenJDK.
>>  -You are receiving a copy of the Elliptic Curve Cryptography library in source
>> +You are receiving a [copy](http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/bd00098fc2d7/src/jdk.crypto.ec/share/native/libsunec/impl)
>> +of the Elliptic Curve Cryptography library in source
>>  form with the JDK and OpenJDK source distributions, and as object code in
>>  the JRE & JDK runtimes.
>>  
>> 
> 


From sergey.kuksenko at oracle.com  Mon Apr 10 18:43:23 2017
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Mon, 10 Apr 2017 11:43:23 -0700
Subject: JDK 10 RFR of 8176894: Provide specialized implementation for
 default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute in
 TreeMap
In-Reply-To: <ff8b4577-8999-9afe-4597-19bba3ff2568@oracle.com>
References: <048a8a8d-20ac-4d32-1b49-244e85afdfd5@oracle.com>
 <CA+kOe0-6r+e74UxYZKX=q_DYYEKQpyMtn53dxqj=3UWBCfm4FQ@mail.gmail.com>
 <507d83cf-2334-303a-1ae3-2bb8b1e9bd4c@oracle.com>
 <75959b26-9023-c662-bfda-87860a614a2c@oracle.com>
 <ff8b4577-8999-9afe-4597-19bba3ff2568@oracle.com>
Message-ID: <d7e2ffdc-814c-8eb5-63c7-2496b84a0a45@oracle.com>

Hi Claes,

There is no need to backport it to 8 & 9. 8 & 9 uses default 
implementation, which is free from such tree corruption issue.


On 04/06/2017 03:45 AM, Claes Redestad wrote:
> Hi Sergey,
>
> this looks good to me*, but I can't help wonder if the modCount 
> checking is something that should be done separately as a bug fix 
> (with a higher priority) and be backported to 8 and 9? Alternatively 
> re-categorize this fix as such.
>
> Thanks!
>
> /Claes
>
> * I wouldn't mind seeing the cleanup Martin suggested, i.e., write the 
> remapValue as:
>
>     private V remapValue(Entry<K, V> t, K key, BiFunction<? super K, ? 
> super V, ? extends V> remappingFunction) {
>         V newValue = remappingFunction.apply(key, t.value);
>         if (newValue == null) {
>             deleteEntry(t);
>         } else {
>             // replace old mapping
>             t.value = newValue;
>         }
>         return newValue;
>      }
>
> On 2017-03-28 21:22, Sergey Kuksenko wrote:
>> Friendly reminder.
>>
>> Have you have chance to review the latest version?
>>
>>
>> On 03/17/2017 12:45 PM, Sergey Kuksenko wrote:
>>> Hi, All.
>>>
>>> I realized (thanks Tagir V.) that if we don't check modCount after 
>>> calling mapping function we may get corrupted tree structure.
>>> new webrev for review:
>>> http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.01/
>>>
>>> On 03/17/2017 11:29 AM, Martin Buchholz wrote:
>>>> Thanks!  This looks pretty good.  I have a similar effort in 
>>>> progress to improve bulk collection operations, most of which made 
>>>> it into jdk9.
>>>>
>>>> ---
>>>>
>>>> Please use standard java.util whitespace, as Aleksey suggested.
>>>>
>>>> ---
>>>>
>>>> Below (and in compute) I wpuld simply
>>>> return newValue;
>>>> saving a line of code and making it clearer that we are returning 
>>>> the result of the remappingFunction
>>>>
>>>>  676     private V remapValue(Entry<K, V> t, K key, BiFunction<? 
>>>> super K, ? super V, ? extends V> remappingFunction) {
>>>>  677         V newValue = remappingFunction.apply(key, t.value);
>>>>  678         if (newValue == null) {
>>>>  679             deleteEntry(t);
>>>>  680             return null;
>>>>  681         } else {
>>>>  682             // replace old mapping
>>>>  683             t.value = newValue;
>>>>  684             return newValue;
>>>>  685         }
>>>>  686     }
>>>> ---
>>>>
>>>> This code is surely tested but testing could also surely be 
>>>> improved.  That's probably not your job though (it may be mine!)
>>>>
>>>> I would probably try hand-injecting some bugs into a copy of the 
>>>> code and seeing if our jtreg tests catch it, to increase coverage 
>>>> confidence.
>>>>
>>>>
>>>> On Thu, Mar 16, 2017 at 12:04 PM, Sergey Kuksenko 
>>>> <sergey.kuksenko at oracle.com <mailto:sergey.kuksenko at oracle.com>> 
>>>> wrote:
>>>>
>>>>     Hi All,
>>>>
>>>>     Please, review:
>>>>     https://bugs.openjdk.java.net/browse/JDK-8176894
>>>>     <https://bugs.openjdk.java.net/browse/JDK-8176894>
>>>> http://cr.openjdk.java.net/~skuksenko/corelibs/utils/8176894/webrev.00/ 
>>>>
>>>> <http://cr.openjdk.java.net/%7Eskuksenko/corelibs/utils/8176894/webrev.00/> 
>>>>
>>>>
>>>>     The issue was created for JDK10 in order to don't disturb JDK9
>>>>     before launch.
>>>>
>>>>     --     Best regards,
>>>>     Sergey Kuksenko
>>>>
>>>>
>>>
>>
>

-- 
Best regards,
Sergey Kuksenko


From claes.redestad at oracle.com  Mon Apr 10 18:50:42 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 10 Apr 2017 20:50:42 +0200
Subject: JDK 10 RFR of 8176894: Provide specialized implementation for
 default methods putIfAbsent, computeIfAbsent, computeIfPresent, compute in
 TreeMap
In-Reply-To: <d7e2ffdc-814c-8eb5-63c7-2496b84a0a45@oracle.com>
References: <048a8a8d-20ac-4d32-1b49-244e85afdfd5@oracle.com>
 <CA+kOe0-6r+e74UxYZKX=q_DYYEKQpyMtn53dxqj=3UWBCfm4FQ@mail.gmail.com>
 <507d83cf-2334-303a-1ae3-2bb8b1e9bd4c@oracle.com>
 <75959b26-9023-c662-bfda-87860a614a2c@oracle.com>
 <ff8b4577-8999-9afe-4597-19bba3ff2568@oracle.com>
 <d7e2ffdc-814c-8eb5-63c7-2496b84a0a45@oracle.com>
Message-ID: <5295622c-940f-486d-4e5d-d24fbd3a804c@oracle.com>

On 2017-04-10 20:43, Sergey Kuksenko wrote:
> Hi Claes,
>
> There is no need to backport it to 8 & 9. 8 & 9 uses default 
> implementation, which is free from such tree corruption issue. 

Ah, I misread the situation then, sorry for the noise.

/Claes

From Roger.Riggs at Oracle.com  Mon Apr 10 19:17:07 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 10 Apr 2017 15:17:07 -0400
Subject: [9] RFR 8177969: Faster FilePermission::implies by avoiding the
 use of Path::relativize
In-Reply-To: <bf713720-eec4-d893-65a4-75465a71703a@oracle.com>
References: <4f1e0c02-a11d-2694-84ad-cf8804021f3c@oracle.com>
 <9f96ed4d-9282-d776-f767-d3fe060ba895@Oracle.com>
 <de22e3da-cca4-5730-607f-5a75f69b9f06@oracle.com>
 <b1e4428e-ab5a-af85-e3e9-349fe3476c78@oracle.com>
 <769a4646-7f6b-5a17-8671-8333cb7042b1@oracle.com>
 <bf713720-eec4-d893-65a4-75465a71703a@oracle.com>
Message-ID: <7123db7f-e4b1-d6f2-2876-9e56702aa4c7@Oracle.com>

+1, looks good.

Thanks, Roger


On 4/10/2017 10:08 AM, Sean Mullan wrote:
> The updated webrev looks good.
>
> Thanks,
> Sean
>
> On 4/7/17 8:39 PM, Weijun Wang wrote:
>> Webrev updated at
>>
>>   http://cr.openjdk.java.net/~weijun/8177969/webrev.02/
>>
>> Changes since webrev.01:
>>
>> 1. Comments.
>>
>> 2. Another enhancement when I am writing comments. Since we can be sure
>> that a path has no ".." by only looking at its head, we can also be sure
>> that a path is all ".." by only looking at its tail.
>>
>> JPRT core+jaxp runs fine. JCK tests run fine.
>>
>> Now benchmark result (after adjusting the granted permission to
>> "../../../../-") is:
>>
>> Benchmark                         Mode  Cnt       Score Error  Units
>> checkReadNewUnfixed  thrpt   15  174963.698 ?  5952.239  ops/s
>> checkReadNewFixed00  thrpt   15  417692.698 ? 24994.735  ops/s
>> checkReadNewFixed02  thrpt   15  447824.218 ? 20199.194  ops/s
>> checkReadOld200      thrpt   15  425353.705 ?  3546.411  ops/s
>> checkReadOld201      thrpt   15    2045.070 ?    57.287  ops/s
>>
>> This time checkReadNewFixed02 looks even better than checkReadOld200
>> running on jdk8u131. I dare not run it again. :-)
>>
>> Thanks
>> Max
>>
>> On 04/08/2017 04:48 AM, Sean Mullan wrote:
>>> This fix looks good to me. However, I would suggest adding some
>>> additional comments to the body of the containsPath method explaining
>>> what it is doing so that it is easier to understand.
>>>
>>> --Sean
>>>
>>> On 4/7/17 10:50 AM, Weijun Wang wrote:
>>>> Webrev updated at
>>>>
>>>>    http://cr.openjdk.java.net/~weijun/8177969/webrev.01/
>>>>
>>>> Changes since webrev.00 [1]
>>>>
>>>> 1. Copyright years.
>>>>
>>>> 2. Test fix. check() should include Windows drive tests like 
>>>> contains()
>>>> does.
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>> [1]
>>>> http://cr.openjdk.java.net/~weijun/8177969/webrev.01/interdiff.patch.html 
>>>>
>>>>
>>>>
>>>> On 04/05/2017 10:13 PM, Roger Riggs wrote:
>>>>> Hi Max,
>>>>>
>>>>> The code looks ok.
>>>>>
>>>>> How much faster does it make FilePermission compares?
>>>>>
>>>>> I assume if it is not accepted to be fixed in JDK 9, you will push
>>>>> it to
>>>>> JDK 10.
>>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>> On 4/3/2017 11:30 AM, Weijun Wang wrote:
>>>>>> http://cr.openjdk.java.net/~weijun/8177969/webrev.00/
>>>>>>
>>>>>> This new implementation of containsPath(Path,Path) uses the logic of
>>>>>> Path::relativize without directly calling it, which is much faster
>>>>>> now.
>>>>>>
>>>>>> Thanks
>>>>>> Max
>>>>>


From martinrb at google.com  Mon Apr 10 21:19:23 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 10 Apr 2017 14:19:23 -0700
Subject: RFR: jsr166 jdk10 integration wave 1
In-Reply-To: <CA+kOe09yVTUQVzdLkxqwMwEZmGB9P2GZdF=8iEeZ6U9wcCCvQw@mail.gmail.com>
References: <CA+kOe0-0fDs7w=Pt95Rc6LKPJOFCdcGfuAh2BZoQm6A9-jdWmw@mail.gmail.com>
 <CA+kOe08=CkCFAhD03dO53WB29N4i5t2V2ErerZ9T+7e2C2bPOg@mail.gmail.com>
 <CA+kOe08uSpzDZM7Shxf2NDM0GhzK3A9dNf5s0=UcvuhEGN3hjw@mail.gmail.com>
 <F3FBAB56-C286-44C9-9FC2-6C34FC6FFCC8@oracle.com>
 <CA+kOe09yVTUQVzdLkxqwMwEZmGB9P2GZdF=8iEeZ6U9wcCCvQw@mail.gmail.com>
Message-ID: <CA+kOe08tivHs_SGJdZUuXaHZ59CY61WjFHw-Cgz0HgeeRDnUCA@mail.gmail.com>

Non-thread-pool changes committed while we wait for thread-pool CCC.

From igor.ignatyev at oracle.com  Mon Apr 10 22:42:04 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 10 Apr 2017 15:42:04 -0700
Subject: RFR(XS) : 8178340: remove unneeded "throws" from
 ProcessTools::createJavaProcessBuilder
Message-ID: <30D206D1-8044-4205-A687-26AF48784FAC@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8178340/webrev.00/index.html
> 8 lines changed: 0 ins; 2 del; 6 mod; 
Hi all,

could you please review this tiny fix which clean up testlibary?

ProcessTools::createJavaProcessBuilder methods can not throw any checked exceptions, but were declared with 'throws Exception', which forced all users of these methods to either have redundant try-catch or throws. the fix cleans up the method declaration in all three copies of testlibary. 

webrev: http://cr.openjdk.java.net/~iignatyev//8178340/webrev.00/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8178340
testing: hotspot, jdk, langtools and jaxp tests

Thanks,
-- Igor


From amy.lu at oracle.com  Tue Apr 11 02:15:49 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 11 Apr 2017 10:15:49 +0800
Subject: JDK 9 RFR of JDK-8169971:
 tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java fails
 intermittently
Message-ID: <2cd4bae2-03d0-a097-1977-45a4228ae77d@oracle.com>

Please review this test-only change.

tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java

This test fails intermittently on Windows platform in the final cleanup 
step, @AfterClass, in which test tries to delete all dirs and files it 
created. Though it?s okay to leave this cleanup work to jtreg, I still 
make it done in test by making test to create everything under 
./testoutput (testdir), and delete this testdir directly with 
FileUtils.deleteFileTreeWithRetry(testdir).

Moreover, in FileUtils, as it tries to delete path with retry, we might 
want to give it a chance to "retry" in case of DirectoryNotEmptyException.

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

Thanks,
Amy


From david.holmes at oracle.com  Tue Apr 11 07:04:38 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 11 Apr 2017 17:04:38 +1000
Subject: RFR(XS) : 8178340: remove unneeded "throws" from
 ProcessTools::createJavaProcessBuilder
In-Reply-To: <30D206D1-8044-4205-A687-26AF48784FAC@oracle.com>
References: <30D206D1-8044-4205-A687-26AF48784FAC@oracle.com>
Message-ID: <b6a505ac-9be7-006b-812d-964b901de0a1@oracle.com>

Hi Igor,

This looks fine to me.

I was a little concerned any tests with a try/catch around these calls 
would fail to compile due to exception checking, but class Exception is 
exempt from that checking.

Thanks,
David

On 11/04/2017 8:42 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8178340/webrev.00/index.html
>> 8 lines changed: 0 ins; 2 del; 6 mod;
> Hi all,
>
> could you please review this tiny fix which clean up testlibary?
>
> ProcessTools::createJavaProcessBuilder methods can not throw any checked exceptions, but were declared with 'throws Exception', which forced all users of these methods to either have redundant try-catch or throws. the fix cleans up the method declaration in all three copies of testlibary.
>
> webrev: http://cr.openjdk.java.net/~iignatyev//8178340/webrev.00/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8178340
> testing: hotspot, jdk, langtools and jaxp tests
>
> Thanks,
> -- Igor
>

From claes.redestad at oracle.com  Tue Apr 11 08:37:45 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 11 Apr 2017 10:37:45 +0200
Subject: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers
In-Reply-To: <9B8481A0-3BFF-4F8C-B69C-C293D9D60547@univ-mlv.fr>
References: <ca7be65a-4246-30f0-6051-05a29296cf15@oracle.com>
 <7C080227-8B26-4FF2-844D-530E9EEF30C6@oracle.com>
 <9B8481A0-3BFF-4F8C-B69C-C293D9D60547@univ-mlv.fr>
Message-ID: <fca32ec9-ff9a-cb2f-58dd-d4f90ff598d5@oracle.com>

Sounds like you want https://bugs.openjdk.java.net/browse/JDK-8061402 - 
which was originally filed back in 2002 but was closed since it got 
filed on the wrong component or something... ?\_(?)_/?

There's still a number of char[] foo = "FOO".toCharArray() in the JDK 
since this allows for a more compact representation in bytecode (but is 
likely a bit slower during startup, especially since compact strings).

/Claes

On 04/10/2017 06:32 PM, Remi Forax wrote:
> Currently playing with a pattern matching representation for Amber, if 
> think we need a form of array constant that does not require a 
> bootstrap method.
> Afaik, an array of any existing constants does not need a Java code to 
> construct itself.
>
> R?mi
>
>
> On April 10, 2017 6:18:07 PM GMT+02:00, Paul Sandoz 
> <paul.sandoz at oracle.com> wrote:
>
>     +1
>
>     These named functions really wanna be LDC?ed but i suspect using constant dynamic + representation in source (when available) might result in it?s own bootstrap issues, still it would be interesting to try when available.
>
>     Paul.
>
>         On 10 Apr 2017, at 07:09, Claes Redestad
>         <claes.redestad at oracle.com> wrote: Hi, profiling initializers
>         in java.lang.invoke shows we're still doing various things
>         during class initialization which could be done lazily or not
>         at all. The proposed patch reduce bytecode executed, memory
>         churn and retained heap footprint when initializing
>         java.lang.invoke: Webrev:
>         http://cr.openjdk.java.net/~redestad/8178384/jdk.01
>         <http://cr.openjdk.java.net/%7Eredestad/8178384/jdk.01>/ Bug:
>         https://bugs.openjdk.java.net/browse/JDK-8178384 Testing:
>         java.lang.invoke jtreg tests, sanity performance testing
>         Thanks! /Claes 
>
>
>
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity. 


From claes.redestad at oracle.com  Tue Apr 11 09:06:42 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 11 Apr 2017 11:06:42 +0200
Subject: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers
In-Reply-To: <6f3d6678-4f14-0987-415d-9e9a68287fbb@oracle.com>
References: <ca7be65a-4246-30f0-6051-05a29296cf15@oracle.com>
 <e1664d96-265f-6b4f-a320-7ea40d42bb08@oracle.com>
 <6f3d6678-4f14-0987-415d-9e9a68287fbb@oracle.com>
Message-ID: <bc56837b-3cd3-09ef-b017-14a309f8f7b7@oracle.com>



On 04/10/2017 05:20 PM, Claes Redestad wrote:
>
> On 04/10/2017 05:19 PM, Vladimir Ivanov wrote:
>> Looks good.
>
> Thanks for reviewing!
>
>>
>> One small suggestion [1]
>
> Sure, updated in-place.

Taking a second look at these constants, it turned out that a few of 
them were unused, but since they
weren't private this wasn't called out in my IDE.  Mind if I clean this 
up (add private modifier, remove
unused JLS_SIG, JLC_SIG, BMHSPECIES_DATA_GFC_SIG, VOID_SIG) as part of 
this patch?

I've verified none of the remaining constants are used anywhere outside 
the class, i.e., no synthetic
accessor methods are added by this refactoring.

Thanks!

/Claes

diff -r 524eb921da04 
src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
--- 
a/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java 
Tue Apr 11 10:51:05 2017 +0200
+++ 
b/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java 
Tue Apr 11 11:01:22 2017 +0200
@@ -450,33 +450,29 @@
       */
      static class Factory {

-        static final String JLO_SIG  = "Ljava/lang/Object;";
-        static final String JLS_SIG  = "Ljava/lang/String;";
-        static final String JLC_SIG  = "Ljava/lang/Class;";
-        static final String MH       = "java/lang/invoke/MethodHandle";
-        static final String MH_SIG   = "L"+MH+";";
-        static final String BMH      = 
"java/lang/invoke/BoundMethodHandle";
-        static final String BMH_NAME = 
"java.lang.invoke.BoundMethodHandle";
-        static final String BMH_SIG  = "L"+BMH+";";
-        static final String SPECIES_DATA     = 
"java/lang/invoke/BoundMethodHandle$SpeciesData";
-        static final String SPECIES_DATA_SIG = "L"+SPECIES_DATA+";";
-        static final String STABLE_SIG       = 
"Ljdk/internal/vm/annotation/Stable;";
+        private static final String JLO_SIG  = "Ljava/lang/Object;";
+        private static final String MH       = 
"java/lang/invoke/MethodHandle";
+        private static final String MH_SIG   = "L"+MH+";";
+        private static final String BMH      = 
"java/lang/invoke/BoundMethodHandle";
+        private static final String BMH_NAME = 
"java.lang.invoke.BoundMethodHandle";
+        private static final String BMH_SIG  = "L"+BMH+";";
+        private static final String SPECIES_DATA     = 
"java/lang/invoke/BoundMethodHandle$SpeciesData";
+        private static final String SPECIES_DATA_SIG = 
"L"+SPECIES_DATA+";";
+        private static final String STABLE_SIG       = 
"Ljdk/internal/vm/annotation/Stable;";

-        static final String SPECIES_PREFIX_NAME = "Species_";
-        static final String SPECIES_PREFIX_PATH = BMH + "$" + 
SPECIES_PREFIX_NAME;
-        static final String SPECIES_CLASS_PREFIX = BMH_NAME + "$" + 
SPECIES_PREFIX_NAME;
+        private static final String SPECIES_PREFIX_NAME = "Species_";
+        private static final String SPECIES_PREFIX_PATH = BMH + "$" + 
SPECIES_PREFIX_NAME;
+        private static final String SPECIES_CLASS_PREFIX = BMH_NAME + 
"$" + SPECIES_PREFIX_NAME;

-        static final String BMHSPECIES_DATA_EWI_SIG = "(B)" + 
SPECIES_DATA_SIG;
-        static final String BMHSPECIES_DATA_GFC_SIG = "(" + JLS_SIG + 
JLC_SIG + ")" + SPECIES_DATA_SIG;
-        static final String MYSPECIES_DATA_SIG = "()" + SPECIES_DATA_SIG;
-        static final String VOID_SIG   = "()V";
-        static final String INT_SIG    = "()I";
+        private static final String BMHSPECIES_DATA_EWI_SIG = "(B)" + 
SPECIES_DATA_SIG;
+        private static final String MYSPECIES_DATA_SIG = "()" + 
SPECIES_DATA_SIG;
+        private static final String INT_SIG    = "()I";

-        static final String SIG_INCIPIT = 
"(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;";
+        private static final String SIG_INCIPIT = 
"(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;";

-        static final String[] E_THROWABLE = new String[] { 
"java/lang/Throwable" };
+        private static final String[] E_THROWABLE = new String[] { 
"java/lang/Throwable" };

-        static final ConcurrentMap<String, Class<? extends 
BoundMethodHandle>> CLASS_CACHE = new ConcurrentHashMap<>();
+        private static final ConcurrentMap<String, Class<? extends 
BoundMethodHandle>> CLASS_CACHE = new ConcurrentHashMap<>();

          /**
           * Get a concrete subclass of BMH for a given combination of 
bound types.


>
> /Claes


From vladimir.x.ivanov at oracle.com  Tue Apr 11 09:16:11 2017
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 11 Apr 2017 12:16:11 +0300
Subject: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers
In-Reply-To: <bc56837b-3cd3-09ef-b017-14a309f8f7b7@oracle.com>
References: <ca7be65a-4246-30f0-6051-05a29296cf15@oracle.com>
 <e1664d96-265f-6b4f-a320-7ea40d42bb08@oracle.com>
 <6f3d6678-4f14-0987-415d-9e9a68287fbb@oracle.com>
 <bc56837b-3cd3-09ef-b017-14a309f8f7b7@oracle.com>
Message-ID: <6dcde0d7-3a16-2ee6-e92b-5e36b0e8bcd0@oracle.com>

Reviewed.

Best regards,
Vladimir Ivanov

On 4/11/17 12:06 PM, Claes Redestad wrote:
>
>
> On 04/10/2017 05:20 PM, Claes Redestad wrote:
>>
>> On 04/10/2017 05:19 PM, Vladimir Ivanov wrote:
>>> Looks good.
>>
>> Thanks for reviewing!
>>
>>>
>>> One small suggestion [1]
>>
>> Sure, updated in-place.
>
> Taking a second look at these constants, it turned out that a few of
> them were unused, but since they
> weren't private this wasn't called out in my IDE.  Mind if I clean this
> up (add private modifier, remove
> unused JLS_SIG, JLC_SIG, BMHSPECIES_DATA_GFC_SIG, VOID_SIG) as part of
> this patch?
>
> I've verified none of the remaining constants are used anywhere outside
> the class, i.e., no synthetic
> accessor methods are added by this refactoring.
>
> Thanks!
>
> /Claes
>
> diff -r 524eb921da04
> src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
> ---
> a/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
> Tue Apr 11 10:51:05 2017 +0200
> +++
> b/src/java.base/share/classes/java/lang/invoke/BoundMethodHandle.java
> Tue Apr 11 11:01:22 2017 +0200
> @@ -450,33 +450,29 @@
>       */
>      static class Factory {
>
> -        static final String JLO_SIG  = "Ljava/lang/Object;";
> -        static final String JLS_SIG  = "Ljava/lang/String;";
> -        static final String JLC_SIG  = "Ljava/lang/Class;";
> -        static final String MH       = "java/lang/invoke/MethodHandle";
> -        static final String MH_SIG   = "L"+MH+";";
> -        static final String BMH      =
> "java/lang/invoke/BoundMethodHandle";
> -        static final String BMH_NAME =
> "java.lang.invoke.BoundMethodHandle";
> -        static final String BMH_SIG  = "L"+BMH+";";
> -        static final String SPECIES_DATA     =
> "java/lang/invoke/BoundMethodHandle$SpeciesData";
> -        static final String SPECIES_DATA_SIG = "L"+SPECIES_DATA+";";
> -        static final String STABLE_SIG       =
> "Ljdk/internal/vm/annotation/Stable;";
> +        private static final String JLO_SIG  = "Ljava/lang/Object;";
> +        private static final String MH       =
> "java/lang/invoke/MethodHandle";
> +        private static final String MH_SIG   = "L"+MH+";";
> +        private static final String BMH      =
> "java/lang/invoke/BoundMethodHandle";
> +        private static final String BMH_NAME =
> "java.lang.invoke.BoundMethodHandle";
> +        private static final String BMH_SIG  = "L"+BMH+";";
> +        private static final String SPECIES_DATA     =
> "java/lang/invoke/BoundMethodHandle$SpeciesData";
> +        private static final String SPECIES_DATA_SIG =
> "L"+SPECIES_DATA+";";
> +        private static final String STABLE_SIG       =
> "Ljdk/internal/vm/annotation/Stable;";
>
> -        static final String SPECIES_PREFIX_NAME = "Species_";
> -        static final String SPECIES_PREFIX_PATH = BMH + "$" +
> SPECIES_PREFIX_NAME;
> -        static final String SPECIES_CLASS_PREFIX = BMH_NAME + "$" +
> SPECIES_PREFIX_NAME;
> +        private static final String SPECIES_PREFIX_NAME = "Species_";
> +        private static final String SPECIES_PREFIX_PATH = BMH + "$" +
> SPECIES_PREFIX_NAME;
> +        private static final String SPECIES_CLASS_PREFIX = BMH_NAME +
> "$" + SPECIES_PREFIX_NAME;
>
> -        static final String BMHSPECIES_DATA_EWI_SIG = "(B)" +
> SPECIES_DATA_SIG;
> -        static final String BMHSPECIES_DATA_GFC_SIG = "(" + JLS_SIG +
> JLC_SIG + ")" + SPECIES_DATA_SIG;
> -        static final String MYSPECIES_DATA_SIG = "()" + SPECIES_DATA_SIG;
> -        static final String VOID_SIG   = "()V";
> -        static final String INT_SIG    = "()I";
> +        private static final String BMHSPECIES_DATA_EWI_SIG = "(B)" +
> SPECIES_DATA_SIG;
> +        private static final String MYSPECIES_DATA_SIG = "()" +
> SPECIES_DATA_SIG;
> +        private static final String INT_SIG    = "()I";
>
> -        static final String SIG_INCIPIT =
> "(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;";
> +        private static final String SIG_INCIPIT =
> "(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;";
>
> -        static final String[] E_THROWABLE = new String[] {
> "java/lang/Throwable" };
> +        private static final String[] E_THROWABLE = new String[] {
> "java/lang/Throwable" };
>
> -        static final ConcurrentMap<String, Class<? extends
> BoundMethodHandle>> CLASS_CACHE = new ConcurrentHashMap<>();
> +        private static final ConcurrentMap<String, Class<? extends
> BoundMethodHandle>> CLASS_CACHE = new ConcurrentHashMap<>();
>
>          /**
>           * Get a concrete subclass of BMH for a given combination of
> bound types.
>
>
>>
>> /Claes
>

From claes.redestad at oracle.com  Tue Apr 11 09:24:42 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 11 Apr 2017 11:24:42 +0200
Subject: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers
In-Reply-To: <6dcde0d7-3a16-2ee6-e92b-5e36b0e8bcd0@oracle.com>
References: <ca7be65a-4246-30f0-6051-05a29296cf15@oracle.com>
 <e1664d96-265f-6b4f-a320-7ea40d42bb08@oracle.com>
 <6f3d6678-4f14-0987-415d-9e9a68287fbb@oracle.com>
 <bc56837b-3cd3-09ef-b017-14a309f8f7b7@oracle.com>
 <6dcde0d7-3a16-2ee6-e92b-5e36b0e8bcd0@oracle.com>
Message-ID: <1dbbba09-60db-9ef6-e1d9-42dc3bcf8b92@oracle.com>

Thanks! Pushed.

/Claes

On 04/11/2017 11:16 AM, Vladimir Ivanov wrote:
> Reviewed.
>
> Best regards,
> Vladimir Ivanov


From Roger.Riggs at Oracle.com  Tue Apr 11 15:55:40 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 11 Apr 2017 11:55:40 -0400
Subject: RFR 9: 8178347 Process and ProcessHandle getPid method name
 inconsistency
Message-ID: <c9f42a71-1801-06f8-9005-05f13f0ae195@Oracle.com>

Please review this change to the name of the ProcessHandle.getPid and 
Process.getPid methods
as observed and recommended in email: [1]

The methods are new in JDK 9 and the renaming corrects the method name 
style to be
consistent within each class.

The change sets propagate the name change to the openjdk uses of the pid 
method.
Libraries using getPid will need to be updated.

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

Webrevs:

http://cr.openjdk.java.net/~rriggs/webrev-pid-8178347
http://cr.openjdk.java.net/~rriggs/webrev-pid-jaxp-8178347
http://cr.openjdk.java.net/~rriggs/webrev-pid-jdk-8178347
http://cr.openjdk.java.net/~rriggs/webrev-pid-hotspot-8178347

Thanks, Roger

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-April/047103.html




From brian.burkhalter at oracle.com  Tue Apr 11 17:11:55 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 11 Apr 2017 10:11:55 -0700
Subject: RFR 9: 8178347 Process and ProcessHandle getPid method name
 inconsistency
In-Reply-To: <c9f42a71-1801-06f8-9005-05f13f0ae195@Oracle.com>
References: <c9f42a71-1801-06f8-9005-05f13f0ae195@Oracle.com>
Message-ID: <BF34C6E1-4728-4619-995A-3FAC6A3F7EFA@oracle.com>

Hi Roger,

Looks fine to me, modulo the usual copyright date.

Thanks,

Brian

On Apr 11, 2017, at 8:55 AM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:

> Please review this change to the name of the ProcessHandle.getPid and Process.getPid methods
> as observed and recommended in email: [1]
> 
> The methods are new in JDK 9 and the renaming corrects the method name style to be
> consistent within each class.
> 
> The change sets propagate the name change to the openjdk uses of the pid method.
> Libraries using getPid will need to be updated.
> 
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8178347
> 
> Webrevs:
> 
> http://cr.openjdk.java.net/~rriggs/webrev-pid-8178347
> http://cr.openjdk.java.net/~rriggs/webrev-pid-jaxp-8178347
> http://cr.openjdk.java.net/~rriggs/webrev-pid-jdk-8178347
> http://cr.openjdk.java.net/~rriggs/webrev-pid-hotspot-8178347
> 
> Thanks, Roger
> 
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-April/047103.html

From Alan.Bateman at oracle.com  Tue Apr 11 17:12:45 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 11 Apr 2017 18:12:45 +0100
Subject: RFR 9: 8178347 Process and ProcessHandle getPid method name
 inconsistency
In-Reply-To: <c9f42a71-1801-06f8-9005-05f13f0ae195@Oracle.com>
References: <c9f42a71-1801-06f8-9005-05f13f0ae195@Oracle.com>
Message-ID: <b69dff15-4c7e-0358-8141-46336b9b5753@oracle.com>



On 11/04/2017 16:55, Roger Riggs wrote:
> Please review this change to the name of the ProcessHandle.getPid and 
> Process.getPid methods
> as observed and recommended in email: [1]
>
I looked through the jdk repo and the changes look fine. In passing then 
I assume the links in Process of the form {@link #getPid() process id} 
should be @linkplain.

-Alan

From jan.lahoda at oracle.com  Tue Apr 11 17:26:38 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 11 Apr 2017 19:26:38 +0200
Subject: RFR 9: JDK-8178012: Finish removal of -Xmodule:
Message-ID: <58ED11CE.5010608@oracle.com>

Hi,

javac used to have an option, -Xmodule:, that allowed to compile given 
sources as if they were part of the specified module.

This functionality has been merged into the --patch-module option, but 
the -Xmodule: option couldn't be fully removed at that time, as some 
tests and tools (e.g. jtreg) depended on it. The option was however 
removed from the javac help, etc.

Since jtreg can use --patch-module instead of -Xmodule: now, I'd like to 
propose further demoting the option to an unsupported -XD-Xmodule: 
setting (the functionality is not removed completely, as there is a 
small amount of remaining dependencies). The option may be removed 
completely eventually when the remaining dependencies are resolved.

The patch spans many repositories besides langtools, as it adjusts 
TEST.ROOT files, and the 
<top-level>/test/lib/jdk/test/lib/InMemoryJavaCompiler.java. The latter 
is used by hotspot tests, and this change is a small tweak to translate 
-Xmodule: to --patch-module. This could be later improved by enhancing 
the test library API to pass the module name explicitly.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8178012

Webrev:
http://cr.openjdk.java.net/~jlahoda/8178012/webrev.00/

Any feedback is welcome.

Thanks,
     Jan

From Roger.Riggs at Oracle.com  Tue Apr 11 18:09:18 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 11 Apr 2017 14:09:18 -0400
Subject: RFR 9: 8178347 Process and ProcessHandle getPid method name
 inconsistency
In-Reply-To: <b69dff15-4c7e-0358-8141-46336b9b5753@oracle.com>
References: <c9f42a71-1801-06f8-9005-05f13f0ae195@Oracle.com>
 <b69dff15-4c7e-0358-8141-46336b9b5753@oracle.com>
Message-ID: <d65ece9b-fd4a-fb8d-52f4-8d3c3d59860b@Oracle.com>

Hi Alan, Brian,

Updated in place with copyrights and corrections to @linkplain in 
java.lang.Process.

Thanks, Roger

http://cr.openjdk.java.net/~rriggs/webrev-pid-8178347
http://cr.openjdk.java.net/~rriggs/webrev-pid-jaxp-8178347
http://cr.openjdk.java.net/~rriggs/webrev-pid-jdk-8178347
http://cr.openjdk.java.net/~rriggs/webrev-pid-hotspot-8178347

On 4/11/2017 1:12 PM, Alan Bateman wrote:
>
>
> On 11/04/2017 16:55, Roger Riggs wrote:
>> Please review this change to the name of the ProcessHandle.getPid and 
>> Process.getPid methods
>> as observed and recommended in email: [1]
>>
> I looked through the jdk repo and the changes look fine. In passing 
> then I assume the links in Process of the form {@link #getPid() 
> process id} should be @linkplain.
>
> -Alan


From forax at univ-mlv.fr  Tue Apr 11 18:20:41 2017
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 11 Apr 2017 20:20:41 +0200 (CEST)
Subject: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers
In-Reply-To: <fca32ec9-ff9a-cb2f-58dd-d4f90ff598d5@oracle.com>
References: <ca7be65a-4246-30f0-6051-05a29296cf15@oracle.com>
 <7C080227-8B26-4FF2-844D-530E9EEF30C6@oracle.com>
 <9B8481A0-3BFF-4F8C-B69C-C293D9D60547@univ-mlv.fr>
 <fca32ec9-ff9a-cb2f-58dd-d4f90ff598d5@oracle.com>
Message-ID: <195172564.891606.1491934841074.JavaMail.zimbra@u-pem.fr>

Hi Claes,
yes !

We use something equivalent to "FOO".toCharArray() at several place in ASM because there is no constant pool constant arrays [1].

Terence Parr also mentions that issue at the JVM Summit 2009 [2].

R?mi
[1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/645c0d3e3977/src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java#l556 
[2] http://parrt.cs.usfca.edu/doc/impl-parsers-in-java.pdf


----- Mail original -----
> De: "Claes Redestad" <claes.redestad at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>, core-libs-dev at openjdk.java.net, "Paul Sandoz" <paul.sandoz at oracle.com>
> Envoy?: Mardi 11 Avril 2017 10:37:45
> Objet: Re: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers

> Sounds like you want https://bugs.openjdk.java.net/browse/JDK-8061402 -
> which was originally filed back in 2002 but was closed since it got
> filed on the wrong component or something... ?\_(?)_/?
> 
> There's still a number of char[] foo = "FOO".toCharArray() in the JDK
> since this allows for a more compact representation in bytecode (but is
> likely a bit slower during startup, especially since compact strings).
> 
> /Claes
> 
> On 04/10/2017 06:32 PM, Remi Forax wrote:
>> Currently playing with a pattern matching representation for Amber, if
>> think we need a form of array constant that does not require a
>> bootstrap method.
>> Afaik, an array of any existing constants does not need a Java code to
>> construct itself.
>>
>> R?mi
>>
>>
>> On April 10, 2017 6:18:07 PM GMT+02:00, Paul Sandoz
>> <paul.sandoz at oracle.com> wrote:
>>
>>     +1
>>
>>     These named functions really wanna be LDC?ed but i suspect using constant
>>     dynamic + representation in source (when available) might result in it?s own
>>     bootstrap issues, still it would be interesting to try when available.
>>
>>     Paul.
>>
>>         On 10 Apr 2017, at 07:09, Claes Redestad
>>         <claes.redestad at oracle.com> wrote: Hi, profiling initializers
>>         in java.lang.invoke shows we're still doing various things
>>         during class initialization which could be done lazily or not
>>         at all. The proposed patch reduce bytecode executed, memory
>>         churn and retained heap footprint when initializing
>>         java.lang.invoke: Webrev:
>>         http://cr.openjdk.java.net/~redestad/8178384/jdk.01
>>         <http://cr.openjdk.java.net/%7Eredestad/8178384/jdk.01>/ Bug:
>>         https://bugs.openjdk.java.net/browse/JDK-8178384 Testing:
>>         java.lang.invoke jtreg tests, sanity performance testing
>>         Thanks! /Claes
>>
>>
>>
>>
>> --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.

From forax at univ-mlv.fr  Tue Apr 11 18:35:05 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 11 Apr 2017 20:35:05 +0200 (CEST)
Subject: RFR 9: JDK-8178012: Finish removal of -Xmodule:
In-Reply-To: <58ED11CE.5010608@oracle.com>
References: <58ED11CE.5010608@oracle.com>
Message-ID: <882534875.892667.1491935705947.JavaMail.zimbra@u-pem.fr>

Yes, please hide -Xmodule,
currently people get confused by -Xmodule vs --patch-module, i had several questions related to that at DevoxxFR.

R?mi

----- Mail original -----
> De: "Jan Lahoda" <jan.lahoda at oracle.com>
> ?: "compiler-dev" <compiler-dev at openjdk.java.net>, "Java Core Libs" <core-libs-dev at openjdk.java.net>,
> hotspot-dev at openjdk.java.net
> Envoy?: Mardi 11 Avril 2017 19:26:38
> Objet: RFR 9: JDK-8178012: Finish removal of -Xmodule:

> Hi,
> 
> javac used to have an option, -Xmodule:, that allowed to compile given
> sources as if they were part of the specified module.
> 
> This functionality has been merged into the --patch-module option, but
> the -Xmodule: option couldn't be fully removed at that time, as some
> tests and tools (e.g. jtreg) depended on it. The option was however
> removed from the javac help, etc.
> 
> Since jtreg can use --patch-module instead of -Xmodule: now, I'd like to
> propose further demoting the option to an unsupported -XD-Xmodule:
> setting (the functionality is not removed completely, as there is a
> small amount of remaining dependencies). The option may be removed
> completely eventually when the remaining dependencies are resolved.
> 
> The patch spans many repositories besides langtools, as it adjusts
> TEST.ROOT files, and the
> <top-level>/test/lib/jdk/test/lib/InMemoryJavaCompiler.java. The latter
> is used by hotspot tests, and this change is a small tweak to translate
> -Xmodule: to --patch-module. This could be later improved by enhancing
> the test library API to pass the module name explicitly.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8178012
> 
> Webrev:
> http://cr.openjdk.java.net/~jlahoda/8178012/webrev.00/
> 
> Any feedback is welcome.
> 
> Thanks,
>      Jan

From brian.burkhalter at oracle.com  Tue Apr 11 18:54:42 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 11 Apr 2017 11:54:42 -0700
Subject: RFR 9: 8178347 Process and ProcessHandle getPid method name
 inconsistency
In-Reply-To: <d65ece9b-fd4a-fb8d-52f4-8d3c3d59860b@Oracle.com>
References: <c9f42a71-1801-06f8-9005-05f13f0ae195@Oracle.com>
 <b69dff15-4c7e-0358-8141-46336b9b5753@oracle.com>
 <d65ece9b-fd4a-fb8d-52f4-8d3c3d59860b@Oracle.com>
Message-ID: <A045BEA6-3BA8-401E-892E-72AA1E9D4ADE@oracle.com>

Hi Roger,

OK by me.

Brian

On Apr 11, 2017, at 11:09 AM, Roger Riggs <Roger.Riggs at Oracle.com> wrote:

> Updated in place with copyrights and corrections to @linkplain in java.lang.Process.


From claes.redestad at oracle.com  Tue Apr 11 19:16:10 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 11 Apr 2017 21:16:10 +0200
Subject: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers
In-Reply-To: <195172564.891606.1491934841074.JavaMail.zimbra@u-pem.fr>
References: <ca7be65a-4246-30f0-6051-05a29296cf15@oracle.com>
 <7C080227-8B26-4FF2-844D-530E9EEF30C6@oracle.com>
 <9B8481A0-3BFF-4F8C-B69C-C293D9D60547@univ-mlv.fr>
 <fca32ec9-ff9a-cb2f-58dd-d4f90ff598d5@oracle.com>
 <195172564.891606.1491934841074.JavaMail.zimbra@u-pem.fr>
Message-ID: <92a2ea5f-a71f-56a7-7e19-8a77b660df17@oracle.com>

Yes, I've seen some of these dirty hacks in the ASM code, as they show 
up here and there in
my startup graphs when I add some lambdas to the mix[1]... ;-)

I hadn't considered the 64K bytecode per method limitation, which means 
you couldn't even
generate a fraction of that number of elements in an array statically in 
a single method, so in
those cases the "FOO".toCharArray() hack makes more sense.

I think constant pool arrays could be a welcome bonus if it can be 
shaken out of the other
things we're doing for amber and valhalla...

Thanks!

/Claes

[1] Since Compact Strings the cost of String.charAt-loops and 
String.toCharArray has jumped
somewhat during startup, but will of course get compiled away and most 
often outperform
after warmup.

On 2017-04-11 20:20, forax at univ-mlv.fr wrote:
> Hi Claes,
> yes !
>
> We use something equivalent to "FOO".toCharArray() at several place in ASM because there is no constant pool constant arrays [1].
>
> Terence Parr also mentions that issue at the JVM Summit 2009 [2].
>
> R?mi
> [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/645c0d3e3977/src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java#l556
> [2] http://parrt.cs.usfca.edu/doc/impl-parsers-in-java.pdf
>
>
> ----- Mail original -----
>> De: "Claes Redestad" <claes.redestad at oracle.com>
>> ?: "Remi Forax" <forax at univ-mlv.fr>, core-libs-dev at openjdk.java.net, "Paul Sandoz" <paul.sandoz at oracle.com>
>> Envoy?: Mardi 11 Avril 2017 10:37:45
>> Objet: Re: [10] RFR: 8178384: Reduce work in java.lang.invoke initializers
>> Sounds like you want https://bugs.openjdk.java.net/browse/JDK-8061402 -
>> which was originally filed back in 2002 but was closed since it got
>> filed on the wrong component or something... ?\_(?)_/?
>>
>> There's still a number of char[] foo = "FOO".toCharArray() in the JDK
>> since this allows for a more compact representation in bytecode (but is
>> likely a bit slower during startup, especially since compact strings).
>>
>> /Claes
>>
>> On 04/10/2017 06:32 PM, Remi Forax wrote:
>>> Currently playing with a pattern matching representation for Amber, if
>>> think we need a form of array constant that does not require a
>>> bootstrap method.
>>> Afaik, an array of any existing constants does not need a Java code to
>>> construct itself.
>>>
>>> R?mi
>>>
>>>
>>> On April 10, 2017 6:18:07 PM GMT+02:00, Paul Sandoz
>>> <paul.sandoz at oracle.com> wrote:
>>>
>>>      +1
>>>
>>>      These named functions really wanna be LDC?ed but i suspect using constant
>>>      dynamic + representation in source (when available) might result in it?s own
>>>      bootstrap issues, still it would be interesting to try when available.
>>>
>>>      Paul.
>>>
>>>          On 10 Apr 2017, at 07:09, Claes Redestad
>>>          <claes.redestad at oracle.com> wrote: Hi, profiling initializers
>>>          in java.lang.invoke shows we're still doing various things
>>>          during class initialization which could be done lazily or not
>>>          at all. The proposed patch reduce bytecode executed, memory
>>>          churn and retained heap footprint when initializing
>>>          java.lang.invoke: Webrev:
>>>          http://cr.openjdk.java.net/~redestad/8178384/jdk.01
>>>          <http://cr.openjdk.java.net/%7Eredestad/8178384/jdk.01>/ Bug:
>>>          https://bugs.openjdk.java.net/browse/JDK-8178384 Testing:
>>>          java.lang.invoke jtreg tests, sanity performance testing
>>>          Thanks! /Claes
>>>
>>>
>>>
>>>
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.


From claes.redestad at oracle.com  Tue Apr 11 19:42:36 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 11 Apr 2017 21:42:36 +0200
Subject: RFR: 8178480: Wrong exception being thrown on an invalid MethodType
Message-ID: <07b31def-03b7-3556-64f9-7fee62430cc3@oracle.com>

Hi,

JDK-8178387 subtly and inadvertently changed what exception was being 
thrown by LambdaForm.compileToBytecode in
certain cases - this patch reverts this simplification and adds a 
comment to warn against future attempts to
simplify too much..

Bug: https://bugs.openjdk.java.net/browse/JDK-8178480

diff -r 9363dd4a4fb9 
src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
--- 
a/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java 
Tue Apr 11 18:57:46 2017 +0200
+++ 
b/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java 
Tue Apr 11 21:35:59 2017 +0200
@@ -673,9 +673,7 @@
      /**
       * Generate customized bytecode for a given LambdaForm.
       */
-    static MemberName generateCustomizedCode(LambdaForm form) {
-        final MethodType invokerType = form.methodType();
-
+    static MemberName generateCustomizedCode(LambdaForm form, 
MethodType invokerType) {
          MemberName pregenerated = lookupPregenerated(form, invokerType);
          if (pregenerated != null)  return pregenerated; // 
pre-generated bytecode

diff -r 9363dd4a4fb9 
src/java.base/share/classes/java/lang/invoke/LambdaForm.java
--- a/src/java.base/share/classes/java/lang/invoke/LambdaForm.java Tue 
Apr 11 18:57:46 2017 +0200
+++ b/src/java.base/share/classes/java/lang/invoke/LambdaForm.java Tue 
Apr 11 21:35:59 2017 +0200
@@ -847,9 +847,10 @@
          if (vmentry != null && isCompiled) {
              return;  // already compiled somehow
          }
-        assert(vmentry == null || 
vmentry.getMethodType().basicType().equals(methodType()));
+        MethodType invokerType = methodType(); // forces IAE to happen 
outside try-catch block
+        assert(vmentry == null || 
vmentry.getMethodType().basicType().equals(invokerType));
          try {
-            vmentry = 
InvokerBytecodeGenerator.generateCustomizedCode(this);
+            vmentry = 
InvokerBytecodeGenerator.generateCustomizedCode(this, invokerType);
              if (TRACE_INTERPRETER)
                  traceInterpreter("compileToBytecode", this);
              isCompiled = true;


Thanks!

/Claes

From paul.sandoz at oracle.com  Tue Apr 11 19:53:27 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 11 Apr 2017 12:53:27 -0700
Subject: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
Message-ID: <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>

Hi Chris,

Thanks for looking at this.

There is some rudimentary testing using streams in CollectAndSummaryStatisticsTest.java.

I think we should enforce constraints where we reliably can:

1) count >= 0

2) count = 0, then min/max/sum are ignored and it?s as if the default constructor was called. (I thought it might be appropriate to reject since a caller might be passing in incorrect information in error, but the defaults for min/max are important and would be a burden for the caller to pass those values.) In this respect having count as the first parameter of the constructor would be useful.

3)  min <= max

Since for count > 0 the constraints, count * max >= sum, count * min <= sum, cannot be reliably enforced due to overflow i am inclined to not bother and just document.


Note this is gonna be blocked from pushing until the new Compatibility and Specification Review (CSR) process is opened up, which i understand is ?soon"ish :-) but that should not block adding some further tests in the interim and tidying up the javadoc.

Paul.


> On 6 Apr 2017, at 07:08, Chris Dennis <chris.w.dennis at gmail.com> wrote:
> 
> Hi Paul (et al)
> 
> Like all things API there are wrinkles here when it comes to implementing.
> 
> This patch isn?t final, there appears to be no existing test coverage for these classes beyond testing the compensating summation used in the double implementation, and I left off adding any until it was decided how much parameter validation we want (since that?s the only testing that can really occur here).
> 
> The wrinkles relate to the issues around instances that have suffered overflow in count and/or sum which the existing implementation doesn?t defend against:
> 
> * I chose to ignore all parameters if 'count == 0? and just leave the instance empty. I held off from validating min, max and count however. This obviously 'breaks things? (beyond how broken they would already be) if count == 0 only due to overflow.
> * I chose to fail if count is negative.
> * I chose to enforce that max and min are logically consistent with count and sum, this can break the moment either one of the overflows as well (I?m also pretty sure that the FPU logic is going to suffer here too - there might be some magic I can do with a pessimistic bit of rounding on the FPU multiplication result).
> 
> I intentionally went with the most aggressive parameter validation here to establish one end of what could be implemented.  There are arguments for this and also arguments for the other extreme (no validation at all).  Personally I?m in favor of the current version where the creation will fail if the inputs are only possible through overflow (modulo fixing the FPU precision issues above) even though it?s at odds with approach of the existing implementation.
> 
> Would appreciate thoughts/feedback.  Thanks.
> 
> Chris
> 
> 
> P.S. I presume tests would be required for the parameter checking (once it is finalized)?
> 
> <8178117.patch>


From Alan.Bateman at oracle.com  Tue Apr 11 19:55:28 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 11 Apr 2017 20:55:28 +0100
Subject: RFR 9: 8178347 Process and ProcessHandle getPid method name
 inconsistency
In-Reply-To: <d65ece9b-fd4a-fb8d-52f4-8d3c3d59860b@Oracle.com>
References: <c9f42a71-1801-06f8-9005-05f13f0ae195@Oracle.com>
 <b69dff15-4c7e-0358-8141-46336b9b5753@oracle.com>
 <d65ece9b-fd4a-fb8d-52f4-8d3c3d59860b@Oracle.com>
Message-ID: <01ff612c-4ec1-9300-c452-adef4fd6eecd@oracle.com>

On 11/04/2017 19:09, Roger Riggs wrote:

> Hi Alan, Brian,
>
> Updated in place with copyrights and corrections to @linkplain in 
> java.lang.Process.
>
> Thanks, Roger
>
> http://cr.openjdk.java.net/~rriggs/webrev-pid-8178347
> http://cr.openjdk.java.net/~rriggs/webrev-pid-jaxp-8178347
> http://cr.openjdk.java.net/~rriggs/webrev-pid-jdk-8178347
> http://cr.openjdk.java.net/~rriggs/webrev-pid-hotspot-8178347
>
Looks good.

-Alan

From paul.sandoz at oracle.com  Tue Apr 11 20:15:59 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 11 Apr 2017 13:15:59 -0700
Subject: RFR: 8178480: Wrong exception being thrown on an invalid
 MethodType
In-Reply-To: <07b31def-03b7-3556-64f9-7fee62430cc3@oracle.com>
References: <07b31def-03b7-3556-64f9-7fee62430cc3@oracle.com>
Message-ID: <4A7FA43C-F891-45B1-A936-9AE259A2E50F@oracle.com>

Tricky!

Would you mind making the comment a little more descriptive? e.g.

// Obtain the invoker MethodType outside of the following try block.
// This ensures that an IllegalArgumentException is directly thrown if the
// type would have 256 or more parameters

(IAE can be confused with Access or Argument)

Paul.

> On 11 Apr 2017, at 12:42, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> JDK-8178387 subtly and inadvertently changed what exception was being thrown by LambdaForm.compileToBytecode in
> certain cases - this patch reverts this simplification and adds a comment to warn against future attempts to
> simplify too much..
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178480
> 
> diff -r 9363dd4a4fb9 src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
> --- a/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Tue Apr 11 18:57:46 2017 +0200
> +++ b/src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Tue Apr 11 21:35:59 2017 +0200
> @@ -673,9 +673,7 @@
>     /**
>      * Generate customized bytecode for a given LambdaForm.
>      */
> -    static MemberName generateCustomizedCode(LambdaForm form) {
> -        final MethodType invokerType = form.methodType();
> -
> +    static MemberName generateCustomizedCode(LambdaForm form, MethodType invokerType) {
>         MemberName pregenerated = lookupPregenerated(form, invokerType);
>         if (pregenerated != null)  return pregenerated; // pre-generated bytecode
> 
> diff -r 9363dd4a4fb9 src/java.base/share/classes/java/lang/invoke/LambdaForm.java
> --- a/src/java.base/share/classes/java/lang/invoke/LambdaForm.java Tue Apr 11 18:57:46 2017 +0200
> +++ b/src/java.base/share/classes/java/lang/invoke/LambdaForm.java Tue Apr 11 21:35:59 2017 +0200
> @@ -847,9 +847,10 @@
>         if (vmentry != null && isCompiled) {
>             return;  // already compiled somehow
>         }
> -        assert(vmentry == null || vmentry.getMethodType().basicType().equals(methodType()));
> +        MethodType invokerType = methodType(); // forces IAE to happen outside try-catch block
> +        assert(vmentry == null || vmentry.getMethodType().basicType().equals(invokerType));
>         try {
> -            vmentry = InvokerBytecodeGenerator.generateCustomizedCode(this);
> +            vmentry = InvokerBytecodeGenerator.generateCustomizedCode(this, invokerType);
>             if (TRACE_INTERPRETER)
>                 traceInterpreter("compileToBytecode", this);
>             isCompiled = true;
> 
> 
> Thanks!
> 
> /Claes


From joe.darcy at oracle.com  Tue Apr 11 20:16:50 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 11 Apr 2017 13:16:50 -0700
Subject: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
Message-ID: <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>

On an API design note, I would prefer to DoubleSummaryStatistics took a 
double... argument to pass in the state of the summation. This 
flexibility is necessary to more fully preserve the computed sum. Also, 
the we want flexibility to change the amount of internal state 
DoubleSummaryStats keeps so we don't want to hard-code that into as 
aspect of the API.

Thanks,

-Joe


On 4/11/2017 12:53 PM, Paul Sandoz wrote:
> Hi Chris,
>
> Thanks for looking at this.
>
> There is some rudimentary testing using streams in CollectAndSummaryStatisticsTest.java.
>
> I think we should enforce constraints where we reliably can:
>
> 1) count >= 0
>
> 2) count = 0, then min/max/sum are ignored and it?s as if the default constructor was called. (I thought it might be appropriate to reject since a caller might be passing in incorrect information in error, but the defaults for min/max are important and would be a burden for the caller to pass those values.) In this respect having count as the first parameter of the constructor would be useful.
>
> 3)  min <= max
>
> Since for count > 0 the constraints, count * max >= sum, count * min <= sum, cannot be reliably enforced due to overflow i am inclined to not bother and just document.
>
>
> Note this is gonna be blocked from pushing until the new Compatibility and Specification Review (CSR) process is opened up, which i understand is ?soon"ish :-) but that should not block adding some further tests in the interim and tidying up the javadoc.
>
> Paul.
>
>
>> On 6 Apr 2017, at 07:08, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>>
>> Hi Paul (et al)
>>
>> Like all things API there are wrinkles here when it comes to implementing.
>>
>> This patch isn?t final, there appears to be no existing test coverage for these classes beyond testing the compensating summation used in the double implementation, and I left off adding any until it was decided how much parameter validation we want (since that?s the only testing that can really occur here).
>>
>> The wrinkles relate to the issues around instances that have suffered overflow in count and/or sum which the existing implementation doesn?t defend against:
>>
>> * I chose to ignore all parameters if 'count == 0? and just leave the instance empty. I held off from validating min, max and count however. This obviously 'breaks things? (beyond how broken they would already be) if count == 0 only due to overflow.
>> * I chose to fail if count is negative.
>> * I chose to enforce that max and min are logically consistent with count and sum, this can break the moment either one of the overflows as well (I?m also pretty sure that the FPU logic is going to suffer here too - there might be some magic I can do with a pessimistic bit of rounding on the FPU multiplication result).
>>
>> I intentionally went with the most aggressive parameter validation here to establish one end of what could be implemented.  There are arguments for this and also arguments for the other extreme (no validation at all).  Personally I?m in favor of the current version where the creation will fail if the inputs are only possible through overflow (modulo fixing the FPU precision issues above) even though it?s at odds with approach of the existing implementation.
>>
>> Would appreciate thoughts/feedback.  Thanks.
>>
>> Chris
>>
>>
>> P.S. I presume tests would be required for the parameter checking (once it is finalized)?
>>
>> <8178117.patch>


From igor.ignatyev at oracle.com  Tue Apr 11 20:33:07 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 11 Apr 2017 13:33:07 -0700
Subject: RFR(XS) : 8178340: remove unneeded "throws" from
 ProcessTools::createJavaProcessBuilder
In-Reply-To: <b6a505ac-9be7-006b-812d-964b901de0a1@oracle.com>
References: <30D206D1-8044-4205-A687-26AF48784FAC@oracle.com>
 <b6a505ac-9be7-006b-812d-964b901de0a1@oracle.com>
Message-ID: <0F943181-F9CD-471E-8883-837E822CBBD2@oracle.com>

Hi David,

thanks for review.

-- Igor

> On Apr 11, 2017, at 12:04 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Igor,
> 
> This looks fine to me.
> 
> I was a little concerned any tests with a try/catch around these calls would fail to compile due to exception checking, but class Exception is exempt from that checking.
> 
> Thanks,
> David
> 
> On 11/04/2017 8:42 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8178340/webrev.00/index.html
>>> 8 lines changed: 0 ins; 2 del; 6 mod;
>> Hi all,
>> 
>> could you please review this tiny fix which clean up testlibary?
>> 
>> ProcessTools::createJavaProcessBuilder methods can not throw any checked exceptions, but were declared with 'throws Exception', which forced all users of these methods to either have redundant try-catch or throws. the fix cleans up the method declaration in all three copies of testlibary.
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8178340/webrev.00/index.html
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8178340
>> testing: hotspot, jdk, langtools and jaxp tests
>> 
>> Thanks,
>> -- Igor
>> 


From claes.redestad at oracle.com  Tue Apr 11 20:35:40 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 11 Apr 2017 22:35:40 +0200
Subject: RFR: 8178480: Wrong exception being thrown on an invalid
 MethodType
In-Reply-To: <4A7FA43C-F891-45B1-A936-9AE259A2E50F@oracle.com>
References: <07b31def-03b7-3556-64f9-7fee62430cc3@oracle.com>
 <4A7FA43C-F891-45B1-A936-9AE259A2E50F@oracle.com>
Message-ID: <b70488e7-97ef-cde5-b70e-08fd9f36dfde@oracle.com>

On 2017-04-11 22:15, Paul Sandoz wrote
> Would you mind making the comment a little more descriptive? e.g.
>
> // Obtain the invoker MethodType outside of the following try block.
> // This ensures that an IllegalArgumentException is directly thrown if the
> // type would have 256 or more parameters

Sure, I'll use that. Thanks for the quick review!

/Claes


From chris.w.dennis at gmail.com  Tue Apr 11 20:48:03 2017
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Tue, 11 Apr 2017 16:48:03 -0400
Subject: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
Message-ID: <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>

Color me confused? what would the javadoc on the parameter say? It could I guess have an @implNote documenting the meanings of the parameters? but then what use is it? The proposed API simply limits the precision with which a DoubleSummaryStatistic can be copied to be the same as the precision with which it can be ?accessed?.  That doesn?t seem an enormous problem since I suspect that bulk of usages would be to marshall a ?finished? instance and therefore there is no real loss occuring. If we wanted to support arbitrary precision wouldn?t it be better to have a constructor variant that took a BigDecimal, and a matching getPreciseSum() that returned a BigDecimal?

Chris

> On Apr 11, 2017, at 4:16 PM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> On an API design note, I would prefer to DoubleSummaryStatistics took a double... argument to pass in the state of the summation. This flexibility is necessary to more fully preserve the computed sum. Also, the we want flexibility to change the amount of internal state DoubleSummaryStats keeps so we don't want to hard-code that into as aspect of the API.
> 
> Thanks,
> 
> -Joe
> 
> 
> On 4/11/2017 12:53 PM, Paul Sandoz wrote:
>> Hi Chris,
>> 
>> Thanks for looking at this.
>> 
>> There is some rudimentary testing using streams in CollectAndSummaryStatisticsTest.java.
>> 
>> I think we should enforce constraints where we reliably can:
>> 
>> 1) count >= 0
>> 
>> 2) count = 0, then min/max/sum are ignored and it?s as if the default constructor was called. (I thought it might be appropriate to reject since a caller might be passing in incorrect information in error, but the defaults for min/max are important and would be a burden for the caller to pass those values.) In this respect having count as the first parameter of the constructor would be useful.
>> 
>> 3)  min <= max
>> 
>> Since for count > 0 the constraints, count * max >= sum, count * min <= sum, cannot be reliably enforced due to overflow i am inclined to not bother and just document.
>> 
>> 
>> Note this is gonna be blocked from pushing until the new Compatibility and Specification Review (CSR) process is opened up, which i understand is ?soon"ish :-) but that should not block adding some further tests in the interim and tidying up the javadoc.
>> 
>> Paul.
>> 
>> 
>>> On 6 Apr 2017, at 07:08, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>>> 
>>> Hi Paul (et al)
>>> 
>>> Like all things API there are wrinkles here when it comes to implementing.
>>> 
>>> This patch isn?t final, there appears to be no existing test coverage for these classes beyond testing the compensating summation used in the double implementation, and I left off adding any until it was decided how much parameter validation we want (since that?s the only testing that can really occur here).
>>> 
>>> The wrinkles relate to the issues around instances that have suffered overflow in count and/or sum which the existing implementation doesn?t defend against:
>>> 
>>> * I chose to ignore all parameters if 'count == 0? and just leave the instance empty. I held off from validating min, max and count however. This obviously 'breaks things? (beyond how broken they would already be) if count == 0 only due to overflow.
>>> * I chose to fail if count is negative.
>>> * I chose to enforce that max and min are logically consistent with count and sum, this can break the moment either one of the overflows as well (I?m also pretty sure that the FPU logic is going to suffer here too - there might be some magic I can do with a pessimistic bit of rounding on the FPU multiplication result).
>>> 
>>> I intentionally went with the most aggressive parameter validation here to establish one end of what could be implemented.  There are arguments for this and also arguments for the other extreme (no validation at all).  Personally I?m in favor of the current version where the creation will fail if the inputs are only possible through overflow (modulo fixing the FPU precision issues above) even though it?s at odds with approach of the existing implementation.
>>> 
>>> Would appreciate thoughts/feedback.  Thanks.
>>> 
>>> Chris
>>> 
>>> 
>>> P.S. I presume tests would be required for the parameter checking (once it is finalized)?
>>> 
>>> <8178117.patch>
> 


From chris.w.dennis at gmail.com  Wed Apr 12 00:44:20 2017
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Tue, 11 Apr 2017 20:44:20 -0400
Subject: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
Message-ID: <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>

Updated patch with the changed parameter validation, updated javadoc and added test coverage.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 8178117.2.patch.txt
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20170411/690eb390/8178117.2.patch-0001.txt>
-------------- next part --------------


> On Apr 11, 2017, at 4:48 PM, Chris Dennis <chris.w.dennis at gmail.com> wrote:
> 
> Color me confused? what would the javadoc on the parameter say? It could I guess have an @implNote documenting the meanings of the parameters? but then what use is it? The proposed API simply limits the precision with which a DoubleSummaryStatistic can be copied to be the same as the precision with which it can be ?accessed?.  That doesn?t seem an enormous problem since I suspect that bulk of usages would be to marshall a ?finished? instance and therefore there is no real loss occuring. If we wanted to support arbitrary precision wouldn?t it be better to have a constructor variant that took a BigDecimal, and a matching getPreciseSum() that returned a BigDecimal?
> 
> Chris
> 
>> On Apr 11, 2017, at 4:16 PM, joe darcy <joe.darcy at oracle.com> wrote:
>> 
>> On an API design note, I would prefer to DoubleSummaryStatistics took a double... argument to pass in the state of the summation. This flexibility is necessary to more fully preserve the computed sum. Also, the we want flexibility to change the amount of internal state DoubleSummaryStats keeps so we don't want to hard-code that into as aspect of the API.
>> 
>> Thanks,
>> 
>> -Joe
>> 
>> 
>> On 4/11/2017 12:53 PM, Paul Sandoz wrote:
>>> Hi Chris,
>>> 
>>> Thanks for looking at this.
>>> 
>>> There is some rudimentary testing using streams in CollectAndSummaryStatisticsTest.java.
>>> 
>>> I think we should enforce constraints where we reliably can:
>>> 
>>> 1) count >= 0
>>> 
>>> 2) count = 0, then min/max/sum are ignored and it?s as if the default constructor was called. (I thought it might be appropriate to reject since a caller might be passing in incorrect information in error, but the defaults for min/max are important and would be a burden for the caller to pass those values.) In this respect having count as the first parameter of the constructor would be useful.
>>> 
>>> 3)  min <= max
>>> 
>>> Since for count > 0 the constraints, count * max >= sum, count * min <= sum, cannot be reliably enforced due to overflow i am inclined to not bother and just document.
>>> 
>>> 
>>> Note this is gonna be blocked from pushing until the new Compatibility and Specification Review (CSR) process is opened up, which i understand is ?soon"ish :-) but that should not block adding some further tests in the interim and tidying up the javadoc.
>>> 
>>> Paul.
>>> 
>>> 
>>>> On 6 Apr 2017, at 07:08, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>>>> 
>>>> Hi Paul (et al)
>>>> 
>>>> Like all things API there are wrinkles here when it comes to implementing.
>>>> 
>>>> This patch isn?t final, there appears to be no existing test coverage for these classes beyond testing the compensating summation used in the double implementation, and I left off adding any until it was decided how much parameter validation we want (since that?s the only testing that can really occur here).
>>>> 
>>>> The wrinkles relate to the issues around instances that have suffered overflow in count and/or sum which the existing implementation doesn?t defend against:
>>>> 
>>>> * I chose to ignore all parameters if 'count == 0? and just leave the instance empty. I held off from validating min, max and count however. This obviously 'breaks things? (beyond how broken they would already be) if count == 0 only due to overflow.
>>>> * I chose to fail if count is negative.
>>>> * I chose to enforce that max and min are logically consistent with count and sum, this can break the moment either one of the overflows as well (I?m also pretty sure that the FPU logic is going to suffer here too - there might be some magic I can do with a pessimistic bit of rounding on the FPU multiplication result).
>>>> 
>>>> I intentionally went with the most aggressive parameter validation here to establish one end of what could be implemented.  There are arguments for this and also arguments for the other extreme (no validation at all).  Personally I?m in favor of the current version where the creation will fail if the inputs are only possible through overflow (modulo fixing the FPU precision issues above) even though it?s at odds with approach of the existing implementation.
>>>> 
>>>> Would appreciate thoughts/feedback.  Thanks.
>>>> 
>>>> Chris
>>>> 
>>>> 
>>>> P.S. I presume tests would be required for the parameter checking (once it is finalized)?
>>>> 
>>>> <8178117.patch>
>> 
> 


From igor.ignatyev at oracle.com  Wed Apr 12 02:29:01 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 11 Apr 2017 19:29:01 -0700
Subject: RFR(S) : 8178415: remove ProcessTools::getPlatformSpecificVMArgs from
 testlibary
Message-ID: <74A681EB-977E-4EA7-B028-36C6C238E20A@oracle.com>

http://cr.openjdk.java.net/~iignatyev/8178415/webrev.00/
> 59 lines changed: 0 ins; 59 del; 0 mod;

Hi all,

could you please review this small clean up of testlibaries?
the only platform specific vm arguments which we had were -d64/32. they were deprecated in jdk9 by 8168010 and will be removed in jdk10 by 8169646. therefore ProcessTools::getPlatformSpecificVMArgs method is not needed anymore and should be removed.

JBS: https://bugs.openjdk.java.net/browse/JDK-8178415
webrev: http://cr.openjdk.java.net/~iignatyev/8178415/webrev.00/
testing: :jdk_tier{1-3}, :hotspot_all
8168010: https://bugs.openjdk.java.net/browse/JDK-8168010
8169646: https://bugs.openjdk.java.net/browse/JDK-8169646

Thanks,
-- Igor

From david.holmes at oracle.com  Wed Apr 12 02:47:31 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 12 Apr 2017 12:47:31 +1000
Subject: RFR(S) : 8178415: remove ProcessTools::getPlatformSpecificVMArgs
 from testlibary
In-Reply-To: <74A681EB-977E-4EA7-B028-36C6C238E20A@oracle.com>
References: <74A681EB-977E-4EA7-B028-36C6C238E20A@oracle.com>
Message-ID: <de11a570-c26a-a22c-08b1-82208716f516@oracle.com>

Hi Igor,

On 12/04/2017 12:29 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8178415/webrev.00/
>> 59 lines changed: 0 ins; 59 del; 0 mod;
>
> Hi all,
>
> could you please review this small clean up of testlibaries?
> the only platform specific vm arguments which we had were -d64/32. they were deprecated in jdk9 by 8168010 and will be removed in jdk10 by 8169646. therefore ProcessTools::getPlatformSpecificVMArgs method is not needed anymore and should be removed.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8178415
> webrev: http://cr.openjdk.java.net/~iignatyev/8178415/webrev.00/
> testing: :jdk_tier{1-3}, :hotspot_all
> 8168010: https://bugs.openjdk.java.net/browse/JDK-8168010
> 8169646: https://bugs.openjdk.java.net/browse/JDK-8169646

These changes look good to me.

Thanks,
David

> Thanks,
> -- Igor
>

From igor.ignatyev at oracle.com  Wed Apr 12 02:48:16 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 11 Apr 2017 19:48:16 -0700
Subject: RFR(S) : 8178415: remove ProcessTools::getPlatformSpecificVMArgs
 from testlibary
In-Reply-To: <de11a570-c26a-a22c-08b1-82208716f516@oracle.com>
References: <74A681EB-977E-4EA7-B028-36C6C238E20A@oracle.com>
 <de11a570-c26a-a22c-08b1-82208716f516@oracle.com>
Message-ID: <91BF0B5F-7BD2-4928-AFA9-8C0CB8D81D56@oracle.com>

Hi David,

thank you for such a prompt review!

-- Igor
> On Apr 11, 2017, at 7:47 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Igor,
> 
> On 12/04/2017 12:29 PM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev/8178415/webrev.00/
>>> 59 lines changed: 0 ins; 59 del; 0 mod;
>> 
>> Hi all,
>> 
>> could you please review this small clean up of testlibaries?
>> the only platform specific vm arguments which we had were -d64/32. they were deprecated in jdk9 by 8168010 and will be removed in jdk10 by 8169646. therefore ProcessTools::getPlatformSpecificVMArgs method is not needed anymore and should be removed.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8178415
>> webrev: http://cr.openjdk.java.net/~iignatyev/8178415/webrev.00/
>> testing: :jdk_tier{1-3}, :hotspot_all
>> 8168010: https://bugs.openjdk.java.net/browse/JDK-8168010
>> 8169646: https://bugs.openjdk.java.net/browse/JDK-8169646
> 
> These changes look good to me.
> 
> Thanks,
> David
> 
>> Thanks,
>> -- Igor
>> 


From dmitry.fazunenko at oracle.com  Wed Apr 12 07:59:35 2017
From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko)
Date: Wed, 12 Apr 2017 10:59:35 +0300
Subject: RFR(S) : 8178415: remove ProcessTools::getPlatformSpecificVMArgs
 from testlibary
In-Reply-To: <74A681EB-977E-4EA7-B028-36C6C238E20A@oracle.com>
References: <74A681EB-977E-4EA7-B028-36C6C238E20A@oracle.com>
Message-ID: <3f0d3013-f86e-893f-f3a0-2773006dd265@oracle.com>

Hi Igor,

The fix looks, thanks for doing it.
Please update the copyrights before integration :)

Thanks,
Dima

On 12.04.2017 5:29, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8178415/webrev.00/
>> 59 lines changed: 0 ins; 59 del; 0 mod;
> Hi all,
>
> could you please review this small clean up of testlibaries?
> the only platform specific vm arguments which we had were -d64/32. they were deprecated in jdk9 by 8168010 and will be removed in jdk10 by 8169646. therefore ProcessTools::getPlatformSpecificVMArgs method is not needed anymore and should be removed.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8178415
> webrev: http://cr.openjdk.java.net/~iignatyev/8178415/webrev.00/
> testing: :jdk_tier{1-3}, :hotspot_all
> 8168010: https://bugs.openjdk.java.net/browse/JDK-8168010
> 8169646: https://bugs.openjdk.java.net/browse/JDK-8169646
>
> Thanks,
> -- Igor


From peter.levart at gmail.com  Wed Apr 12 14:41:29 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 12 Apr 2017 16:41:29 +0200
Subject: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
Message-ID: <adb655c3-4692-fc0d-fa2e-f58c58b80bb7@gmail.com>

Hi Dennis,

On 04/11/2017 10:48 PM, Chris Dennis wrote:
> Color me confused? what would the javadoc on the parameter say? It could I guess have an @implNote documenting the meanings of the parameters? but then what use is it? The proposed API simply limits the precision with which a DoubleSummaryStatistic can be copied to be the same as the precision with which it can be ?accessed?.  That doesn?t seem an enormous problem since I suspect that bulk of usages would be to marshall a ?finished? instance and therefore there is no real loss occuring. If we wanted to support arbitrary precision wouldn?t it be better to have a constructor variant that took a BigDecimal, and a matching getPreciseSum() that returned a BigDecimal?

And how would you compute the value for BigDecimal getPreciseSum() so 
that you could then set 3 internal double fields from BigDecimal without 
loss of information?

I can imagine a "distributed" implementation of Stream that must 
transport partial results across VM boundaries and then combine them. It 
would be bad if the results of such summation differed from default 
local Stream implementation. If we don't want to make 
XxxSummaryStatistics objects Serializable themselves, then perhaps we 
need some other API to support transporting the state over the wire with 
evolvability in mind. What about something like the following:

     public DoubleSummaryStatistics(DataInput dataInput) throws 
IOException {
         int version = dataInput.readByte();
         if (version == 1) {
             long count = dataInput.readLong();
             double sum = dataInput.readDouble();
             double sumCompensation = dataInput.readDouble();
             double simpleSum = dataInput.readDouble();
             double min = dataInput.readDouble();
             double max = dataInput.readDouble();
             // validation of arguments ...

             // ... assignment to fields
             this.count = count;
             this.sum = sum;
             this.sumCompensation = sumCompensation;
             this.simpleSum = simpleSum;
             this.min = min;
             this.max = max;
         } else {
             throw new IllegalArgumentException(
                 "Invalid version in DataInput stream: " + version);
         }
     }

     public void writeTo(DataOutput dataOutput) throws IOException {
         dataOutput.writeByte(1);
         dataOutput.writeLong(count);
         dataOutput.writeDouble(sum);
         dataOutput.writeDouble(sumCompensation);
         dataOutput.writeDouble(simpleSum);
         dataOutput.writeDouble(min);
         dataOutput.writeDouble(max);
     }


Both members could be made protected so that a Serializable subclass 
could be devised and they would not show up as public API.

Regards, Peter


>
> Chris
>
>> On Apr 11, 2017, at 4:16 PM, joe darcy <joe.darcy at oracle.com> wrote:
>>
>> On an API design note, I would prefer to DoubleSummaryStatistics took a double... argument to pass in the state of the summation. This flexibility is necessary to more fully preserve the computed sum. Also, the we want flexibility to change the amount of internal state DoubleSummaryStats keeps so we don't want to hard-code that into as aspect of the API.
>>
>> Thanks,
>>
>> -Joe
>>
>>
>> On 4/11/2017 12:53 PM, Paul Sandoz wrote:
>>> Hi Chris,
>>>
>>> Thanks for looking at this.
>>>
>>> There is some rudimentary testing using streams in CollectAndSummaryStatisticsTest.java.
>>>
>>> I think we should enforce constraints where we reliably can:
>>>
>>> 1) count >= 0
>>>
>>> 2) count = 0, then min/max/sum are ignored and it?s as if the default constructor was called. (I thought it might be appropriate to reject since a caller might be passing in incorrect information in error, but the defaults for min/max are important and would be a burden for the caller to pass those values.) In this respect having count as the first parameter of the constructor would be useful.
>>>
>>> 3)  min <= max
>>>
>>> Since for count > 0 the constraints, count * max >= sum, count * min <= sum, cannot be reliably enforced due to overflow i am inclined to not bother and just document.
>>>
>>>
>>> Note this is gonna be blocked from pushing until the new Compatibility and Specification Review (CSR) process is opened up, which i understand is ?soon"ish :-) but that should not block adding some further tests in the interim and tidying up the javadoc.
>>>
>>> Paul.
>>>
>>>
>>>> On 6 Apr 2017, at 07:08, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>>>>
>>>> Hi Paul (et al)
>>>>
>>>> Like all things API there are wrinkles here when it comes to implementing.
>>>>
>>>> This patch isn?t final, there appears to be no existing test coverage for these classes beyond testing the compensating summation used in the double implementation, and I left off adding any until it was decided how much parameter validation we want (since that?s the only testing that can really occur here).
>>>>
>>>> The wrinkles relate to the issues around instances that have suffered overflow in count and/or sum which the existing implementation doesn?t defend against:
>>>>
>>>> * I chose to ignore all parameters if 'count == 0? and just leave the instance empty. I held off from validating min, max and count however. This obviously 'breaks things? (beyond how broken they would already be) if count == 0 only due to overflow.
>>>> * I chose to fail if count is negative.
>>>> * I chose to enforce that max and min are logically consistent with count and sum, this can break the moment either one of the overflows as well (I?m also pretty sure that the FPU logic is going to suffer here too - there might be some magic I can do with a pessimistic bit of rounding on the FPU multiplication result).
>>>>
>>>> I intentionally went with the most aggressive parameter validation here to establish one end of what could be implemented.  There are arguments for this and also arguments for the other extreme (no validation at all).  Personally I?m in favor of the current version where the creation will fail if the inputs are only possible through overflow (modulo fixing the FPU precision issues above) even though it?s at odds with approach of the existing implementation.
>>>>
>>>> Would appreciate thoughts/feedback.  Thanks.
>>>>
>>>> Chris
>>>>
>>>>
>>>> P.S. I presume tests would be required for the parameter checking (once it is finalized)?
>>>>
>>>> <8178117.patch>


From peter.levart at gmail.com  Wed Apr 12 16:27:20 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 12 Apr 2017 18:27:20 +0200
Subject: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <adb655c3-4692-fc0d-fa2e-f58c58b80bb7@gmail.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <adb655c3-4692-fc0d-fa2e-f58c58b80bb7@gmail.com>
Message-ID: <0815b9cc-4074-131b-460e-e061771fc18c@gmail.com>



On 04/12/2017 04:41 PM, Peter Levart wrote:
> On 04/11/2017 10:48 PM, Chris Dennis wrote:
>> Color me confused? what would the javadoc on the parameter say? It 
>> could I guess have an @implNote documenting the meanings of the 
>> parameters? but then what use is it? The proposed API simply limits 
>> the precision with which a DoubleSummaryStatistic can be copied to be 
>> the same as the precision with which it can be ?accessed?. That 
>> doesn?t seem an enormous problem since I suspect that bulk of usages 
>> would be to marshall a ?finished? instance and therefore there is no 
>> real loss occuring. If we wanted to support arbitrary precision 
>> wouldn?t it be better to have a constructor variant that took a 
>> BigDecimal, and a matching getPreciseSum() that returned a BigDecimal?
>
> And how would you compute the value for BigDecimal getPreciseSum() so 
> that you could then set 3 internal double fields from BigDecimal 
> without loss of information? 


...perhaps we could use the BigDecimal getPreciseSum() together with 
getSum() to reconstruct the state. For exmaple:

     /**
      * Construct an instance with values obtained from another instance.
      *
      * @param count what was returned from another instance's {@link 
#getCount()}
      * @param sum what was returned from another instance's {@link 
#getSum()}
      * @param preciseSum what was returned from another instance's 
{@link #getPreciseSum()}
      * @param min what was returned from another instance's {@link 
#getMin()}
      * @param max what was returned from another instance's {@link 
#getMax()}
      */
     public DoubleSummaryStatistics(long count,
                                    double sum, BigDecimal preciseSum,
                                    double min, double max) {
         if (count < 0L) {
             throw new IllegalArgumentException("count < 0");
         } else if (count > 0L) {
             if (min > max) {
                 throw new IllegalArgumentException("min > max");
             }
             this.count = count;
             this.min = min;
             this.max = max;
             setSum(sum, preciseSum);
         }
     }

     /**
      * If {@link #getSum()} returns {@link Double#NaN} or {@link 
Double#POSITIVE_INFINITY}
      * or {@link Double#NEGATIVE_INFINITY}, then this method returns 
{@code null},
      * otherwise it returns a value that is a more precise 
representation of the
      * sum of values recorded and can be used in
      * {@link #DoubleSummaryStatistics(long, double, BigDecimal, 
double, double)}
      * to construct an object with internal state that closely 
resembles the state of
      * original object.
      *
      * @return a precise sum in BigDecimal form.
      */
     public final BigDecimal getPreciseSum() {
         double sum = getSum();
         if (Double.isNaN(sum) || Double.isInfinite(sum)) {
             return null;
         } else {
             return new BigDecimal(this.sum).add(
                 new BigDecimal(this.sumCompensation));
         }
     }

     private void setSum(double sum, BigDecimal preciseSum) {
         if (preciseSum == null) {
             if (!Double.isNaN(sum) && !Double.isInfinite(sum)) {
                 throw new IllegalArgumentException(
                     "preciseSum is null but sum is not a NaN and not 
Infinite");
             }
             this.sum = this.simpleSum = sum;
             this.sumCompensation = 0d;
         } else {
             if (Double.isNaN(sum) || Double.isInfinite(sum)) {
                 throw new IllegalArgumentException(
                     "preciseSum is non-null but sum is NaN or Infinite");
             }
             this.sum = this.simpleSum = preciseSum.doubleValue();
             this.sumCompensation = preciseSum.subtract(new 
BigDecimal(this.sum)).doubleValue();
         }
     }


Hm....


Regards, Peter


From paul.sandoz at oracle.com  Wed Apr 12 16:36:14 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 12 Apr 2017 09:36:14 -0700
Subject: JDK 9 RFR of JDK-8169971:
 tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java fails
 intermittently
In-Reply-To: <2cd4bae2-03d0-a097-1977-45a4228ae77d@oracle.com>
References: <2cd4bae2-03d0-a097-1977-45a4228ae77d@oracle.com>
Message-ID: <1815B805-1FC8-460D-88CE-7CA842B998F7@oracle.com>

Hi Amy,

FileUtils
?

-            } catch (NoSuchFileException | DirectoryNotEmptyException x) {
+            } catch (NoSuchFileException x) {


You removed the catch and rethrow of DirectoryNotEmptyException. The documentation of deleteFIleIfExistsWithRetry states:

  72     /**
  73      * Deletes a file, retrying if necessary.
  74      * No exception thrown if file doesn't exist.
  75      *
  76      * @param path  the file to delete
  77      *
  78      * @throws NoSuchFileException
  79      *         if the file does not exist (optional specific exception)
  80      * @throws DirectoryNotEmptyException
  81      *         if the file is a directory and could not otherwise be deleted
  82      *         because the directory is not empty (optional specific exception)
  83      * @throws IOException
  84      *         if an I/O error occurs
  85      */
  86     public static void deleteFileIfExistsWithRetry(Path path)


I dunno what it means by "(optional specific exception)?, but what happens now if deleteFileIfExistsWithRetry is called with a non-empty directory?

It?s amazing how hard it is to actually forcibly delete something. Such ?simple? ( :-) ) utilities should be part of the JDK.

?

Do you think it?s simpler just to let jtreg cleanup? There are a few Mr.Jar tests that clean up after themselves but i wonder if it?s just simpler to let jtreg do it? any thoughts on that?

Paul.

> On 10 Apr 2017, at 19:15, Amy Lu <amy.lu at oracle.com> wrote:
> 
> Please review this test-only change.
> 
> tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java
> 
> This test fails intermittently on Windows platform in the final cleanup step, @AfterClass, in which test tries to delete all dirs and files it created. Though it?s okay to leave this cleanup work to jtreg, I still make it done in test by making test to create everything under ./testoutput (testdir), and delete this testdir directly with FileUtils.deleteFileTreeWithRetry(testdir).
> 
> Moreover, in FileUtils, as it tries to delete path with retry, we might want to give it a chance to "retry" in case of DirectoryNotEmptyException.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8169971
> webrev: http://cr.openjdk.java.net/~amlu/8169971/webrev.00/
> 
> Thanks,
> Amy
> 


From Alan.Bateman at oracle.com  Wed Apr 12 16:42:56 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 12 Apr 2017 17:42:56 +0100
Subject: JDK 9 RFR of JDK-8169971:
 tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java fails
 intermittently
In-Reply-To: <1815B805-1FC8-460D-88CE-7CA842B998F7@oracle.com>
References: <2cd4bae2-03d0-a097-1977-45a4228ae77d@oracle.com>
 <1815B805-1FC8-460D-88CE-7CA842B998F7@oracle.com>
Message-ID: <318cf669-42db-a4ac-2ff9-ae3f9aba373c@oracle.com>

On 12/04/2017 17:36, Paul Sandoz wrote:

> Such ?simple? ( :-) ) utilities should be part of the JDK.
>
I think this utility method in the test library may the pre-date in 
jtreg that does retry. As to why we retry, then it's virus checkers and 
the like locking files that are in use by the test. I don't know why 
they are configured to run in test environments as they regularly cause 
interference.

-Alan

From chris.w.dennis at gmail.com  Wed Apr 12 17:08:08 2017
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Wed, 12 Apr 2017 13:08:08 -0400
Subject: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <0815b9cc-4074-131b-460e-e061771fc18c@gmail.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <adb655c3-4692-fc0d-fa2e-f58c58b80bb7@gmail.com>
 <0815b9cc-4074-131b-460e-e061771fc18c@gmail.com>
Message-ID: <652752D2-A328-477F-9466-97DC06F0B78F@gmail.com>

Something like that was what I was envisioning (of course the inability to represent NaN or infinity with a BigDecimal is annoying). To me this approach really only breaks down when you stop using an actual iteration to perform the computation? as long as a ?sum? in some form is part of the internal state then this still works.

> On Apr 12, 2017, at 12:27 PM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> 
> 
> On 04/12/2017 04:41 PM, Peter Levart wrote:
>> On 04/11/2017 10:48 PM, Chris Dennis wrote:
>>> Color me confused? what would the javadoc on the parameter say? It could I guess have an @implNote documenting the meanings of the parameters? but then what use is it? The proposed API simply limits the precision with which a DoubleSummaryStatistic can be copied to be the same as the precision with which it can be ?accessed?. That doesn?t seem an enormous problem since I suspect that bulk of usages would be to marshall a ?finished? instance and therefore there is no real loss occuring. If we wanted to support arbitrary precision wouldn?t it be better to have a constructor variant that took a BigDecimal, and a matching getPreciseSum() that returned a BigDecimal?
>> 
>> And how would you compute the value for BigDecimal getPreciseSum() so that you could then set 3 internal double fields from BigDecimal without loss of information? 
> 
> 
> ...perhaps we could use the BigDecimal getPreciseSum() together with getSum() to reconstruct the state. For exmaple:
> 
>    /**
>     * Construct an instance with values obtained from another instance.
>     *
>     * @param count what was returned from another instance's {@link #getCount()}
>     * @param sum what was returned from another instance's {@link #getSum()}
>     * @param preciseSum what was returned from another instance's {@link #getPreciseSum()}
>     * @param min what was returned from another instance's {@link #getMin()}
>     * @param max what was returned from another instance's {@link #getMax()}
>     */
>    public DoubleSummaryStatistics(long count,
>                                   double sum, BigDecimal preciseSum,
>                                   double min, double max) {
>        if (count < 0L) {
>            throw new IllegalArgumentException("count < 0");
>        } else if (count > 0L) {
>            if (min > max) {
>                throw new IllegalArgumentException("min > max");
>            }
>            this.count = count;
>            this.min = min;
>            this.max = max;
>            setSum(sum, preciseSum);
>        }
>    }
> 
>    /**
>     * If {@link #getSum()} returns {@link Double#NaN} or {@link Double#POSITIVE_INFINITY}
>     * or {@link Double#NEGATIVE_INFINITY}, then this method returns {@code null},
>     * otherwise it returns a value that is a more precise representation of the
>     * sum of values recorded and can be used in
>     * {@link #DoubleSummaryStatistics(long, double, BigDecimal, double, double)}
>     * to construct an object with internal state that closely resembles the state of
>     * original object.
>     *
>     * @return a precise sum in BigDecimal form.
>     */
>    public final BigDecimal getPreciseSum() {
>        double sum = getSum();
>        if (Double.isNaN(sum) || Double.isInfinite(sum)) {
>            return null;
>        } else {
>            return new BigDecimal(this.sum).add(
>                new BigDecimal(this.sumCompensation));
>        }
>    }
> 
>    private void setSum(double sum, BigDecimal preciseSum) {
>        if (preciseSum == null) {
>            if (!Double.isNaN(sum) && !Double.isInfinite(sum)) {
>                throw new IllegalArgumentException(
>                    "preciseSum is null but sum is not a NaN and not Infinite");
>            }
>            this.sum = this.simpleSum = sum;
>            this.sumCompensation = 0d;
>        } else {
>            if (Double.isNaN(sum) || Double.isInfinite(sum)) {
>                throw new IllegalArgumentException(
>                    "preciseSum is non-null but sum is NaN or Infinite");
>            }
>            this.sum = this.simpleSum = preciseSum.doubleValue();
>            this.sumCompensation = preciseSum.subtract(new BigDecimal(this.sum)).doubleValue();
>        }
>    }
> 
> 
> Hm....
> 
> 
> Regards, Peter
> 


From joe.darcy at oracle.com  Wed Apr 12 17:59:29 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 12 Apr 2017 10:59:29 -0700
Subject: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
Message-ID: <58EE6B01.5040908@oracle.com>

On 4/11/2017 1:48 PM, Chris Dennis wrote:
> Color me confused? what would the javadoc on the parameter say? It could I guess have an @implNote documenting the meanings of the parameters? but then what use is it? The proposed API simply limits the precision with which a DoubleSummaryStatistic can be copied to be the same as the precision with which it can be ?accessed?.  That doesn?t seem an enormous problem since I suspect that bulk of usages would be to marshall a ?finished? instance and therefore there is no real loss occuring. If we wanted to support arbitrary precision wouldn?t it be better to have a constructor variant that took a BigDecimal, and a matching getPreciseSum() that returned a BigDecimal?
>

The javadoc would say something like "takes an array of double values 
representing a sum." In other words, rather than forcing the in-progress 
sum to be represented as a single double, it could be represented as 
more than one double.

The current implementation basically uses two doubles internally to 
represent the on-going summation. This extra state prevents many 
numerically poor outcomes occurring when computing the sum. Greater 
accuracy would be possible if additional internal state were used.

-Joe



From chris.hegarty at oracle.com  Wed Apr 12 19:16:32 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 12 Apr 2017 20:16:32 +0100
Subject: JDK 9 RFR of JDK-8169971:
 tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java fails
 intermittently
In-Reply-To: <1815B805-1FC8-460D-88CE-7CA842B998F7@oracle.com>
References: <2cd4bae2-03d0-a097-1977-45a4228ae77d@oracle.com>
 <1815B805-1FC8-460D-88CE-7CA842B998F7@oracle.com>
Message-ID: <342AEE60-097D-480B-BEB3-A541D4356F09@oracle.com>


> On 12 Apr 2017, at 17:36, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> ..
> Do you think it?s simpler just to let jtreg cleanup? There are a few Mr.Jar tests that clean up after themselves but i wonder if it?s just simpler to let jtreg do it? any thoughts on that?

I added these test library utility methods. Some times you actually
need to clean up, other times you can leave it to jtreg ( if the files
are all within the working/scratch directory ). Jtreg has similar
retry logic when deleting files on Windows.

It is common to see tests cleanup after themselves, as the original
author may have been running the test standalone, not in jtreg,
but we're mostly past that now. 

In this particular case it may be ok to leave it to jtreg to do the
clean up.

-Chris.

From peter.levart at gmail.com  Wed Apr 12 20:58:54 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 12 Apr 2017 22:58:54 +0200
Subject: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <58EE6B01.5040908@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <58EE6B01.5040908@oracle.com>
Message-ID: <2316c028-3360-24e7-5831-63d469bde791@gmail.com>

Hi Joe,

On 04/12/2017 07:59 PM, Joseph D. Darcy wrote:
> On 4/11/2017 1:48 PM, Chris Dennis wrote:
>> Color me confused? what would the javadoc on the parameter say? It 
>> could I guess have an @implNote documenting the meanings of the 
>> parameters? but then what use is it? The proposed API simply limits 
>> the precision with which a DoubleSummaryStatistic can be copied to be 
>> the same as the precision with which it can be ?accessed?.  That 
>> doesn?t seem an enormous problem since I suspect that bulk of usages 
>> would be to marshall a ?finished? instance and therefore there is no 
>> real loss occuring. If we wanted to support arbitrary precision 
>> wouldn?t it be better to have a constructor variant that took a 
>> BigDecimal, and a matching getPreciseSum() that returned a BigDecimal?
>>
>
> The javadoc would say something like "takes an array of double values 
> representing a sum." In other words, rather than forcing the 
> in-progress sum to be represented as a single double, it could be 
> represented as more than one double.
>
> The current implementation basically uses two doubles internally to 
> represent the on-going summation. This extra state prevents many 
> numerically poor outcomes occurring when computing the sum. Greater 
> accuracy would be possible if additional internal state were used.
>
> -Joe
>
>

But constructor taking this state is not enough for the solution to the 
problem. There would have to be a getter returning that state too, 
otherwise there's no point in having such constructor, right?

Are you envisioning that any possible future enhancements of the 
summation would all keep the state as a series of double values?

Regards, Peter


From amy.lu at oracle.com  Thu Apr 13 10:28:35 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 13 Apr 2017 18:28:35 +0800
Subject: JDK 9 RFR of JDK-8169971:
 tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java fails
 intermittently
In-Reply-To: <342AEE60-097D-480B-BEB3-A541D4356F09@oracle.com>
References: <2cd4bae2-03d0-a097-1977-45a4228ae77d@oracle.com>
 <1815B805-1FC8-460D-88CE-7CA842B998F7@oracle.com>
 <342AEE60-097D-480B-BEB3-A541D4356F09@oracle.com>
Message-ID: <b00541a4-47f2-371f-e28d-fb961fbbd547@oracle.com>

Thank you for the comments!

Yes, let's just make it simple, let jtreg to do the final clean up.

Please review the updated webrev: 
http://cr.openjdk.java.net/~amlu/8169971/webrev.01/

(Tested on one win64 and one win32, loop run 500 times, all pass.)

Thanks,
Amy


On 4/13/17 3:16 AM, Chris Hegarty wrote:
>> On 12 Apr 2017, at 17:36, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> ..
>> Do you think it?s simpler just to let jtreg cleanup? There are a few Mr.Jar tests that clean up after themselves but i wonder if it?s just simpler to let jtreg do it? any thoughts on that?
> I added these test library utility methods. Some times you actually
> need to clean up, other times you can leave it to jtreg ( if the files
> are all within the working/scratch directory ). Jtreg has similar
> retry logic when deleting files on Windows.
>
> It is common to see tests cleanup after themselves, as the original
> author may have been running the test standalone, not in jtreg,
> but we're mostly past that now.
>
> In this particular case it may be ok to leave it to jtreg to do the
> clean up.
>
> -Chris.


From chris.hegarty at oracle.com  Thu Apr 13 10:42:32 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 13 Apr 2017 11:42:32 +0100
Subject: JDK 9 RFR of JDK-8169971:
 tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java fails
 intermittently
In-Reply-To: <b00541a4-47f2-371f-e28d-fb961fbbd547@oracle.com>
References: <2cd4bae2-03d0-a097-1977-45a4228ae77d@oracle.com>
 <1815B805-1FC8-460D-88CE-7CA842B998F7@oracle.com>
 <342AEE60-097D-480B-BEB3-A541D4356F09@oracle.com>
 <b00541a4-47f2-371f-e28d-fb961fbbd547@oracle.com>
Message-ID: <9B9D9370-1E4C-4716-BC01-CBA78432FC3A@oracle.com>


> On 13 Apr 2017, at 11:28, Amy Lu <amy.lu at oracle.com> wrote:
> 
> Thank you for the comments!
> 
> Yes, let's just make it simple, let jtreg to do the final clean up.
> 
> Please review the updated webrev: http://cr.openjdk.java.net/~amlu/8169971/webrev.01/

Looks ok to me.

-Chris.

From paul.sandoz at oracle.com  Thu Apr 13 17:35:25 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 13 Apr 2017 10:35:25 -0700
Subject: JDK 9 RFR of JDK-8169971:
 tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java fails
 intermittently
In-Reply-To: <9B9D9370-1E4C-4716-BC01-CBA78432FC3A@oracle.com>
References: <2cd4bae2-03d0-a097-1977-45a4228ae77d@oracle.com>
 <1815B805-1FC8-460D-88CE-7CA842B998F7@oracle.com>
 <342AEE60-097D-480B-BEB3-A541D4356F09@oracle.com>
 <b00541a4-47f2-371f-e28d-fb961fbbd547@oracle.com>
 <9B9D9370-1E4C-4716-BC01-CBA78432FC3A@oracle.com>
Message-ID: <C74F63DB-8ECE-4A27-A8D8-6860C87DCC2C@oracle.com>


> On 13 Apr 2017, at 03:42, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> 
>> On 13 Apr 2017, at 11:28, Amy Lu <amy.lu at oracle.com> wrote:
>> 
>> Thank you for the comments!
>> 
>> Yes, let's just make it simple, let jtreg to do the final clean up.
>> 
>> Please review the updated webrev: http://cr.openjdk.java.net/~amlu/8169971/webrev.01/
> 
> Looks ok to me.
> 

+1

Paul.

From volker.simonis at gmail.com  Thu Apr 13 18:50:32 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 13 Apr 2017 20:50:32 +0200
Subject: [9] RFR(S): 8178726: Can't load classes from classpath if it is a UNC
 share
Message-ID: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>

Hi,

can you please review the following change which fixes a problem with
UNC paths on the Windows class path:

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

I would appreciate if somebody could run this trough JPRT for me. I
won't be available until Tuesday after Easter so there's some time for
testing :)

Here comes the detailed problem description (also included in the bug report):

If we set the classpath to a UNC share (e.g. '-cp \\foo\bar\classes')
java won't be able to find classes there. This is also true if we set
the classpath to a drive letter which maps to a network drive (e.g.
'-cp Z:\classes' where 'Z:' is a short-cut for '\\foo\bar').

This error is clearly a regression and should be fixed before Java 9 GA.

The problem is caused by the refactoring of the application class loader:

Before Java 9 the application class loader was a URLClassLoader
(actually sun.misc.Launcher$AppClassLoader which extends
URLClassLoader). It took the classpath from the "java.class.path"
property and transformed it into a File[] by calling
Launcher.getClassPath(). This File[] was then converted into a URL[]
by calling Launcher.pathToURLs() which in turn called
Launcher.getFileURL() which finally called
sun.net.www.ParseUtil.fileToEncodedURL() to convert a File into an
URL. This last function explicitly creates URLs with protocol 'file'
and empty authority (i.e. if the File contained an authority part like
"\\foo" in "\\foo\bar\classs"), this was saved in the path part of the
URL (i.e. 'return new URL("file", "", path)');

Later, these URLs were used to access classes on the classpath. This
was done by creating new File objects from the path components of the
corresponding URLs and because these path components already contained
the full UNC path, everything worked fine.

In JDK 9 now, the legacy class path is constructed in
jdk.internal.loader.ClassLoaders. It also takes the "java.class.path"
property as a starting point but calls addClassPathToUCP() which in
turn calls toFileURL() which finally uses
'Paths.get(s).toRealPath().toUri().toURL()' to transform a string 's'
into an URL. This conversion creates URLs where the authority part
contains the hostname and the path component contains the remaining
path from the UNC paths in the classpath.

The problem is now that during class loading, the new application
class loader jdk.internal.loader.ClassLoaders$AppClassLoader calls
jdk.internal.loader.BuiltinClassLoader.loadClass() which calls
loadClassOrNull() which calls findClassOnClassPathOrNull() which calls
jdk.internal.loader.URLClassPath.getResource(). The class URLClassPath
has a list of all the previously created URLs for each entry of the
classpath. For each of these URLs it creates a
jdk.internal.loader.URLClassPath$Loader by calling getLoader(). If the
corresponding URL represents a file, it will create a
jdk.internal.loader.URLClassPath$FileLoader (which derives from
URLClassPath$Loader). The FileLoader class uses the file component of
the URL to construct a File object for accessing the underlying
ressources. But unlike the jdk8 case, the file part of the URL now
only contains the path component WITHOUT the authority (i.e. 'host')
part. This will be interpreted as a relative path realtively to the
current drive and obviously fail.

Thanks,
Volker

From huaming.li at oracle.com  Fri Apr 14 06:33:39 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 14 Apr 2017 14:33:39 +0800
Subject: RFR of JDK-8145163: Test Task for Platform Logging API and Service --
 for moduralization
Message-ID: <2089ddd7-9f1d-eb06-3d91-45faa193d72f@oracle.com>

Would you please review the below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8145163

webrev: http://cr.openjdk.java.net/~mli/8145163/webrev.00/

Thank you

-Hamlin


From Alan.Bateman at oracle.com  Fri Apr 14 08:41:06 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 14 Apr 2017 09:41:06 +0100
Subject: [9] RFR(S): 8178726: Can't load classes from classpath if it is a
 UNC share
In-Reply-To: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>
References: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>
Message-ID: <0633380e-0b8d-fcd5-8983-91c514b1cf0d@oracle.com>

On 13/04/2017 19:50, Volker Simonis wrote:

> Hi,
>
> can you please review the following change which fixes a problem with
> UNC paths on the Windows class path:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8178726/
> https://bugs.openjdk.java.net/browse/JDK-8178726
>
> I would appreciate if somebody could run this trough JPRT for me. I
> won't be available until Tuesday after Easter so there's some time for
> testing :)
Yes, this is a regression, it seems specific to a class path with 
exploded classes on a network share. The issue has been there since 
jdk-9+111 but I don't think has been reported before now.

I can do some testing with your patch. My general concern is that there 
are lot of conversions going on, specifically URL -> URI -> Path -> File 
(this is after the initial setup that amounts to String -> Path -> URI 
-> URL). I think URLClassPath (which dates back to JDK 1.2 I think) is 
crying out to be replaced and we probably should have done a long time 
ago. Too late now as we have to be cautious.

Given that `dir` is only needed when the resource name contains a ".." 
then there shouldn't be any need to initialize it in the constructor, it 
can be lazy. That would reduce the risk with changing this fragile area. 
It would also remove some of the overhead with a really long class path. 
Once JDK 9 is out of the way then I think we should replace 
URLClassPath.FileLoader, if not all of URLClassPath.

-Alan

From weijun.wang at oracle.com  Fri Apr 14 09:02:58 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 14 Apr 2017 17:02:58 +0800
Subject: [9] RFR(S): 8178726: Can't load classes from classpath if it is a
 UNC share
In-Reply-To: <0633380e-0b8d-fcd5-8983-91c514b1cf0d@oracle.com>
References: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>
 <0633380e-0b8d-fcd5-8983-91c514b1cf0d@oracle.com>
Message-ID: <d62ca091-933c-b8da-0afd-74b86cf041a4@oracle.com>

I see some changes:

- relative url won't be supported

- path is no longer canonicalized

Maybe these are no problem for URLClassPath. Just my 2 cents.

--Max

On 04/14/2017 04:41 PM, Alan Bateman wrote:
> On 13/04/2017 19:50, Volker Simonis wrote:
>
>> Hi,
>>
>> can you please review the following change which fixes a problem with
>> UNC paths on the Windows class path:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8178726/
>> https://bugs.openjdk.java.net/browse/JDK-8178726
>>
>> I would appreciate if somebody could run this trough JPRT for me. I
>> won't be available until Tuesday after Easter so there's some time for
>> testing :)
> Yes, this is a regression, it seems specific to a class path with
> exploded classes on a network share. The issue has been there since
> jdk-9+111 but I don't think has been reported before now.
>
> I can do some testing with your patch. My general concern is that there
> are lot of conversions going on, specifically URL -> URI -> Path -> File
> (this is after the initial setup that amounts to String -> Path -> URI
> -> URL). I think URLClassPath (which dates back to JDK 1.2 I think) is
> crying out to be replaced and we probably should have done a long time
> ago. Too late now as we have to be cautious.
>
> Given that `dir` is only needed when the resource name contains a ".."
> then there shouldn't be any need to initialize it in the constructor, it
> can be lazy. That would reduce the risk with changing this fragile area.
> It would also remove some of the overhead with a really long class path.
> Once JDK 9 is out of the way then I think we should replace
> URLClassPath.FileLoader, if not all of URLClassPath.
>
> -Alan

From daniel.fuchs at oracle.com  Fri Apr 14 10:31:43 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 14 Apr 2017 11:31:43 +0100
Subject: RFR of JDK-8145163: Test Task for Platform Logging API and
 Service -- for moduralization
In-Reply-To: <2089ddd7-9f1d-eb06-3d91-45faa193d72f@oracle.com>
References: <2089ddd7-9f1d-eb06-3d91-45faa193d72f@oracle.com>
Message-ID: <cbb5d114-d059-5a05-a497-5a80f0c2b31b@oracle.com>

Hi Hamlin,

Thank you very much for contributing these tests.
They look good to me!
I'm particularly happy to see that some of them tests the
API with a smaller image built with jlink.
None of the existing logging tests did that!

best regards

-- daniel

On 14/04/2017 07:33, Hamlin Li wrote:
> Would you please review the below patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8145163
>
> webrev: http://cr.openjdk.java.net/~mli/8145163/webrev.00/
>
> Thank you
>
> -Hamlin
>


From huaming.li at oracle.com  Fri Apr 14 10:49:35 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 14 Apr 2017 18:49:35 +0800
Subject: RFR of JDK-8145163: Test Task for Platform Logging API and
 Service -- for moduralization
In-Reply-To: <cbb5d114-d059-5a05-a497-5a80f0c2b31b@oracle.com>
References: <2089ddd7-9f1d-eb06-3d91-45faa193d72f@oracle.com>
 <cbb5d114-d059-5a05-a497-5a80f0c2b31b@oracle.com>
Message-ID: <2a9b7ea3-3688-b161-eb80-3b6de2718894@oracle.com>


Since this is a test development, I think it does not have to go through 
the JDK 9 ramp down 2 approval procedures, I suppose now I'm OK to push 
the code as usual?

Thank you

-Hamlin


On 2017/4/14 18:31, Daniel Fuchs wrote:
> Hi Hamlin,
>
> Thank you very much for contributing these tests.
> They look good to me!
> I'm particularly happy to see that some of them tests the
> API with a smaller image built with jlink.
> None of the existing logging tests did that!
>
> best regards
>
> -- daniel
>
> On 14/04/2017 07:33, Hamlin Li wrote:
>> Would you please review the below patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8145163
>>
>> webrev: http://cr.openjdk.java.net/~mli/8145163/webrev.00/
>>
>> Thank you
>>
>> -Hamlin
>>
>


From daniel.fuchs at oracle.com  Fri Apr 14 10:51:44 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 14 Apr 2017 11:51:44 +0100
Subject: RFR of JDK-8145163: Test Task for Platform Logging API and
 Service -- for moduralization
In-Reply-To: <2a9b7ea3-3688-b161-eb80-3b6de2718894@oracle.com>
References: <2089ddd7-9f1d-eb06-3d91-45faa193d72f@oracle.com>
 <cbb5d114-d059-5a05-a497-5a80f0c2b31b@oracle.com>
 <2a9b7ea3-3688-b161-eb80-3b6de2718894@oracle.com>
Message-ID: <64f26811-552c-5018-f0c8-65bc6a2c190f@oracle.com>

On 14/04/2017 11:49, Hamlin Li wrote:
>
> Since this is a test development, I think it does not have to go through
> the JDK 9 ramp down 2 approval procedures, I suppose now I'm OK to push
> the code as usual?

That's my understanding as well.

best regards,

-- daniel

>
> Thank you
>
> -Hamlin


From huaming.li at oracle.com  Fri Apr 14 10:53:33 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 14 Apr 2017 18:53:33 +0800
Subject: RFR of JDK-8145163: Test Task for Platform Logging API and
 Service -- for moduralization
In-Reply-To: <64f26811-552c-5018-f0c8-65bc6a2c190f@oracle.com>
References: <2089ddd7-9f1d-eb06-3d91-45faa193d72f@oracle.com>
 <cbb5d114-d059-5a05-a497-5a80f0c2b31b@oracle.com>
 <2a9b7ea3-3688-b161-eb80-3b6de2718894@oracle.com>
 <64f26811-552c-5018-f0c8-65bc6a2c190f@oracle.com>
Message-ID: <a1f469cc-aee8-50fc-daaa-13fee9db1756@oracle.com>


On 2017/4/14 18:51, Daniel Fuchs wrote:
> On 14/04/2017 11:49, Hamlin Li wrote:
>>
>> Since this is a test development, I think it does not have to go through
>> the JDK 9 ramp down 2 approval procedures, I suppose now I'm OK to push
>> the code as usual?
>
> That's my understanding as well.
Hi Daniel,

Got it, thank you! will push the code later.

Thank you
-Hamlin
>
> best regards,
>
> -- daniel
>
>>
>> Thank you
>>
>> -Hamlin
>


From Alan.Bateman at oracle.com  Fri Apr 14 12:41:39 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 14 Apr 2017 13:41:39 +0100
Subject: [9] RFR(S): 8178726: Can't load classes from classpath if it is a
 UNC share
In-Reply-To: <d62ca091-933c-b8da-0afd-74b86cf041a4@oracle.com>
References: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>
 <0633380e-0b8d-fcd5-8983-91c514b1cf0d@oracle.com>
 <d62ca091-933c-b8da-0afd-74b86cf041a4@oracle.com>
Message-ID: <bc7e4f28-d29d-747c-7f61-081b795977b2@oracle.com>

On 14/04/2017 10:02, Weijun Wang wrote:

> I see some changes:
>
> - relative url won't be supported
>
> - path is no longer canonicalized
>
> Maybe these are no problem for URLClassPath. Just my 2 cents.
The URLs are already constructed from canonicalized file paths but maybe 
you are thinking about usages of URLClassPath by other code?

-Alan

From chris.hegarty at oracle.com  Fri Apr 14 13:02:45 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 14 Apr 2017 14:02:45 +0100
Subject: [9] RFR(S): 8178726: Can't load classes from classpath if it is a
 UNC share
In-Reply-To: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>
References: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>
Message-ID: <2a1ec694-f3d4-ca25-a08c-36b7d3511bdf@oracle.com>

Volker,

On 13/04/17 19:50, Volker Simonis wrote:
> Hi,
>
> can you please review the following change which fixes a problem with
> UNC paths on the Windows class path:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8178726/
> https://bugs.openjdk.java.net/browse/JDK-8178726
>
> I would appreciate if somebody could run this trough JPRT for me. I
> won't be available until Tuesday after Easter so there's some time for
> testing :)

I know that Alan has provided some comments on this, but I just
grabbed your patch and sent it through our internal build and test
system. I observed a few failures:

1)java/nio/file/spi/SetDefaultProvider.java ( all platforms )

STDERR:
Error: A JNI error has occurred, please check your installation and try 
again
Exception in thread "main" java.lang.Error: java.lang.NullPointerException
	at 
java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:139)
	at 
java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.access$100(FileSystems.java:100)
	at 
java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:109)
	at 
java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:107)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at 
java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:107)
	at 
java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.<clinit>(FileSystems.java:101)
	at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:188)
	at java.base/java.nio.file.Paths.get(Paths.java:138)
	at 
java.base/jdk.internal.loader.URLClassPath$FileLoader.<init>(URLClassPath.java:1049)
	at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:417)
	at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:411)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at 
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:410)
	at 
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:379)
	at 
java.base/jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:245)
	at 
java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:666)
	at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:592)
	at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:550)
	at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:374)
	at 
java.base/sun.launcher.LauncherHelper.loadMainClass(LauncherHelper.java:628)
	at 
java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:524)
Caused by: java.lang.NullPointerException
	at java.base/java.nio.file.Paths.get(Paths.java:138)
	at 
java.base/jdk.internal.loader.URLClassPath$FileLoader.<init>(URLClassPath.java:1049)
	at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:417)
	at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:411)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at 
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:410)
	at 
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:379)
	at 
java.base/jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:245)
	at 
java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:666)
	at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:592)
	at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:550)
	at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:185)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:374)
	at 
java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:129)
	... 24 more

2) java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh
     ( all platforms )

Exception in thread "main" java.lang.IllegalArgumentException: URI is 
not hierarchical
	at java.base/sun.nio.fs.UnixUriUtils.fromUri(UnixUriUtils.java:48)
	at 
java.base/sun.nio.fs.UnixFileSystemProvider.getPath(UnixFileSystemProvider.java:99)
	at java.base/java.nio.file.Paths.get(Paths.java:138)
	at 
java.base/jdk.internal.loader.URLClassPath$FileLoader.<init>(URLClassPath.java:1049)
	at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:417)
	at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:411)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at 
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:410)
	at 
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:379)
	at 
java.base/jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:245)
	at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:450)
	at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:447)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:446)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:540)
	at 
ClassLoaderDeadlock$DelayClassLoader.loadClass(ClassLoaderDeadlock.java:87)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473)
	at ClassLoaderDeadlock.main(ClassLoaderDeadlock.java:38)

3) test\java\net\URLClassLoader\closetest\CloseTest.java ( Windows )

java.lang.IllegalArgumentException: uri
	at 
java.base/jdk.internal.loader.URLClassPath$FileLoader.<init>(URLClassPath.java:1051)
	at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:417)
	at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:411)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at 
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:410)
	at 
java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:379)
	at 
java.base/jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:245)
	at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:450)
	at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:447)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:446)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:540)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:473)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:374)
	at Common.loadClass(Common.java:80)
	at CloseTest.test(CloseTest.java:109)
	at CloseTest.main(CloseTest.java:83)
	at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:563)
	at 
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
	at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.net.URISyntaxException: Illegal character in opaque part 
at index 7: 
file:C:\jprt\T\P1\101420.chhegar\s\jdk\testoutput\jdk_net\JTwork\classes\java\net\URLClassLoader\closetest/testdir/
	at java.base/java.net.URI$Parser.fail(URI.java:2904)
	at java.base/java.net.URI$Parser.checkChars(URI.java:3075)
	at java.base/java.net.URI$Parser.parse(URI.java:3111)
	at java.base/java.net.URI.<init>(URI.java:590)
	at java.base/java.net.URL.toURI(URL.java:1018)
	at 
java.base/jdk.internal.loader.URLClassPath$FileLoader.<init>(URLClassPath.java:1049)
	... 23 more

4) java/net/URLClassLoader/closetest/GetResourceAsStream.java ( Windows )

STDOUT:
Doing tests with URL: 
file:/C:/jprt/T/P1/101420.chhegar/s/jdk/testoutput/jdk_net/JTwork/classes/java/net/URLClassLoader/closetest/test.jar
  ... OK
Doing tests with URL: 
file:/C:/jprt/T/P1/101420.chhegar/s/jdk/testoutput/jdk_net/JTwork/classes/java/net/URLClassLoader/closetest/test.jar
  ... OK
Doing tests with URL: 
file:/C:/jprt/T/P1/101420.chhegar/s/jdk/testoutput/jdk_net/JTwork/classes/java/net/URLClassLoader/closetest/test.jar
  ... OK
STDERR:
java.lang.RuntimeException: Dir exists: 
C:\jprt\T\P1\101420.chhegar\s\jdk\testoutput\jdk_net\JTwork\classes\java\net\URLClassLoader\closetest\testdir
	at Common.copyDir(Common.java:62)
	at GetResourceAsStream.main(GetResourceAsStream.java:71)
	at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
	at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:563)
	at 
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
	at java.base/java.lang.Thread.run(Thread.java:844)

-Chris.

From Alan.Bateman at oracle.com  Fri Apr 14 13:13:27 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 14 Apr 2017 14:13:27 +0100
Subject: [9] RFR(S): 8178726: Can't load classes from classpath if it is a
 UNC share
In-Reply-To: <2a1ec694-f3d4-ca25-a08c-36b7d3511bdf@oracle.com>
References: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>
 <2a1ec694-f3d4-ca25-a08c-36b7d3511bdf@oracle.com>
Message-ID: <4067cfb5-a01c-73e3-7f5d-c4d729830b28@oracle.com>

On 14/04/2017 14:02, Chris Hegarty wrote:

>
> I know that Alan has provided some comments on this, but I just
> grabbed your patch and sent it through our internal build and test
> system. I observed a few failures:
Yes, I think URLClassLoader will be broken (Max is right, I forgot that 
URLClassPath is essentially the implementation of URLClassLoader).

I think Volker will need to change this so that 
ClassLoaders.toFileURL(String) uses toFile().toURI().toURL(). That will 
ensure that URLClassPath doesn't get URLs with the server name in the 
authority component.

-Alan

From stuart.marks at oracle.com  Fri Apr 14 22:36:40 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 14 Apr 2017 15:36:40 -0700
Subject: JDK 9 RFR(s): 8177789 fix collections framework links to point to
 java.util package doc
Message-ID: <fdc2cef2-6615-9df9-5dff-a179604ab946@oracle.com>

Hi all,

Please review this changeset that fixes up links around the JDK that point to 
the old Collections technotes/guides area. This changeset points them to the 
java.util package summary instead.

Most of the changes here simply adjust a link location. The file that's 
different is java/util/package-info.java, which adds the anchor to which all the 
other links point.

Martin,

This changeset includes a bunch of changes to java.util.concurrent classes, as 
well as to files like ArrayDeque which straddle the border between the JDK and 
the JSR166 repo. How did you want to handle these changes? I could just push 
this and you could merge upstream, or I could slice off the diffs from selected 
files and have you put them into JSR166 and then merge into the JDK. In any 
case, the changes are all one-liners, so I don't expect any conflicts. Let me know.

Webrev:

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

Thanks,

s'marks

From brent.christian at oracle.com  Sat Apr 15 00:18:01 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 14 Apr 2017 17:18:01 -0700
Subject: JDK 9 RFR(s): 8177789 fix collections framework links to point to
 java.util package doc
In-Reply-To: <fdc2cef2-6615-9df9-5dff-a179604ab946@oracle.com>
References: <fdc2cef2-6615-9df9-5dff-a179604ab946@oracle.com>
Message-ID: <62cafae9-19df-15fa-3ac0-c2adddf759b5@oracle.com>

Hi, Stuart

The changes look fine.  You found and changed all the references I could 
find.   Having the @index I think will be nice.

-Brent

On 4/14/17 3:36 PM, Stuart Marks wrote:
> Hi all,
>
> Please review this changeset that fixes up links around the JDK that
> point to the old Collections technotes/guides area. This changeset
> points them to the java.util package summary instead.
>
> Most of the changes here simply adjust a link location. The file that's
> different is java/util/package-info.java, which adds the anchor to which
> all the other links point.
>
> Martin,
>
> This changeset includes a bunch of changes to java.util.concurrent
> classes, as well as to files like ArrayDeque which straddle the border
> between the JDK and the JSR166 repo. How did you want to handle these
> changes? I could just push this and you could merge upstream, or I could
> slice off the diffs from selected files and have you put them into
> JSR166 and then merge into the JDK. In any case, the changes are all
> one-liners, so I don't expect any conflicts. Let me know.
>
> Webrev:
>
> http://cr.openjdk.java.net/~smarks/reviews/8177789/webrev.0/
>
> Thanks,
>
> s'marks

From gil at azul.com  Sat Apr 15 15:51:38 2017
From: gil at azul.com (Gil Tene)
Date: Sat, 15 Apr 2017 15:51:38 +0000
Subject: RFR 9: 8165641 : Deprecate Object.finalize
In-Reply-To: <CAMOCf+j8k5kiTP0_Ue6yO3+68iNUKJvVZLostKZEJoudkDRd2A@mail.gmail.com>
References: <c7893765-1c5b-18e3-c5f3-a9ccf9b05094@Oracle.com>
 <96fe9ae0-993a-aea6-cabf-f079450dc128@Oracle.com>
 <49eb0b85-130a-b74d-e760-120674de6ebc@oracle.com>
 <CAMOCf+iAT-29E0wu8WFcNiZq1di1xCq=-kSwjdfhkq2cEA1iJA@mail.gmail.com>
 <f25ac4e3-cfba-ea53-2827-775a18d508ad@redhat.com>
 <CAMOCf+j8k5kiTP0_Ue6yO3+68iNUKJvVZLostKZEJoudkDRd2A@mail.gmail.com>
Message-ID: <C40E2BA5-0B35-4053-BFDA-796B6E3C73AE@azul.com>

IMO, so long as the JDK's own performance-sensitive methods do not follow this advice, it will be hard to "educate" people to use reachabilityFence responsibly.

To be specific:

As long as java.nioDirectByteBuffer.get() is effectively coded like this (after the templates are applied):

    public byte get() {
        return (unsafe.getByte(ix(nextGetIndex())));
    }

Instead of like this:

    public byte get() {
	try {
        	return (unsafe.getByte(ix(nextGetIndex())));
	} finally {
		Reference.reachabilityFence(this);
	}
    }

People will copy it and extend on it, replicating the reachability bug and the use-after-free problem in the current code.

It is hard to ask people to code "responsibly" when the JDK itself doesn't. This is especially true when the bug in the above code is not obvious, and (as Hans points out earlier) it takes a long time to convince people it actually exists. This is especially true since the "well, when was the last time someone complained about DirectByteBuffer.get() doing getting a SEGV on access to a freed buffer?" argument holds some water. And that's where you actually end up usually when discussing the above missing reachabilityFence?

A few things are keeping the JDK code from evolving to properly use Reference.reachabilityFence(this):

a. It didn't exist until recently. [That's a very good excuse]

b. While Reference.reachabilityFence exists now, it's implementation is sub-optimal. IUUC it is modeled [currently] as an opaque method call, which prohibits enough useful optimizations to significantly hurt DirectByteBuffer.get() if it were actually included in the code right now.

c. As Hans notes below, the compilers may temporarily dodge this issue by inhibiting dead variable elimination for references. They do so to allow the actual (semantically buggy) current JDK code to execute safely and performantly.

As long as the compilers paper over this by temporarily dodging the issue and inhibiting dead variable elimination for references, we are giving people a continued excuse to ignore the need for adding reachabilityFences to their code. And this situation will probably continue (for practical purposes) at least as long as using reachabilityFence in the above common form is not optimized in practice to be equivalent to just inhibiting dead variable elimination of (this) across the same scope [and not just implemented as a much more expensive opaque method effect].

This makes the subject somewhat premature for wide public education IMO. A practical set of steps might look like this:

0. Add Reference.reachabilityFence() to the platform [this is basically the existing "collect underpants" step]

1. make try { } finally { Reference.reachabilityFence(this); } optimize well (to be no more expensive than inhibiting dead variable elimination for 'this' across the try block).

2. Change JDK code to actually make use of this code idiom in the various places where it is actually needed for correctness.

3. Relax compiler limitation crutches that currently help make the correctness bugs not trigger often. But do so first with a non-default -XX flag, and later transition to default with a backout flag (since a lot of user code will start breaking when the crutch is taken away).

4. Educate and evangelize for proper use of Reference.reachabilityFence(this); (maybe even add a method annotation for people who like that sort of thing? E.g. @AlwaysReachableThis)

5. Profit


> On Apr 1, 2017, at 10:19 AM, Hans Boehm <hboehm at google.com> wrote:
> 
> That also sounds fine to me.
> 
> The difficulty with applying this, especially in the JNI case, is that you
> may need several reachability fences at the end of each method, guarding
> parameters and temporaries, not all of which may be naturally in scope at
> the end. But we're not going to be able to include a full discussion here.
> 
> In the interest of full disclosure, we currently, at least temporarily,
> dodge this issue by inhibiting dead variable elimination for references.
> 
> 
> On Apr 1, 2017 01:55, "Andrew Haley" <aph at redhat.com> wrote:
> 
> On 31/03/17 19:56, Hans Boehm wrote:
>> This method should be used when cleanup actions (finalize() calls, or
>> Reference enqueuing, Cleaner invocation) could otherwise be triggered
> while
>> a resource under control of the object is still in use. This method should
>> normally be called when these cleanup facilities are used to perform
>> actions other than simply issuing a warning.
> 
> It's still pretty confusing.  It would be simpler to say that
> reachabilityFence should be used at the end of every method of a class
> which has cleanup actions if you don't want those cleanup actions to
> be run before the end of that method.  In that case, reachabilityFence
> only makes any difference in cases where otherwise you'd have a bug.
> 
> Andrew.


From hboehm at google.com  Sat Apr 15 17:14:57 2017
From: hboehm at google.com (Hans Boehm)
Date: Sat, 15 Apr 2017 10:14:57 -0700
Subject: RFR 9: 8165641 : Deprecate Object.finalize
In-Reply-To: <C40E2BA5-0B35-4053-BFDA-796B6E3C73AE@azul.com>
References: <c7893765-1c5b-18e3-c5f3-a9ccf9b05094@Oracle.com>
 <96fe9ae0-993a-aea6-cabf-f079450dc128@Oracle.com>
 <49eb0b85-130a-b74d-e760-120674de6ebc@oracle.com>
 <CAMOCf+iAT-29E0wu8WFcNiZq1di1xCq=-kSwjdfhkq2cEA1iJA@mail.gmail.com>
 <f25ac4e3-cfba-ea53-2827-775a18d508ad@redhat.com>
 <CAMOCf+j8k5kiTP0_Ue6yO3+68iNUKJvVZLostKZEJoudkDRd2A@mail.gmail.com>
 <C40E2BA5-0B35-4053-BFDA-796B6E3C73AE@azul.com>
Message-ID: <CAMOCf+iX-miX8MkH93qU9iJHJpTsZRO-gKm4KRkbUTKbjW6AYw@mail.gmail.com>

The approach Gil is advocating certainly has its attraction. The reason I'm
not really enthusiastic, and don't really view the language design problem
as solved anymore, is that I'm no longer certain that the majority of
programmers will ever be able to use reachabilityFence correctly. The rules
are really, really subtle and unintuitive, especially for JNI-intensive
code. I don't have a termination proof for Gil's step 4.

Android's BigInt.java is a good illustration of the problem. This is a
wrapper around a native (BoringSSL) bignum package, which generally
forwards most operations directly to native code. But functions routinely
take BigInt arguments in addition to "this". Those each need
reachabilityFences, even for those that currently have one-liner
implementations. Often temporary BigInts are allocated, filled in, and
possibly returned as results. Those need reachabilityFences, just in case
the result is not used. The rules for constructors are not 100% clear to
me. But I think those, counterintuitively, also generally need
reachabilityFences to deal with the case in which the protected field is
not subsequently used. I have little confidence I could get this right
without a number of iterations.

I agree that it would be good to make the JDK reachabilityFence-correct.
It's the only available tool, so it's necessary for correctness. But I
would also view it as a feasibility experiment, keeping in mind that the
hardest code to deal with is probably in third-party libraries. My guess is
that we haven't gotten to the final solution here.

On Sat, Apr 15, 2017 at 8:51 AM, Gil Tene <gil at azul.com> wrote:

> IMO, so long as the JDK's own performance-sensitive methods do not follow
> this advice, it will be hard to "educate" people to use reachabilityFence
> responsibly.
>
> To be specific:
>
> As long as java.nioDirectByteBuffer.get() is effectively coded like this
> (after the templates are applied):
>
>     public byte get() {
>         return (unsafe.getByte(ix(nextGetIndex())));
>     }
>
> Instead of like this:
>
>     public byte get() {
>         try {
>                 return (unsafe.getByte(ix(nextGetIndex())));
>         } finally {
>                 Reference.reachabilityFence(this);
>         }
>     }
>
> People will copy it and extend on it, replicating the reachability bug and
> the use-after-free problem in the current code.
>
> It is hard to ask people to code "responsibly" when the JDK itself
> doesn't. This is especially true when the bug in the above code is not
> obvious, and (as Hans points out earlier) it takes a long time to convince
> people it actually exists. This is especially true since the "well, when
> was the last time someone complained about DirectByteBuffer.get() doing
> getting a SEGV on access to a freed buffer?" argument holds some water. And
> that's where you actually end up usually when discussing the above missing
> reachabilityFence?
>
> A few things are keeping the JDK code from evolving to properly use
> Reference.reachabilityFence(this):
>
> a. It didn't exist until recently. [That's a very good excuse]
>
> b. While Reference.reachabilityFence exists now, it's implementation is
> sub-optimal. IUUC it is modeled [currently] as an opaque method call, which
> prohibits enough useful optimizations to significantly hurt
> DirectByteBuffer.get() if it were actually included in the code right now.
>
> c. As Hans notes below, the compilers may temporarily dodge this issue by
> inhibiting dead variable elimination for references. They do so to allow
> the actual (semantically buggy) current JDK code to execute safely and
> performantly.
>
> As long as the compilers paper over this by temporarily dodging the issue
> and inhibiting dead variable elimination for references, we are giving
> people a continued excuse to ignore the need for adding reachabilityFences
> to their code. And this situation will probably continue (for practical
> purposes) at least as long as using reachabilityFence in the above common
> form is not optimized in practice to be equivalent to just inhibiting dead
> variable elimination of (this) across the same scope [and not just
> implemented as a much more expensive opaque method effect].
>
> This makes the subject somewhat premature for wide public education IMO. A
> practical set of steps might look like this:
>
> 0. Add Reference.reachabilityFence() to the platform [this is basically
> the existing "collect underpants" step]
>
> 1. make try { } finally { Reference.reachabilityFence(this); } optimize
> well (to be no more expensive than inhibiting dead variable elimination for
> 'this' across the try block).
>
> 2. Change JDK code to actually make use of this code idiom in the various
> places where it is actually needed for correctness.
>
> 3. Relax compiler limitation crutches that currently help make the
> correctness bugs not trigger often. But do so first with a non-default -XX
> flag, and later transition to default with a backout flag (since a lot of
> user code will start breaking when the crutch is taken away).
>
> 4. Educate and evangelize for proper use of Reference.reachabilityFence(this);
> (maybe even add a method annotation for people who like that sort of thing?
> E.g. @AlwaysReachableThis)
>
> 5. Profit
>
>
> > On Apr 1, 2017, at 10:19 AM, Hans Boehm <hboehm at google.com> wrote:
> >
> > That also sounds fine to me.
> >
> > The difficulty with applying this, especially in the JNI case, is that
> you
> > may need several reachability fences at the end of each method, guarding
> > parameters and temporaries, not all of which may be naturally in scope at
> > the end. But we're not going to be able to include a full discussion
> here.
> >
> > In the interest of full disclosure, we currently, at least temporarily,
> > dodge this issue by inhibiting dead variable elimination for references.
> >
> >
> > On Apr 1, 2017 01:55, "Andrew Haley" <aph at redhat.com> wrote:
> >
> > On 31/03/17 19:56, Hans Boehm wrote:
> >> This method should be used when cleanup actions (finalize() calls, or
> >> Reference enqueuing, Cleaner invocation) could otherwise be triggered
> > while
> >> a resource under control of the object is still in use. This method
> should
> >> normally be called when these cleanup facilities are used to perform
> >> actions other than simply issuing a warning.
> >
> > It's still pretty confusing.  It would be simpler to say that
> > reachabilityFence should be used at the end of every method of a class
> > which has cleanup actions if you don't want those cleanup actions to
> > be run before the end of that method.  In that case, reachabilityFence
> > only makes any difference in cases where otherwise you'd have a bug.
> >
> > Andrew.
>
>

From martinrb at google.com  Sat Apr 15 17:34:52 2017
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 15 Apr 2017 10:34:52 -0700
Subject: JDK 9 RFR(s): 8177789 fix collections framework links to point to
 java.util package doc
In-Reply-To: <fdc2cef2-6615-9df9-5dff-a179604ab946@oracle.com>
References: <fdc2cef2-6615-9df9-5dff-a179604ab946@oracle.com>
Message-ID: <CA+kOe0_qSf=faKiLsZ21cW9TYyZWo2Ri76dvqGi8wb+FLVrPqQ@mail.gmail.com>

On Fri, Apr 14, 2017 at 3:36 PM, Stuart Marks <stuart.marks at oracle.com>
wrote:

>
> Martin,
>
> This changeset includes a bunch of changes to java.util.concurrent
> classes, as well as to files like ArrayDeque which straddle the border
> between the JDK and the JSR166 repo. How did you want to handle these
> changes? I could just push this and you could merge upstream, or I could
> slice off the diffs from selected files and have you put them into JSR166
> and then merge into the JDK. In any case, the changes are all one-liners,
> so I don't expect any conflicts. Let me know.
>

Just commit your changes; they look fine; we will merge into jsr166 CVS.

I have the usual doc-related gripes ... all the docs for openjdk should be
checked into mercurial so they can be maintained along with the classes
they document ... @index is new to me; I couldn't find any documentation
for it.

From aleksej.efimov at oracle.com  Sun Apr 16 22:02:35 2017
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Mon, 17 Apr 2017 01:02:35 +0300
Subject: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable
 reset
Message-ID: <adc0462f-5ff7-f881-ed1d-a05c5ce1ea0f@oracle.com>

Hi,

Please, help to review the fix [1] for a performance regression in 
SPECjvm2008-XML benchmark. The cause of this regression was the 
unconditional reset of SAX parsers symbol table during each reset() 
operation introduced by JDK-8173390.
Proposed fix introduces new system property (CCC request is still 
pending approval) that provides ability to control the symbol table 
reset functionality. By default the reset table functionality is 
disabled, similar to pre JDK-8173390 behavior. JAXWS parsers pool 
implementation was updated to utilize new property to reset symbol table 
only in JAXWS use-cases that helped to restore the performance levels to 
pre JDK-8173390 level.

Modified regression test and XML related JCK tests passes on build with 
proposed changes.

With Best Regards,
Aleksei

[1] http://cr.openjdk.java.net/~aefimov/8176168/00/

From sha.jiang at oracle.com  Mon Apr 17 02:52:58 2017
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 17 Apr 2017 10:52:58 +0800
Subject: RFR[9] JDK-8178840: Adds FieldSetAccessibleTest.java and
 VerifyJimage.java to ProblemList
Message-ID: <bbcff6f1-7d33-0954-5bef-d2fd5f1f86d8@oracle.com>

Hi,
Because of JDK-8178776, 
java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java and 
tools/jimage/VerifyJimage.java should be added to ProblemList.

diff -r 9ba6760481a8 test/ProblemList.txt
--- a/test/ProblemList.txt    Sat Apr 15 16:54:33 2017 -0400
+++ b/test/ProblemList.txt    Sun Apr 16 19:30:49 2017 -0700
@@ -124,6 +124,7 @@
  # jdk_lang

  java/lang/StringCoding/CheckEncodings.sh 7008363 generic-all
+java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java 8178776 
generic-all

  jdk/internal/misc/JavaLangAccess/NewUnsafeString.java 8176188 generic-all

@@ -255,6 +256,8 @@
  tools/jimage/JImageListTest.java 8170120 generic-all
  tools/jimage/JImageVerifyTest.java 8170120 generic-all

+tools/jimage/VerifyJimage.java 8178776 generic-all
+
  ############################################################################

  # jdk_jdi

Best regards,
John Jiang


From Alan.Bateman at oracle.com  Mon Apr 17 07:07:13 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 17 Apr 2017 08:07:13 +0100
Subject: RFR[9] JDK-8178840: Adds FieldSetAccessibleTest.java and
 VerifyJimage.java to ProblemList
In-Reply-To: <bbcff6f1-7d33-0954-5bef-d2fd5f1f86d8@oracle.com>
References: <bbcff6f1-7d33-0954-5bef-d2fd5f1f86d8@oracle.com>
Message-ID: <f4f640c5-407c-12e8-3029-e1ed632f49e2@oracle.com>

On 17/04/2017 03:52, sha.jiang at oracle.com wrote:

> Hi,
> Because of JDK-8178776, 
> java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java and 
> tools/jimage/VerifyJimage.java should be added to ProblemList.
>
Temporarily excluding these tests for a few days is okay. However, we 
need to get attention on the real issue, we should never create a 
run-time image containing types that can't link to their super types.

-Alan

From lance.andersen at oracle.com  Mon Apr 17 15:56:19 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 17 Apr 2017 11:56:19 -0400
Subject: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable
 reset
In-Reply-To: <adc0462f-5ff7-f881-ed1d-a05c5ce1ea0f@oracle.com>
References: <adc0462f-5ff7-f881-ed1d-a05c5ce1ea0f@oracle.com>
Message-ID: <D66EDFDB-6D79-42CA-AF5F-1FCF5E1BD8F3@oracle.com>

Hi Aleksei,

I think the change makes sense and pending CCC approval should be good to go :-)

Best
Lance
> On Apr 16, 2017, at 6:02 PM, Aleks Efimov <aleksej.efimov at oracle.com> wrote:
> 
> Hi,
> 
> Please, help to review the fix [1] for a performance regression in SPECjvm2008-XML benchmark. The cause of this regression was the unconditional reset of SAX parsers symbol table during each reset() operation introduced by JDK-8173390.
> Proposed fix introduces new system property (CCC request is still pending approval) that provides ability to control the symbol table reset functionality. By default the reset table functionality is disabled, similar to pre JDK-8173390 behavior. JAXWS parsers pool implementation was updated to utilize new property to reset symbol table only in JAXWS use-cases that helped to restore the performance levels to pre JDK-8173390 level.
> 
> Modified regression test and XML related JCK tests passes on build with proposed changes.
> 
> With Best Regards,
> Aleksei
> 
> [1] http://cr.openjdk.java.net/~aefimov/8176168/00/

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From brent.christian at oracle.com  Mon Apr 17 16:05:57 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 17 Apr 2017 09:05:57 -0700
Subject: JDK 9 RFR(s): 8177789 fix collections framework links to point to
 java.util package doc
In-Reply-To: <CA+kOe0_qSf=faKiLsZ21cW9TYyZWo2Ri76dvqGi8wb+FLVrPqQ@mail.gmail.com>
References: <fdc2cef2-6615-9df9-5dff-a179604ab946@oracle.com>
 <CA+kOe0_qSf=faKiLsZ21cW9TYyZWo2Ri76dvqGi8wb+FLVrPqQ@mail.gmail.com>
Message-ID: <d5a937da-5629-b626-9093-3baf78e55dc6@oracle.com>

On 4/15/17 10:34 AM, Martin Buchholz wrote:
>@index is new to me; I couldn't find any documentation
> for it.

@index is part of JEP 225, Javadoc Search (right?)

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

-Brent

From mandy.chung at oracle.com  Mon Apr 17 16:11:20 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 17 Apr 2017 09:11:20 -0700
Subject: RFR[9] JDK-8178840: Adds FieldSetAccessibleTest.java and
 VerifyJimage.java to ProblemList
In-Reply-To: <f4f640c5-407c-12e8-3029-e1ed632f49e2@oracle.com>
References: <bbcff6f1-7d33-0954-5bef-d2fd5f1f86d8@oracle.com>
 <f4f640c5-407c-12e8-3029-e1ed632f49e2@oracle.com>
Message-ID: <8DA24FCF-52CD-4AC0-9D63-2809DAF0AA6F@oracle.com>


> On Apr 17, 2017, at 12:07 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 17/04/2017 03:52, sha.jiang at oracle.com wrote:
> 
>> Hi,
>> Because of JDK-8178776, java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java and tools/jimage/VerifyJimage.java should be added to ProblemList.
>> 
> Temporarily excluding these tests for a few days is okay. However, we need to get attention on the real issue, we should never create a run-time image containing types that can't link to their super types.

Agree.  It?s fine to problem list these tests for a few days and resolve this soon.

Mandy


From paul.sandoz at oracle.com  Mon Apr 17 16:54:20 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 17 Apr 2017 09:54:20 -0700
Subject: RFR 9: 8165641 : Deprecate Object.finalize
In-Reply-To: <C40E2BA5-0B35-4053-BFDA-796B6E3C73AE@azul.com>
References: <c7893765-1c5b-18e3-c5f3-a9ccf9b05094@Oracle.com>
 <96fe9ae0-993a-aea6-cabf-f079450dc128@Oracle.com>
 <49eb0b85-130a-b74d-e760-120674de6ebc@oracle.com>
 <CAMOCf+iAT-29E0wu8WFcNiZq1di1xCq=-kSwjdfhkq2cEA1iJA@mail.gmail.com>
 <f25ac4e3-cfba-ea53-2827-775a18d508ad@redhat.com>
 <CAMOCf+j8k5kiTP0_Ue6yO3+68iNUKJvVZLostKZEJoudkDRd2A@mail.gmail.com>
 <C40E2BA5-0B35-4053-BFDA-796B6E3C73AE@azul.com>
Message-ID: <9AAE9B07-868A-4137-AA6E-8DB533F9FB73@oracle.com>


> On 15 Apr 2017, at 08:51, Gil Tene <gil at azul.com> wrote:
> A few things are keeping the JDK code from evolving to properly use Reference.reachabilityFence(this):
> 
> a. It didn't exist until recently. [That's a very good excuse]
> 
> b. While Reference.reachabilityFence exists now, it's implementation is sub-optimal. IUUC it is modeled [currently] as an opaque method call, which prohibits enough useful optimizations to significantly hurt DirectByteBuffer.get() if it were actually included in the code right now.
> 

Correct, reachabilityFence is sort of bodged using @DontInline, which was a fine technique for getting this method in, ok for stuff that ain?t so performance sensitive (many of the use cases?), but not really ok for use within DBB (and for Panama stuff). See:

  https://bugs.openjdk.java.net/browse/JDK-8169605 (IMHO the priority should be higher, P4 if not P3)
  https://bugs.openjdk.java.net/browse/JDK-8149610 (more for the comment).

Paul.

From naoto.sato at oracle.com  Mon Apr 17 19:47:51 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 17 Apr 2017 12:47:51 -0700
Subject: [9] RFR: 8177314: java VM fails to start with a Japanese ShiftJIS
 locale
Message-ID: <6b53e117-7fad-209c-2a87-5d8cd4868bc1@oracle.com>

Hi,

Please review the fix for the following issue:

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

The proposed change is located at:

http://cr.openjdk.java.net/~naoto/8177314/webrev.00/

The change is to move SJIS based encodings into java.base module on 
Linux so that SJIS locale can be used as the default locale to start the 
JVM. Although they are not the default locale in Linux distributions, 
they still seem to be widely used.

Naoto

From kim.barrett at oracle.com  Mon Apr 17 20:47:04 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 17 Apr 2017 16:47:04 -0400
Subject: RFR[9]: 8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue
 property is ignored
Message-ID: <A4B1416D-634E-4D1F-8790-504610DC2BA3@oracle.com>

Please review this fix for a bug in JDK-8175797: the mechanism
provided by that change for reverting to the old behavior of
Reference.enqueue (for backward compatibility) does not work.

Also fixed the ReferenceEnqueue test changes also made as part of
JDK-8175797.  That test would havecaught the problem with the property
but for bugs in the test.

CR:
https://bugs.openjdk.java.net/browse/JDK-8178832

Webrev:
http://cr.openjdk.java.net/~kbarrett/8178832/jdk00/

Testing:
Ran fixed test with unfixed enqueue, and verified expected failure.
Ran fixed test with fixed enqueue, and verified expected pass.


From mandy.chung at oracle.com  Mon Apr 17 20:53:16 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 17 Apr 2017 13:53:16 -0700
Subject: RFR[9]: 8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue
 property is ignored
In-Reply-To: <A4B1416D-634E-4D1F-8790-504610DC2BA3@oracle.com>
References: <A4B1416D-634E-4D1F-8790-504610DC2BA3@oracle.com>
Message-ID: <91D4AA88-F7FD-4268-B178-1C74B2CC9F47@oracle.com>


> On Apr 17, 2017, at 1:47 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> Please review this fix for a bug in JDK-8175797: the mechanism
> provided by that change for reverting to the old behavior of
> Reference.enqueue (for backward compatibility) does not work.
> 
> Also fixed the ReferenceEnqueue test changes also made as part of
> JDK-8175797.  That test would havecaught the problem with the property
> but for bugs in the test.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8178832
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8178832/jdk00/

Looks good.  Thanks for catching this and the typo in the test.

Mandy

From xueming.shen at oracle.com  Mon Apr 17 20:51:15 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 17 Apr 2017 13:51:15 -0700
Subject: [9] RFR: 8177314: java VM fails to start with a Japanese ShiftJIS
 locale
In-Reply-To: <6b53e117-7fad-209c-2a87-5d8cd4868bc1@oracle.com>
References: <6b53e117-7fad-209c-2a87-5d8cd4868bc1@oracle.com>
Message-ID: <58F52AC3.5060605@oracle.com>

looks fine.

On 04/17/2017 12:47 PM, Naoto Sato wrote:
> Hi,
>
> Please review the fix for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8177314
>
> The proposed change is located at:
>
> http://cr.openjdk.java.net/~naoto/8177314/webrev.00/
>
> The change is to move SJIS based encodings into java.base module on Linux so that SJIS locale can be used as the default locale to start the JVM. Although they are not the default locale in Linux distributions, they still seem to be widely used.
>
> Naoto


From mandy.chung at oracle.com  Mon Apr 17 21:08:56 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 17 Apr 2017 14:08:56 -0700
Subject: [9] RFR: 8177314: java VM fails to start with a Japanese ShiftJIS
 locale
In-Reply-To: <6b53e117-7fad-209c-2a87-5d8cd4868bc1@oracle.com>
References: <6b53e117-7fad-209c-2a87-5d8cd4868bc1@oracle.com>
Message-ID: <2652CD4B-BEF6-4E80-B2E6-FC50D5A1262C@oracle.com>


> On Apr 17, 2017, at 12:47 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Hi,
> 
> Please review the fix for the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8177314
> 
> The proposed change is located at:
> 
> http://cr.openjdk.java.net/~naoto/8177314/webrev.00/

Looks fine.  Just curious - how much does this add to java.base size?

Mandy

From naoto.sato at oracle.com  Mon Apr 17 21:28:50 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 17 Apr 2017 14:28:50 -0700
Subject: [9] RFR: 8177314: java VM fails to start with a Japanese ShiftJIS
 locale
In-Reply-To: <2652CD4B-BEF6-4E80-B2E6-FC50D5A1262C@oracle.com>
References: <6b53e117-7fad-209c-2a87-5d8cd4868bc1@oracle.com>
 <2652CD4B-BEF6-4E80-B2E6-FC50D5A1262C@oracle.com>
Message-ID: <50a40205-498f-e5f7-78ac-e14711a1ebef@oracle.com>

On 04/17/2017 02:08 PM, Mandy Chung wrote:

> Looks fine.  Just curious - how much does this add to java.base size?
>
> Mandy
>

On my test build, these two classes are now moved into java.base from 
jdk.charset:

-rw-r--r-- 1 nsato wheel 26711 Apr 17 14:25 SJIS.class
-rw-r--r-- 1 nsato wheel 38385 Apr 17 14:25 MS932.class

Naoto

From mandy.chung at oracle.com  Mon Apr 17 21:39:52 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 17 Apr 2017 14:39:52 -0700
Subject: [9] RFR: 8177314: java VM fails to start with a Japanese ShiftJIS
 locale
In-Reply-To: <50a40205-498f-e5f7-78ac-e14711a1ebef@oracle.com>
References: <6b53e117-7fad-209c-2a87-5d8cd4868bc1@oracle.com>
 <2652CD4B-BEF6-4E80-B2E6-FC50D5A1262C@oracle.com>
 <50a40205-498f-e5f7-78ac-e14711a1ebef@oracle.com>
Message-ID: <19F8B59C-084D-46DA-A853-A323BCA077D5@oracle.com>


> On Apr 17, 2017, at 2:28 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> On 04/17/2017 02:08 PM, Mandy Chung wrote:
> 
>> Looks fine.  Just curious - how much does this add to java.base size?
>> 
>> Mandy
>> 
> 
> On my test build, these two classes are now moved into java.base from jdk.charset:
> 
> -rw-r--r-- 1 nsato wheel 26711 Apr 17 14:25 SJIS.class
> -rw-r--r-- 1 nsato wheel 38385 Apr 17 14:25 MS932.class

Good to know. Thanks.

Mandy


From stuart.marks at oracle.com  Mon Apr 17 23:01:09 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 17 Apr 2017 16:01:09 -0700
Subject: JDK 9 RFR(s): 8177789 fix collections framework links to point to
 java.util package doc
In-Reply-To: <CA+kOe0_qSf=faKiLsZ21cW9TYyZWo2Ri76dvqGi8wb+FLVrPqQ@mail.gmail.com>
References: <fdc2cef2-6615-9df9-5dff-a179604ab946@oracle.com>
 <CA+kOe0_qSf=faKiLsZ21cW9TYyZWo2Ri76dvqGi8wb+FLVrPqQ@mail.gmail.com>
Message-ID: <f50b7082-337f-10c4-ef1e-ab2d79448623@oracle.com>



On 4/15/17 10:34 AM, Martin Buchholz wrote:
> Just commit your changes; they look fine; we will merge into jsr166 CVS.

OK, will do, thanks.

> I have the usual doc-related gripes ... all the docs for openjdk should be
> checked into mercurial so they can be maintained along with the classes they
> document

Yeah, docs are a problem, as usual. There is some progress, though. See JEP 299 
[1] which proposes to reorganize the docs from the "brick wall" diagram. At 
least the various specification documents buried under here (e.g., JNI, 
Serialization, ..., but not JVMS & JLS) will end up in OpenJDK. Various bits of 
docs about component technologies will also be moved into OpenJDK, as I've 
proposed to do for collections with JDK-8177788.

s'marks

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


From Alan.Bateman at oracle.com  Tue Apr 18 07:42:09 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 18 Apr 2017 08:42:09 +0100
Subject: [9] RFR: 8177314: java VM fails to start with a Japanese ShiftJIS
 locale
In-Reply-To: <6b53e117-7fad-209c-2a87-5d8cd4868bc1@oracle.com>
References: <6b53e117-7fad-209c-2a87-5d8cd4868bc1@oracle.com>
Message-ID: <2f5efafc-8860-1d7c-8105-88c20ad606c5@oracle.com>

On 17/04/2017 20:47, Naoto Sato wrote:

> Hi,
>
> Please review the fix for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8177314
>
> The proposed change is located at:
>
> http://cr.openjdk.java.net/~naoto/8177314/webrev.00/
>
> The change is to move SJIS based encodings into java.base module on 
> Linux so that SJIS locale can be used as the default locale to start 
> the JVM. Although they are not the default locale in Linux 
> distributions, they still seem to be widely used.
Looks good. Is there anything to check into on other platforms or is 
this just a Linux only concern.

-Alan

From claes.redestad at oracle.com  Tue Apr 18 12:28:27 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 18 Apr 2017 14:28:27 +0200
Subject: RFR: 8178889: Move creation of AbstractChronology comparators to call
 sites
Message-ID: <8b9e41a9-69ae-6d38-bf01-ef7351d5a031@oracle.com>

Hi,

in AbstractChronology we define a number of comparators which could be 
moved to their
respective call site and thus be lazily initialized when needed with no 
performance
penalty.

Bug: https://bugs.openjdk.java.net/browse/JDK-8178889
Webrev: http://cr.openjdk.java.net/~redestad/8178889/jdk.01/

Testing/analysis:
- naive micro to show this doesn't cause a regression in steady 
state[1], for those in
doubt
- reduces executed bytecode by ~127K and drops 5 generated classes from 
startup of
applications that depend on AbstractChronology but don't use any of 
these comparators
- pass all java/time tests

Thanks!

/Claes

[1]
package org.openjdk;
import org.openjdk.jmh.annotations.Benchmark;
import java.time.chrono.*;
import java.lang.reflect.*;

public class ChronoComparatorBench {

     public static Method timeLineOrder;

     static {
         try {
             timeLineOrder = 
ChronoLocalDate.class.getDeclaredMethod("timeLineOrder");
         } catch (Exception e) {
             throw new RuntimeException(e);
         }
     }

     @Benchmark
     public Object getComparator() throws Exception {
         return timeLineOrder.invoke(null);
     }
}

-f 1 -tu us -bm avgt

Benchmark                            Mode  Cnt  Score   Error Units
ChronoComparatorBench.getComparator  avgt   20 5.979 ? 0.067  ns/op  # 
before
ChronoComparatorBench.getComparator  avgt   20 5.975 ? 0.054  ns/op  # after

From Roger.Riggs at Oracle.com  Tue Apr 18 15:00:17 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 18 Apr 2017 11:00:17 -0400
Subject: RFR: 8178889: Move creation of AbstractChronology comparators to
 call sites
In-Reply-To: <8b9e41a9-69ae-6d38-bf01-ef7351d5a031@oracle.com>
References: <8b9e41a9-69ae-6d38-bf01-ef7351d5a031@oracle.com>
Message-ID: <2b8b6023-3224-bbed-649c-18acebe1ed85@Oracle.com>

Hi Claes,

Looks fine

Roger

On 4/18/2017 8:28 AM, Claes Redestad wrote:
> Hi,
>
> in AbstractChronology we define a number of comparators which could be 
> moved to their
> respective call site and thus be lazily initialized when needed with 
> no performance
> penalty.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178889
> Webrev: http://cr.openjdk.java.net/~redestad/8178889/jdk.01/
>
> Testing/analysis:
> - naive micro to show this doesn't cause a regression in steady 
> state[1], for those in
> doubt
> - reduces executed bytecode by ~127K and drops 5 generated classes 
> from startup of
> applications that depend on AbstractChronology but don't use any of 
> these comparators
> - pass all java/time tests
>
> Thanks!
>
> /Claes
>
> [1]
> package org.openjdk;
> import org.openjdk.jmh.annotations.Benchmark;
> import java.time.chrono.*;
> import java.lang.reflect.*;
>
> public class ChronoComparatorBench {
>
>     public static Method timeLineOrder;
>
>     static {
>         try {
>             timeLineOrder = 
> ChronoLocalDate.class.getDeclaredMethod("timeLineOrder");
>         } catch (Exception e) {
>             throw new RuntimeException(e);
>         }
>     }
>
>     @Benchmark
>     public Object getComparator() throws Exception {
>         return timeLineOrder.invoke(null);
>     }
> }
>
> -f 1 -tu us -bm avgt
>
> Benchmark                            Mode  Cnt  Score   Error Units
> ChronoComparatorBench.getComparator  avgt   20 5.979 ? 0.067 ns/op  # 
> before
> ChronoComparatorBench.getComparator  avgt   20 5.975 ? 0.054 ns/op  # 
> after


From naoto.sato at oracle.com  Tue Apr 18 15:48:09 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 18 Apr 2017 08:48:09 -0700
Subject: [9] RFR: 8177314: java VM fails to start with a Japanese ShiftJIS
 locale
In-Reply-To: <2f5efafc-8860-1d7c-8105-88c20ad606c5@oracle.com>
References: <6b53e117-7fad-209c-2a87-5d8cd4868bc1@oracle.com>
 <2f5efafc-8860-1d7c-8105-88c20ad606c5@oracle.com>
Message-ID: <c245fb69-369e-3335-2c64-21a70a35f58a@oracle.com>

Hi Alan,

On 4/18/17 12:42 AM, Alan Bateman wrote:
>> The change is to move SJIS based encodings into java.base module on
>> Linux so that SJIS locale can be used as the default locale to start
>> the JVM. Although they are not the default locale in Linux
>> distributions, they still seem to be widely used.
> Looks good. Is there anything to check into on other platforms or is
> this just a Linux only concern.

Java runtime for Windows already includes SJIS in java.base so there 
should be no issue there. I don't see any convincing reason for 
macOS/Solaris to have SJIS in java.base, as Solaris has PCK which is 
SJIS equivalent, and macOS has been using UTF-8 as the default at least 
since MacOSX was released.

Naoto

From volker.simonis at gmail.com  Tue Apr 18 17:44:37 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 18 Apr 2017 19:44:37 +0200
Subject: [9] RFR(S): 8178726: Can't load classes from classpath if it is a
 UNC share
In-Reply-To: <4067cfb5-a01c-73e3-7f5d-c4d729830b28@oracle.com>
References: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>
 <2a1ec694-f3d4-ca25-a08c-36b7d3511bdf@oracle.com>
 <4067cfb5-a01c-73e3-7f5d-c4d729830b28@oracle.com>
Message-ID: <CA+3eh133fMLYOL=vxgARCBhdFW3yodr13GoTKZ7SzUtTd65u6A@mail.gmail.com>

Hi Alan, Chris,

thanks for your help and feedback.
It seems my fix was indeed "too optimistic". I've only briefly looked into
the errors reported by Chris. The first one is due to a cyclic dependency
between Paths.get() and FileSystems.getDefault().

So I've finally decided to go with Alan's proposal which is probably the
least invasive one:

http://cr.openjdk.java.net/~simonis/webrevs/2017/8178726.v1/

It would be great if someone could verify this new version once again by
running it through JPRT (I've verified that the reported problems don't
occur any more, but who knows :)

Thank you and best regards,
Volker


On Fri, Apr 14, 2017 at 3:13 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 14/04/2017 14:02, Chris Hegarty wrote:
>
>
>> I know that Alan has provided some comments on this, but I just
>> grabbed your patch and sent it through our internal build and test
>> system. I observed a few failures:
>>
> Yes, I think URLClassLoader will be broken (Max is right, I forgot that
> URLClassPath is essentially the implementation of URLClassLoader).
>
> I think Volker will need to change this so that
> ClassLoaders.toFileURL(String) uses toFile().toURI().toURL(). That will
> ensure that URLClassPath doesn't get URLs with the server name in the
> authority component.
>
> -Alan
>

From Roger.Riggs at Oracle.com  Tue Apr 18 17:48:28 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 18 Apr 2017 13:48:28 -0400
Subject: RFR [9] 8177738: Runtime.Version must be a value-based class
In-Reply-To: <4547C274-290D-442F-BBD6-AB7E7837936A@oracle.com>
References: <F30BD3B5-723E-4688-81AB-7A30BD8C8474@oracle.com>
 <FB9AF92C-FA60-4E00-A68B-8DBE55910C33@oracle.com>
 <23774589-8C1C-4BA1-B5E8-4A25BCF58560@oracle.com>
 <4547C274-290D-442F-BBD6-AB7E7837936A@oracle.com>
Message-ID: <e8a631a0-c695-827e-4a7c-59044e50c2e8@Oracle.com>

Hi Pavel,

These changes look fine.

I think you can update the JEP to match the updated patterns mentioned 
below.

Regards, Roger


On 4/3/2017 7:50 PM, Paul Sandoz wrote:
>> On 3 Apr 2017, at 16:40, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>
>>
>>> On 3 Apr 2017, at 20:39, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> 962 * [1-9][0-9]*((\.0)*\.[1-9][0-9]*)*
>>>
>>> You removed the initial ?^? which is still mentioned in JDK-8148822
>>>
>>> < `^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$`. The sequence may be of arbitrary
>>> ---
>>>> `^[1-9][0-9]*((\.0)*\.[1-9][0-9]*)*$`. The sequence may be of arbitrary
>>> JEP 223 is still using the former. Which is correct?
>> The patch from the thread [1] I referred to in my previous email removes ^ and $.
>> So in this case I simply reused the patch and, once again [2], I do agree this
>> is an odd place to use boundary matchers, given $VNUM is only a prefix in $VSTR
>> and not the whole regex.
>>
>> As for the JEP question, it's more for original designers/authors. If we agree
>> on it I will update the JEP.
>>
> Ok, no objections, i was just unsure as to which was the proposed authoritative answer. Perhaps for the record you should also update the description of JDK-8148822?
>
>
>>> Since Version is now value based i think you need to check where it?s identity is used and replace with equals (which means ensuring that equals is efficient and could use identity under the covers). See usages in JarFile.
>> Will do, thanks!
>>
>>> ?
>>>
>>> Separately i wish we could avoid using List<Integer> as the internal representation, it?s very inefficient, int[] is much better, the cost is then on the version() method but it?s easy to create an immutable List wrapping the array. (I logged an issue for that, but cannot remember the number.)
>> What are you concerns specifically?
> It?s just not particularly efficient to box int to Integer into a List on the heap esp for the expected number of version components, and i suspect the version() method probably not something that will often be called, so taking a hit there with a AbstractList wrapper is fine. It?s quite a simple change, esp. with the the foundation you have set up, so seems worthwhile (separate issue, not this one).
>
> Paul.
>
>
>> The startup time?
>> The amount of simultaneously existing Version objects at runtime?
>> The use of `Integer` wrapper?
>>
>> --------------------------------------------------------------------------------
>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-October/044277.html
>> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046941.html
>>
>>


From alexandre.iline at oracle.com  Tue Apr 18 18:19:45 2017
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Tue, 18 Apr 2017 11:19:45 -0700
Subject: RFR: 8178910 Problemlist sample tests
Message-ID: <4E80B9C3-5C79-4FCD-B84F-22AFC8E88639@oracle.com>

Hi.

Could you please review a quick fix to temporarily disable a couple of tests:

$ hg diff ProblemList.txt 
diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -308,4 +308,7 @@
 
 org/omg/CORBA/OrbPropertiesTest.java			        8175177 generic-all
 
+sample/mergesort/MergeSortTest.java				8178912 generic-all
+sample/chatserver/ChatTest.java					8178912 generic-all
+
 ############################################################################
$

Thank you.

Shura


From joe.darcy at oracle.com  Tue Apr 18 18:22:28 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 18 Apr 2017 11:22:28 -0700
Subject: RFR: 8178910 Problemlist sample tests
In-Reply-To: <4E80B9C3-5C79-4FCD-B84F-22AFC8E88639@oracle.com>
References: <4E80B9C3-5C79-4FCD-B84F-22AFC8E88639@oracle.com>
Message-ID: <139fb042-6af5-a56f-3876-791843d99402@oracle.com>

Looks fine Shura; thanks,

-Joe


On 4/18/2017 11:19 AM, Alexandre (Shura) Iline wrote:
> Hi.
>
> Could you please review a quick fix to temporarily disable a couple of tests:
>
> $ hg diff ProblemList.txt
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -308,4 +308,7 @@
>   
>   org/omg/CORBA/OrbPropertiesTest.java			        8175177 generic-all
>   
> +sample/mergesort/MergeSortTest.java				8178912 generic-all
> +sample/chatserver/ChatTest.java					8178912 generic-all
> +
>   ############################################################################
> $
>
> Thank you.
>
> Shura
>


From lance.andersen at oracle.com  Tue Apr 18 18:26:00 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 18 Apr 2017 14:26:00 -0400
Subject: RFR: 8178910 Problemlist sample tests
In-Reply-To: <4E80B9C3-5C79-4FCD-B84F-22AFC8E88639@oracle.com>
References: <4E80B9C3-5C79-4FCD-B84F-22AFC8E88639@oracle.com>
Message-ID: <31A01CA7-686D-45B2-877C-BE17843A0733@oracle.com>

+1
> On Apr 18, 2017, at 2:19 PM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
> 
> Hi.
> 
> Could you please review a quick fix to temporarily disable a couple of tests:
> 
> $ hg diff ProblemList.txt 
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -308,4 +308,7 @@
> 
> org/omg/CORBA/OrbPropertiesTest.java			        8175177 generic-all
> 
> +sample/mergesort/MergeSortTest.java				8178912 generic-all
> +sample/chatserver/ChatTest.java					8178912 generic-all
> +
> ############################################################################
> $
> 
> Thank you.
> 
> Shura
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From kumar.x.srinivasan at oracle.com  Tue Apr 18 18:39:08 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 18 Apr 2017 11:39:08 -0700
Subject: RFR: 8076417: Update test/jdk/asm/AsmSanity.java with modules
Message-ID: <58F65D4C.9000707@oracle.com>

Hello,

Please review [1] which addresses bug [2]. This test is unnecessary, as 
there
are other components and tests within the jdk, which will fail if ASM
is not included, therefore this test is  removed.

Thanks
Kumar

[1] http://cr.openjdk.java.net/~ksrini/8076417/webrev.00/
[2] https://bugs.openjdk.java.net/browse/JDK-8076417

From stuart.marks at oracle.com  Wed Apr 19 01:23:24 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 18 Apr 2017 18:23:24 -0700
Subject: JDK 9 RFR(s): 8167981: Optional: add notes explaining intended use
Message-ID: <247a3b98-3304-97a9-3a49-23d81350b3bc@oracle.com>

Hi all,

Please review this small set of non-normative documentation changes for 
java.util.Optional and related classes.

The notes describe the primary intent of Optional to be used as a return value, 
and recommend avoiding using null as the value of a variable of Optional type. 
Also, a note is added to get() directing readers to look at orElse() and 
orElseGet().

Corresponding changes are also made to the primitive specializations 
OptionalDouble, OptionalInt, and OptionalLong.

Bug:
	https://bugs.openjdk.java.net/browse/JDK-8167981

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

Thanks,

s'marks

From sundararajan.athijegannathan at oracle.com  Wed Apr 19 02:54:23 2017
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 19 Apr 2017 08:24:23 +0530
Subject: RFR: 8076417: Update test/jdk/asm/AsmSanity.java with modules
In-Reply-To: <58F65D4C.9000707@oracle.com>
References: <58F65D4C.9000707@oracle.com>
Message-ID: <58F6D15F.7020402@oracle.com>

+1

-Sundar

On 19/04/17, 12:09 AM, Kumar Srinivasan wrote:
> Hello,
>
> Please review [1] which addresses bug [2]. This test is unnecessary, 
> as there
> are other components and tests within the jdk, which will fail if ASM
> is not included, therefore this test is  removed.
>
> Thanks
> Kumar
>
> [1] http://cr.openjdk.java.net/~ksrini/8076417/webrev.00/
> [2] https://bugs.openjdk.java.net/browse/JDK-8076417

From martinrb at google.com  Wed Apr 19 03:29:52 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 18 Apr 2017 20:29:52 -0700
Subject: JDK 9 RFR(s): 8167981: Optional: add notes explaining intended use
In-Reply-To: <247a3b98-3304-97a9-3a49-23d81350b3bc@oracle.com>
References: <247a3b98-3304-97a9-3a49-23d81350b3bc@oracle.com>
Message-ID: <CA+kOe0-D+K6rDUqdRjSTvNFtmPcDmdS38Tpt2k5QzW8wzhBUww@mail.gmail.com>

+     * The methods {@link #orElse(java.lang.Object) orElse()} and

It's sad that in 2017 we still can't write
{@link #orElse(T)}
... but ... we can and should write
{@link #orElse(Object) orElse(T)}
making the source and html more readable (orElse is not nullary)

+ * {@code OptionalDouble} is primarily intended for use as a method return
type where
+ * there is a clear need to represent "no result," and where using {@code
null}
+ * is likely to cause errors. A variable whose type is {@code
OptionalDouble} should

The obvious alternative to returning OptionalDouble is returning double,
where null is not possible. I would elide """and where using {@code null}
+ * is likely to cause errors""" unless you want to explicitly compare with
the alternative of returning Double,not double.

(More generally, it seems like Optional would have more value if there was
compiler enforcement of its never-null-ness.)


On Tue, Apr 18, 2017 at 6:23 PM, Stuart Marks <stuart.marks at oracle.com>
wrote:

> Hi all,
>
> Please review this small set of non-normative documentation changes for
> java.util.Optional and related classes.
>
> The notes describe the primary intent of Optional to be used as a return
> value, and recommend avoiding using null as the value of a variable of
> Optional type. Also, a note is added to get() directing readers to look at
> orElse() and orElseGet().
>
> Corresponding changes are also made to the primitive specializations
> OptionalDouble, OptionalInt, and OptionalLong.
>
> Bug:
>         https://bugs.openjdk.java.net/browse/JDK-8167981
>
> Webrev:
>         http://cr.openjdk.java.net/~smarks/reviews/8167981/webrev.0/
>
> Thanks,
>
> s'marks
>

From amy.lu at oracle.com  Wed Apr 19 03:32:22 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 19 Apr 2017 11:32:22 +0800
Subject: RFR: 8076417: Update test/jdk/asm/AsmSanity.java with modules
In-Reply-To: <58F65D4C.9000707@oracle.com>
References: <58F65D4C.9000707@oracle.com>
Message-ID: <59658d95-45d5-6f84-b478-23b4250b3ce5@oracle.com>

Hi, Kumar

As the removed test is the only one test under jdk/asm, it needs to be 
removed from jdk_other test group:

--- a/test/TEST.groups
+++ b/test/TEST.groups
@@ -269,7 +269,6 @@
      javax/transaction \
      javax/xml \
      -javax/xml/crypto \
-    jdk/asm \


Thanks,
Amy

On 4/19/17 2:39 AM, Kumar Srinivasan wrote:
> Hello,
>
> Please review [1] which addresses bug [2]. This test is unnecessary, 
> as there
> are other components and tests within the jdk, which will fail if ASM
> is not included, therefore this test is  removed.
>
> Thanks
> Kumar
>
> [1] http://cr.openjdk.java.net/~ksrini/8076417/webrev.00/
> [2] https://bugs.openjdk.java.net/browse/JDK-8076417


From Sunny.Chan at gs.com  Wed Apr 19 04:44:20 2017
From: Sunny.Chan at gs.com (Chan, Sunny)
Date: Wed, 19 Apr 2017 04:44:20 +0000
Subject: "unsafe" instances in sun.nio.fs.WindowsFileSystem
Message-ID: <7540281ca3c7401c8de96b2cf7b11faa@gsdghkp03etn1.firmwide.corp.gs.com>

While reading the code for sun.nio.fs.WindowsFileSystemProvider and sun.nio.fs.WindowsUserDefinedFileAttributeView, I noticed that there is a private static variable to the Unsafe instance but it doesn't seems to be used anywhere in the code - am I missing something here or should I propose a patch to remove them?

Sunny Chan
Executive Director
Technology

Goldman Sachs (Asia) L.L.C. | 39th Floor | The Center | 99 Queens Road Central | Hong Kong
Email:  sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633

Learn more about Goldman Sachs
GS.com<http://www.goldmansachs.com/> | Blog<http://www.goldmansachs.com/careers/blog/index.html> | LinkedIn<http://www.linkedin.com/company/goldman-sachs/careers> | YouTube<http://www.youtube.com/goldmansachs> | Twitter<http://www.twitter.com/goldmansachs>

This message may contain information that is confidential or privileged.  If you are not the intended recipient, please advise the sender immediately and delete this message.  See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks inherent in electronic communication.


From Alan.Bateman at oracle.com  Wed Apr 19 06:44:05 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Apr 2017 07:44:05 +0100
Subject: "unsafe" instances in sun.nio.fs.WindowsFileSystem
In-Reply-To: <7540281ca3c7401c8de96b2cf7b11faa@gsdghkp03etn1.firmwide.corp.gs.com>
References: <7540281ca3c7401c8de96b2cf7b11faa@gsdghkp03etn1.firmwide.corp.gs.com>
Message-ID: <00694934-e867-30a6-efde-714979d336c7@oracle.com>

On 19/04/2017 05:44, Chan, Sunny wrote:

> While reading the code for sun.nio.fs.WindowsFileSystemProvider and sun.nio.fs.WindowsUserDefinedFileAttributeView, I noticed that there is a private static variable to the Unsafe instance but it doesn't seems to be used anywhere in the code - am I missing something here or should I propose a patch to remove them?
>
I suspect these are left over from past refactoring and shouldn't be an 
issue removing them.

-Alan

From Alan.Bateman at oracle.com  Wed Apr 19 07:03:57 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Apr 2017 08:03:57 +0100
Subject: [9] RFR(S): 8178726: Can't load classes from classpath if it is a
 UNC share
In-Reply-To: <CA+3eh133fMLYOL=vxgARCBhdFW3yodr13GoTKZ7SzUtTd65u6A@mail.gmail.com>
References: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>
 <2a1ec694-f3d4-ca25-a08c-36b7d3511bdf@oracle.com>
 <4067cfb5-a01c-73e3-7f5d-c4d729830b28@oracle.com>
 <CA+3eh133fMLYOL=vxgARCBhdFW3yodr13GoTKZ7SzUtTd65u6A@mail.gmail.com>
Message-ID: <a95ed6fe-ba7d-0d5c-f8d3-93e2a8b48355@oracle.com>

On 18/04/2017 18:44, Volker Simonis wrote:

> Hi Alan, Chris,
>
> thanks for your help and feedback.
> It seems my fix was indeed "too optimistic". I've only briefly looked 
> into the errors reported by Chris. The first one is due to a cyclic 
> dependency between Paths.get() and FileSystems.getDefault().
>
> So I've finally decided to go with Alan's proposal which is probably 
> the least invasive one:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8178726.v1/ 
> <http://cr.openjdk.java.net/%7Esimonis/webrevs/2017/8178726.v1/>
>
> It would be great if someone could verify this new version once again 
> by running it through JPRT (I've verified that the reported problems 
> don't occur any more, but who knows :)
I ran it through the build+test system and don't see any issues. It's 
great that you found this issue before GA, I suspect testing with a 
directory of .class files on a UNC isn't too common (for performance 
reasons) which is why it wasn't noticed (the issue has been in JDK 9 for 
more than a year).

One additional suggestion is to include a comment, something like:

// use File::toURL as URLClassPath can't handle URLs with a UNC
// server name in the authority component

as it won't be immediately clear to readers why the toFile() is needed 
in the chain.

-Alan

From peter.levart at gmail.com  Wed Apr 19 09:02:31 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 19 Apr 2017 11:02:31 +0200
Subject: RFR[9]: 8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue
 property is ignored
In-Reply-To: <91D4AA88-F7FD-4268-B178-1C74B2CC9F47@oracle.com>
References: <A4B1416D-634E-4D1F-8790-504610DC2BA3@oracle.com>
 <91D4AA88-F7FD-4268-B178-1C74B2CC9F47@oracle.com>
Message-ID: <69c4ee3b-bea7-cdb6-97f4-c8e428bed1fd@gmail.com>

Hi Mandy, Kim,

On 04/17/2017 10:53 PM, Mandy Chung wrote:
>> On Apr 17, 2017, at 1:47 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>
>> Please review this fix for a bug in JDK-8175797: the mechanism
>> provided by that change for reverting to the old behavior of
>> Reference.enqueue (for backward compatibility) does not work.
>>
>> Also fixed the ReferenceEnqueue test changes also made as part of
>> JDK-8175797.  That test would havecaught the problem with the property
>> but for bugs in the test.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8178832
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8178832/jdk00/
> Looks good.  Thanks for catching this and the typo in the test.
>
> Mandy

I wonder if there are (or will be) other places where such silent 
swallowing of run-time exceptions happens or will happen. Wouldn't it be 
good to "fix" Boolean.getBoolean() and friends?

I filed the following bug to track this:

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

Regards, Peter


From volker.simonis at gmail.com  Wed Apr 19 09:18:59 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 19 Apr 2017 11:18:59 +0200
Subject: [9] RFR(S): 8178726: Can't load classes from classpath if it is a
 UNC share
In-Reply-To: <a95ed6fe-ba7d-0d5c-f8d3-93e2a8b48355@oracle.com>
References: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>
 <2a1ec694-f3d4-ca25-a08c-36b7d3511bdf@oracle.com>
 <4067cfb5-a01c-73e3-7f5d-c4d729830b28@oracle.com>
 <CA+3eh133fMLYOL=vxgARCBhdFW3yodr13GoTKZ7SzUtTd65u6A@mail.gmail.com>
 <a95ed6fe-ba7d-0d5c-f8d3-93e2a8b48355@oracle.com>
Message-ID: <CA+3eh115RS6U=9-ovZXMWGpHbK9ssvAZNv5ouoZK7xkkBbjc8A@mail.gmail.com>

On Wed, Apr 19, 2017 at 9:03 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 18/04/2017 18:44, Volker Simonis wrote:
>
> Hi Alan, Chris,
>
> thanks for your help and feedback.
> It seems my fix was indeed "too optimistic". I've only briefly looked into
> the errors reported by Chris. The first one is due to a cyclic dependency
> between Paths.get() and FileSystems.getDefault().
>
> So I've finally decided to go with Alan's proposal which is probably the
> least invasive one:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8178726.v1/
>
> It would be great if someone could verify this new version once again by
> running it through JPRT (I've verified that the reported problems don't
> occur any more, but who knows :)
>
> I ran it through the build+test system and don't see any issues. It's great
> that you found this issue before GA, I suspect testing with a directory of
> .class files on a UNC isn't too common (for performance reasons) which is
> why it wasn't noticed (the issue has been in JDK 9 for more than a year).
>
> One additional suggestion is to include a comment, something like:
>
> // use File::toURL as URLClassPath can't handle URLs with a UNC
> // server name in the authority component
>
> as it won't be immediately clear to readers why the toFile() is needed in
> the chain.

That's a good suggestion. I've updated the patch with a slightly
modified comment:

// Use an intermediate File object to construct a URI/URL without
// authority component as URLClassPath can't handle URLs with a UNC
// server name in the authority component.

and also updated the copyright year:

http://cr.openjdk.java.net/~simonis/webrevs/2017/8178726.v2/

Can you please add a "jdk9-fix-yes" label to the bug such that I can
push the change?

Thanks,
Volker

>
> -Alan

From chris.hegarty at oracle.com  Wed Apr 19 09:25:29 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 19 Apr 2017 10:25:29 +0100
Subject: [9] RFR(S): 8178726: Can't load classes from classpath if it is a
 UNC share
In-Reply-To: <CA+3eh115RS6U=9-ovZXMWGpHbK9ssvAZNv5ouoZK7xkkBbjc8A@mail.gmail.com>
References: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>
 <2a1ec694-f3d4-ca25-a08c-36b7d3511bdf@oracle.com>
 <4067cfb5-a01c-73e3-7f5d-c4d729830b28@oracle.com>
 <CA+3eh133fMLYOL=vxgARCBhdFW3yodr13GoTKZ7SzUtTd65u6A@mail.gmail.com>
 <a95ed6fe-ba7d-0d5c-f8d3-93e2a8b48355@oracle.com>
 <CA+3eh115RS6U=9-ovZXMWGpHbK9ssvAZNv5ouoZK7xkkBbjc8A@mail.gmail.com>
Message-ID: <5EBD3D45-F8C8-4119-998E-04E2F75CCC01@oracle.com>


> On 19 Apr 2017, at 10:18, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
>> ...
> 
> That's a good suggestion. I've updated the patch with a slightly
> modified comment:
> 
> // Use an intermediate File object to construct a URI/URL without
> // authority component as URLClassPath can't handle URLs with a UNC
> // server name in the authority component.
> 
> and also updated the copyright year:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8178726.v2/

The changes look good. Thanks Volker.

-Chris.


From Alan.Bateman at oracle.com  Wed Apr 19 10:22:17 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Apr 2017 11:22:17 +0100
Subject: [9] RFR(S): 8178726: Can't load classes from classpath if it is a
 UNC share
In-Reply-To: <CA+3eh115RS6U=9-ovZXMWGpHbK9ssvAZNv5ouoZK7xkkBbjc8A@mail.gmail.com>
References: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>
 <2a1ec694-f3d4-ca25-a08c-36b7d3511bdf@oracle.com>
 <4067cfb5-a01c-73e3-7f5d-c4d729830b28@oracle.com>
 <CA+3eh133fMLYOL=vxgARCBhdFW3yodr13GoTKZ7SzUtTd65u6A@mail.gmail.com>
 <a95ed6fe-ba7d-0d5c-f8d3-93e2a8b48355@oracle.com>
 <CA+3eh115RS6U=9-ovZXMWGpHbK9ssvAZNv5ouoZK7xkkBbjc8A@mail.gmail.com>
Message-ID: <5853aa53-fe95-f68a-34ec-5a31dac42b6a@oracle.com>

On 19/04/2017 10:18, Volker Simonis wrote:

> :
> That's a good suggestion. I've updated the patch with a slightly
> modified comment:
>
> // Use an intermediate File object to construct a URI/URL without
> // authority component as URLClassPath can't handle URLs with a UNC
> // server name in the authority component.
>
> and also updated the copyright year:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2017/8178726.v2/
>
> Can you please add a "jdk9-fix-yes" label to the bug such that I can
> push the change?
>
The update webrev looks good.

-Alan

From volker.simonis at gmail.com  Wed Apr 19 12:21:03 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 19 Apr 2017 14:21:03 +0200
Subject: [9] RFR(S): 8178726: Can't load classes from classpath if it is a
 UNC share
In-Reply-To: <5853aa53-fe95-f68a-34ec-5a31dac42b6a@oracle.com>
References: <CA+3eh11K8T86Y7oXnHBb-HWHpNgrcoGDUR_G1Stp9d_rmkDEWA@mail.gmail.com>
 <2a1ec694-f3d4-ca25-a08c-36b7d3511bdf@oracle.com>
 <4067cfb5-a01c-73e3-7f5d-c4d729830b28@oracle.com>
 <CA+3eh133fMLYOL=vxgARCBhdFW3yodr13GoTKZ7SzUtTd65u6A@mail.gmail.com>
 <a95ed6fe-ba7d-0d5c-f8d3-93e2a8b48355@oracle.com>
 <CA+3eh115RS6U=9-ovZXMWGpHbK9ssvAZNv5ouoZK7xkkBbjc8A@mail.gmail.com>
 <5853aa53-fe95-f68a-34ec-5a31dac42b6a@oracle.com>
Message-ID: <CA+3eh11urat4C8FB16e4iiZjusP0sVVOPiaxhtxzhFgfF6CPWg@mail.gmail.com>

On Wed, Apr 19, 2017 at 12:22 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 19/04/2017 10:18, Volker Simonis wrote:
>
>> :
>> That's a good suggestion. I've updated the patch with a slightly
>> modified comment:
>>
>> // Use an intermediate File object to construct a URI/URL without
>> // authority component as URLClassPath can't handle URLs with a UNC
>> // server name in the authority component.
>>
>> and also updated the copyright year:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8178726.v2/
>>
>> Can you please add a "jdk9-fix-yes" label to the bug such that I can
>> push the change?
>>
> The update webrev looks good.

Thanks Chris, Alan!
I've just pushed the change.

Regards,
Volker

>
> -Alan

From magnus.ihse.bursie at oracle.com  Wed Apr 19 12:54:44 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 19 Apr 2017 14:54:44 +0200
Subject: RFR: JDK-8178037 Move information from jdi-overview.html into jdk.jdi
 module-info.java
Message-ID: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com>

With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html 
is no longer included in the generated documentation. The information 
provided by that file should move to 
src/jdk.jdi/share/classes/module-info.java instead.

I also took the liberty of removing a bunch of other overview.html files 
that are not included in the Javadoc anymore. They provided no real 
informational value, and what text they contained is already expressed 
similarly or better in the corresponding module-info.java files instead.

Bug: https://bugs.openjdk.java.net/browse/JDK-8178037
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01

/Magnus


From erik.joelsson at oracle.com  Wed Apr 19 12:58:09 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 19 Apr 2017 14:58:09 +0200
Subject: RFR: JDK-8178037 Move information from jdi-overview.html into
 jdk.jdi module-info.java
In-Reply-To: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com>
References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com>
Message-ID: <3d150f84-aa75-0ddd-c445-15fdaf2eb970@oracle.com>

Looks good to me.

/Erik


On 2017-04-19 14:54, Magnus Ihse Bursie wrote:
> With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html 
> is no longer included in the generated documentation. The information 
> provided by that file should move to 
> src/jdk.jdi/share/classes/module-info.java instead.
>
> I also took the liberty of removing a bunch of other overview.html 
> files that are not included in the Javadoc anymore. They provided no 
> real informational value, and what text they contained is already 
> expressed similarly or better in the corresponding module-info.java 
> files instead.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178037
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01
>
> /Magnus
>


From Alan.Bateman at oracle.com  Wed Apr 19 13:01:23 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Apr 2017 14:01:23 +0100
Subject: RFR: JDK-8178037 Move information from jdi-overview.html into
 jdk.jdi module-info.java
In-Reply-To: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com>
References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com>
Message-ID: <e3da4f9c-e867-263c-4f4f-99736f861470@oracle.com>

On 19/04/2017 13:54, Magnus Ihse Bursie wrote:

> With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html 
> is no longer included in the generated documentation. The information 
> provided by that file should move to 
> src/jdk.jdi/share/classes/module-info.java instead.
>
> I also took the liberty of removing a bunch of other overview.html 
> files that are not included in the Javadoc anymore. They provided no 
> real informational value, and what text they contained is already 
> expressed similarly or better in the corresponding module-info.java 
> files instead.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178037
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01
The serviceability-dev mailing list is the best place to discuss the 
debugger API.

However, what you have looks okay. I think I would use the opportunity 
to replace "The JDI" with just "JDI" in the second and third paragraphs.

-Alan

From brian.burkhalter at oracle.com  Wed Apr 19 14:37:47 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 19 Apr 2017 07:37:47 -0700
Subject: "unsafe" instances in sun.nio.fs.WindowsFileSystem
In-Reply-To: <00694934-e867-30a6-efde-714979d336c7@oracle.com>
References: <7540281ca3c7401c8de96b2cf7b11faa@gsdghkp03etn1.firmwide.corp.gs.com>
 <00694934-e867-30a6-efde-714979d336c7@oracle.com>
Message-ID: <ADD3A97D-423F-4EE0-920A-732E389BB0FC@oracle.com>

[Looping in nio-dev]

I can file an issue and look into it.

Brian

On Apr 18, 2017, at 11:44 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 19/04/2017 05:44, Chan, Sunny wrote:
> 
>> While reading the code for sun.nio.fs.WindowsFileSystemProvider and sun.nio.fs.WindowsUserDefinedFileAttributeView, I noticed that there is a private static variable to the Unsafe instance but it doesn't seems to be used anywhere in the code - am I missing something here or should I propose a patch to remove them?
>> 
> I suspect these are left over from past refactoring and shouldn't be an issue removing them.
> 
> -Alan


From mandy.chung at oracle.com  Wed Apr 19 16:40:32 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 19 Apr 2017 09:40:32 -0700
Subject: RFR: JDK-8178037 Move information from jdi-overview.html into
 jdk.jdi module-info.java
In-Reply-To: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com>
References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com>
Message-ID: <38E8D569-C58F-4573-A630-A175EEABE240@oracle.com>


> On Apr 19, 2017, at 5:54 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html is no longer included in the generated documentation. The information provided by that file should move to src/jdk.jdi/share/classes/module-info.java instead.
> 
> I also took the liberty of removing a bunch of other overview.html files that are not included in the Javadoc anymore. They provided no real informational value, and what text they contained is already expressed similarly or better in the corresponding module-info.java files instead.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178037
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01


Moving the content from jdi-overview.html to module-info.java is the right choice.

Nit: if you don?t mind, can you replace <code>?</code> with {@code ?}

Otherwise, looks fine.

The following sentence reads a little strange to me that contains a couple of ???.
I just want to point it out and we should leave it as is.

  36  * The JDI also provides explicit control over a virtual machine's execution.
  37  * The ability to suspend and resume threads, and to set breakpoints,
  38  * watchpoints, ... Notification of exceptions, class loading, thread
  39  * creation... The ability to inspect a suspended thread's state, local
  40  * variables, stack backtrace?

Mandy

From paul.sandoz at oracle.com  Wed Apr 19 16:58:53 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 19 Apr 2017 09:58:53 -0700
Subject: JDK 9 RFR(s): 8167981: Optional: add notes explaining intended use
In-Reply-To: <CA+kOe0-D+K6rDUqdRjSTvNFtmPcDmdS38Tpt2k5QzW8wzhBUww@mail.gmail.com>
References: <247a3b98-3304-97a9-3a49-23d81350b3bc@oracle.com>
 <CA+kOe0-D+K6rDUqdRjSTvNFtmPcDmdS38Tpt2k5QzW8wzhBUww@mail.gmail.com>
Message-ID: <054D5B5E-BD04-4F91-8A95-EA1DE2258932@oracle.com>


> On 18 Apr 2017, at 20:29, Martin Buchholz <martinrb at google.com> wrote:
> 
> +     * The methods {@link #orElse(java.lang.Object) orElse()} and
> 
> It's sad that in 2017 we still can't write
> {@link #orElse(T)}
> ... but ... we can and should write
> {@link #orElse(Object) orElse(T)}
> making the source and html more readable (orElse is not nullary)
> 
> + * {@code OptionalDouble} is primarily intended for use as a method return
> type where
> + * there is a clear need to represent "no result," and where using {@code
> null}
> + * is likely to cause errors. A variable whose type is {@code
> OptionalDouble} should
> 
> The obvious alternative to returning OptionalDouble is returning double,
> where null is not possible. I would elide """and where using {@code null}
> + * is likely to cause errors""" unless you want to explicitly compare with
> the alternative of returning Double,not double.
> 

?? and where using the default value (@code {0.0d}) is likely to cause errors."

?

Paul.

> (More generally, it seems like Optional would have more value if there was
> compiler enforcement of its never-null-ness.)
> 
> 
> On Tue, Apr 18, 2017 at 6:23 PM, Stuart Marks <stuart.marks at oracle.com>
> wrote:
> 
>> Hi all,
>> 
>> Please review this small set of non-normative documentation changes for
>> java.util.Optional and related classes.
>> 
>> The notes describe the primary intent of Optional to be used as a return
>> value, and recommend avoiding using null as the value of a variable of
>> Optional type. Also, a note is added to get() directing readers to look at
>> orElse() and orElseGet().
>> 
>> Corresponding changes are also made to the primitive specializations
>> OptionalDouble, OptionalInt, and OptionalLong.
>> 
>> Bug:
>>        https://bugs.openjdk.java.net/browse/JDK-8167981
>> 
>> Webrev:
>>        http://cr.openjdk.java.net/~smarks/reviews/8167981/webrev.0/
>> 
>> Thanks,
>> 
>> s'marks
>> 


From kumar.x.srinivasan at oracle.com  Wed Apr 19 17:52:37 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 19 Apr 2017 10:52:37 -0700
Subject: RFR: 8076417: Update test/jdk/asm/AsmSanity.java with modules
In-Reply-To: <59658d95-45d5-6f84-b478-23b4250b3ce5@oracle.com>
References: <58F65D4C.9000707@oracle.com>
 <59658d95-45d5-6f84-b478-23b4250b3ce5@oracle.com>
Message-ID: <58F7A3E5.4040505@oracle.com>


Ah, yes, good catch. Thanks Amy.

Kumar

> Hi, Kumar
>
> As the removed test is the only one test under jdk/asm, it needs to be 
> removed from jdk_other test group:
>
> --- a/test/TEST.groups
> +++ b/test/TEST.groups
> @@ -269,7 +269,6 @@
>      javax/transaction \
>      javax/xml \
>      -javax/xml/crypto \
> -    jdk/asm \
>
>
> Thanks,
> Amy
>
> On 4/19/17 2:39 AM, Kumar Srinivasan wrote:
>> Hello,
>>
>> Please review [1] which addresses bug [2]. This test is unnecessary, 
>> as there
>> are other components and tests within the jdk, which will fail if ASM
>> is not included, therefore this test is  removed.
>>
>> Thanks
>> Kumar
>>
>> [1] http://cr.openjdk.java.net/~ksrini/8076417/webrev.00/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8076417
>


From kumar.x.srinivasan at oracle.com  Wed Apr 19 18:26:49 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 19 Apr 2017 11:26:49 -0700
Subject: RFR: 8076417: Update test/jdk/asm/AsmSanity.java with modules
In-Reply-To: <59658d95-45d5-6f84-b478-23b4250b3ce5@oracle.com>
References: <58F65D4C.9000707@oracle.com>
 <59658d95-45d5-6f84-b478-23b4250b3ce5@oracle.com>
Message-ID: <58F7ABE9.2030905@oracle.com>


Made the change you recommended, and here is the updated webrev
http://cr.openjdk.java.net/~ksrini/8076417/webrev.01/

Thanks
Kumar

> Hi, Kumar
>
> As the removed test is the only one test under jdk/asm, it needs to be 
> removed from jdk_other test group:
>
> --- a/test/TEST.groups
> +++ b/test/TEST.groups
> @@ -269,7 +269,6 @@
>      javax/transaction \
>      javax/xml \
>      -javax/xml/crypto \
> -    jdk/asm \
>
>
> Thanks,
> Amy
>
> On 4/19/17 2:39 AM, Kumar Srinivasan wrote:
>> Hello,
>>
>> Please review [1] which addresses bug [2]. This test is unnecessary, 
>> as there
>> are other components and tests within the jdk, which will fail if ASM
>> is not included, therefore this test is  removed.
>>
>> Thanks
>> Kumar
>>
>> [1] http://cr.openjdk.java.net/~ksrini/8076417/webrev.00/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8076417
>


From huizhe.wang at oracle.com  Wed Apr 19 18:41:59 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 19 Apr 2017 11:41:59 -0700
Subject: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable
 reset
In-Reply-To: <adc0462f-5ff7-f881-ed1d-a05c5ce1ea0f@oracle.com>
References: <adc0462f-5ff7-f881-ed1d-a05c5ce1ea0f@oracle.com>
Message-ID: <bd08e87c-0c05-2f7f-411f-b72ef98e66ae@oracle.com>

Hi Aleksej,

The changes look good. Some changes to the notes in the test may make it 
a bit clearer on what scenarios are tested: move the current notes for 
the method testResetEnabled to parseAndCheckReset, and then add scenario 
description to the three test* methods, for example, testNoFeatureSet 
verifies two scenarios: resetSymbolTable is and is not requested through 
the System property, while testResetEnabled tests that the feature is 
set  and testResetDisabled unset by using SAXParserFactory's setFeature 
method regardless of whether the System property is set.

Best regards,
Joe

On 4/16/2017 3:02 PM, Aleks Efimov wrote:
> Hi,
>
> Please, help to review the fix [1] for a performance regression in 
> SPECjvm2008-XML benchmark. The cause of this regression was the 
> unconditional reset of SAX parsers symbol table during each reset() 
> operation introduced by JDK-8173390.
> Proposed fix introduces new system property (CCC request is still 
> pending approval) that provides ability to control the symbol table 
> reset functionality. By default the reset table functionality is 
> disabled, similar to pre JDK-8173390 behavior. JAXWS parsers pool 
> implementation was updated to utilize new property to reset symbol 
> table only in JAXWS use-cases that helped to restore the performance 
> levels to pre JDK-8173390 level.
>
> Modified regression test and XML related JCK tests passes on build 
> with proposed changes.
>
> With Best Regards,
> Aleksei
>
> [1] http://cr.openjdk.java.net/~aefimov/8176168/00/


From stuart.marks at oracle.com  Wed Apr 19 18:48:07 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 19 Apr 2017 11:48:07 -0700
Subject: JDK 9 RFR(s): 8167981: Optional: add notes explaining intended use
In-Reply-To: <054D5B5E-BD04-4F91-8A95-EA1DE2258932@oracle.com>
References: <247a3b98-3304-97a9-3a49-23d81350b3bc@oracle.com>
 <CA+kOe0-D+K6rDUqdRjSTvNFtmPcDmdS38Tpt2k5QzW8wzhBUww@mail.gmail.com>
 <054D5B5E-BD04-4F91-8A95-EA1DE2258932@oracle.com>
Message-ID: <e17369c6-07ee-fbec-0c79-08e890d80d8d@oracle.com>


Martin wrote:
> + * The methods {@link #orElse(java.lang.Object) orElse()} and
> It's sad that in 2017 we still can't write
> {@link #orElse(T)}
> ... but ... we can and should write
> {@link #orElse(Object) orElse(T)}
> making the source and html more readable (orElse is not nullary)

Well we're not going to fix the tooling right now, but I take your point about 
the trailing empty parens. I often use foo() as a typographic marker to indicate 
that "foo" is a method, even if it's not nullary; the javadocs aren't terribly 
consistent about this. However, in this case I agree that they're unnecessary 
since the wording clearly indicates that it's a method, and it's also a link 
directly to the method declaration. So, I've removed the parens.

> + * {@code OptionalDouble} is primarily intended for use as a method return type where
> + * there is a clear need to represent "no result," and where using {@code null}
> + * is likely to cause errors. A variable whose type is {@code OptionalDouble} should
>
> The obvious alternative to returning OptionalDouble is returning double, where null is not possible. I would elide """and where using {@code null}
> + * is likely to cause errors""" unless you want to explicitly compare with the alternative of returning Double,not double.

I did have in mind the possibility of the return of a nullable Double 
(respectively, Integer and Long). I did a quick grepcode search and I was pretty 
easily able to find occurrences of methods that returned nullable Integer 
references. I couldn't tell whether these were intended to indicate "no result" 
or whether it was just sloppy programming.

But Paul also points out that 0.0d (resp., 0 and 0L) might be used as default 
values. For int and long I can also imagine -1, MIN_VALUE, etc. also being used 
as sentinels for "no result."

In any case I think it's best to sidestep this entire discussion for the 
purposes of this text and simply omit the mention of null as Martin suggests. 
This results in

    OptionalDouble is primarily intended for use as a method return type where
    there is a clear need to represent "no result."

Full stop. (Respectively for OptionalInt and OptionalLong.) I think that's clear 
enough.

Revised webrev:

http://cr.openjdk.java.net/~smarks/reviews/8167981/webrev.1/

s'marks



On 4/19/17 9:58 AM, Paul Sandoz wrote:
>
>> On 18 Apr 2017, at 20:29, Martin Buchholz <martinrb at google.com> wrote:
>>
>> +     * The methods {@link #orElse(java.lang.Object) orElse()} and
>>
>> It's sad that in 2017 we still can't write
>> {@link #orElse(T)}
>> ... but ... we can and should write
>> {@link #orElse(Object) orElse(T)}
>> making the source and html more readable (orElse is not nullary)
>>
>> + * {@code OptionalDouble} is primarily intended for use as a method return
>> type where
>> + * there is a clear need to represent "no result," and where using {@code
>> null}
>> + * is likely to cause errors. A variable whose type is {@code
>> OptionalDouble} should
>>
>> The obvious alternative to returning OptionalDouble is returning double,
>> where null is not possible. I would elide """and where using {@code null}
>> + * is likely to cause errors""" unless you want to explicitly compare with
>> the alternative of returning Double,not double.
>>
>
> ?? and where using the default value (@code {0.0d}) is likely to cause errors."
>
> ?
>
> Paul.
>
>> (More generally, it seems like Optional would have more value if there was
>> compiler enforcement of its never-null-ness.)
>>
>>
>> On Tue, Apr 18, 2017 at 6:23 PM, Stuart Marks <stuart.marks at oracle.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> Please review this small set of non-normative documentation changes for
>>> java.util.Optional and related classes.
>>>
>>> The notes describe the primary intent of Optional to be used as a return
>>> value, and recommend avoiding using null as the value of a variable of
>>> Optional type. Also, a note is added to get() directing readers to look at
>>> orElse() and orElseGet().
>>>
>>> Corresponding changes are also made to the primitive specializations
>>> OptionalDouble, OptionalInt, and OptionalLong.
>>>
>>> Bug:
>>>        https://bugs.openjdk.java.net/browse/JDK-8167981
>>>
>>> Webrev:
>>>        http://cr.openjdk.java.net/~smarks/reviews/8167981/webrev.0/
>>>
>>> Thanks,
>>>
>>> s'marks
>>>
>

From mandy.chung at oracle.com  Wed Apr 19 18:51:12 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 19 Apr 2017 11:51:12 -0700
Subject: RFR[9]: 8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue
 property is ignored
In-Reply-To: <69c4ee3b-bea7-cdb6-97f4-c8e428bed1fd@gmail.com>
References: <A4B1416D-634E-4D1F-8790-504610DC2BA3@oracle.com>
 <91D4AA88-F7FD-4268-B178-1C74B2CC9F47@oracle.com>
 <69c4ee3b-bea7-cdb6-97f4-c8e428bed1fd@gmail.com>
Message-ID: <7523F914-B955-4332-A802-97C6EFE8FF5A@oracle.com>


> On Apr 19, 2017, at 2:02 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> I wonder if there are (or will be) other places where such silent swallowing of run-time exceptions happens or will happen. Wouldn't it be good to "fix" Boolean.getBoolean() and friends?
> 
> I filed the following bug to track this:
> 
> https://bugs.openjdk.java.net/browse/JDK-8178966
> 

Thanks for creating the issue.  I fully agree that we should fix this and silent swallowing the exceptions makes the underlying problem unnoticed.

Your proposed patch looks good to me.  NPE would be thrown if it?s called before the system properties are initialized. 

Mandy


From kim.barrett at oracle.com  Wed Apr 19 23:57:43 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 19 Apr 2017 19:57:43 -0400
Subject: RFR[9]: 8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue
 property is ignored
In-Reply-To: <7523F914-B955-4332-A802-97C6EFE8FF5A@oracle.com>
References: <A4B1416D-634E-4D1F-8790-504610DC2BA3@oracle.com>
 <91D4AA88-F7FD-4268-B178-1C74B2CC9F47@oracle.com>
 <69c4ee3b-bea7-cdb6-97f4-c8e428bed1fd@gmail.com>
 <7523F914-B955-4332-A802-97C6EFE8FF5A@oracle.com>
Message-ID: <39A27ADF-BDF1-4DE4-9396-2891738755EC@oracle.com>

> On Apr 19, 2017, at 2:51 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> On Apr 19, 2017, at 2:02 AM, Peter Levart <peter.levart at gmail.com> wrote:
>> 
>> I wonder if there are (or will be) other places where such silent swallowing of run-time exceptions happens or will happen. Wouldn't it be good to "fix" Boolean.getBoolean() and friends?
>> 
>> I filed the following bug to track this:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8178966
>> 
> 
> Thanks for creating the issue.  I fully agree that we should fix this and silent swallowing the exceptions makes the underlying problem unnoticed.
> 
> Your proposed patch looks good to me.  NPE would be thrown if it?s called before the system properties are initialized. 
> 
> Mandy

This looks like a good idea to me too.


From amy.lu at oracle.com  Thu Apr 20 01:14:24 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 20 Apr 2017 09:14:24 +0800
Subject: RFR: 8076417: Update test/jdk/asm/AsmSanity.java with modules
In-Reply-To: <58F7ABE9.2030905@oracle.com>
References: <58F65D4C.9000707@oracle.com>
 <59658d95-45d5-6f84-b478-23b4250b3ce5@oracle.com>
 <58F7ABE9.2030905@oracle.com>
Message-ID: <61eda458-2bc2-fc8e-e31b-fec01a49243c@oracle.com>

On 4/20/17 2:26 AM, Kumar Srinivasan wrote:
>
> Made the change you recommended, and here is the updated webrev
> http://cr.openjdk.java.net/~ksrini/8076417/webrev.01/
Thank you Kumar!Looks good.

(I'm not official reviewer)
Thanks,
Amy

>
> Thanks
> Kumar
>
>> Hi, Kumar
>>
>> As the removed test is the only one test under jdk/asm, it needs to 
>> be removed from jdk_other test group:
>>
>> --- a/test/TEST.groups
>> +++ b/test/TEST.groups
>> @@ -269,7 +269,6 @@
>>      javax/transaction \
>>      javax/xml \
>>      -javax/xml/crypto \
>> -    jdk/asm \
>>
>>
>> Thanks,
>> Amy
>>
>> On 4/19/17 2:39 AM, Kumar Srinivasan wrote:
>>> Hello,
>>>
>>> Please review [1] which addresses bug [2]. This test is unnecessary, 
>>> as there
>>> are other components and tests within the jdk, which will fail if ASM
>>> is not included, therefore this test is  removed.
>>>
>>> Thanks
>>> Kumar
>>>
>>> [1] http://cr.openjdk.java.net/~ksrini/8076417/webrev.00/
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8076417
>>
>


From mandy.chung at oracle.com  Thu Apr 20 01:35:39 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 19 Apr 2017 18:35:39 -0700
Subject: RFR: 8076417: Update test/jdk/asm/AsmSanity.java with modules
In-Reply-To: <58F7ABE9.2030905@oracle.com>
References: <58F65D4C.9000707@oracle.com>
 <59658d95-45d5-6f84-b478-23b4250b3ce5@oracle.com>
 <58F7ABE9.2030905@oracle.com>
Message-ID: <543A22BB-A48B-4406-BCE4-337020038CA2@oracle.com>


> On Apr 19, 2017, at 11:26 AM, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
> 
> 
> Made the change you recommended, and here is the updated webrev
> http://cr.openjdk.java.net/~ksrini/8076417/webrev.01/

+1

Mandy

From david.holmes at oracle.com  Thu Apr 20 02:21:21 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 Apr 2017 12:21:21 +1000
Subject: RFR: JDK-8178037 Move information from jdi-overview.html into
 jdk.jdi module-info.java
In-Reply-To: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com>
References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com>
Message-ID: <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com>

On 19/04/2017 10:54 PM, Magnus Ihse Bursie wrote:
> With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html
> is no longer included in the generated documentation. The information
> provided by that file should move to
> src/jdk.jdi/share/classes/module-info.java instead.

Looks good, but highlighted an error with the existing text:

   /**
    * Defines the Java Debugger Interface.
+  * <p>
+  * The Java&trade; Debug Interface (JDI) is a high level Java API 
providing

The first line should read "Debug" not "Debugger".

Contrary to what Alan suggested (sorry Alan!) I think plain "JDI" should 
be replaced by "The JDI".

Thanks,
David

> I also took the liberty of removing a bunch of other overview.html files
> that are not included in the Javadoc anymore. They provided no real
> informational value, and what text they contained is already expressed
> similarly or better in the corresponding module-info.java files instead.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8178037
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01
>
>
> /Magnus
>

From heiko.wagner at apis.de  Thu Apr 20 07:38:11 2017
From: heiko.wagner at apis.de (Heiko Wagner)
Date: Thu, 20 Apr 2017 09:38:11 +0200
Subject: Deprecated Java EE Modules in JDK9
Message-ID: <df46d7a160c4ad5701e81ed640f5a8fd@apis-intern.com>

Sorry for my ignotance, but I need some advice on how to properly write
a desktop app that uses JAX-WS to pull some data from a WS-I Service. 

I can understand why JAX-WS is deprecated and marked for removel to help
out the Java EE crwod to migrate their application servers to JDK9, but
I don't fully understand what the right thing would be to do in my
situation. Is the java.xml.ws module just "moved" to Java EE or is it
completely removed and replaced with a module that has a new name? 

In the first case I ussume it would be the right thing to decare a
dependency on java.xml.ws and rely on the presence of the module in Java
SE 9 and ship a module implementing JAX-WS in Java SE 10 along my
application. I assume jlink would help me out to get a appropriate
runtime image in both cases. This would be just like the Java Mail API
case, where there is nothing wrong with using it in th Java SE context,
when you make sure you supply a implementation with your app and rely on
the platform to provide a implementation in the Java EE context. 

In the latter case, is there already a proper new module name or module
alias I can depend on in my application? 

Thanks for the help, 

Heiko

-- 
Heiko Wagner - APIS Informationstechnologien GmbH
Gewerbepark A 13, 93086 W?rth a.d. Donau, Deutschland
Web: http://www.apis.de
E-Mail: heiko.wagner at apis.de
Tel.: +49 (0) 9482 - 9415 - 0
Fax: +49 (0) 9482 - 9415 - 25
Sitz der GmbH: W?rth/Donau, Amtsgericht Regensburg (HRB 6684)
Gesch?ftsf?hrer: Julia Anna Dietz, J?rgen Eilers, Peter Rosenbeck

From magnus.ihse.bursie at oracle.com  Thu Apr 20 07:57:54 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 20 Apr 2017 09:57:54 +0200
Subject: RFR: JDK-8178037 Move information from jdi-overview.html into
 jdk.jdi module-info.java
In-Reply-To: <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com>
References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com>
 <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com>
Message-ID: <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com>


On 2017-04-20 04:21, David Holmes wrote:
> On 19/04/2017 10:54 PM, Magnus Ihse Bursie wrote:
>> With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html
>> is no longer included in the generated documentation. The information
>> provided by that file should move to
>> src/jdk.jdi/share/classes/module-info.java instead.
>
> Looks good, but highlighted an error with the existing text:
>
>   /**
>    * Defines the Java Debugger Interface.
> +  * <p>
> +  * The Java&trade; Debug Interface (JDI) is a high level Java API 
> providing
>
> The first line should read "Debug" not "Debugger".

Good catch.

I really didn't plan to make any editorial changes in this review, only 
to move the contents to a place were it was once again included. 
However, the text was apparently in need of some freshing up, so I tried 
to fix what was pointed out.

>
> Contrary to what Alan suggested (sorry Alan!) I think plain "JDI" 
> should be replaced by "The JDI".

I love it when I get conflicting reviews! ;-)

I'm sorry Dave, I'm afraid I can't do that. :-) "The JDI" just sounds 
weird, and that's not how acronyms are typically referred to. So I've 
sided with Alan here. If you don't agree, I'll back out that change and 
you can fight it out by yourselves. :)

And Mandy: I agree with the weird ellipses. I changed that to "etc.", 
which I think captures the intent that the list was not exhaustive.

Here is an updated review. It fixes the "Debugger" in the title, "The 
JDI" -> "JDI" in two places, "..." -> "etc." and <code> -> {@code}.

http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.02/

/Magnus

>
> Thanks,
> David
>
>> I also took the liberty of removing a bunch of other overview.html files
>> that are not included in the Javadoc anymore. They provided no real
>> informational value, and what text they contained is already expressed
>> similarly or better in the corresponding module-info.java files instead.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178037
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01 
>>
>>
>>
>> /Magnus
>>


From david.holmes at oracle.com  Thu Apr 20 08:25:53 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 20 Apr 2017 18:25:53 +1000
Subject: RFR: JDK-8178037 Move information from jdi-overview.html into
 jdk.jdi module-info.java
In-Reply-To: <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com>
References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com>
 <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com>
 <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com>
Message-ID: <e91d3efc-d9ca-6b27-6920-fefecbc54238@oracle.com>

On 20/04/2017 5:57 PM, Magnus Ihse Bursie wrote:
> On 2017-04-20 04:21, David Holmes wrote:
>> On 19/04/2017 10:54 PM, Magnus Ihse Bursie wrote:
>>> With JDK-8172312, the file src/jdk.jdi/share/classes/jdi-overview.html
>>> is no longer included in the generated documentation. The information
>>> provided by that file should move to
>>> src/jdk.jdi/share/classes/module-info.java instead.
>>
>> Looks good, but highlighted an error with the existing text:
>>
>>   /**
>>    * Defines the Java Debugger Interface.
>> +  * <p>
>> +  * The Java&trade; Debug Interface (JDI) is a high level Java API
>> providing
>>
>> The first line should read "Debug" not "Debugger".
>
> Good catch.
>
> I really didn't plan to make any editorial changes in this review, only
> to move the contents to a place were it was once again included.
> However, the text was apparently in need of some freshing up, so I tried
> to fix what was pointed out.
>
>>
>> Contrary to what Alan suggested (sorry Alan!) I think plain "JDI"
>> should be replaced by "The JDI".
>
> I love it when I get conflicting reviews! ;-)
>
> I'm sorry Dave, I'm afraid I can't do that. :-) "The JDI" just sounds
> weird, and that's not how acronyms are typically referred to. So I've
> sided with Alan here. If you don't agree, I'll back out that change and
> you can fight it out by yourselves. :)

It depends on the exact nature of the acronym. If you wrote this out you 
would say "The Java Debug Interface .." hence you should say "The JDI ...".

:)

Cheers,
David
-----

> And Mandy: I agree with the weird ellipses. I changed that to "etc.",
> which I think captures the intent that the list was not exhaustive.
>
> Here is an updated review. It fixes the "Debugger" in the title, "The
> JDI" -> "JDI" in two places, "..." -> "etc." and <code> -> {@code}.
>
> http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.02/
>
>
> /Magnus
>
>>
>> Thanks,
>> David
>>
>>> I also took the liberty of removing a bunch of other overview.html files
>>> that are not included in the Javadoc anymore. They provided no real
>>> informational value, and what text they contained is already expressed
>>> similarly or better in the corresponding module-info.java files instead.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8178037
>>> WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.01
>>>
>>>
>>>
>>> /Magnus
>>>
>

From amy.lu at oracle.com  Thu Apr 20 09:10:46 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 20 Apr 2017 17:10:46 +0800
Subject: JDK 9 RFR of JDK-8174171: Move spliterator testing of BitSet into big
 memory tests BitSetStreamTest
Message-ID: <7797193a-5507-7092-db34-b8ca6a8b09de@oracle.com>

Please review this test-only change.

Integer.MAX_VALUE bit set testdata in bitStreamTestcases of 
SpliteratorTraversingAndSplittingTest was removed in JDK-8169838 due to 
out of memory errors. It also cause issue in BitSetStreamTest 
(JDK-8079538). And yes, testing for this do consume lots of memory.

This patch moved the spliterator testing of BitSet into big memory tests 
BitSetStreamTest:

1) bitStreamTestcases removed from SpliteratorTraversingAndSplittingTest
2) Above test cases, with adding back Integer.MAX_VALUE testdata, now is 
in the newly introduced @DataProvider and being tested in BitSetStreamTest.
3) It's better BitSetStreamTest not to be run concurrently with other 
test so to avoid memory usage conflict. With this purpose,
BitSetStreamTest moved to java/util/BitSet/stream subdir, and this 
subdir added to exclusiveAccess.dirs

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

Thanks,
Amy

From ropalka at redhat.com  Thu Apr 20 09:13:28 2017
From: ropalka at redhat.com (Richard Opalka)
Date: Thu, 20 Apr 2017 11:13:28 +0200
Subject: Deprecated Java EE Modules in JDK9
In-Reply-To: <df46d7a160c4ad5701e81ed640f5a8fd@apis-intern.com>
References: <df46d7a160c4ad5701e81ed640f5a8fd@apis-intern.com>
Message-ID: <fbc8aad6-078d-ce28-fe17-737137780b4d@redhat.com>

Hi Heiko,


On 04/20/2017 09:38 AM, Heiko Wagner wrote:
> Sorry for my ignotance, but I need some advice on how to properly write
> a desktop app that uses JAX-WS to pull some data from a WS-I Service.
>
> I can understand why JAX-WS is deprecated and marked for removel to help
> out the Java EE crwod to migrate their application servers to JDK9, but
> I don't fully understand what the right thing would be to do in my
> situation. Is the java.xml.ws module just "moved" to Java EE or is it
> completely removed and replaced with a module that has a new name?
Java EE technology related modules are all 'upgradeable modules'.
The upgrade process is based on module naming scheme.
So Java EE related module names shouldn't change in the future.
And yes, they are "moved" to Java EE.
> In the first case I ussume it would be the right thing to decare a
> dependency on java.xml.ws and rely on the presence of the module in Java
> SE 9 and ship a module implementing JAX-WS in Java SE 10 along my
> application.
Correct.
> In the latter case, is there already a proper new module name or module
> alias I can depend on in my application?
No AFAIK
>
> Thanks for the help,
>
> Heiko
>
Rio

From Alan.Bateman at oracle.com  Thu Apr 20 09:57:14 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 20 Apr 2017 10:57:14 +0100
Subject: Deprecated Java EE Modules in JDK9
In-Reply-To: <df46d7a160c4ad5701e81ed640f5a8fd@apis-intern.com>
References: <df46d7a160c4ad5701e81ed640f5a8fd@apis-intern.com>
Message-ID: <f4c4d2d5-d067-7e3f-9e0d-a68f2d326ead@oracle.com>

On 20/04/2017 08:38, Heiko Wagner wrote:

> Sorry for my ignotance, but I need some advice on how to properly write
> a desktop app that uses JAX-WS to pull some data from a WS-I Service.
>
> I can understand why JAX-WS is deprecated and marked for removel to help
> out the Java EE crwod to migrate their application servers to JDK9, but
> I don't fully understand what the right thing would be to do in my
> situation. Is the java.xml.ws module just "moved" to Java EE or is it
> completely removed and replaced with a module that has a new name?
>
> In the first case I ussume it would be the right thing to decare a
> dependency on java.xml.ws and rely on the presence of the module in Java
> SE 9 and ship a module implementing JAX-WS in Java SE 10 along my
> application. I assume jlink would help me out to get a appropriate
> runtime image in both cases. This would be just like the Java Mail API
> case, where there is nothing wrong with using it in th Java SE context,
> when you make sure you supply a implementation with your app and rely on
> the platform to provide a implementation in the Java EE context.
>
> In the latter case, is there already a proper new module name or module
> alias I can depend on in my application?
>
With JDK 9 then you have several choices. For existing code then it 
should continue to work with any of the following:

1. Compile/run with `--add-modules java.xml.ws` to use the java.xml.ws 
module in the JDK.

2. Deploy the standalone version of JAX-WS on the class path.

3. Deploy the standalone version of the java.xml.ws module on the 
upgrade module path (to override the module in the JDK) and compile/run 
with `--add-modules java.xml.ws`

If you migrate your code to a module then your module will `requires 
java.xml.ws` so you won't need `--add-modules java.xml.ws` on the 
command line. You have the choice to use the java.xml.ws in the JDK or 
you can deploy the standalone version of the java.xml.ws on the upgrade 
module path.

If java.xml.ws is dropped in Java SE 10, and if JDK 10 declines to 
bundle it, then deployments using the standalone version should continue 
to just work.

To your question then I'm not aware of any proposal to rename the 
java.xml.ws module. However, I believe the standalone version has chosen 
to continue with the historical splitting of the API and implementation. 
The API module will be "java.xml.ws" and the implementation modules will 
have other names. This should be transparent to consumers of java.xml.ws 
of course. Dmitry Kornilov or Roman Grigoriadi may wish to comment on 
this as I think it would be useful to get some early testing of the 
standalone versions as modules to make sure that there aren't any issues.

-Alan


From huaming.li at oracle.com  Thu Apr 20 10:23:04 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Thu, 20 Apr 2017 18:23:04 +0800
Subject: JDK 9 RFR of JDK-8174171: Move spliterator testing of BitSet into
 big memory tests BitSetStreamTest
In-Reply-To: <7797193a-5507-7092-db34-b8ca6a8b09de@oracle.com>
References: <7797193a-5507-7092-db34-b8ca6a8b09de@oracle.com>
Message-ID: <de8610ac-6be1-81a6-21ab-623df397151d@oracle.com>

Hi Amy,

Thank you for taking this. Have some minor comments about 
BitSetStreamTest.java

1. is below line necessary? or 2g big enough?

51 * @requires os.maxMemory >= 2g

2. I'm not sure if Xmx1024m should be a bigger value.

55 * @run testng/othervm -Xms512m -Xmx1024m

3. spliteratorOfIntDataProvider is created only once and shared between 
multiple tests. I'm not sure if parallel is enabled, but if it is 
already enabled or enable some day in future, it might face issue 
although possibility is very low, so adding volatile might make it safe.

Thank you
-Hamlin

On 2017/4/20 17:10, Amy Lu wrote:
> Please review this test-only change.
>
> Integer.MAX_VALUE bit set testdata in bitStreamTestcases of 
> SpliteratorTraversingAndSplittingTest was removed in JDK-8169838 due 
> to out of memory errors. It also cause issue in BitSetStreamTest 
> (JDK-8079538). And yes, testing for this do consume lots of memory.
>
> This patch moved the spliterator testing of BitSet into big memory 
> tests BitSetStreamTest:
>
> 1) bitStreamTestcases removed from SpliteratorTraversingAndSplittingTest
> 2) Above test cases, with adding back Integer.MAX_VALUE testdata, now 
> is in the newly introduced @DataProvider and being tested in 
> BitSetStreamTest.
> 3) It's better BitSetStreamTest not to be run concurrently with other 
> test so to avoid memory usage conflict. With this purpose,
> BitSetStreamTest moved to java/util/BitSet/stream subdir, and this 
> subdir added to exclusiveAccess.dirs
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8174171
> webrev: http://cr.openjdk.java.net/~amlu/8174171/webrev.00/
>
> Thanks,
> Amy


From lance.andersen at oracle.com  Thu Apr 20 13:40:36 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 20 Apr 2017 09:40:36 -0400
Subject: RFR 8178915: Minor update to the PooledConnection javadoc
Message-ID: <DC56770D-2C41-45B0-816E-62438ECD7E2B@oracle.com>

Hi all,

This RFR makes a minor update to the PooledConnection javadoc.  The CCC has been approved.  

Here is the diff:

???????
$ hg diff
diff -r 9ba6760481a8 src/java.sql/share/classes/javax/sql/PooledConnection.java
--- a/src/java.sql/share/classes/javax/sql/PooledConnection.java	Sat Apr 15 16:54:33 2017 -0400
+++ b/src/java.sql/share/classes/javax/sql/PooledConnection.java	Tue Apr 18 14:50:44 2017 -0400
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -69,8 +69,9 @@
  * <p>
  * If the connection pool manager wraps or provides a proxy to the logical
  * handle returned from a call to {@code PoolConnection.getConnection}, the pool
- * manager must do
- * one of the following when the application calls {@code Connection.close}:
+ * manager must do one of the following when the connection pool manager
+ * closes or returns the {@code PooledConnection} to the pool in response to
+ * the application calling {@code Connection.close}:
  * <ul>
  * <li>call {@code endRequest} on the logical {@code Connection} handle
  * <li>call {@code close} on the logical {@code Connection} handle
ljanders-mac:src ljanders$ 
??????????

Best
Lance
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From magnus.ihse.bursie at oracle.com  Thu Apr 20 13:49:14 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 20 Apr 2017 15:49:14 +0200
Subject: RFR: JDK-8179022 Add serialization spec as markdown
Message-ID: <c35c1c23-1761-062d-2461-cd726f022dd4@oracle.com>

Here's the first step towards fixing JDK-8177434 
<https://bugs.openjdk.java.net/browse/JDK-8177434>. A framework is added 
for converting markdown specs to html using pandoc. The Java 
serialization spec is added in markdown format as a proof of concept. I 
also reintroduced the functionality to enable full docs if all 
prerequisites are present.

Note that this fix is dependent on the patch for JDK-8178038 et al that 
is currently out for review. The webrev is created with that patch as 
baseline.

This fix is part of JEP 299. I intend to push it to jdk9.

Here's an example of the generated output:
http://cr.openjdk.java.net/~ihse/JDK-8179022-javadoc-output-demo/specs/serialization/

Bug: https://bugs.openjdk.java.net/browse/JDK-8179022
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.01

/Magnus

From Alan.Bateman at oracle.com  Thu Apr 20 13:59:06 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 20 Apr 2017 14:59:06 +0100
Subject: RFR: JDK-8179022 Add serialization spec as markdown
In-Reply-To: <c35c1c23-1761-062d-2461-cd726f022dd4@oracle.com>
References: <c35c1c23-1761-062d-2461-cd726f022dd4@oracle.com>
Message-ID: <7bd7afd5-7d32-bddb-2811-9992577c3eb5@oracle.com>

On 20/04/2017 14:49, Magnus Ihse Bursie wrote:

> Here's the first step towards fixing JDK-8177434 
> <https://bugs.openjdk.java.net/browse/JDK-8177434>. A framework is 
> added for converting markdown specs to html using pandoc. The Java 
> serialization spec is added in markdown format as a proof of concept. 
> I also reintroduced the functionality to enable full docs if all 
> prerequisites are present.
>
> Note that this fix is dependent on the patch for JDK-8178038 et al 
> that is currently out for review. The webrev is created with that 
> patch as baseline.
>
> This fix is part of JEP 299. I intend to push it to jdk9.
>
> Here's an example of the generated output:
> http://cr.openjdk.java.net/~ihse/JDK-8179022-javadoc-output-demo/specs/serialization/ 
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179022
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.01
I just skimmed this and notice this adds class.gif with output that I 
think is serialver. This tool has been changed in JDK 9 to drop the GUI 
and so this image and the reference to the "Show" button are now 
obsolete. I'm sure you don't want want to get into issues like this but 
we will need to submit a few bugs to ensure that some of the dusty 
documents are updated.

-Alan

From erik.joelsson at oracle.com  Thu Apr 20 14:40:40 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 20 Apr 2017 16:40:40 +0200
Subject: RFR: JDK-8179022 Add serialization spec as markdown
In-Reply-To: <c35c1c23-1761-062d-2461-cd726f022dd4@oracle.com>
References: <c35c1c23-1761-062d-2461-cd726f022dd4@oracle.com>
Message-ID: <c114a14f-3faf-b01a-3fd1-ef1cd5708d6d@oracle.com>

The build changes look good to me. I can't comment on the actual .md files.

/Erik


On 2017-04-20 15:49, Magnus Ihse Bursie wrote:
> Here's the first step towards fixing JDK-8177434 
> <https://bugs.openjdk.java.net/browse/JDK-8177434>. A framework is 
> added for converting markdown specs to html using pandoc. The Java 
> serialization spec is added in markdown format as a proof of concept. 
> I also reintroduced the functionality to enable full docs if all 
> prerequisites are present.
>
> Note that this fix is dependent on the patch for JDK-8178038 et al 
> that is currently out for review. The webrev is created with that 
> patch as baseline.
>
> This fix is part of JEP 299. I intend to push it to jdk9.
>
> Here's an example of the generated output:
> http://cr.openjdk.java.net/~ihse/JDK-8179022-javadoc-output-demo/specs/serialization/ 
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179022
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.01
>
> /Magnus


From mandy.chung at oracle.com  Thu Apr 20 14:56:18 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 20 Apr 2017 07:56:18 -0700
Subject: RFR: JDK-8178037 Move information from jdi-overview.html into
 jdk.jdi module-info.java
In-Reply-To: <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com>
References: <9bdbdbca-f699-f569-3021-d029555799ab@oracle.com>
 <4e664f6d-98a0-eaf2-b65f-9d44788e117c@oracle.com>
 <968b1798-fdd5-2bfb-d0ae-8d49fa644b31@oracle.com>
Message-ID: <55B9D093-687F-428E-8DD1-DFA9D1F2A8C2@oracle.com>


> On Apr 20, 2017, at 12:57 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> 
> http://cr.openjdk.java.net/~ihse/JDK-8178037-fix-obsolete-overview-files/webrev.02/

Looks good.

Mandy

From pavel.rappo at oracle.com  Thu Apr 20 16:08:58 2017
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 20 Apr 2017 17:08:58 +0100
Subject: RFR [9] 8179021: Latest bugfixes to WebSocket/HPACK from the sandbox
 repo
Message-ID: <D7FD6802-0417-4CC4-B0BD-CBD5ACC4CFCC@oracle.com>

Hello,

Please review the following change:

   http://cr.openjdk.java.net/~prappo/8179021/webrev.00/

Along with refactoring this change contains a number of critical fixes for
WebSocket. Critical fixes are applied to Receiver and OpeningHandshake.

Also this change removes 2 convenience methods and 1 constant from WebSocket
interface. Since this interface is a part of incubation feature there shouldn't
be any problem. Those members were initially controversial. 

Thanks,
-Pavel


From martinrb at google.com  Thu Apr 20 17:03:35 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 20 Apr 2017 10:03:35 -0700
Subject: JDK 9 RFR(s): 8167981: Optional: add notes explaining intended use
In-Reply-To: <e17369c6-07ee-fbec-0c79-08e890d80d8d@oracle.com>
References: <247a3b98-3304-97a9-3a49-23d81350b3bc@oracle.com>
 <CA+kOe0-D+K6rDUqdRjSTvNFtmPcDmdS38Tpt2k5QzW8wzhBUww@mail.gmail.com>
 <054D5B5E-BD04-4F91-8A95-EA1DE2258932@oracle.com>
 <e17369c6-07ee-fbec-0c79-08e890d80d8d@oracle.com>
Message-ID: <CA+kOe0_0-uZakfcrZ_nYkMOqqNCRyXxerorikMppnCoXHDnoDw@mail.gmail.com>

This looks good.

I don't think there's any need anymore to have fully qualified class names
in @links, so just:

{@link #orElseGet(Supplier) orElseGet}

(but there's a global cleanup there)

---

I would write
"result".
instead of
"result."

(but the latter has never made sense to me even as a child)


On Wed, Apr 19, 2017 at 11:48 AM, Stuart Marks <stuart.marks at oracle.com>
wrote:

>
> Martin wrote:
>
>> + * The methods {@link #orElse(java.lang.Object) orElse()} and
>> It's sad that in 2017 we still can't write
>> {@link #orElse(T)}
>> ... but ... we can and should write
>> {@link #orElse(Object) orElse(T)}
>> making the source and html more readable (orElse is not nullary)
>>
>
> Well we're not going to fix the tooling right now, but I take your point
> about the trailing empty parens. I often use foo() as a typographic marker
> to indicate that "foo" is a method, even if it's not nullary; the javadocs
> aren't terribly consistent about this. However, in this case I agree that
> they're unnecessary since the wording clearly indicates that it's a method,
> and it's also a link directly to the method declaration. So, I've removed
> the parens.
>
> + * {@code OptionalDouble} is primarily intended for use as a method
>> return type where
>> + * there is a clear need to represent "no result," and where using
>> {@code null}
>> + * is likely to cause errors. A variable whose type is {@code
>> OptionalDouble} should
>>
>> The obvious alternative to returning OptionalDouble is returning double,
>> where null is not possible. I would elide """and where using {@code null}
>> + * is likely to cause errors""" unless you want to explicitly compare
>> with the alternative of returning Double,not double.
>>
>
> I did have in mind the possibility of the return of a nullable Double
> (respectively, Integer and Long). I did a quick grepcode search and I was
> pretty easily able to find occurrences of methods that returned nullable
> Integer references. I couldn't tell whether these were intended to indicate
> "no result" or whether it was just sloppy programming.
>
> But Paul also points out that 0.0d (resp., 0 and 0L) might be used as
> default values. For int and long I can also imagine -1, MIN_VALUE, etc.
> also being used as sentinels for "no result."
>
> In any case I think it's best to sidestep this entire discussion for the
> purposes of this text and simply omit the mention of null as Martin
> suggests. This results in
>
>    OptionalDouble is primarily intended for use as a method return type
> where
>    there is a clear need to represent "no result."
>
> Full stop. (Respectively for OptionalInt and OptionalLong.) I think that's
> clear enough.
>
> Revised webrev:
>
> http://cr.openjdk.java.net/~smarks/reviews/8167981/webrev.1/
>
> s'marks
>
>
>
>
> On 4/19/17 9:58 AM, Paul Sandoz wrote:
>
>>
>> On 18 Apr 2017, at 20:29, Martin Buchholz <martinrb at google.com> wrote:
>>>
>>> +     * The methods {@link #orElse(java.lang.Object) orElse()} and
>>>
>>> It's sad that in 2017 we still can't write
>>> {@link #orElse(T)}
>>> ... but ... we can and should write
>>> {@link #orElse(Object) orElse(T)}
>>> making the source and html more readable (orElse is not nullary)
>>>
>>> + * {@code OptionalDouble} is primarily intended for use as a method
>>> return
>>> type where
>>> + * there is a clear need to represent "no result," and where using
>>> {@code
>>> null}
>>> + * is likely to cause errors. A variable whose type is {@code
>>> OptionalDouble} should
>>>
>>> The obvious alternative to returning OptionalDouble is returning double,
>>> where null is not possible. I would elide """and where using {@code null}
>>> + * is likely to cause errors""" unless you want to explicitly compare
>>> with
>>> the alternative of returning Double,not double.
>>>
>>>
>> ?? and where using the default value (@code {0.0d}) is likely to cause
>> errors."
>>
>> ?
>>
>> Paul.
>>
>> (More generally, it seems like Optional would have more value if there was
>>> compiler enforcement of its never-null-ness.)
>>>
>>>
>>> On Tue, Apr 18, 2017 at 6:23 PM, Stuart Marks <stuart.marks at oracle.com>
>>> wrote:
>>>
>>> Hi all,
>>>>
>>>> Please review this small set of non-normative documentation changes for
>>>> java.util.Optional and related classes.
>>>>
>>>> The notes describe the primary intent of Optional to be used as a return
>>>> value, and recommend avoiding using null as the value of a variable of
>>>> Optional type. Also, a note is added to get() directing readers to look
>>>> at
>>>> orElse() and orElseGet().
>>>>
>>>> Corresponding changes are also made to the primitive specializations
>>>> OptionalDouble, OptionalInt, and OptionalLong.
>>>>
>>>> Bug:
>>>>        https://bugs.openjdk.java.net/browse/JDK-8167981
>>>>
>>>> Webrev:
>>>>        http://cr.openjdk.java.net/~smarks/reviews/8167981/webrev.0/
>>>>
>>>> Thanks,
>>>>
>>>> s'marks
>>>>
>>>>
>>

From huizhe.wang at oracle.com  Thu Apr 20 17:20:30 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 20 Apr 2017 10:20:30 -0700
Subject: RFR 8178915: Minor update to the PooledConnection javadoc
In-Reply-To: <DC56770D-2C41-45B0-816E-62438ECD7E2B@oracle.com>
References: <DC56770D-2C41-45B0-816E-62438ECD7E2B@oracle.com>
Message-ID: <5319b0e3-c660-624e-e269-749077a5079b@oracle.com>

Hi Lance,

The changes look good to me.

-Joe

On 4/20/2017 6:40 AM, Lance Andersen wrote:
> Hi all,
>
> This RFR makes a minor update to the PooledConnection javadoc.  The CCC has been approved.
>
> Here is the diff:
>
> ???????
> $ hg diff
> diff -r 9ba6760481a8 src/java.sql/share/classes/javax/sql/PooledConnection.java
> --- a/src/java.sql/share/classes/javax/sql/PooledConnection.java	Sat Apr 15 16:54:33 2017 -0400
> +++ b/src/java.sql/share/classes/javax/sql/PooledConnection.java	Tue Apr 18 14:50:44 2017 -0400
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.
>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>    *
>    * This code is free software; you can redistribute it and/or modify it
> @@ -69,8 +69,9 @@
>    * <p>
>    * If the connection pool manager wraps or provides a proxy to the logical
>    * handle returned from a call to {@code PoolConnection.getConnection}, the pool
> - * manager must do
> - * one of the following when the application calls {@code Connection.close}:
> + * manager must do one of the following when the connection pool manager
> + * closes or returns the {@code PooledConnection} to the pool in response to
> + * the application calling {@code Connection.close}:
>    * <ul>
>    * <li>call {@code endRequest} on the logical {@code Connection} handle
>    * <li>call {@code close} on the logical {@code Connection} handle
> ljanders-mac:src ljanders$
> ??????????
>
> Best
> Lance
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>


From magnus.ihse.bursie at oracle.com  Thu Apr 20 18:47:13 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 20 Apr 2017 20:47:13 +0200
Subject: RFR: JDK-8179022 Add serialization spec as markdown
In-Reply-To: <7bd7afd5-7d32-bddb-2811-9992577c3eb5@oracle.com>
References: <c35c1c23-1761-062d-2461-cd726f022dd4@oracle.com>
 <7bd7afd5-7d32-bddb-2811-9992577c3eb5@oracle.com>
Message-ID: <d4dfc2ae-26db-94ef-ea6e-db63772159df@oracle.com>

On 2017-04-20 15:59, Alan Bateman wrote:
> On 20/04/2017 14:49, Magnus Ihse Bursie wrote:
>
>> Here's the first step towards fixing JDK-8177434 
>> <https://bugs.openjdk.java.net/browse/JDK-8177434>. A framework is 
>> added for converting markdown specs to html using pandoc. The Java 
>> serialization spec is added in markdown format as a proof of concept. 
>> I also reintroduced the functionality to enable full docs if all 
>> prerequisites are present.
>>
>> Note that this fix is dependent on the patch for JDK-8178038 et al 
>> that is currently out for review. The webrev is created with that 
>> patch as baseline.
>>
>> This fix is part of JEP 299. I intend to push it to jdk9.
>>
>> Here's an example of the generated output:
>> http://cr.openjdk.java.net/~ihse/JDK-8179022-javadoc-output-demo/specs/serialization/ 
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179022
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.01
> I just skimmed this and notice this adds class.gif with output that I 
> think is serialver. This tool has been changed in JDK 9 to drop the 
> GUI and so this image and the reference to the "Show" button are now 
> obsolete. I'm sure you don't want want to get into issues like this 
> but we will need to submit a few bugs to ensure that some of the dusty 
> documents are updated.

You are right that I do not want to make any substantial changes to the 
documentation. I have made an effort to make sure the markdown is of a 
high quality (like any other source code), so that it should be easy to 
read and update. In this process I noticed a few minor issues (like 
syntactic errors in the examples, or incorrect/inconsistent formatting) 
which I have fixed.

I have also noticed some things that sound like they need to be updated, 
like the serialver stuff. I'm no expert on serialization, but perhaps I 
can have an offline chat with someone who are, and come with a couple of 
suggestions on things to improve with the documentation.

---

I just noticed that I had missed to do "hg add" so webrev did not pick 
up my new script that creates the pandoc bundle. Here's an updated 
webrev that added this:

http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.02

/Magnus

>
> -Alan


From Roger.Riggs at Oracle.com  Thu Apr 20 18:51:43 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 20 Apr 2017 14:51:43 -0400
Subject: RFR: JDK-8179022 Add serialization spec as markdown
In-Reply-To: <d4dfc2ae-26db-94ef-ea6e-db63772159df@oracle.com>
References: <c35c1c23-1761-062d-2461-cd726f022dd4@oracle.com>
 <7bd7afd5-7d32-bddb-2811-9992577c3eb5@oracle.com>
 <d4dfc2ae-26db-94ef-ea6e-db63772159df@oracle.com>
Message-ID: <9c7e600e-002c-4423-630b-796c54d206b1@Oracle.com>

Hi Magnus,

How did you verify that the result was the same as the previous 
specification?
It would have been good to separate the content changes from the other parts
so they could be properly reviewed.  The proposed markdown source does not
favorably easily with the spec as I worked on it a couple of months ago.
That's going to take more work to verify.

Thanks, Roger


On 4/20/2017 2:47 PM, Magnus Ihse Bursie wrote:
> On 2017-04-20 15:59, Alan Bateman wrote:
>> On 20/04/2017 14:49, Magnus Ihse Bursie wrote:
>>
>>> Here's the first step towards fixing JDK-8177434 
>>> <https://bugs.openjdk.java.net/browse/JDK-8177434>. A framework is 
>>> added for converting markdown specs to html using pandoc. The Java 
>>> serialization spec is added in markdown format as a proof of 
>>> concept. I also reintroduced the functionality to enable full docs 
>>> if all prerequisites are present.
>>>
>>> Note that this fix is dependent on the patch for JDK-8178038 et al 
>>> that is currently out for review. The webrev is created with that 
>>> patch as baseline.
>>>
>>> This fix is part of JEP 299. I intend to push it to jdk9.
>>>
>>> Here's an example of the generated output:
>>> http://cr.openjdk.java.net/~ihse/JDK-8179022-javadoc-output-demo/specs/serialization/ 
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179022
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.01
>> I just skimmed this and notice this adds class.gif with output that I 
>> think is serialver. This tool has been changed in JDK 9 to drop the 
>> GUI and so this image and the reference to the "Show" button are now 
>> obsolete. I'm sure you don't want want to get into issues like this 
>> but we will need to submit a few bugs to ensure that some of the 
>> dusty documents are updated.
>
> You are right that I do not want to make any substantial changes to 
> the documentation. I have made an effort to make sure the markdown is 
> of a high quality (like any other source code), so that it should be 
> easy to read and update. In this process I noticed a few minor issues 
> (like syntactic errors in the examples, or incorrect/inconsistent 
> formatting) which I have fixed.
>
> I have also noticed some things that sound like they need to be 
> updated, like the serialver stuff. I'm no expert on serialization, but 
> perhaps I can have an offline chat with someone who are, and come with 
> a couple of suggestions on things to improve with the documentation.
>
> ---
>
> I just noticed that I had missed to do "hg add" so webrev did not pick 
> up my new script that creates the pandoc bundle. Here's an updated 
> webrev that added this:
>
> http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.02 
>
>
> /Magnus
>
>>
>> -Alan
>


From mandy.chung at oracle.com  Thu Apr 20 19:28:10 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 20 Apr 2017 12:28:10 -0700
Subject: RFR: JDK-8179022 Add serialization spec as markdown
In-Reply-To: <d4dfc2ae-26db-94ef-ea6e-db63772159df@oracle.com>
References: <c35c1c23-1761-062d-2461-cd726f022dd4@oracle.com>
 <7bd7afd5-7d32-bddb-2811-9992577c3eb5@oracle.com>
 <d4dfc2ae-26db-94ef-ea6e-db63772159df@oracle.com>
Message-ID: <5ED77D59-502A-421F-9445-885B8E2616C5@oracle.com>


> On Apr 20, 2017, at 11:47 AM, Magnus Ihse Bursie wrote:
> 
> http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.02

A passing comment.

Copyright header is missing in make/devkit/createPandocBundle.sh

Mandy


From naoto.sato at oracle.com  Thu Apr 20 19:42:12 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 20 Apr 2017 12:42:12 -0700
Subject: [9] RFR: 8178823: Unable to initialize HijrahCalendar:
 Hijrah-umalqura when running with a security manager
Message-ID: <50231fc8-4648-8172-e5d3-91623ef853f3@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8178823/webrev.01/

The fix is to allow "accessSystemModule" RuntimePermission on reading 
the Hijrah properties file, which is now required from JDK9 build 165+.

Naoto

From stuart.marks at oracle.com  Thu Apr 20 20:21:22 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 20 Apr 2017 13:21:22 -0700
Subject: JDK 9 RFR(s): 8167981: Optional: add notes explaining intended use
In-Reply-To: <CA+kOe0_0-uZakfcrZ_nYkMOqqNCRyXxerorikMppnCoXHDnoDw@mail.gmail.com>
References: <247a3b98-3304-97a9-3a49-23d81350b3bc@oracle.com>
 <CA+kOe0-D+K6rDUqdRjSTvNFtmPcDmdS38Tpt2k5QzW8wzhBUww@mail.gmail.com>
 <054D5B5E-BD04-4F91-8A95-EA1DE2258932@oracle.com>
 <e17369c6-07ee-fbec-0c79-08e890d80d8d@oracle.com>
 <CA+kOe0_0-uZakfcrZ_nYkMOqqNCRyXxerorikMppnCoXHDnoDw@mail.gmail.com>
Message-ID: <336616c6-b40b-da37-ea9b-37589161afb2@oracle.com>



On 4/20/17 10:03 AM, Martin Buchholz wrote:
> This looks good.
>
> I don't think there's any need anymore to have fully qualified class names in
> @links, so just:
>
> {@link #orElseGet(Supplier) orElseGet}
>
> (but there's a global cleanup there)

Thanks for reviewing.

Yes, "java.util.function.Supplier" is unnecessary. "Supplier" is sufficient in 
this context, since the file imports java.util.function.Supplier, and javadoc 
respects imports. I've fixed this occurrence and one other similar unnecessarily 
fully-qualified name in the class doc. (Along with corresponding changes in 
Optional{Double,Int,Long}.)

> I would write
> "result".
> instead of
> "result."
>
> (but the latter has never made sense to me even as a child)

Yeah, this is a long-standing usage dispute over typography, probably dating 
back to before there were programming languages. I don't think we're going to 
resolve it here. :-)

s'marks

From lance.andersen at oracle.com  Thu Apr 20 20:50:31 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 20 Apr 2017 16:50:31 -0400
Subject: [9] RFR: 8178823: Unable to initialize HijrahCalendar:
 Hijrah-umalqura when running with a security manager
In-Reply-To: <50231fc8-4648-8172-e5d3-91623ef853f3@oracle.com>
References: <50231fc8-4648-8172-e5d3-91623ef853f3@oracle.com>
Message-ID: <3E3C1A9F-4C92-4EB6-BA90-C8FF6926B3CC@oracle.com>

Hi Naoto

Looks fine

Best
Lance
> On Apr 20, 2017, at 3:42 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Hello,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8178823
> 
> The proposed fix is located at:
> 
> http://cr.openjdk.java.net/~naoto/8178823/webrev.01/
> 
> The fix is to allow "accessSystemModule" RuntimePermission on reading the Hijrah properties file, which is now required from JDK9 build 165+.
> 
> Naoto

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From Roger.Riggs at Oracle.com  Thu Apr 20 20:54:31 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 20 Apr 2017 16:54:31 -0400
Subject: [9] RFR: 8178823: Unable to initialize HijrahCalendar:
 Hijrah-umalqura when running with a security manager
In-Reply-To: <3E3C1A9F-4C92-4EB6-BA90-C8FF6926B3CC@oracle.com>
References: <50231fc8-4648-8172-e5d3-91623ef853f3@oracle.com>
 <3E3C1A9F-4C92-4EB6-BA90-C8FF6926B3CC@oracle.com>
Message-ID: <04bfc2db-503f-942e-3f44-32c1cb1b5119@Oracle.com>

+1,

Looks good Naoto,

Thanks, Roger

On 4/20/2017 4:50 PM, Lance Andersen wrote:
> Hi Naoto
>
> Looks fine
>
> Best
> Lance
>> On Apr 20, 2017, at 3:42 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8178823
>>
>> The proposed fix is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8178823/webrev.01/
>>
>> The fix is to allow "accessSystemModule" RuntimePermission on reading the Hijrah properties file, which is now required from JDK9 build 165+.
>>
>> Naoto
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>


From aleksej.efimov at oracle.com  Fri Apr 21 00:17:53 2017
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Fri, 21 Apr 2017 03:17:53 +0300
Subject: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable
 reset
In-Reply-To: <bd08e87c-0c05-2f7f-411f-b72ef98e66ae@oracle.com>
References: <adc0462f-5ff7-f881-ed1d-a05c5ce1ea0f@oracle.com>
 <bd08e87c-0c05-2f7f-411f-b72ef98e66ae@oracle.com>
Message-ID: <103a0157-8c66-0b6a-fbee-133490f746e1@oracle.com>

Hi Joe, Lance,

Thank you both for the reviews! I've updated the test methods with 
comments per Joe suggestions [1]. Also the CCC request was approved 
recently. If there will be no further comments I'll push the changes.

Best Regards,
Aleksei

[1] http://cr.openjdk.java.net/~aefimov/8176168/01/

On 19/04/17 21:41, huizhe wang wrote:
> Hi Aleksej,
>
> The changes look good. Some changes to the notes in the test may make 
> it a bit clearer on what scenarios are tested: move the current notes 
> for the method testResetEnabled to parseAndCheckReset, and then add 
> scenario description to the three test* methods, for example, 
> testNoFeatureSet verifies two scenarios: resetSymbolTable is and is 
> not requested through the System property, while testResetEnabled 
> tests that the feature is set  and testResetDisabled unset by using 
> SAXParserFactory's setFeature method regardless of whether the System 
> property is set.
>
> Best regards,
> Joe
>
> On 4/16/2017 3:02 PM, Aleks Efimov wrote:
>> Hi,
>>
>> Please, help to review the fix [1] for a performance regression in 
>> SPECjvm2008-XML benchmark. The cause of this regression was the 
>> unconditional reset of SAX parsers symbol table during each reset() 
>> operation introduced by JDK-8173390.
>> Proposed fix introduces new system property (CCC request is still 
>> pending approval) that provides ability to control the symbol table 
>> reset functionality. By default the reset table functionality is 
>> disabled, similar to pre JDK-8173390 behavior. JAXWS parsers pool 
>> implementation was updated to utilize new property to reset symbol 
>> table only in JAXWS use-cases that helped to restore the performance 
>> levels to pre JDK-8173390 level.
>>
>> Modified regression test and XML related JCK tests passes on build 
>> with proposed changes.
>>
>> With Best Regards,
>> Aleksei
>>
>> [1] http://cr.openjdk.java.net/~aefimov/8176168/00/
>


From huizhe.wang at oracle.com  Fri Apr 21 03:58:39 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 20 Apr 2017 20:58:39 -0700
Subject: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable
 reset
In-Reply-To: <103a0157-8c66-0b6a-fbee-133490f746e1@oracle.com>
References: <adc0462f-5ff7-f881-ed1d-a05c5ce1ea0f@oracle.com>
 <bd08e87c-0c05-2f7f-411f-b72ef98e66ae@oracle.com>
 <103a0157-8c66-0b6a-fbee-133490f746e1@oracle.com>
Message-ID: <65007d22-b1ef-7798-4620-e32279defe60@oracle.com>

Looks fine.

-Joe

On 4/20/2017 5:17 PM, Aleks Efimov wrote:
> Hi Joe, Lance,
>
> Thank you both for the reviews! I've updated the test methods with 
> comments per Joe suggestions [1]. Also the CCC request was approved 
> recently. If there will be no further comments I'll push the changes.
>
> Best Regards,
> Aleksei
>
> [1] http://cr.openjdk.java.net/~aefimov/8176168/01/
>
> On 19/04/17 21:41, huizhe wang wrote:
>> Hi Aleksej,
>>
>> The changes look good. Some changes to the notes in the test may make 
>> it a bit clearer on what scenarios are tested: move the current notes 
>> for the method testResetEnabled to parseAndCheckReset, and then add 
>> scenario description to the three test* methods, for example, 
>> testNoFeatureSet verifies two scenarios: resetSymbolTable is and is 
>> not requested through the System property, while testResetEnabled 
>> tests that the feature is set  and testResetDisabled unset by using 
>> SAXParserFactory's setFeature method regardless of whether the System 
>> property is set.
>>
>> Best regards,
>> Joe
>>
>> On 4/16/2017 3:02 PM, Aleks Efimov wrote:
>>> Hi,
>>>
>>> Please, help to review the fix [1] for a performance regression in 
>>> SPECjvm2008-XML benchmark. The cause of this regression was the 
>>> unconditional reset of SAX parsers symbol table during each reset() 
>>> operation introduced by JDK-8173390.
>>> Proposed fix introduces new system property (CCC request is still 
>>> pending approval) that provides ability to control the symbol table 
>>> reset functionality. By default the reset table functionality is 
>>> disabled, similar to pre JDK-8173390 behavior. JAXWS parsers pool 
>>> implementation was updated to utilize new property to reset symbol 
>>> table only in JAXWS use-cases that helped to restore the performance 
>>> levels to pre JDK-8173390 level.
>>>
>>> Modified regression test and XML related JCK tests passes on build 
>>> with proposed changes.
>>>
>>> With Best Regards,
>>> Aleksei
>>>
>>> [1] http://cr.openjdk.java.net/~aefimov/8176168/00/
>>
>


From amy.lu at oracle.com  Fri Apr 21 04:47:29 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Fri, 21 Apr 2017 12:47:29 +0800
Subject: JDK 9 RFR of JDK-8174171: Move spliterator testing of BitSet into
 big memory tests BitSetStreamTest
In-Reply-To: <de8610ac-6be1-81a6-21ab-623df397151d@oracle.com>
References: <7797193a-5507-7092-db34-b8ca6a8b09de@oracle.com>
 <de8610ac-6be1-81a6-21ab-623df397151d@oracle.com>
Message-ID: <03ab6939-6eeb-e402-3e10-8b23ddc056d5@oracle.com>

Thank you Hamlin for your comments.

On 4/20/17 6:23 PM, Hamlin Li wrote:
> Hi Amy,
>
> Thank you for taking this. Have some minor comments about 
> BitSetStreamTest.java
>
> 1. is below line necessary? or 2g big enough?
>
> 51 * @requires os.maxMemory >= 2g
>
> 2. I'm not sure if Xmx1024m should be a bigger value.
>
> 55 * @run testng/othervm -Xms512m -Xmx1024m

With profiler, the max heap size is ~700m, sometime higher but less than 1g.

I tested on different configs:
JPRT on all platforms, 10 runs of whole jdk_util, all pass;
Also tried:
At 2 cores, 4G mem, Win32 machine, jdk_util, 10 times of run, all pass
At 4 cores, 16G mem, Win64 machine, whole jdk/test:tier1, 10 runs, all pass
At 4 cores, 8G mem, Linux32 machine, whole jdk/test:tier1, 10 runs, all pass

I would like this test to be skipped on very poor config system, <2g mem.
>
> 3. spliteratorOfIntDataProvider is created only once and shared 
> between multiple tests. I'm not sure if parallel is enabled, but if it 
> is already enabled or enable some day in future, it might face issue 
> although possibility is very low, so adding volatile might make it safe.

No parallel.

Thanks,
Amy

>
> Thank you
> -Hamlin
>
> On 2017/4/20 17:10, Amy Lu wrote:
>> Please review this test-only change.
>>
>> Integer.MAX_VALUE bit set testdata in bitStreamTestcases of 
>> SpliteratorTraversingAndSplittingTest was removed in JDK-8169838 due 
>> to out of memory errors. It also cause issue in BitSetStreamTest 
>> (JDK-8079538). And yes, testing for this do consume lots of memory.
>>
>> This patch moved the spliterator testing of BitSet into big memory 
>> tests BitSetStreamTest:
>>
>> 1) bitStreamTestcases removed from SpliteratorTraversingAndSplittingTest
>> 2) Above test cases, with adding back Integer.MAX_VALUE testdata, now 
>> is in the newly introduced @DataProvider and being tested in 
>> BitSetStreamTest.
>> 3) It's better BitSetStreamTest not to be run concurrently with other 
>> test so to avoid memory usage conflict. With this purpose,
>> BitSetStreamTest moved to java/util/BitSet/stream subdir, and this 
>> subdir added to exclusiveAccess.dirs
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8174171
>> webrev: http://cr.openjdk.java.net/~amlu/8174171/webrev.00/
>>
>> Thanks,
>> Amy
>


From huaming.li at oracle.com  Fri Apr 21 06:14:52 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 21 Apr 2017 14:14:52 +0800
Subject: JDK 9 RFR of JDK-8174171: Move spliterator testing of BitSet into
 big memory tests BitSetStreamTest
In-Reply-To: <03ab6939-6eeb-e402-3e10-8b23ddc056d5@oracle.com>
References: <7797193a-5507-7092-db34-b8ca6a8b09de@oracle.com>
 <de8610ac-6be1-81a6-21ab-623df397151d@oracle.com>
 <03ab6939-6eeb-e402-3e10-8b23ddc056d5@oracle.com>
Message-ID: <d3798e49-a300-870e-54ef-b52e00db1726@oracle.com>

Thank you for explanation Amy. you still need a reviewer.

Thank you

-Hamlin


On 2017/4/21 12:47, Amy Lu wrote:
> Thank you Hamlin for your comments.
>
> On 4/20/17 6:23 PM, Hamlin Li wrote:
>> Hi Amy,
>>
>> Thank you for taking this. Have some minor comments about 
>> BitSetStreamTest.java
>>
>> 1. is below line necessary? or 2g big enough?
>>
>> 51 * @requires os.maxMemory >= 2g
>>
>> 2. I'm not sure if Xmx1024m should be a bigger value.
>>
>> 55 * @run testng/othervm -Xms512m -Xmx1024m
>
> With profiler, the max heap size is ~700m, sometime higher but less 
> than 1g.
>
> I tested on different configs:
> JPRT on all platforms, 10 runs of whole jdk_util, all pass;
> Also tried:
> At 2 cores, 4G mem, Win32 machine, jdk_util, 10 times of run, all pass
> At 4 cores, 16G mem, Win64 machine, whole jdk/test:tier1, 10 runs, all 
> pass
> At 4 cores, 8G mem, Linux32 machine, whole jdk/test:tier1, 10 runs, 
> all pass
>
> I would like this test to be skipped on very poor config system, <2g mem.
>>
>> 3. spliteratorOfIntDataProvider is created only once and shared 
>> between multiple tests. I'm not sure if parallel is enabled, but if 
>> it is already enabled or enable some day in future, it might face 
>> issue although possibility is very low, so adding volatile might make 
>> it safe.
>
> No parallel.
>
> Thanks,
> Amy
>
>>
>> Thank you
>> -Hamlin
>>
>> On 2017/4/20 17:10, Amy Lu wrote:
>>> Please review this test-only change.
>>>
>>> Integer.MAX_VALUE bit set testdata in bitStreamTestcases of 
>>> SpliteratorTraversingAndSplittingTest was removed in JDK-8169838 due 
>>> to out of memory errors. It also cause issue in BitSetStreamTest 
>>> (JDK-8079538). And yes, testing for this do consume lots of memory.
>>>
>>> This patch moved the spliterator testing of BitSet into big memory 
>>> tests BitSetStreamTest:
>>>
>>> 1) bitStreamTestcases removed from 
>>> SpliteratorTraversingAndSplittingTest
>>> 2) Above test cases, with adding back Integer.MAX_VALUE testdata, 
>>> now is in the newly introduced @DataProvider and being tested in 
>>> BitSetStreamTest.
>>> 3) It's better BitSetStreamTest not to be run concurrently with 
>>> other test so to avoid memory usage conflict. With this purpose,
>>> BitSetStreamTest moved to java/util/BitSet/stream subdir, and this 
>>> subdir added to exclusiveAccess.dirs
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8174171
>>> webrev: http://cr.openjdk.java.net/~amlu/8174171/webrev.00/
>>>
>>> Thanks,
>>> Amy
>>
>


From lance.andersen at oracle.com  Fri Apr 21 11:31:56 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 21 Apr 2017 07:31:56 -0400
Subject: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable
 reset
In-Reply-To: <103a0157-8c66-0b6a-fbee-133490f746e1@oracle.com>
References: <adc0462f-5ff7-f881-ed1d-a05c5ce1ea0f@oracle.com>
 <bd08e87c-0c05-2f7f-411f-b72ef98e66ae@oracle.com>
 <103a0157-8c66-0b6a-fbee-133490f746e1@oracle.com>
Message-ID: <FD54F495-1124-43A3-8B33-3844F2CE7148@oracle.com>

Hi Aleksej

looks good

Best
Lance
> On Apr 20, 2017, at 8:17 PM, Aleks Efimov <aleksej.efimov at oracle.com> wrote:
> 
> Hi Joe, Lance,
> 
> Thank you both for the reviews! I've updated the test methods with comments per Joe suggestions [1]. Also the CCC request was approved recently. If there will be no further comments I'll push the changes.
> 
> Best Regards,
> Aleksei
> 
> [1] http://cr.openjdk.java.net/~aefimov/8176168/01/
> 
> On 19/04/17 21:41, huizhe wang wrote:
>> Hi Aleksej,
>> 
>> The changes look good. Some changes to the notes in the test may make it a bit clearer on what scenarios are tested: move the current notes for the method testResetEnabled to parseAndCheckReset, and then add scenario description to the three test* methods, for example, testNoFeatureSet verifies two scenarios: resetSymbolTable is and is not requested through the System property, while testResetEnabled tests that the feature is set  and testResetDisabled unset by using SAXParserFactory's setFeature method regardless of whether the System property is set.
>> 
>> Best regards,
>> Joe
>> 
>> On 4/16/2017 3:02 PM, Aleks Efimov wrote:
>>> Hi,
>>> 
>>> Please, help to review the fix [1] for a performance regression in SPECjvm2008-XML benchmark. The cause of this regression was the unconditional reset of SAX parsers symbol table during each reset() operation introduced by JDK-8173390.
>>> Proposed fix introduces new system property (CCC request is still pending approval) that provides ability to control the symbol table reset functionality. By default the reset table functionality is disabled, similar to pre JDK-8173390 behavior. JAXWS parsers pool implementation was updated to utilize new property to reset symbol table only in JAXWS use-cases that helped to restore the performance levels to pre JDK-8173390 level.
>>> 
>>> Modified regression test and XML related JCK tests passes on build with proposed changes.
>>> 
>>> With Best Regards,
>>> Aleksei
>>> 
>>> [1] http://cr.openjdk.java.net/~aefimov/8176168/00/
>> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From Roger.Riggs at Oracle.com  Fri Apr 21 14:46:01 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 21 Apr 2017 10:46:01 -0400
Subject: RFR: JDK-8179022 Add serialization spec as markdown
In-Reply-To: <9c7e600e-002c-4423-630b-796c54d206b1@Oracle.com>
References: <c35c1c23-1761-062d-2461-cd726f022dd4@oracle.com>
 <7bd7afd5-7d32-bddb-2811-9992577c3eb5@oracle.com>
 <d4dfc2ae-26db-94ef-ea6e-db63772159df@oracle.com>
 <9c7e600e-002c-4423-630b-796c54d206b1@Oracle.com>
Message-ID: <0a1d5bd0-77a8-4fff-1479-d293bcf8ccf6@Oracle.com>

Hi Magnus,

Looks good, I checked the previous and new html content and found no 
significant differences.
There are some content improvements that should be made but that's a 
separate task.

Thanks, Roger


On 4/20/2017 2:51 PM, Roger Riggs wrote:
> Hi Magnus,
>
> How did you verify that the result was the same as the previous 
> specification?
> It would have been good to separate the content changes from the other 
> parts
> so they could be properly reviewed.  The proposed markdown source does 
> not
> favorably easily with the spec as I worked on it a couple of months ago.
> That's going to take more work to verify.
>
> Thanks, Roger
>
>
> On 4/20/2017 2:47 PM, Magnus Ihse Bursie wrote:
>> On 2017-04-20 15:59, Alan Bateman wrote:
>>> On 20/04/2017 14:49, Magnus Ihse Bursie wrote:
>>>
>>>> Here's the first step towards fixing JDK-8177434 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8177434>. A framework is 
>>>> added for converting markdown specs to html using pandoc. The Java 
>>>> serialization spec is added in markdown format as a proof of 
>>>> concept. I also reintroduced the functionality to enable full docs 
>>>> if all prerequisites are present.
>>>>
>>>> Note that this fix is dependent on the patch for JDK-8178038 et al 
>>>> that is currently out for review. The webrev is created with that 
>>>> patch as baseline.
>>>>
>>>> This fix is part of JEP 299. I intend to push it to jdk9.
>>>>
>>>> Here's an example of the generated output:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8179022-javadoc-output-demo/specs/serialization/ 
>>>>
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179022
>>>> WebRev: 
>>>> http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.01
>>> I just skimmed this and notice this adds class.gif with output that 
>>> I think is serialver. This tool has been changed in JDK 9 to drop 
>>> the GUI and so this image and the reference to the "Show" button are 
>>> now obsolete. I'm sure you don't want want to get into issues like 
>>> this but we will need to submit a few bugs to ensure that some of 
>>> the dusty documents are updated.
>>
>> You are right that I do not want to make any substantial changes to 
>> the documentation. I have made an effort to make sure the markdown is 
>> of a high quality (like any other source code), so that it should be 
>> easy to read and update. In this process I noticed a few minor issues 
>> (like syntactic errors in the examples, or incorrect/inconsistent 
>> formatting) which I have fixed.
>>
>> I have also noticed some things that sound like they need to be 
>> updated, like the serialver stuff. I'm no expert on serialization, 
>> but perhaps I can have an offline chat with someone who are, and come 
>> with a couple of suggestions on things to improve with the 
>> documentation.
>>
>> ---
>>
>> I just noticed that I had missed to do "hg add" so webrev did not 
>> pick up my new script that creates the pandoc bundle. Here's an 
>> updated webrev that added this:
>>
>> http://cr.openjdk.java.net/~ihse/JDK-8179022-add-markdown-serialization-spec/webrev.02 
>>
>>
>> /Magnus
>>
>>>
>>> -Alan
>>
>


From paul.sandoz at oracle.com  Fri Apr 21 17:18:29 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 21 Apr 2017 10:18:29 -0700
Subject: JDK 9 RFR of JDK-8174171: Move spliterator testing of BitSet into
 big memory tests BitSetStreamTest
In-Reply-To: <d3798e49-a300-870e-54ef-b52e00db1726@oracle.com>
References: <7797193a-5507-7092-db34-b8ca6a8b09de@oracle.com>
 <de8610ac-6be1-81a6-21ab-623df397151d@oracle.com>
 <03ab6939-6eeb-e402-3e10-8b23ddc056d5@oracle.com>
 <d3798e49-a300-870e-54ef-b52e00db1726@oracle.com>
Message-ID: <E37F0D5B-DEE5-4229-A2C6-A57F3D2D045C@oracle.com>


> On 20 Apr 2017, at 23:14, Hamlin Li <huaming.li at oracle.com> wrote:
> 
> Thank you for explanation Amy. you still need a reviewer.
> 

+1

It would be nice as a follow on for the test to be smart and only run certain tests when there is enough memory, or split the test further.

Paul.

From ivan.gerasimov at oracle.com  Fri Apr 21 17:55:25 2017
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 21 Apr 2017 10:55:25 -0700
Subject: [10] RFR 8179086: java.time.temporal.ValueRange has poor hashCode()
Message-ID: <ffda3430-ba29-adff-0bb6-20dc0785ecaf@oracle.com>

Hello!

It was noticed that ValueRange.hashCode() returns zero for many values.
This is due to lack of some parentheses to set correct precedence.

Would you please help review the trivial fix?

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

The fix is applicable to jdk 9, but I'm not sure it's that critical.
We can later backport it to an update release.

-- 
With kind regards,
Ivan Gerasimov


From Roger.Riggs at Oracle.com  Fri Apr 21 18:07:36 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 21 Apr 2017 14:07:36 -0400
Subject: [10] RFR 8179086: java.time.temporal.ValueRange has poor
 hashCode()
In-Reply-To: <ffda3430-ba29-adff-0bb6-20dc0785ecaf@oracle.com>
References: <ffda3430-ba29-adff-0bb6-20dc0785ecaf@oracle.com>
Message-ID: <d9140a9f-b076-6851-0fe7-36a31af1f2f0@Oracle.com>

Hi Ivan,

Looks fine,  I don't expect many ValueRanges in hash maps.
JDK 10 is a fine place to put it.

Thanks, Roger


On 4/21/2017 1:55 PM, Ivan Gerasimov wrote:
> Hello!
>
> It was noticed that ValueRange.hashCode() returns zero for many values.
> This is due to lack of some parentheses to set correct precedence.
>
> Would you please help review the trivial fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8179086
> WEBREV: http://cr.openjdk.java.net/~igerasim/8179086/00/webrev/
>
> The fix is applicable to jdk 9, but I'm not sure it's that critical.
> We can later backport it to an update release.
>


From ivan.gerasimov at oracle.com  Fri Apr 21 18:42:14 2017
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 21 Apr 2017 11:42:14 -0700
Subject: [10] RFR 8179086: java.time.temporal.ValueRange has poor
 hashCode()
In-Reply-To: <d9140a9f-b076-6851-0fe7-36a31af1f2f0@Oracle.com>
References: <ffda3430-ba29-adff-0bb6-20dc0785ecaf@oracle.com>
 <d9140a9f-b076-6851-0fe7-36a31af1f2f0@Oracle.com>
Message-ID: <b43650c0-b4d5-1905-bb64-ab323eb81174@oracle.com>

Thank you Roger!

Pushed.


On 4/21/17 11:07 AM, Roger Riggs wrote:
> Hi Ivan,
>
> Looks fine,  I don't expect many ValueRanges in hash maps.
> JDK 10 is a fine place to put it.
>
> Thanks, Roger
>
>
> On 4/21/2017 1:55 PM, Ivan Gerasimov wrote:
>> Hello!
>>
>> It was noticed that ValueRange.hashCode() returns zero for many values.
>> This is due to lack of some parentheses to set correct precedence.
>>
>> Would you please help review the trivial fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8179086
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8179086/00/webrev/
>>
>> The fix is applicable to jdk 9, but I'm not sure it's that critical.
>> We can later backport it to an update release.
>>
>
>

-- 
With kind regards,
Ivan Gerasimov


From peter.levart at gmail.com  Sat Apr 22 09:40:24 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 22 Apr 2017 11:40:24 +0200
Subject: Optional.isEmpty()
Message-ID: <a12cce31-1900-eeb1-c868-81cc71d226f8@gmail.com>

Hi,

Seeing the following line in some JDK test that was up for review:

     return cf.findModule(target).orElse(null) == null;

I immediately jumped to suggest it would look better if written as:

     return !cf.findModule(target).isPresent();


But then I leaned back and asked myself: "Would it really?"

The boolean negation in front of a chain of method calls tends to 
visually disappear from the view when we finally reach the offending 
method and might get missed when quickly browsing the code. In this 
respect, ".orElse(null) == null" is actually better. But the best would 
of course be something like that:

     return cf.findModule(target).isEmpty();

What do you think? Would this pull its weight?

Regards, Peter


From jbluettduncan at gmail.com  Sat Apr 22 13:31:43 2017
From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan)
Date: Sat, 22 Apr 2017 14:31:43 +0100
Subject: Optional.isEmpty()
In-Reply-To: <a12cce31-1900-eeb1-c868-81cc71d226f8@gmail.com>
References: <a12cce31-1900-eeb1-c868-81cc71d226f8@gmail.com>
Message-ID: <CAPMys85vLPVY_fK6bVss7ZwqwUUEQ7qg3Ppj20VMYwcxiPEe4Q@mail.gmail.com>

Hi Peter,

Your reasoning has personally convinced me that a method like `isEmpty()`
would pull its weight. However, at the risk of bikeshedding, I think it
should be named differently, as `isEmpty()` immediately makes me think that
`findModule()` returns a List, which I'd easily find confusing.

How about `isNotPresent()` instead?

Best regards,
Jonathan

On 22 April 2017 at 10:40, Peter Levart <peter.levart at gmail.com> wrote:

> Hi,
>
> Seeing the following line in some JDK test that was up for review:
>
>     return cf.findModule(target).orElse(null) == null;
>
> I immediately jumped to suggest it would look better if written as:
>
>     return !cf.findModule(target).isPresent();
>
>
> But then I leaned back and asked myself: "Would it really?"
>
> The boolean negation in front of a chain of method calls tends to visually
> disappear from the view when we finally reach the offending method and
> might get missed when quickly browsing the code. In this respect,
> ".orElse(null) == null" is actually better. But the best would of course be
> something like that:
>
>     return cf.findModule(target).isEmpty();
>
> What do you think? Would this pull its weight?
>
> Regards, Peter
>
>

From adinn at redhat.com  Mon Apr 24 08:26:04 2017
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 24 Apr 2017 09:26:04 +0100
Subject: Optional.isEmpty()
In-Reply-To: <CAPMys85vLPVY_fK6bVss7ZwqwUUEQ7qg3Ppj20VMYwcxiPEe4Q@mail.gmail.com>
References: <a12cce31-1900-eeb1-c868-81cc71d226f8@gmail.com>
 <CAPMys85vLPVY_fK6bVss7ZwqwUUEQ7qg3Ppj20VMYwcxiPEe4Q@mail.gmail.com>
Message-ID: <22b905ae-407e-1e6f-1217-4776e0f2836b@redhat.com>

On 22/04/17 14:31, Jonathan Bluett-Duncan wrote:
> Your reasoning has personally convinced me that a method like `isEmpty()`
> would pull its weight. However, at the risk of bikeshedding, I think it
> should be named differently, as `isEmpty()` immediately makes me think that
> `findModule()` returns a List, which I'd easily find confusing.
> 
> How about `isNotPresent()` instead?

Ah, bike-shedding!

Personally, I much prefer isAbsent() to isNotPresent(), presence and
absence being a historically well-sanctioned English language pairing.

[n.b. I'll grant that my preference for C18th literature over Comp Sci
argot might have swayed my judgement in this matter so I'll leave it to
others to sanction or reject that suggestion via a conformantly aligned,
textually rendered act of pollification (i.e. go on, post yer +/-1
follow-ups)]

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From amy.lu at oracle.com  Mon Apr 24 09:01:28 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Mon, 24 Apr 2017 17:01:28 +0800
Subject: JDK 9 RFR of JDK-8174171: Move spliterator testing of BitSet into
 big memory tests BitSetStreamTest
In-Reply-To: <E37F0D5B-DEE5-4229-A2C6-A57F3D2D045C@oracle.com>
References: <7797193a-5507-7092-db34-b8ca6a8b09de@oracle.com>
 <de8610ac-6be1-81a6-21ab-623df397151d@oracle.com>
 <03ab6939-6eeb-e402-3e10-8b23ddc056d5@oracle.com>
 <d3798e49-a300-870e-54ef-b52e00db1726@oracle.com>
 <E37F0D5B-DEE5-4229-A2C6-A57F3D2D045C@oracle.com>
Message-ID: <9602bb2b-c59c-b816-9a1b-4431e793bfd7@oracle.com>

On 4/22/17 1:18 AM, Paul Sandoz wrote:
>> On 20 Apr 2017, at 23:14, Hamlin Li <huaming.li at oracle.com> wrote:
>>
>> Thank you for explanation Amy. you still need a reviewer.
>>
> +1
>
> It would be nice as a follow on for the test to be smart and only run certain tests when there is enough memory, or split the test further.
>
> Paul.

Thank you for reviewing!

Pushed and created JDK-8179213 as the follow-on.

Thanks,
Amy


From vyom.tewari at oracle.com  Mon Apr 24 09:15:44 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Mon, 24 Apr 2017 14:45:44 +0530
Subject: RFR: 8178298 (LdapLoginModule)Migrate the JNDI properties technote to
 javadoc doc-files
Message-ID: <2d811080-fc39-c852-36d1-3f2b5cac7091@oracle.com>

Hi All,

Please review the simple doc fix.

Webrev   : http://cr.openjdk.java.net/~vtewari/8178298/webrev0.0/index.html

Bugid      : https://bugs.openjdk.java.net/browse/JDK-8178298

Note, this patch depends on "JDK-8178725".

Thanks,

Vyom


From dalibor.topic at oracle.com  Mon Apr 24 09:59:43 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Mon, 24 Apr 2017 11:59:43 +0200
Subject: Optional.isEmpty()
In-Reply-To: <22b905ae-407e-1e6f-1217-4776e0f2836b@redhat.com>
References: <a12cce31-1900-eeb1-c868-81cc71d226f8@gmail.com>
 <CAPMys85vLPVY_fK6bVss7ZwqwUUEQ7qg3Ppj20VMYwcxiPEe4Q@mail.gmail.com>
 <22b905ae-407e-1e6f-1217-4776e0f2836b@redhat.com>
Message-ID: <bf6328f5-881f-ab96-fdb4-256313c96c0b@oracle.com>



On 24.04.2017 10:26, Andrew Dinn wrote:
> Ah, bike-shedding!
>
> Personally, I much prefer isAbsent() to isNotPresent(), presence and
> absence being a historically well-sanctioned English language pairing.
>
> [n.b. I'll grant that my preference for C18th literature over Comp Sci
> argot might have swayed my judgement in this matter so I'll leave it to
> others to sanction or reject that suggestion via a conformantly aligned,
> textually rendered act of pollification (i.e. go on, post yer +/-1
> follow-ups)]

If we're going with fine aged literature references for naming things, 
then isBarren() might signify appealing, yet slightly terrifying 
existential emptiness. [0] [1]

cheers,
dalibor topic

[0] 'The Draculas were, says Arminius, a great and noble race, though 
now and again were scions who were held by their coevals to have had 
dealings with the Evil One. They learned his secrets in the Scholomance, 
amongst the mountains over Lake Hermanstadt, where the devil claims the 
tenth scholar as his due. In the records are such words as 
?stregoica??witch, ?ordog,? and ?pokol??Satan and hell; and in one 
manuscript this very Dracula is spoken of as ?wampyr,? which we all 
understand too well. There have been from the loins of this very one 
great men and good women, and their graves make sacred the earth where 
alone this foulness can dwell. For it is not the least of its terrors 
that this evil thing is rooted deep in all good; in soil barren of holy 
memories it cannot rest.?'

[1] "I desired that I might pass my life on that barren rock, wearily, 
it is true, but uninterrupted by any sudden shock of misery. If I 
returned, it was to be sacrificed or to see those whom I most loved die 
under the grasp of a daemon whom I had myself created."

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

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

From sander.mak at luminis.eu  Mon Apr 24 10:06:37 2017
From: sander.mak at luminis.eu (Sander Mak)
Date: Mon, 24 Apr 2017 10:06:37 +0000
Subject: Optional.isEmpty()
In-Reply-To: <a12cce31-1900-eeb1-c868-81cc71d226f8@gmail.com>
References: <a12cce31-1900-eeb1-c868-81cc71d226f8@gmail.com>
Message-ID: <F825EC7C-49E5-41CA-A72B-4CB8DE4E4368@luminis.eu>


> On 22 Apr 2017, at 11:40, Peter Levart <peter.levart at gmail.com> wrote:
>    return cf.findModule(target).isEmpty();
> 
> What do you think? Would this pull its weight?

If I had a nickel for each time I started typing .isEm.., I'd have a respectable nickel collection. Big +1 from me.


Sander


From daniel.fuchs at oracle.com  Mon Apr 24 15:38:00 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 24 Apr 2017 16:38:00 +0100
Subject: [JDK 10] RFR: 8179222 SimpleConsoleLogger should protect against
 MissingResourceException
Message-ID: <05927fb0-6479-6cc8-5470-83b3975f32ab@oracle.com>

Hi,

Please find below a patch for:

8179222 SimpleConsoleLogger should protect against
         MissingResourceException
https://bugs.openjdk.java.net/browse/JDK-8179222

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8179222/webrev.00/

java.util.logging Formatters will traditionally catch 
MissingResourceException when invoking ResourceBundle::getString,
and use the original key string as message if a
MissingResourceException is thrown.

The SimpleConsoleLogger however does not have this logic and will
throw a MissingResourceException in that case.
For the sake of uniformity it would be better if SimpleConsoleLogger
behaved in the same way that java.util.logging does, even though
there's currently no code in the JDK (that I know of) which might
trigger this issue.

best regards,

-- daniel

From naoto.sato at oracle.com  Mon Apr 24 15:51:50 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 24 Apr 2017 08:51:50 -0700
Subject: [JDK 10] RFR: 8179222 SimpleConsoleLogger should protect against
 MissingResourceException
In-Reply-To: <05927fb0-6479-6cc8-5470-83b3975f32ab@oracle.com>
References: <05927fb0-6479-6cc8-5470-83b3975f32ab@oracle.com>
Message-ID: <bf7b4fbe-61f6-6d93-fa6c-314ae3ad267c@oracle.com>

Hi Daniel,

The change looks good to me. EmptyResourceBundle could just return null 
in handleGetObject(), and Collections.emptyEnumeration() in getKeys(), 
without having empty map field.

Naoto

On 4/24/17 8:38 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch for:
>
> 8179222 SimpleConsoleLogger should protect against
>         MissingResourceException
> https://bugs.openjdk.java.net/browse/JDK-8179222
>
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8179222/webrev.00/
>
> java.util.logging Formatters will traditionally catch
> MissingResourceException when invoking ResourceBundle::getString,
> and use the original key string as message if a
> MissingResourceException is thrown.
>
> The SimpleConsoleLogger however does not have this logic and will
> throw a MissingResourceException in that case.
> For the sake of uniformity it would be better if SimpleConsoleLogger
> behaved in the same way that java.util.logging does, even though
> there's currently no code in the JDK (that I know of) which might
> trigger this issue.
>
> best regards,
>
> -- daniel

From daniel.fuchs at oracle.com  Mon Apr 24 16:10:57 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 24 Apr 2017 17:10:57 +0100
Subject: [JDK 10] RFR: 8179222 SimpleConsoleLogger should protect against
 MissingResourceException
In-Reply-To: <bf7b4fbe-61f6-6d93-fa6c-314ae3ad267c@oracle.com>
References: <05927fb0-6479-6cc8-5470-83b3975f32ab@oracle.com>
 <bf7b4fbe-61f6-6d93-fa6c-314ae3ad267c@oracle.com>
Message-ID: <11414674-06bc-7af2-0476-1ddd7657e115@oracle.com>

On 24/04/2017 16:51, Naoto Sato wrote:
> Hi Daniel,
>
> The change looks good to me. EmptyResourceBundle could just return null
> in handleGetObject(), and Collections.emptyEnumeration() in getKeys(),
> without having empty map field.

Thanks Naoto.

Updated webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8179222/webrev.01/index.html

-- daniel

>
> Naoto
>
> On 4/24/17 8:38 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a patch for:
>>
>> 8179222 SimpleConsoleLogger should protect against
>>         MissingResourceException
>> https://bugs.openjdk.java.net/browse/JDK-8179222
>>
>> webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8179222/webrev.00/
>>
>> java.util.logging Formatters will traditionally catch
>> MissingResourceException when invoking ResourceBundle::getString,
>> and use the original key string as message if a
>> MissingResourceException is thrown.
>>
>> The SimpleConsoleLogger however does not have this logic and will
>> throw a MissingResourceException in that case.
>> For the sake of uniformity it would be better if SimpleConsoleLogger
>> behaved in the same way that java.util.logging does, even though
>> there's currently no code in the JDK (that I know of) which might
>> trigger this issue.
>>
>> best regards,
>>
>> -- daniel


From naoto.sato at oracle.com  Mon Apr 24 16:43:27 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 24 Apr 2017 09:43:27 -0700
Subject: [JDK 10] RFR: 8179222 SimpleConsoleLogger should protect against
 MissingResourceException
In-Reply-To: <11414674-06bc-7af2-0476-1ddd7657e115@oracle.com>
References: <05927fb0-6479-6cc8-5470-83b3975f32ab@oracle.com>
 <bf7b4fbe-61f6-6d93-fa6c-314ae3ad267c@oracle.com>
 <11414674-06bc-7af2-0476-1ddd7657e115@oracle.com>
Message-ID: <72e23ff7-6364-6994-6692-3ba32a6f403c@oracle.com>

+1

Naoto

On 4/24/17 9:10 AM, Daniel Fuchs wrote:
> On 24/04/2017 16:51, Naoto Sato wrote:
>> Hi Daniel,
>>
>> The change looks good to me. EmptyResourceBundle could just return null
>> in handleGetObject(), and Collections.emptyEnumeration() in getKeys(),
>> without having empty map field.
>
> Thanks Naoto.
>
> Updated webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8179222/webrev.01/index.html
>
> -- daniel
>
>>
>> Naoto
>>
>> On 4/24/17 8:38 AM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a patch for:
>>>
>>> 8179222 SimpleConsoleLogger should protect against
>>>         MissingResourceException
>>> https://bugs.openjdk.java.net/browse/JDK-8179222
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8179222/webrev.00/
>>>
>>> java.util.logging Formatters will traditionally catch
>>> MissingResourceException when invoking ResourceBundle::getString,
>>> and use the original key string as message if a
>>> MissingResourceException is thrown.
>>>
>>> The SimpleConsoleLogger however does not have this logic and will
>>> throw a MissingResourceException in that case.
>>> For the sake of uniformity it would be better if SimpleConsoleLogger
>>> behaved in the same way that java.util.logging does, even though
>>> there's currently no code in the JDK (that I know of) which might
>>> trigger this issue.
>>>
>>> best regards,
>>>
>>> -- daniel
>

From anthony.vanelverdinghe at gmail.com  Mon Apr 24 17:15:24 2017
From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe)
Date: Mon, 24 Apr 2017 19:15:24 +0200
Subject: Optional.isEmpty()
In-Reply-To: <a12cce31-1900-eeb1-c868-81cc71d226f8@gmail.com>
References: <a12cce31-1900-eeb1-c868-81cc71d226f8@gmail.com>
Message-ID: <2f8bcea9-d5bb-5d39-fa38-0a3cf4617b56@gmail.com>

Hi Peter

I'd say no: it's merely the negation of an existing method, and given 
that the bar for adding methods to Optional is set very high (see e.g. 
[1] and [2]), I don't see how this one would meet it.

Moreover, I don't see any issues with simply writing:

     return !cf.findModule(target).isPresent();

and there are plenty of one-liners that don't use boolean negation as 
well, for example:

     return cf.findModule(target).orElse(null) == null; // [3]
     return cf.findModule(target).map(m -> false).orElse(true); // [4]
     return cf.findModule(target).stream().count() == 0;
     return cf.findModule(target).stream().allMatch(m -> false);
     return cf.findModule(target).isPresent() ^ true;
     ...
     return cf.findModule(target).equals(Optional.empty());

Adding a static import to the last one gets you very close to the 
proposed method already:
     return cf.findModule(target).equals(empty());

Of course, another option is to introduce a variable to avoid the 
combination of boolean negation and method chaining:
     boolean moduleFound = cf.findModule(target).isPresent();
     return !moduleFound;

Kind regards, Anthony

[1] https://bugs.openjdk.java.net/browse/JDK-8057557
[2] https://bugs.openjdk.java.net/browse/JDK-8058707
[3] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012273.html
[4] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012290.html


On 22/04/2017 11:40, peter.levart at gmail.com (Peter Levart) wrote:
> Hi,
>
> Seeing the following line in some JDK test that was up for review:
>
>       return cf.findModule(target).orElse(null) == null;
>
> I immediately jumped to suggest it would look better if written as:
>
>       return !cf.findModule(target).isPresent();
>
>
> But then I leaned back and asked myself: "Would it really?"
>
> The boolean negation in front of a chain of method calls tends to
> visually disappear from the view when we finally reach the offending
> method and might get missed when quickly browsing the code. In this
> respect, ".orElse(null) == null" is actually better. But the best would
> of course be something like that:
>
>       return cf.findModule(target).isEmpty();
>
> What do you think? Would this pull its weight?
>
> Regards, Peter
>
>


From Roger.Riggs at Oracle.com  Mon Apr 24 18:10:40 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 24 Apr 2017 14:10:40 -0400
Subject: Optional.isEmpty()
In-Reply-To: <2f8bcea9-d5bb-5d39-fa38-0a3cf4617b56@gmail.com>
References: <a12cce31-1900-eeb1-c868-81cc71d226f8@gmail.com>
 <2f8bcea9-d5bb-5d39-fa38-0a3cf4617b56@gmail.com>
Message-ID: <7625db14-3d9b-a50d-f17c-2b149f0a87c8@Oracle.com>

Hi,

IMHO,boolean isEmpty() would be a good complement to the existing 
empty() method.

$.02, Roger


On 4/24/2017 1:15 PM, Anthony Vanelverdinghe wrote:
> Hi Peter
>
> I'd say no: it's merely the negation of an existing method, and given 
> that the bar for adding methods to Optional is set very high (see e.g. 
> [1] and [2]), I don't see how this one would meet it.
>
> Moreover, I don't see any issues with simply writing:
>
>     return !cf.findModule(target).isPresent();
>
> and there are plenty of one-liners that don't use boolean negation as 
> well, for example:
>
>     return cf.findModule(target).orElse(null) == null; // [3]
>     return cf.findModule(target).map(m -> false).orElse(true); // [4]
>     return cf.findModule(target).stream().count() == 0;
>     return cf.findModule(target).stream().allMatch(m -> false);
>     return cf.findModule(target).isPresent() ^ true;
>     ...
>     return cf.findModule(target).equals(Optional.empty());
>
> Adding a static import to the last one gets you very close to the 
> proposed method already:
>     return cf.findModule(target).equals(empty());
>
> Of course, another option is to introduce a variable to avoid the 
> combination of boolean negation and method chaining:
>     boolean moduleFound = cf.findModule(target).isPresent();
>     return !moduleFound;
>
> Kind regards, Anthony
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8057557
> [2] https://bugs.openjdk.java.net/browse/JDK-8058707
> [3] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012273.html
> [4] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012290.html
>
>
> On 22/04/2017 11:40, peter.levart at gmail.com (Peter Levart) wrote:
>> Hi,
>>
>> Seeing the following line in some JDK test that was up for review:
>>
>>       return cf.findModule(target).orElse(null) == null;
>>
>> I immediately jumped to suggest it would look better if written as:
>>
>>       return !cf.findModule(target).isPresent();
>>
>>
>> But then I leaned back and asked myself: "Would it really?"
>>
>> The boolean negation in front of a chain of method calls tends to
>> visually disappear from the view when we finally reach the offending
>> method and might get missed when quickly browsing the code. In this
>> respect, ".orElse(null) == null" is actually better. But the best would
>> of course be something like that:
>>
>>       return cf.findModule(target).isEmpty();
>>
>> What do you think? Would this pull its weight?
>>
>> Regards, Peter
>>
>>
>


From brian.burkhalter at oracle.com  Mon Apr 24 22:08:33 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 24 Apr 2017 15:08:33 -0700
Subject: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java: add
 some instrumentation which might illuminate the failure of 2016-09-14
Message-ID: <2BC04F53-AAAF-4ABB-BBE4-D77C3A7DCFDC@oracle.com>

This might not be enough or might be totally unnecessary but could prove useful.

https://bugs.openjdk.java.net/browse/JDK-8179247
http://cr.openjdk.java.net/~bpb/8179247/webrev.00/

Thanks,

Brian

From amy.lu at oracle.com  Tue Apr 25 03:22:11 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 25 Apr 2017 11:22:11 +0800
Subject: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java:
 add some instrumentation which might illuminate the failure of
 2016-09-14
In-Reply-To: <2BC04F53-AAAF-4ABB-BBE4-D77C3A7DCFDC@oracle.com>
References: <2BC04F53-AAAF-4ABB-BBE4-D77C3A7DCFDC@oracle.com>
Message-ID: <718b7219-0f66-0406-462d-780073575b98@oracle.com>

I noticed something else:

  148         Path zpath = Paths.get(System.getProperty("test.dir", "."),

  272         Path zpath = Paths.get(System.getProperty("test.dir", "."),

Is it better to use "user.dir" instead of "test.dir" here?

Thanks,Amy


On 4/25/17 6:08 AM, Brian Burkhalter wrote:
> This might not be enough or might be totally unnecessary but could prove useful.
>
> https://bugs.openjdk.java.net/browse/JDK-8179247
> http://cr.openjdk.java.net/~bpb/8179247/webrev.00/
>
> Thanks,
>
> Brian

From martinrb at google.com  Tue Apr 25 03:26:34 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 24 Apr 2017 20:26:34 -0700
Subject: Accessing module internals from bytecode rewriting agent
Message-ID: <CA+kOe09dgq+HERCtFFecG2Jguixg0j_FP-0duWOrZrdK15W6KQ@mail.gmail.com>

We've been playing with byteman.  If I have a simple rule that accesses a
private field,

RULE trace java.util.PriorityQueue_add
CLASS java.util.PriorityQueue
METHOD add
AT EXIT
IF true
DO traceln(java.util.Arrays.toString($0.queue))
ENDRULE

Then with jdk8 I get output like:

 [1, 2, 3]

but in jdk9 we fail with

java.lang.IllegalArgumentException: illegal lookupClass: class
java.util.PriorityQueue

Bytecode rewriting agents have the power to inject code into classes; they
should somehow also be able to reflectively inspect those same classes!
But how?  We ran into similar problems trying to port java agents at Google
to jdk9.

Details:
JAVA_TOOL_OPTIONS="-javaagent:${BYTEMAN_JAR}=script:${BYTEMAN_SCRIPT},boot:${BYTEMAN_JAR}"

     [java] java.lang.IllegalArgumentException: illegal lookupClass: class
java.util.PriorityQueue
     [java] at
java.base/java.lang.invoke.MethodHandleStatics.newIllegalArgumentException(MethodHandleStatics.java:123)
     [java] at
java.base/java.lang.invoke.MethodHandles$Lookup.checkUnprivilegedlookupClass(MethodHandles.java:1003)
     [java] at
java.base/java.lang.invoke.MethodHandles$Lookup.<init>(MethodHandles.java:750)
     [java] at
java.base/java.lang.invoke.MethodHandles.privateLookupIn(MethodHandles.java:205)
     [java] at
org.jboss.byteman.jigsaw/org.jboss.byteman.jigsaw.JigsawAccessEnabler.createFieldGetter(JigsawAccessEnabler.java)
     [java] at
org.jboss.byteman.rule.Rule.addAccessibleFieldGetter(Rule.java:1043)
     [java] at
org.jboss.byteman.rule.expression.FieldExpression.lookupField(FieldExpression.java:549)
     [java] at
org.jboss.byteman.rule.expression.FieldExpression.typeCheckAny(FieldExpression.java:201)
     [java] at
org.jboss.byteman.rule.expression.FieldExpression.typeCheck(FieldExpression.java:110)
     [java] at
org.jboss.byteman.rule.expression.MethodExpression.findMethod(MethodExpression.java:297)

From Alan.Bateman at oracle.com  Tue Apr 25 06:22:30 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 25 Apr 2017 07:22:30 +0100
Subject: Accessing module internals from bytecode rewriting agent
In-Reply-To: <CA+kOe09dgq+HERCtFFecG2Jguixg0j_FP-0duWOrZrdK15W6KQ@mail.gmail.com>
References: <CA+kOe09dgq+HERCtFFecG2Jguixg0j_FP-0duWOrZrdK15W6KQ@mail.gmail.com>
Message-ID: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com>

On 25/04/2017 04:26, Martin Buchholz wrote:

> :
>
> java.lang.IllegalArgumentException: illegal lookupClass: class
> java.util.PriorityQueue
>
> Bytecode rewriting agents have the power to inject code into classes; they
> should somehow also be able to reflectively inspect those same classes!
> But how?  We ran into similar problems trying to port java agents at Google
> to jdk9.
On the general point: agents (both java and JVM TI agents) can redefine 
any module in support of instrumentation and any amount of deep 
reflection that the agent might do. So I wouldn't expect too many issues 
although some java agents may need updates to work on JDK 9 without 
encapsulation busting command line options.

On Byteman, Andrew Dinn has been working with us on jigsaw-dev on the 
agent support. From the stack trace then I suspect the issue you are 
running into is that Byteman has also changed to use the new reflection 
API (java.lang.invoke) and is running into a long standing check to 
prevent full power lookups to full privileged classes from leaking. 
Andrew brought this up on jigsaw-dev [1] a few days ago and we could 
probably move that thread to core-libs-dev.

-Alan

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012267.html

From jeremymanson at google.com  Tue Apr 25 06:22:48 2017
From: jeremymanson at google.com (Jeremy Manson)
Date: Mon, 24 Apr 2017 23:22:48 -0700
Subject: Accessing module internals from bytecode rewriting agent
In-Reply-To: <CA+kOe09dgq+HERCtFFecG2Jguixg0j_FP-0duWOrZrdK15W6KQ@mail.gmail.com>
References: <CA+kOe09dgq+HERCtFFecG2Jguixg0j_FP-0duWOrZrdK15W6KQ@mail.gmail.com>
Message-ID: <CAPYFHW2s12cHiGvusXp1Yu74egOKVV8bZvWNGcp8iC=LA5Ve+Q@mail.gmail.com>

Just to underline this - the conversation with Martin about this came from
my trying to test my allocation instrumenter
<https://github.com/google/allocation-instrumenter> with JDK 9.

The instrument API specifically supports a Boot-Class-Path attribute in the
MANIFEST, as well as Instrumentation.appendToBootStrapClassLoaderSearch.  I
had been using that as a way to make it possible to rewrite JDK internals
(add allocation instrumentation to them).  I hadn't finished testing when
Martin sent this email, but I hadn't been able to get those things to work,
and what byteman does is pretty similar to what I was trying to test.

It sure would be nice if there were still a supported way to rewrite system
internals.  Bytecode rewriting is the recommended way to track allocations
<http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#bci>, and
it is very reasonable to want to do this kind of thing in the system
classes.

Jeremy

On Mon, Apr 24, 2017 at 8:26 PM, Martin Buchholz <martinrb at google.com>
wrote:

> We've been playing with byteman.  If I have a simple rule that accesses a
> private field,
>
> RULE trace java.util.PriorityQueue_add
> CLASS java.util.PriorityQueue
> METHOD add
> AT EXIT
> IF true
> DO traceln(java.util.Arrays.toString($0.queue))
> ENDRULE
>
> Then with jdk8 I get output like:
>
>  [1, 2, 3]
>
> but in jdk9 we fail with
>
> java.lang.IllegalArgumentException: illegal lookupClass: class
> java.util.PriorityQueue
>
> Bytecode rewriting agents have the power to inject code into classes; they
> should somehow also be able to reflectively inspect those same classes!
> But how?  We ran into similar problems trying to port java agents at Google
> to jdk9.
>
> Details:
> JAVA_TOOL_OPTIONS="-javaagent:${BYTEMAN_JAR}=script:${
> BYTEMAN_SCRIPT},boot:${BYTEMAN_JAR}"
>
>      [java] java.lang.IllegalArgumentException: illegal lookupClass:
> class java.util.PriorityQueue
>      [java] at java.base/java.lang.invoke.MethodHandleStatics.
> newIllegalArgumentException(MethodHandleStatics.java:123)
>      [java] at java.base/java.lang.invoke.MethodHandles$Lookup.
> checkUnprivilegedlookupClass(MethodHandles.java:1003)
>      [java] at java.base/java.lang.invoke.MethodHandles$Lookup.<init>(
> MethodHandles.java:750)
>      [java] at java.base/java.lang.invoke.MethodHandles.privateLookupIn(
> MethodHandles.java:205)
>      [java] at org.jboss.byteman.jigsaw/org.jboss.byteman.jigsaw.
> JigsawAccessEnabler.createFieldGetter(JigsawAccessEnabler.java)
>      [java] at org.jboss.byteman.rule.Rule.addAccessibleFieldGetter(Rule.
> java:1043)
>      [java] at org.jboss.byteman.rule.expression.FieldExpression.
> lookupField(FieldExpression.java:549)
>      [java] at org.jboss.byteman.rule.expression.FieldExpression.
> typeCheckAny(FieldExpression.java:201)
>      [java] at org.jboss.byteman.rule.expression.FieldExpression.
> typeCheck(FieldExpression.java:110)
>      [java] at org.jboss.byteman.rule.expression.MethodExpression.
> findMethod(MethodExpression.java:297)
>
>

From jeremymanson at google.com  Tue Apr 25 06:29:08 2017
From: jeremymanson at google.com (Jeremy Manson)
Date: Mon, 24 Apr 2017 23:29:08 -0700
Subject: Accessing module internals from bytecode rewriting agent
In-Reply-To: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com>
References: <CA+kOe09dgq+HERCtFFecG2Jguixg0j_FP-0duWOrZrdK15W6KQ@mail.gmail.com>
 <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com>
Message-ID: <CAPYFHW2jRNJpzC--Y1JwWT7nuJv_u3tStnRWjYnDqcTK-6qh6A@mail.gmail.com>

Ah, then it sounds as if I just don't know what I'm doing.  Any pointers?

Jeremy

On Mon, Apr 24, 2017 at 11:22 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 25/04/2017 04:26, Martin Buchholz wrote:
>
> :
>>
>> java.lang.IllegalArgumentException: illegal lookupClass: class
>> java.util.PriorityQueue
>>
>> Bytecode rewriting agents have the power to inject code into classes; they
>> should somehow also be able to reflectively inspect those same classes!
>> But how?  We ran into similar problems trying to port java agents at
>> Google
>> to jdk9.
>>
> On the general point: agents (both java and JVM TI agents) can redefine
> any module in support of instrumentation and any amount of deep reflection
> that the agent might do. So I wouldn't expect too many issues although some
> java agents may need updates to work on JDK 9 without encapsulation busting
> command line options.
>
> On Byteman, Andrew Dinn has been working with us on jigsaw-dev on the
> agent support. From the stack trace then I suspect the issue you are
> running into is that Byteman has also changed to use the new reflection API
> (java.lang.invoke) and is running into a long standing check to prevent
> full power lookups to full privileged classes from leaking. Andrew brought
> this up on jigsaw-dev [1] a few days ago and we could probably move that
> thread to core-libs-dev.
>
> -Alan
>
> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April
> /012267.html
>

From Alan.Bateman at oracle.com  Tue Apr 25 06:35:50 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 25 Apr 2017 07:35:50 +0100
Subject: Accessing module internals from bytecode rewriting agent
In-Reply-To: <CAPYFHW2s12cHiGvusXp1Yu74egOKVV8bZvWNGcp8iC=LA5Ve+Q@mail.gmail.com>
References: <CA+kOe09dgq+HERCtFFecG2Jguixg0j_FP-0duWOrZrdK15W6KQ@mail.gmail.com>
 <CAPYFHW2s12cHiGvusXp1Yu74egOKVV8bZvWNGcp8iC=LA5Ve+Q@mail.gmail.com>
Message-ID: <fcdba462-d62f-0653-aff6-4e81291d378c@oracle.com>

On 25/04/2017 07:22, Jeremy Manson wrote:

> :
>
> The instrument API specifically supports a Boot-Class-Path attribute in the
> MANIFEST, as well as Instrumentation.appendToBootStrapClassLoaderSearch.  I
> had been using that as a way to make it possible to rewrite JDK internals
> (add allocation instrumentation to them).
I wouldn't expect any issues with that scenario as the VM adds the 
readability needed for this to work. From the javadoc:

"As an aid to agents that deploy supporting classes on the search path 
of the bootstrap class loader, or the search path of the class loader 
that loads the main agent class, the Java virtual machine arranges for 
the module of transformed classes to read the unnamed module of both 
class loaders."

Instead, I think the issue in Martin's mail is more to do with Byteman 
moving to java.lang.invoke and running into an issue getting full power 
lookups to fully privileged classes.

-Alan.

From jeremymanson at google.com  Tue Apr 25 06:40:49 2017
From: jeremymanson at google.com (Jeremy Manson)
Date: Mon, 24 Apr 2017 23:40:49 -0700
Subject: Accessing module internals from bytecode rewriting agent
In-Reply-To: <fcdba462-d62f-0653-aff6-4e81291d378c@oracle.com>
References: <CA+kOe09dgq+HERCtFFecG2Jguixg0j_FP-0duWOrZrdK15W6KQ@mail.gmail.com>
 <CAPYFHW2s12cHiGvusXp1Yu74egOKVV8bZvWNGcp8iC=LA5Ve+Q@mail.gmail.com>
 <fcdba462-d62f-0653-aff6-4e81291d378c@oracle.com>
Message-ID: <CAPYFHW0vSVOqtE7-3WA_rY-Li6aw4CGUB9ryhMSrEFsJ02qNMA@mail.gmail.com>

Thanks, Alan.  I don't use byteman, and my agent wasn't working out of the
box to redefine JDK classes...  I guess I can keep digging.

Jeremy

On Mon, Apr 24, 2017 at 11:35 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 25/04/2017 07:22, Jeremy Manson wrote:
>
> :
>>
>> The instrument API specifically supports a Boot-Class-Path attribute in
>> the
>> MANIFEST, as well as Instrumentation.appendToBootStrapClassLoaderSearch.
>> I
>> had been using that as a way to make it possible to rewrite JDK internals
>> (add allocation instrumentation to them).
>>
> I wouldn't expect any issues with that scenario as the VM adds the
> readability needed for this to work. From the javadoc:
>
> "As an aid to agents that deploy supporting classes on the search path of
> the bootstrap class loader, or the search path of the class loader that
> loads the main agent class, the Java virtual machine arranges for the
> module of transformed classes to read the unnamed module of both class
> loaders."
>
> Instead, I think the issue in Martin's mail is more to do with Byteman
> moving to java.lang.invoke and running into an issue getting full power
> lookups to fully privileged classes.
>
> -Alan.
>

From Alan.Bateman at oracle.com  Tue Apr 25 06:50:38 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 25 Apr 2017 07:50:38 +0100
Subject: Accessing module internals from bytecode rewriting agent
In-Reply-To: <CAPYFHW2jRNJpzC--Y1JwWT7nuJv_u3tStnRWjYnDqcTK-6qh6A@mail.gmail.com>
References: <CA+kOe09dgq+HERCtFFecG2Jguixg0j_FP-0duWOrZrdK15W6KQ@mail.gmail.com>
 <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com>
 <CAPYFHW2jRNJpzC--Y1JwWT7nuJv_u3tStnRWjYnDqcTK-6qh6A@mail.gmail.com>
Message-ID: <a013c001-f2a6-8f2b-4a1a-465188a8cb16@oracle.com>

On 25/04/2017 07:29, Jeremy Manson wrote:

> Ah, then it sounds as if I just don't know what I'm doing.  Any pointers?
>
This should help:

http://download.java.net/java/jdk9/docs/api/java/lang/instrument/Instrumentation.html#redefineModule-java.lang.Module-java.util.Set-java.util.Map-java.util.Map-java.util.Set-java.util.Map-

-Alan

From jeremymanson at google.com  Tue Apr 25 07:14:05 2017
From: jeremymanson at google.com (Jeremy Manson)
Date: Tue, 25 Apr 2017 00:14:05 -0700
Subject: Accessing module internals from bytecode rewriting agent
In-Reply-To: <a013c001-f2a6-8f2b-4a1a-465188a8cb16@oracle.com>
References: <CA+kOe09dgq+HERCtFFecG2Jguixg0j_FP-0duWOrZrdK15W6KQ@mail.gmail.com>
 <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com>
 <CAPYFHW2jRNJpzC--Y1JwWT7nuJv_u3tStnRWjYnDqcTK-6qh6A@mail.gmail.com>
 <a013c001-f2a6-8f2b-4a1a-465188a8cb16@oracle.com>
Message-ID: <CAPYFHW2+pHxNbWTk+OPCT5WRTcAMUVTb9hRCycAUf8OdExv3wg@mail.gmail.com>

Thanks.

It wouldn't have occurred to me that I needed to use a Java 9 API.  I can't
remember ever having an upgrade path for anything in any Java version for
which I couldn't use the same code in Java N and Java N+1, if the use case
was a supported part of the spec in both.

The usual migration path we have is to make all of our code work in both
JDK N and JDK N+1, and then flip the switch to migrate to N+1.  I expect we
are not alone in that.

I guess I can call it reflectively.

This is pretty nice, otherwise, because we have lots of reflective hacks
into the JDK in our codebase, and it gives us a way to do the ones we can't
do with Unsafe. :)

Jeremy

On Mon, Apr 24, 2017 at 11:50 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 25/04/2017 07:29, Jeremy Manson wrote:
>
> Ah, then it sounds as if I just don't know what I'm doing.  Any pointers?
>>
>> This should help:
>
> http://download.java.net/java/jdk9/docs/api/java/lang/instru
> ment/Instrumentation.html#redefineModule-java.lang.Modul
> e-java.util.Set-java.util.Map-java.util.Map-java.util.Set-java.util.Map-
>
> -Alan
>

From adinn at redhat.com  Tue Apr 25 08:19:39 2017
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 25 Apr 2017 09:19:39 +0100
Subject: Accessing module internals from bytecode rewriting agent
In-Reply-To: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com>
References: <CA+kOe09dgq+HERCtFFecG2Jguixg0j_FP-0duWOrZrdK15W6KQ@mail.gmail.com>
 <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com>
Message-ID: <cd84f05f-42d6-a2b6-166d-8638f9e2f0bc@redhat.com>

On 25/04/17 07:22, Alan Bateman wrote:
> On 25/04/2017 04:26, Martin Buchholz wrote:
> 
>> :
>>
>> java.lang.IllegalArgumentException: illegal lookupClass: class
>> java.util.PriorityQueue
>>
>> Bytecode rewriting agents have the power to inject code into classes;
>> they
>> should somehow also be able to reflectively inspect those same classes!
>> But how?  We ran into similar problems trying to port java agents at
>> Google
>> to jdk9.
> <snip>
> On Byteman, Andrew Dinn has been working with us on jigsaw-dev on the
> agent support. From the stack trace then I suspect the issue you are
> running into is that Byteman has also changed to use the new reflection
> API (java.lang.invoke) and is running into a long standing check to
> prevent full power lookups to full privileged classes from leaking.
> Andrew brought this up on jigsaw-dev [1] a few days ago and we could
> probably move that thread to core-libs-dev.

This discussion really ought to be happening on the Byteman forum but
anyway ...

Yes, Alan is right that this is exactly what is going on. Byteman on
jdk9 (the 4.0.0-BETA release series) now uses method handles in place of
reflection. Unfortunately, it is limited by a slightly arbitrary
restriction on the use of method handles in java.* and sun.* packages (a
blunt instrument to provide some security guarantees).

This is being addressed on two fronts. I am in the process of adding
unit tests to complete a workaround which remedies this problem by
falling back to reflection in the specific cases where the restriction
applies (yes, that means there is probably going to be another
4.0.0-BETA release before jdk9 goes live %-/ ).

Meanwhile, Mandy Chung has kindly offered to look into the security
considerations that are at play and come up with a less restrictive
policy which enforces the security needs more accurately. At that point
I will probably remove the fallback -- in part because I hope that by
then both reflection and method handles will employ a common blacklist
of inaccessible methods. I think it would make sense for them both to
offer equivalent access and for that access to take security seriously.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

From forax at univ-mlv.fr  Tue Apr 25 09:41:49 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 25 Apr 2017 11:41:49 +0200 (CEST)
Subject: Accessing module internals from bytecode rewriting agent
In-Reply-To: <cd84f05f-42d6-a2b6-166d-8638f9e2f0bc@redhat.com>
References: <CA+kOe09dgq+HERCtFFecG2Jguixg0j_FP-0duWOrZrdK15W6KQ@mail.gmail.com>
 <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com>
 <cd84f05f-42d6-a2b6-166d-8638f9e2f0bc@redhat.com>
Message-ID: <1802453874.996397.1493113309752.JavaMail.zimbra@u-pem.fr>

[...]

> 
> Meanwhile, Mandy Chung has kindly offered to look into the security
> considerations that are at play and come up with a less restrictive
> policy which enforces the security needs more accurately. At that point
> I will probably remove the fallback -- in part because I hope that by
> then both reflection and method handles will employ a common blacklist
> of inaccessible methods. I think it would make sense for them both to
> offer equivalent access and for that access to take security seriously.

I've seen this kind of fallback in different language runtimes, mine included,
having a "less blunt" checks would be great.

> 
> regards,
> 
> 
> Andrew Dinn

R?mi

From chris.hegarty at oracle.com  Tue Apr 25 15:11:23 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 25 Apr 2017 16:11:23 +0100
Subject: RFR: 8178298 (LdapLoginModule)Migrate the JNDI properties
 technote to javadoc doc-files
In-Reply-To: <2d811080-fc39-c852-36d1-3f2b5cac7091@oracle.com>
References: <2d811080-fc39-c852-36d1-3f2b5cac7091@oracle.com>
Message-ID: <BA0F1B99-87A3-4CD9-BE83-5C61EE0C5AF0@oracle.com>

Vyom,

> On 24 Apr 2017, at 10:15, Vyom Tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi All,
> 
> Please review the simple doc fix.
> 
> Webrev   : http://cr.openjdk.java.net/~vtewari/8178298/webrev0.0/index.html
> 
> Bugid      : https://bugs.openjdk.java.net/browse/JDK-8178298
> 
> Note, this patch depends on "JDK-8178725".

This is confusing. The bug synopsis and description indicate that the guide,
jndi-ldap-gl.html, will be moved into the jdk repository as a doc-file, similar
to what happened in 8178101 [1], but your webrev clearly does not implement
this. It instead proposes to use the new extLink, as you have eluded to in the
email. If the latter, then the changes are ok, just update the bug details to 
match what is being done.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8178101
 

From brian.burkhalter at oracle.com  Tue Apr 25 16:06:33 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 25 Apr 2017 09:06:33 -0700
Subject: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java:
 add some instrumentation which might illuminate the failure of 2016-09-14
In-Reply-To: <718b7219-0f66-0406-462d-780073575b98@oracle.com>
References: <2BC04F53-AAAF-4ABB-BBE4-D77C3A7DCFDC@oracle.com>
 <718b7219-0f66-0406-462d-780073575b98@oracle.com>
Message-ID: <4E06C9B7-9493-4F74-8630-9F9884584313@oracle.com>

Hi Amy,

I think test.dir is preferred in case the folder location is specified to the harness.

Brian

On Apr 24, 2017, at 8:22 PM, Amy Lu <amy.lu at oracle.com> wrote:

> I noticed something else:
>  148         Path zpath = Paths.get(System.getProperty("test.dir", "."),
> 
>  272         Path zpath = Paths.get(System.getProperty("test.dir", "."),
> 
> Is it better to use "user.dir" instead of "test.dir" here?
> 
> Thanks,
> Amy
> 
> On 4/25/17 6:08 AM, Brian Burkhalter wrote:
>> This might not be enough or might be totally unnecessary but could prove useful.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8179247
>> http://cr.openjdk.java.net/~bpb/8179247/webrev.00/
>> 
>> Thanks,
>> 
>> Brian


From vyom.tewari at oracle.com  Tue Apr 25 16:07:07 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Tue, 25 Apr 2017 21:37:07 +0530
Subject: RFR: 8178298 (LdapLoginModule)Migrate the JNDI properties
 technote to javadoc doc-files
In-Reply-To: <BA0F1B99-87A3-4CD9-BE83-5C61EE0C5AF0@oracle.com>
References: <2d811080-fc39-c852-36d1-3f2b5cac7091@oracle.com>
 <BA0F1B99-87A3-4CD9-BE83-5C61EE0C5AF0@oracle.com>
Message-ID: <c3c52e09-8e32-8b17-bea7-8521632d70f6@oracle.com>



On Tuesday 25 April 2017 08:41 PM, Chris Hegarty wrote:
> Vyom,
>
>> On 24 Apr 2017, at 10:15, Vyom Tewari <vyom.tewari at oracle.com> wrote:
>>
>> Hi All,
>>
>> Please review the simple doc fix.
>>
>> Webrev   : http://cr.openjdk.java.net/~vtewari/8178298/webrev0.0/index.html
>>
>> Bugid      : https://bugs.openjdk.java.net/browse/JDK-8178298
>>
>> Note, this patch depends on "JDK-8178725".
> This is confusing. The bug synopsis and description indicate that the guide,
> jndi-ldap-gl.html, will be moved into the jdk repository as a doc-file, similar
> to what happened in 8178101 [1], but your webrev clearly does not implement
> this. It instead proposes to use the new extLink, as you have eluded to in the
> email. If the latter, then the changes are ok, just update the bug details to
> match what is being done.
Hi Chris thanks for review, when i created the issue, i did not knew the 
approach how i am going to fix it.I will update the bug detail.
thanks,
Vyom
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8178101
>   


From amy.lu at oracle.com  Wed Apr 26 01:32:27 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 26 Apr 2017 09:32:27 +0800
Subject: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java:
 add some instrumentation which might illuminate the failure of
 2016-09-14
In-Reply-To: <4E06C9B7-9493-4F74-8630-9F9884584313@oracle.com>
References: <2BC04F53-AAAF-4ABB-BBE4-D77C3A7DCFDC@oracle.com>
 <718b7219-0f66-0406-462d-780073575b98@oracle.com>
 <4E06C9B7-9493-4F74-8630-9F9884584313@oracle.com>
Message-ID: <3fe07c83-01e6-f166-2a26-345980e29c06@oracle.com>

On 4/26/17 12:06 AM, Brian Burkhalter wrote:
> Hi Amy,
>
> I think test.dir is preferred in case the folder location is specified 
> to the harness.

Yes, makes sense.

(I'm not a reviewer.)
Thanks,
Amy
>
> Brian
>
> On Apr 24, 2017, at 8:22 PM, Amy Lu <amy.lu at oracle.com 
> <mailto:amy.lu at oracle.com>> wrote:
>
>> I noticed something else:
>>   148         Path zpath = Paths.get(System.getProperty("test.dir", "."),
>>
>>   272         Path zpath = Paths.get(System.getProperty("test.dir", "."),
>>
>> Is it better to use "user.dir" instead of "test.dir" here?
>>
>> Thanks,Amy
>>
>> On 4/25/17 6:08 AM, Brian Burkhalter wrote:
>>> This might not be enough or might be totally unnecessary but could prove useful.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8179247
>>> http://cr.openjdk.java.net/~bpb/8179247/webrev.00/
>>>
>>> Thanks,
>>>
>>> Brian
>


From brian.burkhalter at oracle.com  Wed Apr 26 05:49:14 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 25 Apr 2017 22:49:14 -0700
Subject: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java:
 add some instrumentation which might illuminate the failure of 2016-09-14
In-Reply-To: <3fe07c83-01e6-f166-2a26-345980e29c06@oracle.com>
References: <2BC04F53-AAAF-4ABB-BBE4-D77C3A7DCFDC@oracle.com>
 <718b7219-0f66-0406-462d-780073575b98@oracle.com>
 <4E06C9B7-9493-4F74-8630-9F9884584313@oracle.com>
 <3fe07c83-01e6-f166-2a26-345980e29c06@oracle.com>
Message-ID: <C04D9DFC-6678-43BA-854B-02D2BE9D47D8@oracle.com>

Hi Amy,

The status of test.dir is a little vague to some of us right now. Your comments are appreciated.

Brian

On Apr 25, 2017, at 6:32 PM, Amy Lu <amy.lu at oracle.com> wrote:

> On 4/26/17 12:06 AM, Brian Burkhalter wrote:
>> Hi Amy,
>> 
>> I think test.dir is preferred in case the folder location is specified to the harness.
> 
> Yes, makes sense.
> 
> (I'm not a reviewer.)
> Thanks,
> Amy
>> 
>> 
>> Brian
>> 
>> On Apr 24, 2017, at 8:22 PM, Amy Lu <amy.lu at oracle.com> wrote:
>> 
>>> I noticed something else:
>>>  148         Path zpath = Paths.get(System.getProperty("test.dir", "."),
>>> 
>>>  272         Path zpath = Paths.get(System.getProperty("test.dir", "."),
>>> 
>>> Is it better to use "user.dir" instead of "test.dir" here?
>>> 
>>> Thanks,
>>> Amy
>>> 
>>> On 4/25/17 6:08 AM, Brian Burkhalter wrote:
>>>> This might not be enough or might be totally unnecessary but could prove useful.
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8179247
>>>> http://cr.openjdk.java.net/~bpb/8179247/webrev.00/
>>>> 
>>>> Thanks,
>>>> 
>>>> Brian
>> 
> 


From daniel.fuchs at oracle.com  Wed Apr 26 09:51:57 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 26 Apr 2017 10:51:57 +0100
Subject: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java:
 add some instrumentation which might illuminate the failure of
 2016-09-14
In-Reply-To: <C04D9DFC-6678-43BA-854B-02D2BE9D47D8@oracle.com>
References: <2BC04F53-AAAF-4ABB-BBE4-D77C3A7DCFDC@oracle.com>
 <718b7219-0f66-0406-462d-780073575b98@oracle.com>
 <4E06C9B7-9493-4F74-8630-9F9884584313@oracle.com>
 <3fe07c83-01e6-f166-2a26-345980e29c06@oracle.com>
 <C04D9DFC-6678-43BA-854B-02D2BE9D47D8@oracle.com>
Message-ID: <50da4082-138c-6b5d-6304-7c5d6ae2740f@oracle.com>

Hi,

Looking at the test - is it possible that "test.dir" is used here
simply to make it easier to run the test outside of jtreg - e.g. from
within an IDE like e.g. NetBeans? Then if so "test.dir" has probably
nothing to do with jtreg...

If you run a test (I mean its main() method) from within NetBeans, then
by default user.dir is set by NetBeans to the project's root directory.
That's usually not where you want to put your temporary test files.
So maybe the intent was to make it possible to specify something like
-Dtest.dir=build/scratch to the run environment when running the
test in standalone from within an IDE;

For practical purposes I suspect that using
System.getProperty("user.dir", ".") or directly using "." have the same
effect when running with jtreg.

So:

dir = System.getProperty("test.dir", ".")
dir = System.getProperty("test.dir", System.getProperty("user.dir",
"."));
dir = ".";

are probably all equivalent when running the test in jtreg.

hope this helps,

-- daniel



On 26/04/2017 06:49, Brian Burkhalter wrote:
> Hi Amy,
>
> The status of test.dir is a little vague to some of us right now. Your comments are appreciated.
>
> Brian
>
> On Apr 25, 2017, at 6:32 PM, Amy Lu <amy.lu at oracle.com> wrote:
>
>> On 4/26/17 12:06 AM, Brian Burkhalter wrote:
>>> Hi Amy,
>>>
>>> I think test.dir is preferred in case the folder location is specified to the harness.
>>
>> Yes, makes sense.
>>
>> (I'm not a reviewer.)
>> Thanks,
>> Amy
>>>
>>>
>>> Brian
>>>
>>> On Apr 24, 2017, at 8:22 PM, Amy Lu <amy.lu at oracle.com> wrote:
>>>
>>>> I noticed something else:
>>>>  148         Path zpath = Paths.get(System.getProperty("test.dir", "."),
>>>>
>>>>  272         Path zpath = Paths.get(System.getProperty("test.dir", "."),
>>>>
>>>> Is it better to use "user.dir" instead of "test.dir" here?
>>>>
>>>> Thanks,
>>>> Amy
>>>>
>>>> On 4/25/17 6:08 AM, Brian Burkhalter wrote:
>>>>> This might not be enough or might be totally unnecessary but could prove useful.
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8179247
>>>>> http://cr.openjdk.java.net/~bpb/8179247/webrev.00/
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Brian
>>>
>>
>


From roger.riggs at oracle.com  Wed Apr 26 13:37:19 2017
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 26 Apr 2017 09:37:19 -0400
Subject: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java:
 add some instrumentation which might illuminate the failure of
 2016-09-14
In-Reply-To: <50da4082-138c-6b5d-6304-7c5d6ae2740f@oracle.com>
References: <2BC04F53-AAAF-4ABB-BBE4-D77C3A7DCFDC@oracle.com>
 <718b7219-0f66-0406-462d-780073575b98@oracle.com>
 <4E06C9B7-9493-4F74-8630-9F9884584313@oracle.com>
 <3fe07c83-01e6-f166-2a26-345980e29c06@oracle.com>
 <C04D9DFC-6678-43BA-854B-02D2BE9D47D8@oracle.com>
 <50da4082-138c-6b5d-6304-7c5d6ae2740f@oracle.com>
Message-ID: <a883fc8e-9324-abb5-26b7-2cbfd967f4d9@oracle.com>

Hi,

I would keep it simple and use the current form. It make it easy to run 
the tests standalone.
   dir = System.getProperty("test.dir", ".")

Adding in the additional "user.dir" variant just complicates the code 
and understanding without improving the use cases.   (by default 
user.dir is set to the absolute pathname of ".").

$.02, Roger



On 4/26/17 5:51 AM, Daniel Fuchs wrote:
> Hi,
>
> Looking at the test - is it possible that "test.dir" is used here
> simply to make it easier to run the test outside of jtreg - e.g. from
> within an IDE like e.g. NetBeans? Then if so "test.dir" has probably
> nothing to do with jtreg...
>
> If you run a test (I mean its main() method) from within NetBeans, then
> by default user.dir is set by NetBeans to the project's root directory.
> That's usually not where you want to put your temporary test files.
> So maybe the intent was to make it possible to specify something like
> -Dtest.dir=build/scratch to the run environment when running the
> test in standalone from within an IDE;
>
> For practical purposes I suspect that using
> System.getProperty("user.dir", ".") or directly using "." have the same
> effect when running with jtreg.
>
> So:
>
> dir = System.getProperty("test.dir", ".")
> dir = System.getProperty("test.dir", System.getProperty("user.dir",
> "."));
> dir = ".";
>
> are probably all equivalent when running the test in jtreg.
>
> hope this helps,
>
> -- daniel
>
>
>
> On 26/04/2017 06:49, Brian Burkhalter wrote:
>> Hi Amy,
>>
>> The status of test.dir is a little vague to some of us right now. 
>> Your comments are appreciated.
>>
>> Brian
>>
>> On Apr 25, 2017, at 6:32 PM, Amy Lu <amy.lu at oracle.com> wrote:
>>
>>> On 4/26/17 12:06 AM, Brian Burkhalter wrote:
>>>> Hi Amy,
>>>>
>>>> I think test.dir is preferred in case the folder location is 
>>>> specified to the harness.
>>>
>>> Yes, makes sense.
>>>
>>> (I'm not a reviewer.)
>>> Thanks,
>>> Amy
>>>>
>>>>
>>>> Brian
>>>>
>>>> On Apr 24, 2017, at 8:22 PM, Amy Lu <amy.lu at oracle.com> wrote:
>>>>
>>>>> I noticed something else:
>>>>>  148         Path zpath = Paths.get(System.getProperty("test.dir", 
>>>>> "."),
>>>>>
>>>>>  272         Path zpath = Paths.get(System.getProperty("test.dir", 
>>>>> "."),
>>>>>
>>>>> Is it better to use "user.dir" instead of "test.dir" here?
>>>>>
>>>>> Thanks,
>>>>> Amy
>>>>>
>>>>> On 4/25/17 6:08 AM, Brian Burkhalter wrote:
>>>>>> This might not be enough or might be totally unnecessary but 
>>>>>> could prove useful.
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8179247
>>>>>> http://cr.openjdk.java.net/~bpb/8179247/webrev.00/
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Brian
>>>>
>>>
>>
>


From brian.burkhalter at oracle.com  Wed Apr 26 15:15:31 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 26 Apr 2017 08:15:31 -0700
Subject: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java:
 add some instrumentation which might illuminate the failure of 2016-09-14
In-Reply-To: <a883fc8e-9324-abb5-26b7-2cbfd967f4d9@oracle.com>
References: <2BC04F53-AAAF-4ABB-BBE4-D77C3A7DCFDC@oracle.com>
 <718b7219-0f66-0406-462d-780073575b98@oracle.com>
 <4E06C9B7-9493-4F74-8630-9F9884584313@oracle.com>
 <3fe07c83-01e6-f166-2a26-345980e29c06@oracle.com>
 <C04D9DFC-6678-43BA-854B-02D2BE9D47D8@oracle.com>
 <50da4082-138c-6b5d-6304-7c5d6ae2740f@oracle.com>
 <a883fc8e-9324-abb5-26b7-2cbfd967f4d9@oracle.com>
Message-ID: <1178FA8C-2749-4C9C-B4EF-D9E3BB293F2B@oracle.com>

I was wondering whether test.dir is there to allow to direct to large disks if large files are involved. This is a general observation, not just for this test.

Brian

On Apr 26, 2017, at 6:37 AM, Roger Riggs <roger.riggs at oracle.com> wrote:

> I would keep it simple and use the current form. It make it easy to run the tests standalone.
>  dir = System.getProperty("test.dir", ".")
> 
> Adding in the additional "user.dir" variant just complicates the code and understanding without improving the use cases.   (by default user.dir is set to the absolute pathname of ".").


From ron.pressler at oracle.com  Wed Apr 26 16:50:16 2017
From: ron.pressler at oracle.com (Ron Pressler)
Date: Wed, 26 Apr 2017 19:50:16 +0300
Subject: JDK 9 RFR: JDK-8177146 MethodHandles.Lookup::bind allows illegal
 protected access
Message-ID: <5900CFC8.2010104@oracle.com>

Hi.
Please review,

Bug: https://bugs.openjdk.java.net/browse/JDK-8177146
Webrev: 
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8177146-bind-protected-method/webrev/

-----

The patch contains a few changes:

1. The method `getDirectMethodCommon`, was changed so that if narrowing 
due to protected method access must be done, it will be done regardless 
of the flag doRestrict.

2. The private method ` getDirectMethodNoRestrict` was renamed to ` 
getDirectMethodNoRestrictInvokeSpecial`.

3. The method `bind` was changed to throw the correct exception type, 
IAException.

4. `restrictReceiver` was changed such that it never widens the receiver 
type. This could happen when the receiver was a subclass of the caller 
class, and triggered the assertion (this happened not only in calls to 
`bind` but also to `findVirtual`).

-----

Thanks
Ron



From paul.sandoz at oracle.com  Wed Apr 26 17:00:24 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 26 Apr 2017 10:00:24 -0700
Subject: JDK 9 RFR: JDK-8177146 MethodHandles.Lookup::bind allows illegal
 protected access
In-Reply-To: <5900CFC8.2010104@oracle.com>
References: <5900CFC8.2010104@oracle.com>
Message-ID: <550448C2-3B7E-4670-885E-48625CCE6E19@oracle.com>


> On 26 Apr 2017, at 09:50, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> Hi.
> Please review,
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177146
> Webrev: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8177146-bind-protected-method/webrev/
> 

+1

Paul.

> -----
> 
> The patch contains a few changes:
> 
> 1. The method `getDirectMethodCommon`, was changed so that if narrowing due to protected method access must be done, it will be done regardless of the flag doRestrict.
> 
> 2. The private method ` getDirectMethodNoRestrict` was renamed to ` getDirectMethodNoRestrictInvokeSpecial`.
> 
> 3. The method `bind` was changed to throw the correct exception type, IAException.
> 
> 4. `restrictReceiver` was changed such that it never widens the receiver type. This could happen when the receiver was a subclass of the caller class, and triggered the assertion (this happened not only in calls to `bind` but also to `findVirtual`).
> 
> -----
> 
> Thanks
> Ron
> 
> 


From Roger.Riggs at Oracle.com  Wed Apr 26 17:43:53 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 26 Apr 2017 13:43:53 -0400
Subject: JDK 9 RFR: JDK-8177146 MethodHandles.Lookup::bind allows illegal
 protected access
In-Reply-To: <550448C2-3B7E-4670-885E-48625CCE6E19@oracle.com>
References: <5900CFC8.2010104@oracle.com>
 <550448C2-3B7E-4670-885E-48625CCE6E19@oracle.com>
Message-ID: <f97289dd-c302-fc42-f73a-54bcf1b5f52e@Oracle.com>

Hi,

Not to be really picky but the MethodHandles source file really stresses 
the coding conventions for long lines,
recommended line breaks, etc.  But not a comment on the proposed changes.

Roger


On 4/26/2017 1:00 PM, Paul Sandoz wrote:
>> On 26 Apr 2017, at 09:50, Ron Pressler <ron.pressler at oracle.com> wrote:
>>
>> Hi.
>> Please review,
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177146
>> Webrev: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8177146-bind-protected-method/webrev/
>>
> +1
>
> Paul.
>
>> -----
>>
>> The patch contains a few changes:
>>
>> 1. The method `getDirectMethodCommon`, was changed so that if narrowing due to protected method access must be done, it will be done regardless of the flag doRestrict.
>>
>> 2. The private method ` getDirectMethodNoRestrict` was renamed to ` getDirectMethodNoRestrictInvokeSpecial`.
>>
>> 3. The method `bind` was changed to throw the correct exception type, IAException.
>>
>> 4. `restrictReceiver` was changed such that it never widens the receiver type. This could happen when the receiver was a subclass of the caller class, and triggered the assertion (this happened not only in calls to `bind` but also to `findVirtual`).
>>
>> -----
>>
>> Thanks
>> Ron
>>
>>


From vladimir.x.ivanov at oracle.com  Wed Apr 26 17:53:24 2017
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 26 Apr 2017 20:53:24 +0300
Subject: JDK 9 RFR: JDK-8177146 MethodHandles.Lookup::bind allows illegal
 protected access
In-Reply-To: <5900CFC8.2010104@oracle.com>
References: <5900CFC8.2010104@oracle.com>
Message-ID: <8bd20999-8b9a-6dd0-5387-00ec75625781@oracle.com>

Ron,

The fix looks good.

One request: please, try to avoid bug ids in test names. It's much 
easier to work with tests when they have meaningful names and there's 
already @bug jtreg tag to refer to the fixed bug from the test.

Best regards,
Vladimir Ivanov

On 4/26/17 7:50 PM, Ron Pressler wrote:
> Hi.
> Please review,
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177146
> Webrev:
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8177146-bind-protected-method/webrev/
>
>
> -----
>
> The patch contains a few changes:
>
> 1. The method `getDirectMethodCommon`, was changed so that if narrowing
> due to protected method access must be done, it will be done regardless
> of the flag doRestrict.
>
> 2. The private method ` getDirectMethodNoRestrict` was renamed to `
> getDirectMethodNoRestrictInvokeSpecial`.
>
> 3. The method `bind` was changed to throw the correct exception type,
> IAException.
>
> 4. `restrictReceiver` was changed such that it never widens the receiver
> type. This could happen when the receiver was a subclass of the caller
> class, and triggered the assertion (this happened not only in calls to
> `bind` but also to `findVirtual`).
>
> -----
>
> Thanks
> Ron
>
>

From claes.redestad at oracle.com  Wed Apr 26 18:06:07 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 26 Apr 2017 20:06:07 +0200
Subject: JDK 9 RFR: JDK-8177146 MethodHandles.Lookup::bind allows illegal
 protected access
In-Reply-To: <5900CFC8.2010104@oracle.com>
References: <5900CFC8.2010104@oracle.com>
Message-ID: <0D255C4B-6F61-4A04-A3D0-C86A0FA51525@oracle.com>

Hi,

looks good to me!

Nit: I prefer descriptive test names, but can't find the creativity to suggest a better name in this case.

Thanks! 

/Claes

Ron Pressler <ron.pressler at oracle.com> skrev: (26 april 2017 18:50:16 CEST)
>Hi.
>Please review,
>
>Bug: https://bugs.openjdk.java.net/browse/JDK-8177146
>Webrev: 
>http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8177146-bind-protected-method/webrev/
>
>-----
>
>The patch contains a few changes:
>
>1. The method `getDirectMethodCommon`, was changed so that if narrowing
>
>due to protected method access must be done, it will be done regardless
>
>of the flag doRestrict.
>
>2. The private method ` getDirectMethodNoRestrict` was renamed to ` 
>getDirectMethodNoRestrictInvokeSpecial`.
>
>3. The method `bind` was changed to throw the correct exception type, 
>IAException.
>
>4. `restrictReceiver` was changed such that it never widens the
>receiver 
>type. This could happen when the receiver was a subclass of the caller 
>class, and triggered the assertion (this happened not only in calls to 
>`bind` but also to `findVirtual`).
>
>-----
>
>Thanks
>Ron

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From Roger.Riggs at Oracle.com  Wed Apr 26 18:14:06 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 26 Apr 2017 14:14:06 -0400
Subject: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java:
 add some instrumentation which might illuminate the failure of
 2016-09-14
In-Reply-To: <1178FA8C-2749-4C9C-B4EF-D9E3BB293F2B@oracle.com>
References: <2BC04F53-AAAF-4ABB-BBE4-D77C3A7DCFDC@oracle.com>
 <718b7219-0f66-0406-462d-780073575b98@oracle.com>
 <4E06C9B7-9493-4F74-8630-9F9884584313@oracle.com>
 <3fe07c83-01e6-f166-2a26-345980e29c06@oracle.com>
 <C04D9DFC-6678-43BA-854B-02D2BE9D47D8@oracle.com>
 <50da4082-138c-6b5d-6304-7c5d6ae2740f@oracle.com>
 <a883fc8e-9324-abb5-26b7-2cbfd967f4d9@oracle.com>
 <1178FA8C-2749-4C9C-B4EF-D9E3BB293F2B@oracle.com>
Message-ID: <6514a1fc-d3a4-ee3b-07fc-221699f23055@Oracle.com>

Hi,

The test.dir property seems like a convenience for the test developer.
It is not defined by jtreg in the tag specification as are the other 
properties [1].
It is not widely used in tests but could be understandable when manually 
testing to
avoid cluttering the working directory with test files.


On the original webrev:
In addition to checking if the directory exists would you want to list 
its contents?

And if checking the status of zpath, list its permission attributes?

Is there any chance that a previous delete of zpath has not completed, 
(since windows
has the delayed delete if the file is in use behavior).
I think can't think why that would be intermittent though.

$.02, Roger

[1] http://openjdk.java.net/jtreg/tag-spec.html#testvars

On 4/26/2017 11:15 AM, Brian Burkhalter wrote:
> I was wondering whether test.dir is there to allow to direct to large 
> disks if large files are involved. This is a general observation, not 
> just for this test.
>
> Brian
>
> On Apr 26, 2017, at 6:37 AM, Roger Riggs <roger.riggs at oracle.com 
> <mailto:roger.riggs at oracle.com>> wrote:
>
>> I would keep it simple and use the current form. It make it easy to 
>> run the tests standalone.
>>  dir = System.getProperty("test.dir", ".")
>>
>> Adding in the additional "user.dir" variant just complicates the code 
>> and understanding without improving the use cases.   (by default 
>> user.dir is set to the absolute pathname of ".").
>


From brian.burkhalter at oracle.com  Wed Apr 26 19:00:43 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 26 Apr 2017 12:00:43 -0700
Subject: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java:
 add some instrumentation which might illuminate the failure of 2016-09-14
In-Reply-To: <6514a1fc-d3a4-ee3b-07fc-221699f23055@Oracle.com>
References: <2BC04F53-AAAF-4ABB-BBE4-D77C3A7DCFDC@oracle.com>
 <718b7219-0f66-0406-462d-780073575b98@oracle.com>
 <4E06C9B7-9493-4F74-8630-9F9884584313@oracle.com>
 <3fe07c83-01e6-f166-2a26-345980e29c06@oracle.com>
 <C04D9DFC-6678-43BA-854B-02D2BE9D47D8@oracle.com>
 <50da4082-138c-6b5d-6304-7c5d6ae2740f@oracle.com>
 <a883fc8e-9324-abb5-26b7-2cbfd967f4d9@oracle.com>
 <1178FA8C-2749-4C9C-B4EF-D9E3BB293F2B@oracle.com>
 <6514a1fc-d3a4-ee3b-07fc-221699f23055@Oracle.com>
Message-ID: <1624B2E3-4736-4E41-AFDC-1768E50B7F2E@oracle.com>


On Apr 26, 2017, at 11:14 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> The test.dir property seems like a convenience for the test developer.
> It is not defined by jtreg in the tag specification as are the other properties [1].
> It is not widely used in tests but could be understandable when manually testing to
> avoid cluttering the working directory with test files.

Logical.

> On the original webrev:
> In addition to checking if the directory exists would you want to list its contents?

Good idea.

> And if checking the status of zpath, list its permission attributes?

I had thought of that as well but did not implement it. I can add that also.

> Is there any chance that a previous delete of zpath has not completed, (since windows
> has the delayed delete if the file is in use behavior).
> I think can't think why that would be intermittent though.

Thanks,

Brian

From jonathan.gibbons at oracle.com  Wed Apr 26 20:30:28 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 26 Apr 2017 13:30:28 -0700
Subject: RFR: 8179364: update "<a name=" in java.base module to use id
 attribute
Message-ID: <59010364.3000508@oracle.com>

Please review the following conceptually simple fix to change
     <a name=
to
     <a id=

in the public doc comments for the contents of java.base module.

This is for compatibility with HTML 5.

The change was done mechanically with the following two commands:

$ sed -i -e 's/<a name=/<a id=/g' $files
$ sed -i -e 's/<A NAME=/<a id=/' $files

where $files was derived from the set of files reported by "javadoc 
-html5" as containing  the use of the name attribute.

The covers files in the following packages:

java.base java/io
java.base java/lang
java.base java/lang/invoke
java.base java/lang/ref
java.base java/lang/reflect
java.base java/net
java.base java/nio
java.base java/nio/channels
java.base java/nio/charset
java.base java/nio/file
java.base java/text
java.base java/util
java.base java/util/jar
java.base java/util/regex
java.base java/util/spi
java.base java/util/stream


Notes:
1. There may be instances of the name attribute remaining in other 
comments that have not been updated.
2. There are many instances where the id attribute could be moved into 
an immediate neighbor. For simplicity, that has not been done at this 
time. It would be a worthy update when we have fully committed to 
delivering HTML 5 docs, and have the resources to do a more hands-on update.


JBS: https://bugs.openjdk.java.net/browse/JDK-8179364
Webrev: http://cr.openjdk.java.net/~jjg/8179364/webrev.00/

-- Jon

From joe.darcy at oracle.com  Wed Apr 26 20:34:55 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 26 Apr 2017 13:34:55 -0700
Subject: RFR: 8179364: update "<a name=" in java.base module to use id
 attribute
In-Reply-To: <59010364.3000508@oracle.com>
References: <59010364.3000508@oracle.com>
Message-ID: <53f9710c-fec6-87a3-d6f9-4799730d44cc@oracle.com>

Looks fine Jon; thanks,

-Joe


On 4/26/2017 1:30 PM, Jonathan Gibbons wrote:
> Please review the following conceptually simple fix to change
>     <a name=
> to
>     <a id=
>
> in the public doc comments for the contents of java.base module.
>
> This is for compatibility with HTML 5.
>
> The change was done mechanically with the following two commands:
>
> $ sed -i -e 's/<a name=/<a id=/g' $files
> $ sed -i -e 's/<A NAME=/<a id=/' $files
>
> where $files was derived from the set of files reported by "javadoc 
> -html5" as containing  the use of the name attribute.
>
> The covers files in the following packages:
>
> java.base java/io
> java.base java/lang
> java.base java/lang/invoke
> java.base java/lang/ref
> java.base java/lang/reflect
> java.base java/net
> java.base java/nio
> java.base java/nio/channels
> java.base java/nio/charset
> java.base java/nio/file
> java.base java/text
> java.base java/util
> java.base java/util/jar
> java.base java/util/regex
> java.base java/util/spi
> java.base java/util/stream
>
>
> Notes:
> 1. There may be instances of the name attribute remaining in other 
> comments that have not been updated.
> 2. There are many instances where the id attribute could be moved into 
> an immediate neighbor. For simplicity, that has not been done at this 
> time. It would be a worthy update when we have fully committed to 
> delivering HTML 5 docs, and have the resources to do a more hands-on 
> update.
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179364
> Webrev: http://cr.openjdk.java.net/~jjg/8179364/webrev.00/
>
> -- Jon


From brian.burkhalter at oracle.com  Wed Apr 26 20:57:54 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 26 Apr 2017 13:57:54 -0700
Subject: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java:
 add some instrumentation which might illuminate the failure of 2016-09-14
In-Reply-To: <1624B2E3-4736-4E41-AFDC-1768E50B7F2E@oracle.com>
References: <2BC04F53-AAAF-4ABB-BBE4-D77C3A7DCFDC@oracle.com>
 <718b7219-0f66-0406-462d-780073575b98@oracle.com>
 <4E06C9B7-9493-4F74-8630-9F9884584313@oracle.com>
 <3fe07c83-01e6-f166-2a26-345980e29c06@oracle.com>
 <C04D9DFC-6678-43BA-854B-02D2BE9D47D8@oracle.com>
 <50da4082-138c-6b5d-6304-7c5d6ae2740f@oracle.com>
 <a883fc8e-9324-abb5-26b7-2cbfd967f4d9@oracle.com>
 <1178FA8C-2749-4C9C-B4EF-D9E3BB293F2B@oracle.com>
 <6514a1fc-d3a4-ee3b-07fc-221699f23055@Oracle.com>
 <1624B2E3-4736-4E41-AFDC-1768E50B7F2E@oracle.com>
Message-ID: <6A69E517-EE83-4496-87B1-11B4C7F31E2C@oracle.com>

Hi Roger,

Here is an updated patch containing the suggested changes:

http://cr.openjdk.java.net/~bpb/8179247/webrev.01/

Thanks,

Brian

On Apr 26, 2017, at 12:00 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

>> On the original webrev:
>> In addition to checking if the directory exists would you want to list its contents?
> 
> Good idea.
> 
>> And if checking the status of zpath, list its permission attributes?
> 
> I had thought of that as well but did not implement it. I can add that also.
> 
>> Is there any chance that a previous delete of zpath has not completed, (since windows
>> has the delayed delete if the file is in use behavior).
>> I think can't think why that would be intermittent though.


From Roger.Riggs at Oracle.com  Wed Apr 26 20:59:23 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 26 Apr 2017 16:59:23 -0400
Subject: JDK 9 test-only RFR of 8179247: java/util/zip/TestExtraTime.java:
 add some instrumentation which might illuminate the failure of
 2016-09-14
In-Reply-To: <6A69E517-EE83-4496-87B1-11B4C7F31E2C@oracle.com>
References: <2BC04F53-AAAF-4ABB-BBE4-D77C3A7DCFDC@oracle.com>
 <718b7219-0f66-0406-462d-780073575b98@oracle.com>
 <4E06C9B7-9493-4F74-8630-9F9884584313@oracle.com>
 <3fe07c83-01e6-f166-2a26-345980e29c06@oracle.com>
 <C04D9DFC-6678-43BA-854B-02D2BE9D47D8@oracle.com>
 <50da4082-138c-6b5d-6304-7c5d6ae2740f@oracle.com>
 <a883fc8e-9324-abb5-26b7-2cbfd967f4d9@oracle.com>
 <1178FA8C-2749-4C9C-B4EF-D9E3BB293F2B@oracle.com>
 <6514a1fc-d3a4-ee3b-07fc-221699f23055@Oracle.com>
 <1624B2E3-4736-4E41-AFDC-1768E50B7F2E@oracle.com>
 <6A69E517-EE83-4496-87B1-11B4C7F31E2C@oracle.com>
Message-ID: <332414a1-52ca-c1da-f9ce-2f8ea218a26c@Oracle.com>

Hi Brian,

Looks good

Thanks, Roger


On 4/26/2017 4:57 PM, Brian Burkhalter wrote:
> Hi Roger,
>
> Here is an updated patch containing the suggested changes:
>
> http://cr.openjdk.java.net/~bpb/8179247/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ebpb/8179247/webrev.01/>
>
> Thanks,
>
> Brian
>
> On Apr 26, 2017, at 12:00 PM, Brian Burkhalter 
> <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>
>>> On the original webrev:
>>> In addition to checking if the directory exists would you want to 
>>> list its contents?
>>
>> Good idea.
>>
>>> And if checking the status of zpath, list its permission attributes?
>>
>> I had thought of that as well but did not implement it. I can add 
>> that also.
>>
>>> Is there any chance that a previous delete of zpath has not 
>>> completed, (since windows
>>> has the delayed delete if the file is in use behavior).
>>> I think can't think why that would be intermittent though.
>


From jonathan.gibbons at oracle.com  Wed Apr 26 22:31:27 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 26 Apr 2017 15:31:27 -0700
Subject: RFR: 8179367: update use of align, valign attributes in java.base
 to use style attribute
Message-ID: <59011FBF.2000007@oracle.com>

Please review the following conceptually simple fix to change use of the 
align and valign attributes in table-related tags to inline style 
attributes in the public doc comments for the contents of java.base module.

This is for compatibility with HTML 5.

The change was done mechanically with the following sed script, which 
was applied to the set of files reported by "javadoc -html5" as 
containing  the use of the align and valign attribute.

s/ align="*left"*/ style="text-align:left"/
s/ align="*center"*/ style="text-align:center"/
s/ ALIGN="*CENTER"*/ style="text-align:center"/
s/ align="*right"*/ style="text-align:right"/
s/ valign="*top"*/ style="vertical-align:top"/
s/ valign="*bottom"*/ style="vertical-align:bottom"/
s/ style="\([^"]*\)" style="\([^"]*\)"/ style="\1; \2"/

The first six lines change the variants of align and valign into the 
corresponding style attributes. And, because there were some instances 
where a tag had both align and valign, the final line of the script 
merges two instances of the style attribute into a single instance.

This covers files in the following packages:

java.base java/io
java.base java/lang
java.base java/lang/reflect
java.base java/math
java.base java/nio/charset
java.base java/text
java.base java/time/chrono
java.base java/time/format
java.base java/util
java.base java/util/concurrent
java.base java/util/regex

JBS: https://bugs.openjdk.java.net/browse/JDK-8179367
webrev: http://cr.openjdk.java.net/~jjg/8179367/webrev/

-- Jon

From martinrb at google.com  Wed Apr 26 22:40:03 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 26 Apr 2017 15:40:03 -0700
Subject: RFR: 8179367: update use of align, valign attributes in java.base
 to use style attribute
In-Reply-To: <59011FBF.2000007@oracle.com>
References: <59011FBF.2000007@oracle.com>
Message-ID: <CA+kOe09vP0daFo5-D8gpvtCcHugO5ux2kkLuhDUQyajm46qOjg@mail.gmail.com>

This looks good.

jsr166 maintainers will merge into jsr166 CVS.

I'm unsure whether the ";" should be used as separator or terminator.  I
would have terminated every style with a ";"

On Wed, Apr 26, 2017 at 3:31 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Please review the following conceptually simple fix to change use of the
> align and valign attributes in table-related tags to inline style
> attributes in the public doc comments for the contents of java.base module.
>
> This is for compatibility with HTML 5.
>
> The change was done mechanically with the following sed script, which was
> applied to the set of files reported by "javadoc -html5" as containing  the
> use of the align and valign attribute.
>
> s/ align="*left"*/ style="text-align:left"/
> s/ align="*center"*/ style="text-align:center"/
> s/ ALIGN="*CENTER"*/ style="text-align:center"/
> s/ align="*right"*/ style="text-align:right"/
> s/ valign="*top"*/ style="vertical-align:top"/
> s/ valign="*bottom"*/ style="vertical-align:bottom"/
> s/ style="\([^"]*\)" style="\([^"]*\)"/ style="\1; \2"/
>
> The first six lines change the variants of align and valign into the
> corresponding style attributes. And, because there were some instances
> where a tag had both align and valign, the final line of the script merges
> two instances of the style attribute into a single instance.
>
> This covers files in the following packages:
>
> java.base java/io
> java.base java/lang
> java.base java/lang/reflect
> java.base java/math
> java.base java/nio/charset
> java.base java/text
> java.base java/time/chrono
> java.base java/time/format
> java.base java/util
> java.base java/util/concurrent
> java.base java/util/regex
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179367
> webrev: http://cr.openjdk.java.net/~jjg/8179367/webrev/
>
> -- Jon
>

From martinrb at google.com  Wed Apr 26 22:44:58 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 26 Apr 2017 15:44:58 -0700
Subject: RFR: 8179367: update use of align, valign attributes in java.base
 to use style attribute
In-Reply-To: <CA+kOe09vP0daFo5-D8gpvtCcHugO5ux2kkLuhDUQyajm46qOjg@mail.gmail.com>
References: <59011FBF.2000007@oracle.com>
 <CA+kOe09vP0daFo5-D8gpvtCcHugO5ux2kkLuhDUQyajm46qOjg@mail.gmail.com>
Message-ID: <CA+kOe0_h0o-xc+JA30SCbhPoD5w74pcax+C8CDZpQKefdAGxdg@mail.gmail.com>

http://stackoverflow.com/questions/11939595/leaving-out-the-last-semicolon-of-a-css-block

Terminating with a semicolon consistently seems to be good practice even if
it's not necessary.

On Wed, Apr 26, 2017 at 3:40 PM, Martin Buchholz <martinrb at google.com>
wrote:

> This looks good.
>
> jsr166 maintainers will merge into jsr166 CVS.
>
> I'm unsure whether the ";" should be used as separator or terminator.  I
> would have terminated every style with a ";"
>
> On Wed, Apr 26, 2017 at 3:31 PM, Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> Please review the following conceptually simple fix to change use of the
>> align and valign attributes in table-related tags to inline style
>> attributes in the public doc comments for the contents of java.base module.
>>
>> This is for compatibility with HTML 5.
>>
>> The change was done mechanically with the following sed script, which was
>> applied to the set of files reported by "javadoc -html5" as containing  the
>> use of the align and valign attribute.
>>
>> s/ align="*left"*/ style="text-align:left"/
>> s/ align="*center"*/ style="text-align:center"/
>> s/ ALIGN="*CENTER"*/ style="text-align:center"/
>> s/ align="*right"*/ style="text-align:right"/
>> s/ valign="*top"*/ style="vertical-align:top"/
>> s/ valign="*bottom"*/ style="vertical-align:bottom"/
>> s/ style="\([^"]*\)" style="\([^"]*\)"/ style="\1; \2"/
>>
>> The first six lines change the variants of align and valign into the
>> corresponding style attributes. And, because there were some instances
>> where a tag had both align and valign, the final line of the script merges
>> two instances of the style attribute into a single instance.
>>
>> This covers files in the following packages:
>>
>> java.base java/io
>> java.base java/lang
>> java.base java/lang/reflect
>> java.base java/math
>> java.base java/nio/charset
>> java.base java/text
>> java.base java/time/chrono
>> java.base java/time/format
>> java.base java/util
>> java.base java/util/concurrent
>> java.base java/util/regex
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179367
>> webrev: http://cr.openjdk.java.net/~jjg/8179367/webrev/
>>
>> -- Jon
>>
>
>

From jonathan.gibbons at oracle.com  Wed Apr 26 22:47:49 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 26 Apr 2017 15:47:49 -0700
Subject: RFR: 8179367: update use of align, valign attributes in java.base
 to use style attribute
In-Reply-To: <CA+kOe09vP0daFo5-D8gpvtCcHugO5ux2kkLuhDUQyajm46qOjg@mail.gmail.com>
References: <59011FBF.2000007@oracle.com>
 <CA+kOe09vP0daFo5-D8gpvtCcHugO5ux2kkLuhDUQyajm46qOjg@mail.gmail.com>
Message-ID: <59012395.3000604@oracle.com>

Martin,

';' can be used either way ... it's an optional terminator on the last 
item.   w3schools typically shows without the ';' when it is not necessary.

-- Jon

On 04/26/2017 03:40 PM, Martin Buchholz wrote:
> This looks good.
>
> jsr166 maintainers will merge into jsr166 CVS.
>
> I'm unsure whether the ";" should be used as separator or terminator.  
> I would have terminated every style with a ";"
>
> On Wed, Apr 26, 2017 at 3:31 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Please review the following conceptually simple fix to change use
>     of the align and valign attributes in table-related tags to inline
>     style attributes in the public doc comments for the contents of
>     java.base module.
>
>     This is for compatibility with HTML 5.
>
>     The change was done mechanically with the following sed script,
>     which was applied to the set of files reported by "javadoc -html5"
>     as containing  the use of the align and valign attribute.
>
>     s/ align="*left"*/ style="text-align:left"/
>     s/ align="*center"*/ style="text-align:center"/
>     s/ ALIGN="*CENTER"*/ style="text-align:center"/
>     s/ align="*right"*/ style="text-align:right"/
>     s/ valign="*top"*/ style="vertical-align:top"/
>     s/ valign="*bottom"*/ style="vertical-align:bottom"/
>     s/ style="\([^"]*\)" style="\([^"]*\)"/ style="\1; \2"/
>
>     The first six lines change the variants of align and valign into
>     the corresponding style attributes. And, because there were some
>     instances where a tag had both align and valign, the final line of
>     the script merges two instances of the style attribute into a
>     single instance.
>
>     This covers files in the following packages:
>
>     java.base java/io
>     java.base java/lang
>     java.base java/lang/reflect
>     java.base java/math
>     java.base java/nio/charset
>     java.base java/text
>     java.base java/time/chrono
>     java.base java/time/format
>     java.base java/util
>     java.base java/util/concurrent
>     java.base java/util/regex
>
>     JBS: https://bugs.openjdk.java.net/browse/JDK-8179367
>     <https://bugs.openjdk.java.net/browse/JDK-8179367>
>     webrev: http://cr.openjdk.java.net/~jjg/8179367/webrev/
>     <http://cr.openjdk.java.net/%7Ejjg/8179367/webrev/>
>
>     -- Jon
>
>


From martinrb at google.com  Wed Apr 26 22:50:49 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 26 Apr 2017 15:50:49 -0700
Subject: RFR: 8179367: update use of align, valign attributes in java.base
 to use style attribute
In-Reply-To: <59012395.3000604@oracle.com>
References: <59011FBF.2000007@oracle.com>
 <CA+kOe09vP0daFo5-D8gpvtCcHugO5ux2kkLuhDUQyajm46qOjg@mail.gmail.com>
 <59012395.3000604@oracle.com>
Message-ID: <CA+kOe0_WwV7rbXK2VddaB0UuSb0610YtJ0Di-_92KTGzCQ5Osw@mail.gmail.com>

LGTM

On Wed, Apr 26, 2017 at 3:47 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Martin,
>
> ';' can be used either way ... it's an optional terminator on the last
> item.   w3schools typically shows without the ';' when it is not necessary.
>
> -- Jon
>
>
> On 04/26/2017 03:40 PM, Martin Buchholz wrote:
>
> This looks good.
>
> jsr166 maintainers will merge into jsr166 CVS.
>
> I'm unsure whether the ";" should be used as separator or terminator.  I
> would have terminated every style with a ";"
>
> On Wed, Apr 26, 2017 at 3:31 PM, Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> Please review the following conceptually simple fix to change use of the
>> align and valign attributes in table-related tags to inline style
>> attributes in the public doc comments for the contents of java.base module.
>>
>> This is for compatibility with HTML 5.
>>
>> The change was done mechanically with the following sed script, which was
>> applied to the set of files reported by "javadoc -html5" as containing  the
>> use of the align and valign attribute.
>>
>> s/ align="*left"*/ style="text-align:left"/
>> s/ align="*center"*/ style="text-align:center"/
>> s/ ALIGN="*CENTER"*/ style="text-align:center"/
>> s/ align="*right"*/ style="text-align:right"/
>> s/ valign="*top"*/ style="vertical-align:top"/
>> s/ valign="*bottom"*/ style="vertical-align:bottom"/
>> s/ style="\([^"]*\)" style="\([^"]*\)"/ style="\1; \2"/
>>
>> The first six lines change the variants of align and valign into the
>> corresponding style attributes. And, because there were some instances
>> where a tag had both align and valign, the final line of the script merges
>> two instances of the style attribute into a single instance.
>>
>> This covers files in the following packages:
>>
>> java.base java/io
>> java.base java/lang
>> java.base java/lang/reflect
>> java.base java/math
>> java.base java/nio/charset
>> java.base java/text
>> java.base java/time/chrono
>> java.base java/time/format
>> java.base java/util
>> java.base java/util/concurrent
>> java.base java/util/regex
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179367
>> webrev: http://cr.openjdk.java.net/~jjg/8179367/webrev/
>>
>> -- Jon
>>
>
>
>

From jonathan.gibbons at oracle.com  Wed Apr 26 22:52:10 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 26 Apr 2017 15:52:10 -0700
Subject: RFR: 8179367: update use of align, valign attributes in java.base
 to use style attribute
In-Reply-To: <CA+kOe0_h0o-xc+JA30SCbhPoD5w74pcax+C8CDZpQKefdAGxdg@mail.gmail.com>
References: <59011FBF.2000007@oracle.com>
 <CA+kOe09vP0daFo5-D8gpvtCcHugO5ux2kkLuhDUQyajm46qOjg@mail.gmail.com>
 <CA+kOe0_h0o-xc+JA30SCbhPoD5w74pcax+C8CDZpQKefdAGxdg@mail.gmail.com>
Message-ID: <5901249A.1090903@oracle.com>

Martin,

I would agree that in a stylesheet .css file it would be better to 
include the terminating semicolon, especially when the items are laid 
out on multiple lines.

Here, they're in inline style attributes, so I don't think the trailing 
semicolon is so important.  A better cleanup, in time, is to avoid using 
these inline styles altogether, in favor of styles in a stylesheet 
somewhere.

-- Jon

On 04/26/2017 03:44 PM, Martin Buchholz wrote:
> http://stackoverflow.com/questions/11939595/leaving-out-the-last-semicolon-of-a-css-block
>
> Terminating with a semicolon consistently seems to be good practice 
> even if it's not necessary.
>
> On Wed, Apr 26, 2017 at 3:40 PM, Martin Buchholz <martinrb at google.com 
> <mailto:martinrb at google.com>> wrote:
>
>     This looks good.
>
>     jsr166 maintainers will merge into jsr166 CVS.
>
>     I'm unsure whether the ";" should be used as separator or
>     terminator.  I would have terminated every style with a ";"
>
>     On Wed, Apr 26, 2017 at 3:31 PM, Jonathan Gibbons
>     <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>>
>     wrote:
>
>         Please review the following conceptually simple fix to change
>         use of the align and valign attributes in table-related tags
>         to inline style attributes in the public doc comments for the
>         contents of java.base module.
>
>         This is for compatibility with HTML 5.
>
>         The change was done mechanically with the following sed
>         script, which was applied to the set of files reported by
>         "javadoc -html5" as containing  the use of the align and
>         valign attribute.
>
>         s/ align="*left"*/ style="text-align:left"/
>         s/ align="*center"*/ style="text-align:center"/
>         s/ ALIGN="*CENTER"*/ style="text-align:center"/
>         s/ align="*right"*/ style="text-align:right"/
>         s/ valign="*top"*/ style="vertical-align:top"/
>         s/ valign="*bottom"*/ style="vertical-align:bottom"/
>         s/ style="\([^"]*\)" style="\([^"]*\)"/ style="\1; \2"/
>
>         The first six lines change the variants of align and valign
>         into the corresponding style attributes. And, because there
>         were some instances where a tag had both align and valign, the
>         final line of the script merges two instances of the style
>         attribute into a single instance.
>
>         This covers files in the following packages:
>
>         java.base java/io
>         java.base java/lang
>         java.base java/lang/reflect
>         java.base java/math
>         java.base java/nio/charset
>         java.base java/text
>         java.base java/time/chrono
>         java.base java/time/format
>         java.base java/util
>         java.base java/util/concurrent
>         java.base java/util/regex
>
>         JBS: https://bugs.openjdk.java.net/browse/JDK-8179367
>         <https://bugs.openjdk.java.net/browse/JDK-8179367>
>         webrev: http://cr.openjdk.java.net/~jjg/8179367/webrev/
>         <http://cr.openjdk.java.net/%7Ejjg/8179367/webrev/>
>
>         -- Jon
>
>
>


From mandy.chung at oracle.com  Wed Apr 26 22:54:58 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 26 Apr 2017 15:54:58 -0700
Subject: RFR: 8179367: update use of align,
 valign attributes in java.base to use style attribute
In-Reply-To: <59011FBF.2000007@oracle.com>
References: <59011FBF.2000007@oracle.com>
Message-ID: <DE37F085-E83C-49B4-B823-1D21C0467A41@oracle.com>

The patch looks okay to me.
Mandy

> On Apr 26, 2017, at 3:31 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Please review the following conceptually simple fix to change use of the align and valign attributes in table-related tags to inline style attributes in the public doc comments for the contents of java.base module.
> 
> This is for compatibility with HTML 5.
> 
> The change was done mechanically with the following sed script, which was applied to the set of files reported by "javadoc -html5" as containing  the use of the align and valign attribute.
> 
> s/ align="*left"*/ style="text-align:left"/
> s/ align="*center"*/ style="text-align:center"/
> s/ ALIGN="*CENTER"*/ style="text-align:center"/
> s/ align="*right"*/ style="text-align:right"/
> s/ valign="*top"*/ style="vertical-align:top"/
> s/ valign="*bottom"*/ style="vertical-align:bottom"/
> s/ style="\([^"]*\)" style="\([^"]*\)"/ style="\1; \2"/
> 
> The first six lines change the variants of align and valign into the corresponding style attributes. And, because there were some instances where a tag had both align and valign, the final line of the script merges two instances of the style attribute into a single instance.
> 
> This covers files in the following packages:
> 
> java.base java/io
> java.base java/lang
> java.base java/lang/reflect
> java.base java/math
> java.base java/nio/charset
> java.base java/text
> java.base java/time/chrono
> java.base java/time/format
> java.base java/util
> java.base java/util/concurrent
> java.base java/util/regex
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179367
> webrev: http://cr.openjdk.java.net/~jjg/8179367/webrev/
> 
> -- Jon


From martinrb at google.com  Wed Apr 26 22:59:22 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 26 Apr 2017 15:59:22 -0700
Subject: RFR: 8179367: update use of align, valign attributes in java.base
 to use style attribute
In-Reply-To: <5901249A.1090903@oracle.com>
References: <59011FBF.2000007@oracle.com>
 <CA+kOe09vP0daFo5-D8gpvtCcHugO5ux2kkLuhDUQyajm46qOjg@mail.gmail.com>
 <CA+kOe0_h0o-xc+JA30SCbhPoD5w74pcax+C8CDZpQKefdAGxdg@mail.gmail.com>
 <5901249A.1090903@oracle.com>
Message-ID: <CA+kOe08=boSUWifUmaAcS=eiaWJY_7=r7WgOvw8mEDMKExWONA@mail.gmail.com>

On Wed, Apr 26, 2017 at 3:52 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Martin,
>
> I would agree that in a stylesheet .css file it would be better to include
> the terminating semicolon, especially when the items are laid out on
> multiple lines.
>
> Here, they're in inline style attributes, so I don't think the trailing
> semicolon is so important.  A better cleanup, in time, is to avoid using
> these inline styles altogether, in favor of styles in a stylesheet
> somewhere.
>

OK, we have complete agreement!  I now realize I have the equivalent style
with java array initializers.

From paul.sandoz at oracle.com  Wed Apr 26 23:06:31 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 26 Apr 2017 16:06:31 -0700
Subject: [JDK9] RFR 8167229: Improve VarHandle documentation
Message-ID: <431E7583-CA7B-4CB0-9C4C-696FC24EB5D5@oracle.com>

Hi,

Please review some documentation changes to VarHandle:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8167229-varhandle-docs/webrev/index.html

There are no changes to the specification.

A significant portion of the changes are based on feedback from Alex who observed it?s possible to simplify the specification by removing the notion of shape and focusing on the list of coordinate types (the types of coordinate expressions).

Paul.


From jonathan.gibbons at oracle.com  Thu Apr 27 00:50:55 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 26 Apr 2017 17:50:55 -0700
Subject: RFR: 8179370: Replace use of <tt>,
 <center> and <font> tags in java.base
Message-ID: <5901406F.6080402@oracle.com>

Please review these mostly simple changes to replace HTML tags which are 
not valid in HTML 5 in public doc comments in java.base.

As with the previous changes, the changes were done mechanically, using 
the following sed script:

s|<tt>|<code>|g
s|</tt>|</code>|g
s|<\\/tt>|<\\/code>|g
s|\(<td[^>]*\)><center>\([^<]*\)</center>|\1 style="text-align:center">\2|
s|<center><table |<div style="text-align:center"><table style="margin:0 
auto" |
s|</center>|</div>|
s|<font |<span |
s|</font>|</span>|

The unusual form of the 3rd line was to cover the occurrence in a makefile.

The 4th line is specific for DataInput.java, and replaces <center> 
within a <td> with a style on the <td> element itself.

The 5th and 6th lines are specific to URLConnection. The use of the 
table itself and the ASCII art that follows it are questionable, but the 
intent here is just to update the HTML and not to rework the visual 
appearance of the generated documentation.

The changes cover files in the following packages:

java.base java/io
java.base java/net
java.base java/util
java.base javax/net/ssl


JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/

-- Jon

From joe.darcy at oracle.com  Thu Apr 27 00:55:49 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 26 Apr 2017 17:55:49 -0700
Subject: RFR: 8179370: Replace use of <tt>, <center> and <font> tags in
 java.base
In-Reply-To: <5901406F.6080402@oracle.com>
References: <5901406F.6080402@oracle.com>
Message-ID: <59014195.1070408@oracle.com>

Hi Jon,

I'd prefer if the "<tt>foo</tt>" were replaced with "{@code tt}" rather 
than "<code>foo</code>"- none of the tricky cases which preclude use of 
{@code } use seem to be present here - but will approve the changeset in 
its current form too.

Cheers,

-Joe

On 4/26/2017 5:50 PM, Jonathan Gibbons wrote:
> Please review these mostly simple changes to replace HTML tags which 
> are not valid in HTML 5 in public doc comments in java.base.
>
> As with the previous changes, the changes were done mechanically, 
> using the following sed script:
>
> s|<tt>|<code>|g
> s|</tt>|</code>|g
> s|<\\/tt>|<\\/code>|g
> s|\(<td[^>]*\)><center>\([^<]*\)</center>|\1 
> style="text-align:center">\2|
> s|<center><table |<div style="text-align:center"><table 
> style="margin:0 auto" |
> s|</center>|</div>|
> s|<font |<span |
> s|</font>|</span>|
>
> The unusual form of the 3rd line was to cover the occurrence in a 
> makefile.
>
> The 4th line is specific for DataInput.java, and replaces <center> 
> within a <td> with a style on the <td> element itself.
>
> The 5th and 6th lines are specific to URLConnection. The use of the 
> table itself and the ASCII art that follows it are questionable, but 
> the intent here is just to update the HTML and not to rework the 
> visual appearance of the generated documentation.
>
> The changes cover files in the following packages:
>
> java.base java/io
> java.base java/net
> java.base java/util
> java.base javax/net/ssl
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
> Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/
>
> -- Jon


From jonathan.gibbons at oracle.com  Thu Apr 27 01:09:52 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 26 Apr 2017 18:09:52 -0700
Subject: RFR: 8179370: Replace use of <tt>, <center> and <font> tags in
 java.base
In-Reply-To: <59014195.1070408@oracle.com>
References: <5901406F.6080402@oracle.com> <59014195.1070408@oracle.com>
Message-ID: <590144E0.4050400@oracle.com>

Joe,

Yes, there are occurrences here that require <code> instead of {@code}, 
because of the presence of HTML entities. It's about 50/50.

I'd prefer to stay with mechanical updates as much as possible for these 
bulk updates, as compared to manual updates, but I may be able to 
improve the sed script for this case.

-- Jon

On 04/26/2017 05:55 PM, Joseph D. Darcy wrote:
> Hi Jon,
>
> I'd prefer if the "<tt>foo</tt>" were replaced with "{@code tt}" 
> rather than "<code>foo</code>"- none of the tricky cases which 
> preclude use of {@code } use seem to be present here - but will 
> approve the changeset in its current form too.
>
> Cheers,
>
> -Joe
>
> On 4/26/2017 5:50 PM, Jonathan Gibbons wrote:
>> Please review these mostly simple changes to replace HTML tags which 
>> are not valid in HTML 5 in public doc comments in java.base.
>>
>> As with the previous changes, the changes were done mechanically, 
>> using the following sed script:
>>
>> s|<tt>|<code>|g
>> s|</tt>|</code>|g
>> s|<\\/tt>|<\\/code>|g
>> s|\(<td[^>]*\)><center>\([^<]*\)</center>|\1 
>> style="text-align:center">\2|
>> s|<center><table |<div style="text-align:center"><table 
>> style="margin:0 auto" |
>> s|</center>|</div>|
>> s|<font |<span |
>> s|</font>|</span>|
>>
>> The unusual form of the 3rd line was to cover the occurrence in a 
>> makefile.
>>
>> The 4th line is specific for DataInput.java, and replaces <center> 
>> within a <td> with a style on the <td> element itself.
>>
>> The 5th and 6th lines are specific to URLConnection. The use of the 
>> table itself and the ASCII art that follows it are questionable, but 
>> the intent here is just to update the HTML and not to rework the 
>> visual appearance of the generated documentation.
>>
>> The changes cover files in the following packages:
>>
>> java.base java/io
>> java.base java/net
>> java.base java/util
>> java.base javax/net/ssl
>>
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
>> Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/
>>
>> -- Jon
>


From mandy.chung at oracle.com  Thu Apr 27 01:23:06 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 26 Apr 2017 18:23:06 -0700
Subject: RFR: 8179370: Replace use of <tt>,
 <center> and <font> tags in java.base
In-Reply-To: <5901406F.6080402@oracle.com>
References: <5901406F.6080402@oracle.com>
Message-ID: <89650C1C-15F8-4413-88B8-0A3E95849501@oracle.com>

Looks okay.
Mandy

> On Apr 26, 2017, at 5:50 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Please review these mostly simple changes to replace HTML tags which are not valid in HTML 5 in public doc comments in java.base.
> 
> As with the previous changes, the changes were done mechanically, using the following sed script:
> 
> s|<tt>|<code>|g
> s|</tt>|</code>|g
> s|<\\/tt>|<\\/code>|g
> s|\(<td[^>]*\)><center>\([^<]*\)</center>|\1 style="text-align:center">\2|
> s|<center><table |<div style="text-align:center"><table style="margin:0 auto" |
> s|</center>|</div>|
> s|<font |<span |
> s|</font>|</span>|
> 
> The unusual form of the 3rd line was to cover the occurrence in a makefile.
> 
> The 4th line is specific for DataInput.java, and replaces <center> within a <td> with a style on the <td> element itself.
> 
> The 5th and 6th lines are specific to URLConnection. The use of the table itself and the ASCII art that follows it are questionable, but the intent here is just to update the HTML and not to rework the visual appearance of the generated documentation.
> 
> The changes cover files in the following packages:
> 
> java.base java/io
> java.base java/net
> java.base java/util
> java.base javax/net/ssl
> 
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
> Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/
> 
> -- Jon


From jonathan.gibbons at oracle.com  Thu Apr 27 01:49:11 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 26 Apr 2017 18:49:11 -0700
Subject: RFR: 8179370: Replace use of <tt>, <center> and <font> tags in
 java.base
In-Reply-To: <590144E0.4050400@oracle.com>
References: <5901406F.6080402@oracle.com> <59014195.1070408@oracle.com>
 <590144E0.4050400@oracle.com>
Message-ID: <59014E17.2020802@oracle.com>

Updated webrev to address Joe's suggestion to try harder to use {@code} 
as a substitute for <tt>.

http://cr.openjdk.java.net/~jjg/8179370/webrev.01

The modified sed script has a new first line:

s|<tt>\([^&<>]*\)</tt>|{@code \1}|g
s|<tt>|<code>|g
s|</tt>|</code>|g
s|<\\/tt>|<\\/code>|g
s|\(<td[^>]*\)><center>\([^<]*\)</center>|\1 style="text-align:center">\2|
s|<center><table |<div style="text-align:center"><table style="margin:0 
auto" |
s|</center>|</div>|
s|<font |<span |
s|</font>|</span>|

Also note that there is a small visible bug in webrev. If you look at 
ServiceLoader.java:133,
the second instance of <tt> is not converted to {@code} because the 
embedded '\' is actually
an entity in the source file ... and so it is inappropriate to use 
{@code} for that instance.

-- Jon



On 04/26/2017 06:09 PM, Jonathan Gibbons wrote:
> Joe,
>
> Yes, there are occurrences here that require <code> instead of 
> {@code}, because of the presence of HTML entities. It's about 50/50.
>
> I'd prefer to stay with mechanical updates as much as possible for 
> these bulk updates, as compared to manual updates, but I may be able 
> to improve the sed script for this case.
>
> -- Jon
>
> On 04/26/2017 05:55 PM, Joseph D. Darcy wrote:
>> Hi Jon,
>>
>> I'd prefer if the "<tt>foo</tt>" were replaced with "{@code tt}" 
>> rather than "<code>foo</code>"- none of the tricky cases which 
>> preclude use of {@code } use seem to be present here - but will 
>> approve the changeset in its current form too.
>>
>> Cheers,
>>
>> -Joe
>>
>> On 4/26/2017 5:50 PM, Jonathan Gibbons wrote:
>>> Please review these mostly simple changes to replace HTML tags which 
>>> are not valid in HTML 5 in public doc comments in java.base.
>>>
>>> As with the previous changes, the changes were done mechanically, 
>>> using the following sed script:
>>>
>>> s|<tt>|<code>|g
>>> s|</tt>|</code>|g
>>> s|<\\/tt>|<\\/code>|g
>>> s|\(<td[^>]*\)><center>\([^<]*\)</center>|\1 
>>> style="text-align:center">\2|
>>> s|<center><table |<div style="text-align:center"><table 
>>> style="margin:0 auto" |
>>> s|</center>|</div>|
>>> s|<font |<span |
>>> s|</font>|</span>|
>>>
>>> The unusual form of the 3rd line was to cover the occurrence in a 
>>> makefile.
>>>
>>> The 4th line is specific for DataInput.java, and replaces <center> 
>>> within a <td> with a style on the <td> element itself.
>>>
>>> The 5th and 6th lines are specific to URLConnection. The use of the 
>>> table itself and the ASCII art that follows it are questionable, but 
>>> the intent here is just to update the HTML and not to rework the 
>>> visual appearance of the generated documentation.
>>>
>>> The changes cover files in the following packages:
>>>
>>> java.base java/io
>>> java.base java/net
>>> java.base java/util
>>> java.base javax/net/ssl
>>>
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
>>> Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/
>>>
>>> -- Jon
>>
>


From joe.darcy at oracle.com  Thu Apr 27 02:41:08 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 26 Apr 2017 19:41:08 -0700
Subject: RFR: 8179370: Replace use of <tt>, <center> and <font> tags in
 java.base
In-Reply-To: <59014E17.2020802@oracle.com>
References: <5901406F.6080402@oracle.com> <59014195.1070408@oracle.com>
 <590144E0.4050400@oracle.com> <59014E17.2020802@oracle.com>
Message-ID: <b8ea2d00-0fc6-157b-4f39-a17460edd132@oracle.com>

Looks better; thanks Jon,

-Joe


On 4/26/2017 6:49 PM, Jonathan Gibbons wrote:
> Updated webrev to address Joe's suggestion to try harder to use 
> {@code} as a substitute for <tt>.
>
> http://cr.openjdk.java.net/~jjg/8179370/webrev.01
>
> The modified sed script has a new first line:
>
> s|<tt>\([^&<>]*\)</tt>|{@code \1}|g
> s|<tt>|<code>|g
> s|</tt>|</code>|g
> s|<\\/tt>|<\\/code>|g
> s|\(<td[^>]*\)><center>\([^<]*\)</center>|\1 
> style="text-align:center">\2|
> s|<center><table |<div style="text-align:center"><table 
> style="margin:0 auto" |
> s|</center>|</div>|
> s|<font |<span |
> s|</font>|</span>|
>
> Also note that there is a small visible bug in webrev. If you look at 
> ServiceLoader.java:133,
> the second instance of <tt> is not converted to {@code} because the 
> embedded '\' is actually
> an entity in the source file ... and so it is inappropriate to use 
> {@code} for that instance.
>
> -- Jon
>
>
>
> On 04/26/2017 06:09 PM, Jonathan Gibbons wrote:
>> Joe,
>>
>> Yes, there are occurrences here that require <code> instead of 
>> {@code}, because of the presence of HTML entities. It's about 50/50.
>>
>> I'd prefer to stay with mechanical updates as much as possible for 
>> these bulk updates, as compared to manual updates, but I may be able 
>> to improve the sed script for this case.
>>
>> -- Jon
>>
>> On 04/26/2017 05:55 PM, Joseph D. Darcy wrote:
>>> Hi Jon,
>>>
>>> I'd prefer if the "<tt>foo</tt>" were replaced with "{@code tt}" 
>>> rather than "<code>foo</code>"- none of the tricky cases which 
>>> preclude use of {@code } use seem to be present here - but will 
>>> approve the changeset in its current form too.
>>>
>>> Cheers,
>>>
>>> -Joe
>>>
>>> On 4/26/2017 5:50 PM, Jonathan Gibbons wrote:
>>>> Please review these mostly simple changes to replace HTML tags 
>>>> which are not valid in HTML 5 in public doc comments in java.base.
>>>>
>>>> As with the previous changes, the changes were done mechanically, 
>>>> using the following sed script:
>>>>
>>>> s|<tt>|<code>|g
>>>> s|</tt>|</code>|g
>>>> s|<\\/tt>|<\\/code>|g
>>>> s|\(<td[^>]*\)><center>\([^<]*\)</center>|\1 
>>>> style="text-align:center">\2|
>>>> s|<center><table |<div style="text-align:center"><table 
>>>> style="margin:0 auto" |
>>>> s|</center>|</div>|
>>>> s|<font |<span |
>>>> s|</font>|</span>|
>>>>
>>>> The unusual form of the 3rd line was to cover the occurrence in a 
>>>> makefile.
>>>>
>>>> The 4th line is specific for DataInput.java, and replaces <center> 
>>>> within a <td> with a style on the <td> element itself.
>>>>
>>>> The 5th and 6th lines are specific to URLConnection. The use of the 
>>>> table itself and the ASCII art that follows it are questionable, 
>>>> but the intent here is just to update the HTML and not to rework 
>>>> the visual appearance of the generated documentation.
>>>>
>>>> The changes cover files in the following packages:
>>>>
>>>> java.base java/io
>>>> java.base java/net
>>>> java.base java/util
>>>> java.base javax/net/ssl
>>>>
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
>>>> Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/
>>>>
>>>> -- Jon
>>>
>>
>


From vyom.tewari at oracle.com  Thu Apr 27 08:00:43 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Thu, 27 Apr 2017 13:30:43 +0530
Subject: RFR: 8178298 (LdapLoginModule)Migrate the JNDI properties
 technote to javadoc doc-files
In-Reply-To: <BA0F1B99-87A3-4CD9-BE83-5C61EE0C5AF0@oracle.com>
References: <2d811080-fc39-c852-36d1-3f2b5cac7091@oracle.com>
 <BA0F1B99-87A3-4CD9-BE83-5C61EE0C5AF0@oracle.com>
Message-ID: <370c9327-d5fe-d7fc-cbe5-1c0d9dc309c2@oracle.com>



On Tuesday 25 April 2017 08:41 PM, Chris Hegarty wrote:
> Vyom,
>
>> On 24 Apr 2017, at 10:15, Vyom Tewari <vyom.tewari at oracle.com> wrote:
>>
>> Hi All,
>>
>> Please review the simple doc fix.
>>
>> Webrev   : http://cr.openjdk.java.net/~vtewari/8178298/webrev0.0/index.html
>>
>> Bugid      : https://bugs.openjdk.java.net/browse/JDK-8178298
>>
>> Note, this patch depends on "JDK-8178725".
> This is confusing. The bug synopsis and description indicate that the guide,
> jndi-ldap-gl.html, will be moved into the jdk repository as a doc-file, similar
> to what happened in 8178101 [1], but your webrev clearly does not implement
> this. It instead proposes to use the new extLink, as you have eluded to in the
> email. If the latter, then the changes are ok, just update the bug details to
> match what is being done.
Hi Chris,
thanks for review, i updated the issue description.
Vyom
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8178101
>   


From Alan.Bateman at oracle.com  Thu Apr 27 11:45:48 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 27 Apr 2017 12:45:48 +0100
Subject: RFR: 8179370: Replace use of <tt>, <center> and <font> tags in
 java.base
In-Reply-To: <59014E17.2020802@oracle.com>
References: <5901406F.6080402@oracle.com> <59014195.1070408@oracle.com>
 <590144E0.4050400@oracle.com> <59014E17.2020802@oracle.com>
Message-ID: <c3a93d4d-550c-b102-13fa-5e9ca0ff41f4@oracle.com>



On 27/04/2017 02:49, Jonathan Gibbons wrote:
> Updated webrev to address Joe's suggestion to try harder to use 
> {@code} as a substitute for <tt>.
>
> http://cr.openjdk.java.net/~jjg/8179370/webrev.01
>
The updated version using {@code ... } looks better and also keeps the 
lines from growing too long.

-Alan

From mandy.chung at oracle.com  Thu Apr 27 15:03:01 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 27 Apr 2017 08:03:01 -0700
Subject: RFR: 8179370: Replace use of <tt>,
 <center> and <font> tags in java.base
In-Reply-To: <59014E17.2020802@oracle.com>
References: <5901406F.6080402@oracle.com> <59014195.1070408@oracle.com>
 <590144E0.4050400@oracle.com> <59014E17.2020802@oracle.com>
Message-ID: <E034E254-45EE-4AB7-82F7-7DDEC5CE414B@oracle.com>


> On Apr 26, 2017, at 6:49 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Updated webrev to address Joe's suggestion to try harder to use {@code} as a substitute for <tt>.
> 
> http://cr.openjdk.java.net/~jjg/8179370/webrev.01

Looks good.
Mandy

From rob.mckenna at oracle.com  Thu Apr 27 15:27:05 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 27 Apr 2017 16:27:05 +0100
Subject: [RFR] 8160768: Add capability to custom resolve host/domain
 names within the default JDNI LDAP provider
In-Reply-To: <4ed39a66-f594-d4aa-adce-56f05315d771@oracle.com>
References: <20170125163141.GB3628@tecra> <20170125174453.GE3628@tecra>
 <f81eb731-358e-a680-0788-05230af9ce07@oracle.com>
 <20170126040326.GA3544@vimes> <20170201200550.GH2829@vimes>
 <f6b229bf-292b-2fc1-278c-a4acaa869968@oracle.com>
 <20170202221415.GD2648@vimes>
 <4ed39a66-f594-d4aa-adce-56f05315d771@oracle.com>
Message-ID: <20170427152705.GA3219@vimes>

Hi folks, I'd like to revisit this for JDK10 as it was judged to be a
bit late in the game for 9.

I've published a new webrev at:
http://cr.openjdk.java.net/~robm/8160768/webrev.05/ which incorporates
very helpful feedback from Michael Osipov.

Notes:

- The 9 request rejection noted that there were concerns about a
  "dependency on the DNS provider" - to be explicit, there should be no
  new dependencies from the original code. (the new DefaultDnsProvider
  is simply a repackaging of how we currently do things)
- As Michael noted, the assumption that the DN will map to the correct
  domain name is incorrect. The major implication from this is that the
  DNS provider will need to return both a domain name *AND* a list of
  urls corresponding to server endpoints.

The latter point results in some implementation issues. I wanted to be
able to provide this functionality with the following restrictions:

a) avoid a new public type to leave the door open to backporting the
change.

b) maintain type safety (i.e. avoid the use of Object in generic types)

I've thought of 3 possible approaches with the first of these being the
one implemented in the webrev. Per-approach, the DNS provider must
return a:

1) List<String> where the first element in the list corresponds to the
domain name and subsequent elements correspond to server endpoints.

2) Map<String, String> where the key represents the server endpoints and
the value represents the domain name. (this is particularly ungainly as the
map values will be identical but alongside option 3) is also the most
flexible)

3) Map<String, List<String>> where the key "domain" points to a list
with a single element (the domain name) and the key "urls" contains a
list of server endpoints.

Feedback (or alternative approaches) would be much appreciated!

    -Rob

On 03/02/17 01:44, Vyom Tewari wrote:
> Hi Rob,
> 
> Most of the code changes looks fine except new code will throw NPE if
> "ServiceLocator.mapDnToDomainName(ldapUrl.getDN())" is not able to map. you
> have to check for null in LdapCtxFactory.java class as follows.
> 
> if(ServiceLocator.mapDnToDomainName(ldapUrl.getDN())!=null){
>                 ((LdapCtx) ctx).setDomainName(
> ServiceLocator.mapDnToDomainName(ldapUrl.getDN()));
>                 }
> 
> 
> ##############################
> 
> Exception in thread "main" java.lang.NullPointerException
>     at java.base/java.util.Hashtable.put(Hashtable.java:474)
>     at
> java.naming/com.sun.jndi.ldap.LdapCtx.setDomainName(LdapCtx.java:2346)
>     at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> ################################
> 
> Thanks,
> 
> Vyom
> 
> 
> On Friday 03 February 2017 03:44 AM, Rob McKenna wrote:
> >Thanks Daniel,
> >
> >New webrev at http://cr.openjdk.java.net/~robm/8160768/webrev.04/
> >
> >In addition to your comments below I've added the package access check
> >we discussed.
> >
> >Note: when a provider returns multiple results we create an LdapCtx
> >based on the first of those. I think it might be useful to extend
> >LdapClient to accept a list of addresses which can be iterated over in the
> >event of a connection failure but I'll tackle that separately.
> >
> >     -Rob
> >
> >On 02/02/17 11:01, Daniel Fuchs wrote:
> >>Hi Rob,
> >>
> >>This is not a code I know well - but here are a couple
> >>of comments:
> >>
> >>LdapCtxFactory.java:
> >>
> >>168         NamingException ne = new NamingException();
> >>232         NamingException ne = new NamingException();
> >>
> >>Creating an exception is somewhat costly as it records the
> >>backtrace in the Throwable constructor. I don't know if
> >>it's an issue there but I thought I'd mention it. It might
> >>be better to create the exception only if you're actually
> >>going to throw it.
> >>
> >>  186         } catch (Exception e) {
> >>  187             ne.setRootCause(e);
> >>  188         }
> >>
> >>This will catch the NamingException thrown at line 173
> >>and set it at the cause of another NamingException that
> >>has no message. Maybe it would be better to have two
> >>catch clauses:
> >>
> >>  186         } catch (NamingException e) {
> >>  187             throw e;
> >>  186         } catch (Exception e) {
> >>                  ... transform it to NamingException ...
> >>
> >>In getDnsUrls:
> >>
> >>  198         if (env.containsKey(LdapCtx.DNS_PROVIDER)
> >>  199                 && env.get(LdapCtx.DNS_PROVIDER) != null
> >>  200                 && !env.get(LdapCtx.DNS_PROVIDER).equals(""))
> >>
> >>I'd suggest to simplify this and make a single lookup:
> >>
> >>              String providerClass = env.get(LdapCtx.DNS_PROVIDER);
> >>              if (providerClass != null && !providerClass.isEmpty()) {
> >>                  ...
> >>                  Class<?> cls = Class.forName(providerClass, true, cl);
> >>
> >>best regards,
> >>
> >>-- daniel
> >>
> >>
> >>On 01/02/17 20:05, Rob McKenna wrote:
> >>>New webrev with updated test here:
> >>>
> >>>http://cr.openjdk.java.net/~robm/8160768/webrev.03/
> >>>
> >>>    -Rob
> >>>
> >>>On 26/01/17 04:03, Rob McKenna wrote:
> >>>>Ack, apologies, thats what I get for rushing. (which I suppose I'm doing
> >>>>again) That code was actually supposed to be in the getDnsUrls method.
> >>>>Updated in place:
> >>>>
> >>>>http://cr.openjdk.java.net/~robm/8160768/webrev.02/
> >>>>
> >>>>I'll add a couple of tests for the SecurityManager along with some input
> >>>>checking tests too.
> >>>>
> >>>>    -Rob
> >>>>
> >>>>On 25/01/17 05:50, Daniel Fuchs wrote:
> >>>>>Hi Rob,
> >>>>>
> >>>>>I believe you should move the security check to before
> >>>>>the class is actually loaded, before the call to
> >>>>>171             List<String> urls = getDnsUrls(url, env);
> >>>>>
> >>>>>best regards,
> >>>>>
> >>>>>-- daniel
> >>>>>
> >>>>>On 25/01/17 17:44, Rob McKenna wrote:
> >>>>>>I neglected to include a security check so I've cribbed the one from
> >>>>>>OBJECT_FACTORIES (NamingManager.setObjectFactoryBuilder()) - see:
> >>>>>>
> >>>>>>http://cr.openjdk.java.net/~robm/8160768/webrev.02/
> >>>>>>
> >>>>>>Note, this wraps the SecurityException in a NamingException. Presumably
> >>>>>>its better to throw something than simply leave the default value in
> >>>>>>place, but feedback appreciated!
> >>>>>>
> >>>>>>   -Rob
> >>>>>>
> >>>>>>On 25/01/17 04:31, Rob McKenna wrote:
> >>>>>>>Hi folks,
> >>>>>>>
> >>>>>>>I'm looking for feedback on this suggested fix for the following bug:
> >>>>>>>
> >>>>>>>https://bugs.openjdk.java.net/browse/JDK-816076
> >>>>>>>http://cr.openjdk.java.net/~robm/8160768/webrev.01/
> >>>>>>>
> >>>>>>>This is something that has come up a few times. Basically in certain
> >>>>>>>environments (e.g. MS Active Directory) there is a dependence on
> >>>>>>>DNS records to provide a pointer to the actual ldap server to be used
> >>>>>>>for a given LdapCtx.PROVIDER_URL where the url itself simply points to the
> >>>>>>>domain name.
> >>>>>>>
> >>>>>>>This fix add a new Ldap context property which allows a user to specify a
> >>>>>>>class (implementing BiFunction) which can perform any necessary extra steps
> >>>>>>>to derive the ldap servers hostname/port from the PROVIDER_URL.
> >>>>>>>
> >>>>>>>   -Rob
> >>>>>>>
> 

From martinrb at google.com  Thu Apr 27 17:20:10 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 27 Apr 2017 10:20:10 -0700
Subject: [JDK9] RFR 8167229: Improve VarHandle documentation
In-Reply-To: <431E7583-CA7B-4CB0-9C4C-696FC24EB5D5@oracle.com>
References: <431E7583-CA7B-4CB0-9C4C-696FC24EB5D5@oracle.com>
Message-ID: <CA+kOe0_7fa4Cm1uq6+9yfQM43WRpBq=bC-gSP36cUzXZqwjz6A@mail.gmail.com>

<p>Each access mode is associated with an <em>access mode method</em>

Tautological.  Did you mean to say "Each VarHandle method" or "Each access"
?


>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8167229-
> varhandle-docs/webrev/index.html
>

From martinrb at google.com  Thu Apr 27 17:32:08 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 27 Apr 2017 10:32:08 -0700
Subject: [JDK9] RFR 8167229: Improve VarHandle documentation
In-Reply-To: <CA+kOe0_7fa4Cm1uq6+9yfQM43WRpBq=bC-gSP36cUzXZqwjz6A@mail.gmail.com>
References: <431E7583-CA7B-4CB0-9C4C-696FC24EB5D5@oracle.com>
 <CA+kOe0_7fa4Cm1uq6+9yfQM43WRpBq=bC-gSP36cUzXZqwjz6A@mail.gmail.com>
Message-ID: <CA+kOe0_GG7TBgRieg_Re+ZrnNJyHYcC+zJymVRSBkyN78RsawA@mail.gmail.com>

Oh wait, there's a distinction between "access mode" and "access mode
method", because of VarHandle.AccessMode.

Is it true that each access mode is associated with exactly one access mode
method ?  Seems to be yes, because of
http://download.java.net/java/jdk9/docs/api/java/lang/invoke/VarHandle.AccessMode.html#methodName--


It might be worth making that clearer somehow.

<p>Each access mode is associated with one <em>access mode method</em>

On Thu, Apr 27, 2017 at 10:20 AM, Martin Buchholz <martinrb at google.com>
wrote:

>
> <p>Each access mode is associated with an <em>access mode method</em>
>
> Tautological.  Did you mean to say "Each VarHandle method" or "Each
> access" ?
>
>
>>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8167229-varhand
>> le-docs/webrev/index.html
>>
>

From martinrb at google.com  Thu Apr 27 17:38:48 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 27 Apr 2017 10:38:48 -0700
Subject: [JDK9] RFR 8167229: Improve VarHandle documentation
In-Reply-To: <CA+kOe0_GG7TBgRieg_Re+ZrnNJyHYcC+zJymVRSBkyN78RsawA@mail.gmail.com>
References: <431E7583-CA7B-4CB0-9C4C-696FC24EB5D5@oracle.com>
 <CA+kOe0_7fa4Cm1uq6+9yfQM43WRpBq=bC-gSP36cUzXZqwjz6A@mail.gmail.com>
 <CA+kOe0_GG7TBgRieg_Re+ZrnNJyHYcC+zJymVRSBkyN78RsawA@mail.gmail.com>
Message-ID: <CA+kOe0-6sA9FZtnvF0KoPRHQbyWu0hYXRqVQp_6BVZ=J2mT5vg@mail.gmail.com>

Add missing period.

1787          * Returns the {@code VarHandle} signature-polymorphic method
name
1788          * associated with this {@code AccessMode} value
1789          *

From bradford.wetmore at oracle.com  Thu Apr 27 18:07:39 2017
From: bradford.wetmore at oracle.com (Brad R. Wetmore)
Date: Thu, 27 Apr 2017 11:07:39 -0700
Subject: RFR: 8179370: Replace use of <tt>, <center> and <font> tags in
 java.base
In-Reply-To: <89650C1C-15F8-4413-88B8-0A3E95849501@oracle.com>
References: <5901406F.6080402@oracle.com>
 <89650C1C-15F8-4413-88B8-0A3E95849501@oracle.com>
Message-ID: <80e8a78c-2e83-110f-3ab3-dc0922aba03d@oracle.com>

Only comment is updating the copyright dates to 2017.

Brad




On 4/26/2017 6:23 PM, Mandy Chung wrote:
> Looks okay.
> Mandy
>
>> On Apr 26, 2017, at 5:50 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>
>> Please review these mostly simple changes to replace HTML tags which are not valid in HTML 5 in public doc comments in java.base.
>>
>> As with the previous changes, the changes were done mechanically, using the following sed script:
>>
>> s|<tt>|<code>|g
>> s|</tt>|</code>|g
>> s|<\\/tt>|<\\/code>|g
>> s|\(<td[^>]*\)><center>\([^<]*\)</center>|\1 style="text-align:center">\2|
>> s|<center><table |<div style="text-align:center"><table style="margin:0 auto" |
>> s|</center>|</div>|
>> s|<font |<span |
>> s|</font>|</span>|
>>
>> The unusual form of the 3rd line was to cover the occurrence in a makefile.
>>
>> The 4th line is specific for DataInput.java, and replaces <center> within a <td> with a style on the <td> element itself.
>>
>> The 5th and 6th lines are specific to URLConnection. The use of the table itself and the ASCII art that follows it are questionable, but the intent here is just to update the HTML and not to rework the visual appearance of the generated documentation.
>>
>> The changes cover files in the following packages:
>>
>> java.base java/io
>> java.base java/net
>> java.base java/util
>> java.base javax/net/ssl
>>
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179370
>> Webrev: http://cr.openjdk.java.net/~jjg/8179370/webrev/
>>
>> -- Jon
>

From martinrb at google.com  Thu Apr 27 18:32:59 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 27 Apr 2017 11:32:59 -0700
Subject: [JDK9] RFR 8167229: Improve VarHandle documentation
In-Reply-To: <CA+kOe0-6sA9FZtnvF0KoPRHQbyWu0hYXRqVQp_6BVZ=J2mT5vg@mail.gmail.com>
References: <431E7583-CA7B-4CB0-9C4C-696FC24EB5D5@oracle.com>
 <CA+kOe0_7fa4Cm1uq6+9yfQM43WRpBq=bC-gSP36cUzXZqwjz6A@mail.gmail.com>
 <CA+kOe0_GG7TBgRieg_Re+ZrnNJyHYcC+zJymVRSBkyN78RsawA@mail.gmail.com>
 <CA+kOe0-6sA9FZtnvF0KoPRHQbyWu0hYXRqVQp_6BVZ=J2mT5vg@mail.gmail.com>
Message-ID: <CA+kOe0_uMZ_a-o2gREGHpPOiG0-uf0Zh1ChexJRqXxsJkYwguw@mail.gmail.com>

Looks good!

---

Consider changing parameter name of findVarHandle name to make it clearer
it's a field name
name => fieldName
findVarHandle(Class<?> recv, String name, Class<?> type)

I might have named these methods instanceFieldVarHandle and
staticFieldVarHandle to make it clearer there are many kinds of VarHandle
and ways of obtaining them.  But probably too late now.

---

it's => its

1921          * {@code volatile} declaration) in accordance to it's
specified
1922          * access modes.

From brent.christian at oracle.com  Thu Apr 27 19:08:03 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 27 Apr 2017 12:08:03 -0700
Subject: RFR 9 test-only RFR 8177328 :
 java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with
 -Xcomp
Message-ID: <a0d5ef17-08bb-7a4a-7679-91783c8d6a32@oracle.com>

Hi,

This test times out under our automated testing configurations that 
include -Xcomp.

Please review my change to increase the timeout for this test.  It is 
sufficient for the test configurations in question to pass on two 
different local machines (Mac & Linux).

diff -r 7c04ab31b4d6 
test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java
--- a/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java 
Wed Apr 26 09:37:23 2017 -0700
+++ b/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java 
Thu Apr 27 12:03:33 2017 -0700
@@ -29,7 +29,7 @@
   * @library /lib/testlibrary
   * @modules java.base/jdk.internal.module
   * @build JarUtils CompilerUtils
- * @run main/timeout=240 ClassLoaderTest
+ * @run main/timeout=1200 ClassLoaderTest
   */

Thanks,
-Brent

From huizhe.wang at oracle.com  Thu Apr 27 20:30:42 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 27 Apr 2017 13:30:42 -0700
Subject: RFR 9 test-only RFR 8177328 :
 java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with
 -Xcomp
In-Reply-To: <a0d5ef17-08bb-7a4a-7679-91783c8d6a32@oracle.com>
References: <a0d5ef17-08bb-7a4a-7679-91783c8d6a32@oracle.com>
Message-ID: <264d057f-2997-960b-9e50-669208f4472a@oracle.com>

+1

Joe

On 4/27/2017 12:08 PM, Brent Christian wrote:
> Hi,
>
> This test times out under our automated testing configurations that 
> include -Xcomp.
>
> Please review my change to increase the timeout for this test.  It is 
> sufficient for the test configurations in question to pass on two 
> different local machines (Mac & Linux).
>
> diff -r 7c04ab31b4d6 
> test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java
> --- a/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java 
> Wed Apr 26 09:37:23 2017 -0700
> +++ b/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java 
> Thu Apr 27 12:03:33 2017 -0700
> @@ -29,7 +29,7 @@
>   * @library /lib/testlibrary
>   * @modules java.base/jdk.internal.module
>   * @build JarUtils CompilerUtils
> - * @run main/timeout=240 ClassLoaderTest
> + * @run main/timeout=1200 ClassLoaderTest
>   */
>
> Thanks,
> -Brent


From joe.darcy at oracle.com  Thu Apr 27 21:25:04 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 27 Apr 2017 14:25:04 -0700
Subject: RFR 9 test-only RFR 8177328 :
 java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with
 -Xcomp
In-Reply-To: <a0d5ef17-08bb-7a4a-7679-91783c8d6a32@oracle.com>
References: <a0d5ef17-08bb-7a4a-7679-91783c8d6a32@oracle.com>
Message-ID: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com>

I understand the interest in having test pass reliably, but I don't 
think giving the test very large timeouts is the preferred way of 
accomplishing that.

For all configurations, the test can now run for up to 20 minutes, up 
from 4 minutes. We want to run the entire test suite, thousands of 
tests, in about 20 minutes. The the timeout factor used for Xcomp run, 
the test would probably now be able to run for over an hour before 
timing out.

I suggest making the test run faster, or seeing if there has been a 
regressions in Xcomp to make test perform more poorly there.

Thanks,

-Joe


On 4/27/2017 12:08 PM, Brent Christian wrote:
> Hi,
>
> This test times out under our automated testing configurations that 
> include -Xcomp.
>
> Please review my change to increase the timeout for this test.  It is 
> sufficient for the test configurations in question to pass on two 
> different local machines (Mac & Linux).
>
> diff -r 7c04ab31b4d6 
> test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java
> --- a/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java 
> Wed Apr 26 09:37:23 2017 -0700
> +++ b/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java 
> Thu Apr 27 12:03:33 2017 -0700
> @@ -29,7 +29,7 @@
>   * @library /lib/testlibrary
>   * @modules java.base/jdk.internal.module
>   * @build JarUtils CompilerUtils
> - * @run main/timeout=240 ClassLoaderTest
> + * @run main/timeout=1200 ClassLoaderTest
>   */
>
> Thanks,
> -Brent


From paul.sandoz at oracle.com  Thu Apr 27 21:26:50 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 27 Apr 2017 14:26:50 -0700
Subject: [JDK9] RFR 8167229: Improve VarHandle documentation
In-Reply-To: <CA+kOe0_uMZ_a-o2gREGHpPOiG0-uf0Zh1ChexJRqXxsJkYwguw@mail.gmail.com>
References: <431E7583-CA7B-4CB0-9C4C-696FC24EB5D5@oracle.com>
 <CA+kOe0_7fa4Cm1uq6+9yfQM43WRpBq=bC-gSP36cUzXZqwjz6A@mail.gmail.com>
 <CA+kOe0_GG7TBgRieg_Re+ZrnNJyHYcC+zJymVRSBkyN78RsawA@mail.gmail.com>
 <CA+kOe0-6sA9FZtnvF0KoPRHQbyWu0hYXRqVQp_6BVZ=J2mT5vg@mail.gmail.com>
 <CA+kOe0_uMZ_a-o2gREGHpPOiG0-uf0Zh1ChexJRqXxsJkYwguw@mail.gmail.com>
Message-ID: <6877AEB9-655E-4061-B14A-47C6B16E3568@oracle.com>


> On 27 Apr 2017, at 11:32, Martin Buchholz <martinrb at google.com> wrote:
> 
> Looks good!
> 

Thanks, i made the changes you propose in the previous emails.


> ---
> 
> Consider changing parameter name of findVarHandle name to make it clearer it's a field name
> name => fieldName
> findVarHandle(Class<?> recv, String name, Class<?> type)
> 

?name? is consistently used throughout, so i would prefer to keep as in and consider doing something more global if necessary. I don?t really have a strong opinion on this.


> I might have named these methods instanceFieldVarHandle and staticFieldVarHandle to make it clearer there are many kinds of VarHandle and ways of obtaining them.  But probably too late now.
> 

They are kept in sync with the method handle getter/setter equivalents.


> ---
> 
> it's => its
> 
> 1921          * {@code volatile} declaration) in accordance to it's specified
> 1922          * access modes.
> 

Done.

Pal.



From stuart.marks at oracle.com  Thu Apr 27 22:34:22 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 27 Apr 2017 15:34:22 -0700
Subject: JDK 9 RFR(m): 8150488: Scanner.findAll() can return infinite stream
 if regex matches zero chars
Message-ID: <a748f1be-8635-cb7f-e960-189197206a70@oracle.com>

Hi all,

Please review this fix [1] for JDK-8150488 [2] to prevent Scanner.findAll() from 
returning an infinite stream of zero-length matches in certain cases.

This was previously an issue that simply documented this limitation. In the 
review for that issue [3], Timo K convinced me that this behavior is actually a 
bug, and Sherman convinced me that it's worth fixing in 9 since findAll() is a 
newly introduced API. Also, thanks to Sherman for providing an initial 
implementation.

Thanks,

s'marks

[1] Webrev: http://cr.openjdk.java.net/~smarks/reviews/8150488/webrev.0/

[2] Bug: https://bugs.openjdk.java.net/browse/JDK-8150488

[3] Previous review threads:

     http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046995.html
     http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-April/047055.html

From jonathan.gibbons at oracle.com  Fri Apr 28 00:25:10 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 27 Apr 2017 17:25:10 -0700
Subject: RFR: 8179413: Fix remaining minor HTML5 issues in java.base module
Message-ID: <59028BE6.9090107@oracle.com>

Please review a handful of small changes that were not caught be the 
earlier bulk updates. Unlike those earlier updates, these few were 
determined manually.

After these minor changes, all remaining issues in java.base are related 
to the use and appearance of tables.

JBS: https://bugs.openjdk.java.net/browse/JDK-8179413
Webrev: http://cr.openjdk.java.net/~jjg/8179413/webrev/index.html

-- Jon

From lance.andersen at oracle.com  Fri Apr 28 00:34:38 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 27 Apr 2017 20:34:38 -0400
Subject: RFR: 8179413: Fix remaining minor HTML5 issues in java.base module
In-Reply-To: <59028BE6.9090107@oracle.com>
References: <59028BE6.9090107@oracle.com>
Message-ID: <0E33FF48-BC38-410D-98C3-BFE7B402B2F1@oracle.com>

+1
> On Apr 27, 2017, at 8:25 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Please review a handful of small changes that were not caught be the earlier bulk updates. Unlike those earlier updates, these few were determined manually.
> 
> After these minor changes, all remaining issues in java.base are related to the use and appearance of tables.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179413
> Webrev: http://cr.openjdk.java.net/~jjg/8179413/webrev/index.html
> 
> -- Jon

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From joe.darcy at oracle.com  Fri Apr 28 00:37:25 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 27 Apr 2017 17:37:25 -0700
Subject: RFR: 8179413: Fix remaining minor HTML5 issues in java.base module
In-Reply-To: <0E33FF48-BC38-410D-98C3-BFE7B402B2F1@oracle.com>
References: <59028BE6.9090107@oracle.com>
 <0E33FF48-BC38-410D-98C3-BFE7B402B2F1@oracle.com>
Message-ID: <59028EC5.9070504@oracle.com>

Looks fine; thanks,

-Joe

On 4/27/2017 5:34 PM, Lance Andersen wrote:
> +1
>> On Apr 27, 2017, at 8:25 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>
>> Please review a handful of small changes that were not caught be the earlier bulk updates. Unlike those earlier updates, these few were determined manually.
>>
>> After these minor changes, all remaining issues in java.base are related to the use and appearance of tables.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179413
>> Webrev: http://cr.openjdk.java.net/~jjg/8179413/webrev/index.html
>>
>> -- Jon
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>


From martinrb at google.com  Fri Apr 28 00:53:01 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 27 Apr 2017 17:53:01 -0700
Subject: RFR: 8179413: Fix remaining minor HTML5 issues in java.base module
In-Reply-To: <59028BE6.9090107@oracle.com>
References: <59028BE6.9090107@oracle.com>
Message-ID: <CA+kOe08Mi5_cpC7H_YmVBXZ9wnzL1YaJehJVntNe1ZFEAqMYYA@mail.gmail.com>

Thanks.

On Thu, Apr 27, 2017 at 5:25 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com>
>
> After these minor changes, all remaining issues in java.base are related
> to the use and appearance of tables.
>

Aside: most tables can probably be modified to do simply
<table border=1>
even if their appearance then changes slightly

From jonathan.gibbons at oracle.com  Fri Apr 28 01:10:53 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 27 Apr 2017 18:10:53 -0700
Subject: RFR: 8179413: Fix remaining minor HTML5 issues in java.base module
In-Reply-To: <CA+kOe08Mi5_cpC7H_YmVBXZ9wnzL1YaJehJVntNe1ZFEAqMYYA@mail.gmail.com>
References: <59028BE6.9090107@oracle.com>
 <CA+kOe08Mi5_cpC7H_YmVBXZ9wnzL1YaJehJVntNe1ZFEAqMYYA@mail.gmail.com>
Message-ID: <5902969D.4050207@oracle.com>



On 04/27/2017 05:53 PM, Martin Buchholz wrote:
> Thanks.
>
> On Thu, Apr 27, 2017 at 5:25 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>>
>
>     After these minor changes, all remaining issues in java.base are
>     related to the use and appearance of tables.
>
>
> Aside: most tables can probably be modified to do simply
> <table border=1>
> even if their appearance then changes slightly

Tables need to be addressed, and next up is a survey of the uses of 
tables. If we can get away with "<table border=1>" that would be nice, 
but that will default to no padding for the cells, which is ugly. We may 
need to change the stylesheet but I am wary of changing the default 
style for all tables in the main javadoc tool stylesheet.

We will investigate the options.

If anyone wants to volunteer to clean up tables (borders, summary, 
caption, padding, etc) in javadoc comments that they look after, that 
would be most helpful ;-)

-- Jon

From mandy.chung at oracle.com  Fri Apr 28 01:11:47 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 27 Apr 2017 18:11:47 -0700
Subject: RFR: 8179413: Fix remaining minor HTML5 issues in java.base module
In-Reply-To: <59028BE6.9090107@oracle.com>
References: <59028BE6.9090107@oracle.com>
Message-ID: <0647FD30-D875-4247-9997-7BF853E5CE26@oracle.com>

+1

Mandy

> On Apr 27, 2017, at 5:25 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Please review a handful of small changes that were not caught be the earlier bulk updates. Unlike those earlier updates, these few were determined manually.
> 
> After these minor changes, all remaining issues in java.base are related to the use and appearance of tables.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179413
> Webrev: http://cr.openjdk.java.net/~jjg/8179413/webrev/index.html
> 
> -- Jon


From xueming.shen at oracle.com  Fri Apr 28 04:05:17 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 27 Apr 2017 21:05:17 -0700
Subject: JDK 9 RFR(m): 8150488: Scanner.findAll() can return infinite
 stream if regex matches zero chars
In-Reply-To: <a748f1be-8635-cb7f-e960-189197206a70@oracle.com>
References: <a748f1be-8635-cb7f-e960-189197206a70@oracle.com>
Message-ID: <5902BF7D.3090804@oracle.com>

+1

On 4/27/17, 3:34 PM, Stuart Marks wrote:
> Hi all,
>
> Please review this fix [1] for JDK-8150488 [2] to prevent 
> Scanner.findAll() from returning an infinite stream of zero-length 
> matches in certain cases.
>
> This was previously an issue that simply documented this limitation. 
> In the review for that issue [3], Timo K convinced me that this 
> behavior is actually a bug, and Sherman convinced me that it's worth 
> fixing in 9 since findAll() is a newly introduced API. Also, thanks to 
> Sherman for providing an initial implementation.
>
> Thanks,
>
> s'marks
>
> [1] Webrev: http://cr.openjdk.java.net/~smarks/reviews/8150488/webrev.0/
>
> [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8150488
>
> [3] Previous review threads:
>
>     
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-March/046995.html
>     
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-April/047055.html


From ron.pressler at oracle.com  Fri Apr 28 18:05:48 2017
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 28 Apr 2017 21:05:48 +0300
Subject: JDK 9 RFR: JDK-8177146 MethodHandles.Lookup::bind allows illegal
 protected access
In-Reply-To: <8bd20999-8b9a-6dd0-5387-00ec75625781@oracle.com>
References: <5900CFC8.2010104@oracle.com>
 <8bd20999-8b9a-6dd0-5387-00ec75625781@oracle.com>
Message-ID: <5903847C.7000408@oracle.com>

Do you mean just in the class name or also the directory name?

Ron

On 26/04/2017 20:53, Vladimir Ivanov wrote:
> Ron,
>
> The fix looks good.
>
> One request: please, try to avoid bug ids in test names. It's much 
> easier to work with tests when they have meaningful names and there's 
> already @bug jtreg tag to refer to the fixed bug from the test.
>
> Best regards,
> Vladimir Ivanov
>
> On 4/26/17 7:50 PM, Ron Pressler wrote:
>> Hi.
>> Please review,
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8177146
>> Webrev:
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8177146-bind-protected-method/webrev/ 
>>
>>
>>
>> -----
>>
>> The patch contains a few changes:
>>
>> 1. The method `getDirectMethodCommon`, was changed so that if narrowing
>> due to protected method access must be done, it will be done regardless
>> of the flag doRestrict.
>>
>> 2. The private method ` getDirectMethodNoRestrict` was renamed to `
>> getDirectMethodNoRestrictInvokeSpecial`.
>>
>> 3. The method `bind` was changed to throw the correct exception type,
>> IAException.
>>
>> 4. `restrictReceiver` was changed such that it never widens the receiver
>> type. This could happen when the receiver was a subclass of the caller
>> class, and triggered the assertion (this happened not only in calls to
>> `bind` but also to `findVirtual`).
>>
>> -----
>>
>> Thanks
>> Ron
>>
>>


From joe.darcy at oracle.com  Fri Apr 28 19:18:36 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 28 Apr 2017 12:18:36 -0700
Subject: JDK 9 RFR of JDK-8179448: Mark ImageModules.java as failing
 intermittently
Message-ID: <a3cbcc38-da73-66b3-87ca-3062948cecb7@oracle.com>

Hello,

  The test

jdk/modules/incubator/ImageModules.java

has been seen to intermittently fail at a low frequency (JDK-8175022) 
and should be marked accordingly.

Please review the patch below.

Thanks,

-Joe

diff -r 7c04ab31b4d6 test/jdk/modules/incubator/ImageModules.java
--- a/test/jdk/modules/incubator/ImageModules.java    Wed Apr 26 
09:37:23 2017 -0700
+++ b/test/jdk/modules/incubator/ImageModules.java    Fri Apr 28 
12:17:08 2017 -0700
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -26,6 +26,7 @@
   * @bug 8170859
   * @summary Basic test for incubator modules in jmods and images
   * @library /lib/testlibrary
+ * @key intermittent
   * @modules jdk.compiler jdk.jartool jdk.jlink
   * @build CompilerUtils
   * @run testng/othervm ImageModules


From chris.hegarty at oracle.com  Fri Apr 28 19:24:48 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 28 Apr 2017 20:24:48 +0100
Subject: JDK 9 RFR of JDK-8179448: Mark ImageModules.java as failing
 intermittently
In-Reply-To: <a3cbcc38-da73-66b3-87ca-3062948cecb7@oracle.com>
References: <a3cbcc38-da73-66b3-87ca-3062948cecb7@oracle.com>
Message-ID: <495026FB-6D00-4125-98D2-BD89F34BE5C7@oracle.com>

Reviewed. I?ll take a look at 8175022 soon.

-Chris.

> On 28 Apr 2017, at 20:18, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> The test
> 
> jdk/modules/incubator/ImageModules.java
> 
> has been seen to intermittently fail at a low frequency (JDK-8175022) and should be marked accordingly.
> 
> Please review the patch below.
> 
> Thanks,
> 
> -Joe
> 
> diff -r 7c04ab31b4d6 test/jdk/modules/incubator/ImageModules.java
> --- a/test/jdk/modules/incubator/ImageModules.java    Wed Apr 26 09:37:23 2017 -0700
> +++ b/test/jdk/modules/incubator/ImageModules.java    Fri Apr 28 12:17:08 2017 -0700
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -26,6 +26,7 @@
>  * @bug 8170859
>  * @summary Basic test for incubator modules in jmods and images
>  * @library /lib/testlibrary
> + * @key intermittent
>  * @modules jdk.compiler jdk.jartool jdk.jlink
>  * @build CompilerUtils
>  * @run testng/othervm ImageModules
> 


From ron.pressler at oracle.com  Fri Apr 28 19:28:21 2017
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 28 Apr 2017 22:28:21 +0300
Subject: JDK 10 RFR JDK-8177153: LambdaMetafactory has default constructor
Message-ID: <590397D5.3010004@oracle.com>

Hi.
Please review this trivial fix:

-------
diff -r 83d37efcd2a5 
src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java
--- 
a/src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java 
Thu Apr 13 20:35:17 2017 +0000
+++ 
b/src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java 
Fri Apr 28 17:51:42 2017 +0000
@@ -213,7 +213,8 @@
   * methods.
   * @since 1.8
   */
-public class LambdaMetafactory {
+public final class LambdaMetafactory {
+    private LambdaMetafactory() {}

      /** Flag for alternate metafactories indicating the lambda object
       * must be serializable */
-------

Ron

From ron.pressler at oracle.com  Fri Apr 28 19:34:34 2017
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 28 Apr 2017 22:34:34 +0300
Subject: JDK 10 RFR JDK-8174267: Stream.findFirst unnecessarily always
 allocates an Op
Message-ID: <5903994A.3070307@oracle.com>

Hi.
Please review the following patch, which creates static final instances 
of FindOp.

Bug: https://bugs.openjdk.java.net/browse/JDK-8174267

I believe an additional test is not required as this is an 
implementation detail.

-------
diff -r 83d37efcd2a5 
src/java.base/share/classes/java/util/stream/FindOps.java
--- a/src/java.base/share/classes/java/util/stream/FindOps.java Thu Apr 
13 20:35:17 2017 +0000
+++ b/src/java.base/share/classes/java/util/stream/FindOps.java Fri Apr 
28 19:28:36 2017 +0000
@@ -54,9 +54,10 @@
       *        first element in the encounter order
       * @return a {@code TerminalOp} implementing the find operation
       */
+    @SuppressWarnings("unchecked")
      public static <T> TerminalOp<T, Optional<T>> makeRef(boolean 
mustFindFirst) {
-        return new FindOp<>(mustFindFirst, StreamShape.REFERENCE, 
Optional.empty(),
-                            Optional::isPresent, FindSink.OfRef::new);
+        return (TerminalOp<T, Optional<T>>)
+                (mustFindFirst ? FindSink.OfRef.OP_FIND_FIRST : 
FindSink.OfRef.OP_FIND_ANY);
      }

      /**
@@ -67,8 +68,7 @@
       * @return a {@code TerminalOp} implementing the find operation
       */
      public static TerminalOp<Integer, OptionalInt> makeInt(boolean 
mustFindFirst) {
-        return new FindOp<>(mustFindFirst, StreamShape.INT_VALUE, 
OptionalInt.empty(),
-                            OptionalInt::isPresent, FindSink.OfInt::new);
+        return mustFindFirst ? FindSink.OfInt.OP_FIND_FIRST : 
FindSink.OfInt.OP_FIND_ANY;
      }

      /**
@@ -79,8 +79,7 @@
       * @return a {@code TerminalOp} implementing the find operation
       */
      public static TerminalOp<Long, OptionalLong> makeLong(boolean 
mustFindFirst) {
-        return new FindOp<>(mustFindFirst, StreamShape.LONG_VALUE, 
OptionalLong.empty(),
-                            OptionalLong::isPresent, FindSink.OfLong::new);
+        return mustFindFirst ? FindSink.OfLong.OP_FIND_FIRST : 
FindSink.OfLong.OP_FIND_ANY;
      }

      /**
@@ -91,8 +90,7 @@
       * @return a {@code TerminalOp} implementing the find operation
       */
      public static TerminalOp<Double, OptionalDouble> 
makeDouble(boolean mustFindFirst) {
-        return new FindOp<>(mustFindFirst, StreamShape.DOUBLE_VALUE, 
OptionalDouble.empty(),
-                            OptionalDouble::isPresent, 
FindSink.OfDouble::new);
+        return mustFindFirst ? FindSink.OfDouble.OP_FIND_FIRST : 
FindSink.OfDouble.OP_FIND_ANY;
      }

      /**
@@ -195,6 +193,14 @@
              public Optional<T> get() {
                  return hasValue ? Optional.of(value) : null;
              }
+
+            static final TerminalOp<?, ?> OP_FIND_FIRST = new 
FindOp<>(true,
+                    StreamShape.REFERENCE, Optional.empty(),
+                    Optional::isPresent, FindSink.OfRef::new);
+
+            static final TerminalOp<?, ?> OP_FIND_ANY = new FindOp<>(false,
+                    StreamShape.REFERENCE, Optional.empty(),
+                    Optional::isPresent, FindSink.OfRef::new);
          }

          /** Specialization of {@code FindSink} for int streams */
@@ -210,6 +216,13 @@
              public OptionalInt get() {
                  return hasValue ? OptionalInt.of(value) : null;
              }
+
+            static final TerminalOp<Integer, OptionalInt> OP_FIND_FIRST 
= new FindOp<>(true,
+                    StreamShape.INT_VALUE, OptionalInt.empty(),
+                    OptionalInt::isPresent, FindSink.OfInt::new);
+            static final TerminalOp<Integer, OptionalInt> OP_FIND_ANY = 
new FindOp<>(false,
+                    StreamShape.INT_VALUE, OptionalInt.empty(),
+                    OptionalInt::isPresent, FindSink.OfInt::new);
          }

          /** Specialization of {@code FindSink} for long streams */
@@ -225,6 +238,13 @@
              public OptionalLong get() {
                  return hasValue ? OptionalLong.of(value) : null;
              }
+
+            static final TerminalOp<Long, OptionalLong> OP_FIND_FIRST = 
new FindOp<>(true,
+                    StreamShape.LONG_VALUE, OptionalLong.empty(),
+                    OptionalLong::isPresent, FindSink.OfLong::new);
+            static final TerminalOp<Long, OptionalLong> OP_FIND_ANY = 
new FindOp<>(false,
+                    StreamShape.LONG_VALUE, OptionalLong.empty(),
+                    OptionalLong::isPresent, FindSink.OfLong::new);
          }

          /** Specialization of {@code FindSink} for double streams */
@@ -240,6 +260,13 @@
              public OptionalDouble get() {
                  return hasValue ? OptionalDouble.of(value) : null;
              }
+
+            static final TerminalOp<Double, OptionalDouble> 
OP_FIND_FIRST = new FindOp<>(true,
+                    StreamShape.DOUBLE_VALUE, OptionalDouble.empty(),
+                    OptionalDouble::isPresent, FindSink.OfDouble::new);
+            static final TerminalOp<Double, OptionalDouble> OP_FIND_ANY 
= new FindOp<>(false,
+                    StreamShape.DOUBLE_VALUE, OptionalDouble.empty(),
+                    OptionalDouble::isPresent, FindSink.OfDouble::new);
          }
      }

-------

Ron

From brian.burkhalter at oracle.com  Fri Apr 28 19:43:06 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 28 Apr 2017 12:43:06 -0700
Subject: JDK test-only RFR of 8179452: Remove "intermittent" key from some
 tests which appear no longer to fail
Message-ID: <5DE21B40-6F5F-4739-A93C-D4295C5F56F5@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8179452
Patch:	[1]

Thanks,

Brian

[1] diff

--- a/test/java/io/FileInputStream/LargeFileAvailable.java
+++ b/test/java/io/FileInputStream/LargeFileAvailable.java
@@ -24,7 +24,6 @@
 /*
  * @test
  * @bug 6402006 7030573 8011136
- * @key intermittent
  * @summary Test if available returns correct value when reading
  *          a large file.
  * @run main/timeout=300 LargeFileAvailable

--- a/test/java/nio/channels/FileChannel/LoopingTruncate.java
+++ b/test/java/nio/channels/FileChannel/LoopingTruncate.java
@@ -24,7 +24,6 @@
 /**
  * @test
  * @bug 8137121 8137230
- * @key intermittent
  * @summary (fc) Infinite loop FileChannel.truncate
  * @library /lib/testlibrary
  * @build jdk.testlibrary.Utils

--- a/test/java/nio/channels/FileChannel/Transfer.java
+++ b/test/java/nio/channels/FileChannel/Transfer.java
@@ -23,7 +23,6 @@
 
 /* @test
  * @bug 4434723 4482726 4559072 4795550 5081340 5103988 6984545
- * @key intermittent
  * @summary Test FileChannel.transferFrom and transferTo (use -Dseed=X to set PRNG seed)
  * @library ..
  * @library /lib/testlibrary/

--- a/test/java/nio/channels/FileChannel/Transfers.java
+++ b/test/java/nio/channels/FileChannel/Transfers.java
@@ -22,7 +22,6 @@
  */
 
 /* @test
- * @key intermittent
  * @summary Comprehensive test for FileChannel.transfer{From,To}
  * @bug 4708120
  * @author Mark Reinhold


From lance.andersen at oracle.com  Fri Apr 28 19:52:11 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 28 Apr 2017 15:52:11 -0400
Subject: JDK test-only RFR of 8179452: Remove "intermittent" key from some
 tests which appear no longer to fail
In-Reply-To: <5DE21B40-6F5F-4739-A93C-D4295C5F56F5@oracle.com>
References: <5DE21B40-6F5F-4739-A93C-D4295C5F56F5@oracle.com>
Message-ID: <53A42B88-7C01-4F24-BE2D-1DE09E5B9362@oracle.com>

+1
> On Apr 28, 2017, at 3:43 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Please review at your convenience.
> 
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8179452
> Patch:	[1]
> 
> Thanks,
> 
> Brian
> 
> [1] diff
> 
> --- a/test/java/io/FileInputStream/LargeFileAvailable.java
> +++ b/test/java/io/FileInputStream/LargeFileAvailable.java
> @@ -24,7 +24,6 @@
> /*
>  * @test
>  * @bug 6402006 7030573 8011136
> - * @key intermittent
>  * @summary Test if available returns correct value when reading
>  *          a large file.
>  * @run main/timeout=300 LargeFileAvailable
> 
> --- a/test/java/nio/channels/FileChannel/LoopingTruncate.java
> +++ b/test/java/nio/channels/FileChannel/LoopingTruncate.java
> @@ -24,7 +24,6 @@
> /**
>  * @test
>  * @bug 8137121 8137230
> - * @key intermittent
>  * @summary (fc) Infinite loop FileChannel.truncate
>  * @library /lib/testlibrary
>  * @build jdk.testlibrary.Utils
> 
> --- a/test/java/nio/channels/FileChannel/Transfer.java
> +++ b/test/java/nio/channels/FileChannel/Transfer.java
> @@ -23,7 +23,6 @@
> 
> /* @test
>  * @bug 4434723 4482726 4559072 4795550 5081340 5103988 6984545
> - * @key intermittent
>  * @summary Test FileChannel.transferFrom and transferTo (use -Dseed=X to set PRNG seed)
>  * @library ..
>  * @library /lib/testlibrary/
> 
> --- a/test/java/nio/channels/FileChannel/Transfers.java
> +++ b/test/java/nio/channels/FileChannel/Transfers.java
> @@ -22,7 +22,6 @@
>  */
> 
> /* @test
> - * @key intermittent
>  * @summary Comprehensive test for FileChannel.transfer{From,To}
>  * @bug 4708120
>  * @author Mark Reinhold
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From paul.sandoz at oracle.com  Fri Apr 28 19:53:46 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 28 Apr 2017 12:53:46 -0700
Subject: JDK 10 RFR JDK-8177153: LambdaMetafactory has default constructor
In-Reply-To: <590397D5.3010004@oracle.com>
References: <590397D5.3010004@oracle.com>
Message-ID: <2C07837B-C9C8-47A1-A201-E7C8D33FF63D@oracle.com>

Hi,

This will require that we submit a CSR, when this opens up. (Sorry, i should of realised when suggesting easy bugs.)

Still, i think this change is ok, grepcode.com <http://grepcode.com/> shows no subtypes, and there are only static methods.

So i think we can pursue this once the CSR is ready.

Paul.

> On 28 Apr 2017, at 12:28, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> Hi.
> Please review this trivial fix:
> 
> -------
> diff -r 83d37efcd2a5 src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java
> --- a/src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java Thu Apr 13 20:35:17 2017 +0000
> +++ b/src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java Fri Apr 28 17:51:42 2017 +0000
> @@ -213,7 +213,8 @@
>  * methods.
>  * @since 1.8
>  */
> -public class LambdaMetafactory {
> +public final class LambdaMetafactory {
> +    private LambdaMetafactory() {}
> 
>     /** Flag for alternate metafactories indicating the lambda object
>      * must be serializable */
> -------
> 
> Ron


From joe.darcy at oracle.com  Fri Apr 28 19:55:23 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 28 Apr 2017 12:55:23 -0700
Subject: JDK test-only RFR of 8179452: Remove "intermittent" key from some
 tests which appear no longer to fail
In-Reply-To: <53A42B88-7C01-4F24-BE2D-1DE09E5B9362@oracle.com>
References: <5DE21B40-6F5F-4739-A93C-D4295C5F56F5@oracle.com>
 <53A42B88-7C01-4F24-BE2D-1DE09E5B9362@oracle.com>
Message-ID: <911cca34-4ba5-7d6a-710f-b45a91aeeeb4@oracle.com>

Looks fine to me too.

-Joe

On 4/28/2017 12:52 PM, Lance Andersen wrote:
> +1
>> On Apr 28, 2017, at 3:43 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>>
>> Please review at your convenience.
>>
>> Issue:	https://bugs.openjdk.java.net/browse/JDK-8179452
>> Patch:	[1]
>>
>> Thanks,
>>
>> Brian
>>
>> [1] diff
>>
>> --- a/test/java/io/FileInputStream/LargeFileAvailable.java
>> +++ b/test/java/io/FileInputStream/LargeFileAvailable.java
>> @@ -24,7 +24,6 @@
>> /*
>>   * @test
>>   * @bug 6402006 7030573 8011136
>> - * @key intermittent
>>   * @summary Test if available returns correct value when reading
>>   *          a large file.
>>   * @run main/timeout=300 LargeFileAvailable
>>
>> --- a/test/java/nio/channels/FileChannel/LoopingTruncate.java
>> +++ b/test/java/nio/channels/FileChannel/LoopingTruncate.java
>> @@ -24,7 +24,6 @@
>> /**
>>   * @test
>>   * @bug 8137121 8137230
>> - * @key intermittent
>>   * @summary (fc) Infinite loop FileChannel.truncate
>>   * @library /lib/testlibrary
>>   * @build jdk.testlibrary.Utils
>>
>> --- a/test/java/nio/channels/FileChannel/Transfer.java
>> +++ b/test/java/nio/channels/FileChannel/Transfer.java
>> @@ -23,7 +23,6 @@
>>
>> /* @test
>>   * @bug 4434723 4482726 4559072 4795550 5081340 5103988 6984545
>> - * @key intermittent
>>   * @summary Test FileChannel.transferFrom and transferTo (use -Dseed=X to set PRNG seed)
>>   * @library ..
>>   * @library /lib/testlibrary/
>>
>> --- a/test/java/nio/channels/FileChannel/Transfers.java
>> +++ b/test/java/nio/channels/FileChannel/Transfers.java
>> @@ -22,7 +22,6 @@
>>   */
>>
>> /* @test
>> - * @key intermittent
>>   * @summary Comprehensive test for FileChannel.transfer{From,To}
>>   * @bug 4708120
>>   * @author Mark Reinhold
>>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>   <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>


From paul.sandoz at oracle.com  Fri Apr 28 20:09:03 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 28 Apr 2017 13:09:03 -0700
Subject: JDK 10 RFR JDK-8174267: Stream.findFirst unnecessarily always
 allocates an Op
In-Reply-To: <5903994A.3070307@oracle.com>
References: <5903994A.3070307@oracle.com>
Message-ID: <940FA3E2-24FE-4FBB-A9A2-F723B30D7ACC@oracle.com>


> On 28 Apr 2017, at 12:34, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> Hi.
> Please review the following patch, which creates static final instances of FindOp.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8174267
> 

+1


> I believe an additional test is not required as this is an implementation detail.
> 

Our existing stream tests cover this.

Paul.

> -------
> diff -r 83d37efcd2a5 src/java.base/share/classes/java/util/stream/FindOps.java
> --- a/src/java.base/share/classes/java/util/stream/FindOps.java Thu Apr 13 20:35:17 2017 +0000
> +++ b/src/java.base/share/classes/java/util/stream/FindOps.java Fri Apr 28 19:28:36 2017 +0000
> @@ -54,9 +54,10 @@
>      *        first element in the encounter order
>      * @return a {@code TerminalOp} implementing the find operation
>      */
> +    @SuppressWarnings("unchecked")
>     public static <T> TerminalOp<T, Optional<T>> makeRef(boolean mustFindFirst) {
> -        return new FindOp<>(mustFindFirst, StreamShape.REFERENCE, Optional.empty(),
> -                            Optional::isPresent, FindSink.OfRef::new);
> +        return (TerminalOp<T, Optional<T>>)
> +                (mustFindFirst ? FindSink.OfRef.OP_FIND_FIRST : FindSink.OfRef.OP_FIND_ANY);
>     }
> 
>     /**
> @@ -67,8 +68,7 @@
>      * @return a {@code TerminalOp} implementing the find operation
>      */
>     public static TerminalOp<Integer, OptionalInt> makeInt(boolean mustFindFirst) {
> -        return new FindOp<>(mustFindFirst, StreamShape.INT_VALUE, OptionalInt.empty(),
> -                            OptionalInt::isPresent, FindSink.OfInt::new);
> +        return mustFindFirst ? FindSink.OfInt.OP_FIND_FIRST : FindSink.OfInt.OP_FIND_ANY;
>     }
> 
>     /**
> @@ -79,8 +79,7 @@
>      * @return a {@code TerminalOp} implementing the find operation
>      */
>     public static TerminalOp<Long, OptionalLong> makeLong(boolean mustFindFirst) {
> -        return new FindOp<>(mustFindFirst, StreamShape.LONG_VALUE, OptionalLong.empty(),
> -                            OptionalLong::isPresent, FindSink.OfLong::new);
> +        return mustFindFirst ? FindSink.OfLong.OP_FIND_FIRST : FindSink.OfLong.OP_FIND_ANY;
>     }
> 
>     /**
> @@ -91,8 +90,7 @@
>      * @return a {@code TerminalOp} implementing the find operation
>      */
>     public static TerminalOp<Double, OptionalDouble> makeDouble(boolean mustFindFirst) {
> -        return new FindOp<>(mustFindFirst, StreamShape.DOUBLE_VALUE, OptionalDouble.empty(),
> -                            OptionalDouble::isPresent, FindSink.OfDouble::new);
> +        return mustFindFirst ? FindSink.OfDouble.OP_FIND_FIRST : FindSink.OfDouble.OP_FIND_ANY;
>     }
> 
>     /**
> @@ -195,6 +193,14 @@
>             public Optional<T> get() {
>                 return hasValue ? Optional.of(value) : null;
>             }
> +
> +            static final TerminalOp<?, ?> OP_FIND_FIRST = new FindOp<>(true,
> +                    StreamShape.REFERENCE, Optional.empty(),
> +                    Optional::isPresent, FindSink.OfRef::new);
> +
> +            static final TerminalOp<?, ?> OP_FIND_ANY = new FindOp<>(false,
> +                    StreamShape.REFERENCE, Optional.empty(),
> +                    Optional::isPresent, FindSink.OfRef::new);
>         }
> 
>         /** Specialization of {@code FindSink} for int streams */
> @@ -210,6 +216,13 @@
>             public OptionalInt get() {
>                 return hasValue ? OptionalInt.of(value) : null;
>             }
> +
> +            static final TerminalOp<Integer, OptionalInt> OP_FIND_FIRST = new FindOp<>(true,
> +                    StreamShape.INT_VALUE, OptionalInt.empty(),
> +                    OptionalInt::isPresent, FindSink.OfInt::new);
> +            static final TerminalOp<Integer, OptionalInt> OP_FIND_ANY = new FindOp<>(false,
> +                    StreamShape.INT_VALUE, OptionalInt.empty(),
> +                    OptionalInt::isPresent, FindSink.OfInt::new);
>         }
> 
>         /** Specialization of {@code FindSink} for long streams */
> @@ -225,6 +238,13 @@
>             public OptionalLong get() {
>                 return hasValue ? OptionalLong.of(value) : null;
>             }
> +
> +            static final TerminalOp<Long, OptionalLong> OP_FIND_FIRST = new FindOp<>(true,
> +                    StreamShape.LONG_VALUE, OptionalLong.empty(),
> +                    OptionalLong::isPresent, FindSink.OfLong::new);
> +            static final TerminalOp<Long, OptionalLong> OP_FIND_ANY = new FindOp<>(false,
> +                    StreamShape.LONG_VALUE, OptionalLong.empty(),
> +                    OptionalLong::isPresent, FindSink.OfLong::new);
>         }
> 
>         /** Specialization of {@code FindSink} for double streams */
> @@ -240,6 +260,13 @@
>             public OptionalDouble get() {
>                 return hasValue ? OptionalDouble.of(value) : null;
>             }
> +
> +            static final TerminalOp<Double, OptionalDouble> OP_FIND_FIRST = new FindOp<>(true,
> +                    StreamShape.DOUBLE_VALUE, OptionalDouble.empty(),
> +                    OptionalDouble::isPresent, FindSink.OfDouble::new);
> +            static final TerminalOp<Double, OptionalDouble> OP_FIND_ANY = new FindOp<>(false,
> +                    StreamShape.DOUBLE_VALUE, OptionalDouble.empty(),
> +                    OptionalDouble::isPresent, FindSink.OfDouble::new);
>         }
>     }
> 
> -------
> 
> Ron


From joe.darcy at oracle.com  Fri Apr 28 21:10:16 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 28 Apr 2017 14:10:16 -0700
Subject: JDK 10 RFR JDK-8177153: LambdaMetafactory has default constructor
In-Reply-To: <2C07837B-C9C8-47A1-A201-E7C8D33FF63D@oracle.com>
References: <590397D5.3010004@oracle.com>
 <2C07837B-C9C8-47A1-A201-E7C8D33FF63D@oracle.com>
Message-ID: <dd5177cc-cc33-7021-22c5-92b5283a2256@oracle.com>

Hello,

As this is a binary incompatible change, effectively removing a public 
constructor, I'd prefer if this change got into JDK 9 instead, pending 
the review process of course.

(I've thought it would be worthwhile to audit the JDK for default 
constructors and/or add a javac lint warning for that situation, but I 
haven't done that, yet.)

Thanks,

-Joe


On 4/28/2017 12:53 PM, Paul Sandoz wrote:
> Hi,
>
> This will require that we submit a CSR, when this opens up. (Sorry, i should of realised when suggesting easy bugs.)
>
> Still, i think this change is ok, grepcode.com <http://grepcode.com/> shows no subtypes, and there are only static methods.
>
> So i think we can pursue this once the CSR is ready.
>
> Paul.
>
>> On 28 Apr 2017, at 12:28, Ron Pressler <ron.pressler at oracle.com> wrote:
>>
>> Hi.
>> Please review this trivial fix:
>>
>> -------
>> diff -r 83d37efcd2a5 src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java
>> --- a/src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java Thu Apr 13 20:35:17 2017 +0000
>> +++ b/src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java Fri Apr 28 17:51:42 2017 +0000
>> @@ -213,7 +213,8 @@
>>   * methods.
>>   * @since 1.8
>>   */
>> -public class LambdaMetafactory {
>> +public final class LambdaMetafactory {
>> +    private LambdaMetafactory() {}
>>
>>      /** Flag for alternate metafactories indicating the lambda object
>>       * must be serializable */
>> -------
>>
>> Ron


From paul.sandoz at oracle.com  Fri Apr 28 21:19:34 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 28 Apr 2017 14:19:34 -0700
Subject: JDK 10 RFR JDK-8177153: LambdaMetafactory has default constructor
In-Reply-To: <dd5177cc-cc33-7021-22c5-92b5283a2256@oracle.com>
References: <590397D5.3010004@oracle.com>
 <2C07837B-C9C8-47A1-A201-E7C8D33FF63D@oracle.com>
 <dd5177cc-cc33-7021-22c5-92b5283a2256@oracle.com>
Message-ID: <8CD3C6F7-EC79-4435-854D-79D75078FB1C@oracle.com>


> On 28 Apr 2017, at 14:10, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> As this is a binary incompatible change, effectively removing a public constructor, I'd prefer if this change got into JDK 9 instead, pending the review process of course.
> 

Fair point, the earlier the better in that regard.


> (I've thought it would be worthwhile to audit the JDK for default constructors and/or add a javac lint warning for that situation, but I haven't done that, yet.)
> 

If we used something like error prone (perhaps with integration into javac) i presume this would be rather easy to do.

Paul.


From martinrb at google.com  Fri Apr 28 21:22:42 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 28 Apr 2017 14:22:42 -0700
Subject: JDK 10 RFR JDK-8177153: LambdaMetafactory has default constructor
In-Reply-To: <8CD3C6F7-EC79-4435-854D-79D75078FB1C@oracle.com>
References: <590397D5.3010004@oracle.com>
 <2C07837B-C9C8-47A1-A201-E7C8D33FF63D@oracle.com>
 <dd5177cc-cc33-7021-22c5-92b5283a2256@oracle.com>
 <8CD3C6F7-EC79-4435-854D-79D75078FB1C@oracle.com>
Message-ID: <CA+kOe09JcOettQWKKgmd657bdKc3EjHMVDf_eHvNoeo=VNpWLA@mail.gmail.com>

http://errorprone.info/bugpattern/PrivateConstructorForUtilityClass

On Fri, Apr 28, 2017 at 2:19 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> > On 28 Apr 2017, at 14:10, joe darcy <joe.darcy at oracle.com> wrote:
> >
> > Hello,
> >
> > As this is a binary incompatible change, effectively removing a public
> constructor, I'd prefer if this change got into JDK 9 instead, pending the
> review process of course.
> >
>
> Fair point, the earlier the better in that regard.
>
>
> > (I've thought it would be worthwhile to audit the JDK for default
> constructors and/or add a javac lint warning for that situation, but I
> haven't done that, yet.)
> >
>
> If we used something like error prone (perhaps with integration into
> javac) i presume this would be rather easy to do.
>
> Paul.
>
>

From alex.buckley at oracle.com  Fri Apr 28 21:55:57 2017
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 28 Apr 2017 14:55:57 -0700
Subject: [JDK9] RFR 8167229: Improve VarHandle documentation
In-Reply-To: <431E7583-CA7B-4CB0-9C4C-696FC24EB5D5@oracle.com>
References: <431E7583-CA7B-4CB0-9C4C-696FC24EB5D5@oracle.com>
Message-ID: <5903BA6D.8020805@oracle.com>

On 4/26/2017 4:06 PM, Paul Sandoz wrote:
> Please review some documentation changes to VarHandle:
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8167229-varhandle-docs/webrev/index.html

I notice that "shape" is still mentioned throughout the 
MethodHandles.Lookup class.

59  * {@code CT1, CT2, ..., CTn}, the types of <em>coordinate 
expressions</em> that
60  * uniquely locate a variable referenced by this VarHandle.

I'm unsure of "uniquely locate". Distinct coordinate expressions can 
refer to the same object, due to aliasing. And there is nothing said 
later about one VarHandle being the exclusive systemwide locator of a 
variable. Do you mean "that _jointly_ locate a variable ..." ?

73  * instance, the initial arguments to the invocation are coordinate 
expressions
74  * that indicate precisely which variable is to be accessed.

"that indicate _in precisely which object_ the variable is to be 
accessed." ?

BTW Since "array elements" are mentioned in the opening paragraph, and 
since here is an example involving String[] as a coordinate type later, 
it would be nice to say how a VarHandle pointing to an array element can 
be created.

209  * <h1>Compilation of an access mode's method</h1>

First, the term "access mode's method" appears only here and in 
accessModeType, but I think you mean "mode" not "mode's".

Second, this section isn't about compilation of the method. Access mode 
methods are not native and there is nothing to suggest that a suitably 
skilled platform developer can't write one in Java and compile it -- yet 
this section will not tell them how to compile it. (I appreciate the 
style comes from j.l.i.MethodHandle, and it would be better to avoid 
speaking of "Method handle compilation" there.) I recommend "Invoking 
access mode methods from source code" and "Invoking access mode methods 
from bytecode". Or "Compiling invocation of access mode methods" and 
"Performing invocation of access mode methods".

Alex

From paul.sandoz at oracle.com  Fri Apr 28 22:39:43 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 28 Apr 2017 15:39:43 -0700
Subject: [JDK9] RFR 8167229: Improve VarHandle documentation
In-Reply-To: <5903BA6D.8020805@oracle.com>
References: <431E7583-CA7B-4CB0-9C4C-696FC24EB5D5@oracle.com>
 <5903BA6D.8020805@oracle.com>
Message-ID: <0E92A3A1-F696-4615-81E7-85BD344D644A@oracle.com>


> On 28 Apr 2017, at 14:55, Alex Buckley <alex.buckley at Oracle.COM> wrote:
> 
> On 4/26/2017 4:06 PM, Paul Sandoz wrote:
>> Please review some documentation changes to VarHandle:
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8167229-varhandle-docs/webrev/index.html
> 
> I notice that "shape" is still mentioned throughout the MethodHandles.Lookup class.
> 

Are you looking at the old version? I removed ?em all from the new version.


> 59  * {@code CT1, CT2, ..., CTn}, the types of <em>coordinate expressions</em> that
> 60  * uniquely locate a variable referenced by this VarHandle.
> 
> I'm unsure of "uniquely locate". Distinct coordinate expressions can refer to the same object, due to aliasing. And there is nothing said later about one VarHandle being the exclusive systemwide locator of a variable. Do you mean "that _jointly_ locate a variable ??

Ok, good point, it should be unique within the confines of a VarHandle instance, but could be aliased by another VarHandle instance or something else.


> ?
> 

> 73  * instance, the initial arguments to the invocation are coordinate expressions
> 74  * that indicate precisely which variable is to be accessed.
> 
> "that indicate _in precisely which object_ the variable is to be accessed.?

Ok.


> ?
> 

> BTW Since "array elements" are mentioned in the opening paragraph, and since here is an example involving String[] as a coordinate type later, it would be nice to say how a VarHandle pointing to an array element can be created.
> 

Ok.


> 209  * <h1>Compilation of an access mode's method</h1>
> 
> First, the term "access mode's method" appears only here and in accessModeType, but I think you mean "mode" not "mode's?.
> 

Yes, i updated all relevant places.


> Second, this section isn't about compilation of the method. Access mode methods are not native and there is nothing to suggest that a suitably skilled platform developer can't write one in Java and compile it -- yet this section will not tell them how to compile it. (I appreciate the style comes from j.l.i.MethodHandle, and it would be better to avoid speaking of "Method handle compilation" there.) I recommend "Invoking access mode methods from source code" and "Invoking access mode methods from bytecode". Or "Compiling invocation of access mode methods" and "Performing invocation of access mode methods?.

I opted for the later.

Below is a diff on the webrev.

Thanks,
Paul.

diff -r 64fdd70fe45c src/java.base/share/classes/java/lang/invoke/VarHandle.java
--- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java	Fri Apr 28 15:03:01 2017 -0700
+++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java	Fri Apr 28 15:36:04 2017 -0700
@@ -57,7 +57,7 @@
  * by this VarHandle; and
  * <li>a list of {@link #coordinateTypes coordinate types}
  * {@code CT1, CT2, ..., CTn}, the types of <em>coordinate expressions</em> that
- * uniquely locate a variable referenced by this VarHandle.
+ * jointly locate a variable referenced by this VarHandle.
  * </ul>
  * Variable and coordinate types may be primitive or reference, and are
  * represented by {@code Class} objects.  The list of coordinate types may be
@@ -71,11 +71,11 @@
  * <a href="MethodHandle.html#sigpoly">signature polymorphic</a> method named
  * for the access mode.  When an access mode method is invoked on a VarHandle
  * instance, the initial arguments to the invocation are coordinate expressions
- * that indicate precisely which variable is to be accessed.  Trailing arguments
- * to the invocation represent values of importance to the access mode.  For
- * example, the various compare-and-set or compare-and-exchange access modes
- * require two trailing arguments for the variable's expected value and new
- * value.
+ * that indicate in precisely which object the variable is to be accessed.
+ * Trailing arguments to the invocation represent values of importance to the
+ * access mode.  For example, the various compare-and-set or compare-and-exchange
+ * access modes require two trailing arguments for the variable's expected value
+ * and new value.
  *
  * <p>The arity and types of arguments to the invocation of an access mode
  * method are not checked statically.  Instead, each access mode method
@@ -101,6 +101,14 @@
  * is {@code String}.  The access mode type for {@code compareAndSet} on this
  * VarHandle instance would be
  * {@code (String[] c1, int c2, String expectedValue, String newValue)boolean}.
+ * Such a VarHandle instance may produced by the
+ * {@link MethodHandles#arrayElementVarHandle(Class) array factory method} and
+ * access array elements as follows:
+ * <pre> {@code
+ * String[] sa = ...
+ * VarHandle avh = MethodHandles.arrayElementVarHandle(String[].class);
+ * avh.compareAndSet(sa, 10, "expected", "new");
+ * }</pre>
  *
  * <p>Access modes are grouped into the following categories:
  * <ul>
@@ -206,7 +214,7 @@
  * precise phrasing of the specification of access mode methods and memory fence
  * methods may accompany future updates of the Java Language Specification.
  *
- * <h1>Compilation of an access mode's method</h1>
+ * <h1>Compiling invocation of access mode methods</h1>
  * A Java method call expression naming an access mode method can invoke a
  * VarHandle from Java source code.  From the viewpoint of source code, these
  * methods can take any arguments and their polymorphic result (if expressed)
@@ -238,7 +246,7 @@
  * except the null reference.
  *
  *
- * <h1><a name="invoke">Invocation of an access mode's method</a></h1>
+ * <h1><a name="invoke">Performing invocation of access mode methods</a></h1>
  * The first time an {@code invokevirtual} instruction is executed it is linked
  * by symbolically resolving the names in the instruction and verifying that
  * the method call is statically legal.  This also holds for calls to access mode
@@ -255,11 +263,11 @@
  * invoking is not present on the individual VarHandle being invoked.
  *
  * <p>
- * Invocation of an access mode's signature-polymorphic method behaves as if an
- * invocation of {@link MethodHandle#invoke}, where the receiving method handle
- * accepts the VarHandle instance as the leading argument.  More specifically,
- * the following, where {@code {access-mode}} corresponds to the access mode
- * method name:
+ * Invocation of an access mode method behaves as if an invocation of
+ * {@link MethodHandle#invoke}, where the receiving method handle accepts the
+ * VarHandle instance as the leading argument.  More specifically, the
+ * following, where {@code {access-mode}} corresponds to the access mode method
+ * name:
  * <pre> {@code
  * VarHandle vh = ..
  * R r = (R) vh.{access-mode}(p1, p2, ..., pN);
@@ -1856,14 +1864,13 @@
     }

     /**
-     * Obtains the canonical access mode type for this VarHandle and a given
-     * access mode.
+     * Obtains the access mode type for this VarHandle and a given access mode.
      *
      * <p>The access mode type's parameter types will consist of a prefix that
      * is the coordinate types of this VarHandle followed by further
-     * types as defined by the access mode's method.
+     * types as defined by the access mode method.
      * The access mode type's return type is defined by the return type of the
-     * access mode's method.
+     * access mode method.
      *
      * @param accessMode the access mode, corresponding to the
      * signature-polymorphic method of the same name
@@ -1886,7 +1893,7 @@
      *
      * <p>The return of a {@code false} value for a given access mode indicates
      * that an {@code UnsupportedOperationException} is thrown on invocation
-     * of the corresponding access mode's signature-polymorphic method.
+     * of the corresponding access mode method.
      *
      * @param accessMode the access mode, corresponding to the
      * signature-polymorphic method of the same name



From alex.buckley at oracle.com  Fri Apr 28 22:47:42 2017
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 28 Apr 2017 15:47:42 -0700
Subject: [JDK9] RFR 8167229: Improve VarHandle documentation
In-Reply-To: <0E92A3A1-F696-4615-81E7-85BD344D644A@oracle.com>
References: <431E7583-CA7B-4CB0-9C4C-696FC24EB5D5@oracle.com>
 <5903BA6D.8020805@oracle.com>
 <0E92A3A1-F696-4615-81E7-85BD344D644A@oracle.com>
Message-ID: <5903C68E.6000904@oracle.com>

On 4/28/2017 3:39 PM, Paul Sandoz wrote:
>> On 28 Apr 2017, at 14:55, Alex Buckley <alex.buckley at Oracle.COM> wrote:
>>
>> On 4/26/2017 4:06 PM, Paul Sandoz wrote:
>>> Please review some documentation changes to VarHandle:
>>>
>>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8167229-varhandle-docs/webrev/index.html
>>
>> I notice that "shape" is still mentioned throughout the MethodHandles.Lookup class.
>>
>
> Are you looking at the old version? I removed ?em all from the new version.

Ah sorry, I forgot to look at Lookup within the MethodHandles.java 
webrev. All looks good.

>> BTW Since "array elements" are mentioned in the opening paragraph, and since here is an example involving String[] as a coordinate type later, it would be nice to say how a VarHandle pointing to an array element can be created.
>
> Ok.

This is a nice and surprisingly compact example.

Alex

From kumar.x.srinivasan at oracle.com  Fri Apr 28 23:16:19 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 28 Apr 2017 16:16:19 -0700
Subject: RFR: 8179415: Update java.management and java.management.rmi to be
 HTML-5 friendly
Message-ID: <5903CD43.3030402@oracle.com>

Hello,

Please review changes for java.management and java.management.rmi to
be HTML5 ready, there are outliers like cellpadding, cellspacing that needs
to be done separately, note this was *not* done mechanically by a script.

http://cr.openjdk.java.net/~ksrini/8179415/
https://bugs.openjdk.java.net/browse/JDK-8179415

Thanks
Kumar




From mandy.chung at oracle.com  Fri Apr 28 23:39:28 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 28 Apr 2017 16:39:28 -0700
Subject: RFR: 8179415: Update java.management and java.management.rmi to
 be HTML-5 friendly
In-Reply-To: <5903CD43.3030402@oracle.com>
References: <5903CD43.3030402@oracle.com>
Message-ID: <6C740129-09DF-4E41-ABEB-57DD5F2D9C0F@oracle.com>


> On Apr 28, 2017, at 4:16 PM, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
> 
> Hello,
> 
> Please review changes for java.management and java.management.rmi to
> be HTML5 ready, there are outliers like cellpadding, cellspacing that needs
> to be done separately, note this was *not* done mechanically by a script.
> 
> http://cr.openjdk.java.net/~ksrini/8179415/
> https://bugs.openjdk.java.net/browse/JDK-8179415

Looks fine to me.
Mandy


From martinrb at google.com  Sat Apr 29 04:51:29 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 28 Apr 2017 21:51:29 -0700
Subject: JDK 10 RFR JDK-8177153: LambdaMetafactory has default constructor
In-Reply-To: <CA+kOe09JcOettQWKKgmd657bdKc3EjHMVDf_eHvNoeo=VNpWLA@mail.gmail.com>
References: <590397D5.3010004@oracle.com>
 <2C07837B-C9C8-47A1-A201-E7C8D33FF63D@oracle.com>
 <dd5177cc-cc33-7021-22c5-92b5283a2256@oracle.com>
 <8CD3C6F7-EC79-4435-854D-79D75078FB1C@oracle.com>
 <CA+kOe09JcOettQWKKgmd657bdKc3EjHMVDf_eHvNoeo=VNpWLA@mail.gmail.com>
Message-ID: <CA+kOe08G7jgx2mBnJwMUTyb2h30ivG1zT-tiG20AFFD5Sn027g@mail.gmail.com>

[cc'ing some errorprone folk ...]

On Fri, Apr 28, 2017 at 2:22 PM, Martin Buchholz <martinrb at google.com>
wrote:

> http://errorprone.info/bugpattern/PrivateConstructorForUtilityClass
>

It's highly non-obvious how to run errorprone against recent jdk sources.
You need a prerelease of errorprone, add a module to get javax.annotation,
and add a bunch of flags to allow access to javac internals.  The script
below finds 430 PrivateConstructorForUtilityClass warnings in openjdk10:

#!/bin/bash
declare -r JDK9="$HOME/jdk/jdk9"
declare -r JDK_SRC="$HOME/ws/jdk10"
declare -r BUG_PATTERN="PrivateConstructorForUtilityClass"
declare -r ERRORPRONE_JAR_URL="
https://oss.sonatype.org/content/repositories/snapshots/com/google/errorprone/error_prone_ant/2.0.20-SNAPSHOT/error_prone_ant-2.0.20-20170428.043038-14.jar
"

set -eu
declare -r ERRORPRONE_JAR="/tmp/${0##*/}.jar"
declare -r LOGFILE="/tmp/${0##*/}.log"
declare -ar JAVA_FLAGS_JAVAC=(
  -Xms64M -Xmx1600M -XX:ThreadStackSize=1536
  --add-modules=java.xml.ws.annotation
  --add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
  --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
  --add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED
  --add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED
  --add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED
  --add-exports=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED
  --add-exports=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED
)
declare -ar JAVAC_WARNINGS=(
  -Xmaxwarns 999999
  -processorpath "$ERRORPRONE_JAR"
  "'-Xplugin:ErrorProne -XepDisableAllChecks -Xep:${BUG_PATTERN}:WARN'"
)
(
  cd "$JDK_SRC"
  wget -qO"$ERRORPRONE_JAR" "$ERRORPRONE_JAR_URL"
  bash ./configure --with-boot-jdk="$JDK9" --disable-sjavac
--disable-javac-server
  make clean
  make \
    JAVA_FLAGS_JAVAC="${JAVA_FLAGS_JAVAC[*]}" \
    JAVAC_WARNINGS="${JAVAC_WARNINGS[*]}" \
    images
) |& tee "$LOGFILE" | grep -A1 "warning:..${BUG_PATTERN}"

From martinrb at google.com  Sun Apr 30 02:47:55 2017
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 29 Apr 2017 19:47:55 -0700
Subject: Accessing module internals from bytecode rewriting agent
In-Reply-To: <cd84f05f-42d6-a2b6-166d-8638f9e2f0bc@redhat.com>
References: <CA+kOe09dgq+HERCtFFecG2Jguixg0j_FP-0duWOrZrdK15W6KQ@mail.gmail.com>
 <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com>
 <cd84f05f-42d6-a2b6-166d-8638f9e2f0bc@redhat.com>
Message-ID: <CA+kOe0_VBmUNgAqVWORdgULgCLwny9n6E3QDxAqSpaqOONokKw@mail.gmail.com>

Thanks, all.  I should have remembered the special casing of
java.util.concurrent in checkUnprivilegedlookupClass.  It's surprising to
see different behavior crossing the java.util.concurrent boundary, as I
observed trying to access PriorityQueue.queue (fails!) vs.
PriorityBlockingQueue.queue (succeeds!).  Tools such as java agents should
have a single consistent mechanism that works for all target classes.

On Tue, Apr 25, 2017 at 1:19 AM, Andrew Dinn <adinn at redhat.com> wrote:

> On 25/04/17 07:22, Alan Bateman wrote:
> > On 25/04/2017 04:26, Martin Buchholz wrote:
> >
> >> :
> >>
> >> java.lang.IllegalArgumentException: illegal lookupClass: class
> >> java.util.PriorityQueue
> >>
> >> Bytecode rewriting agents have the power to inject code into classes;
> >> they
> >> should somehow also be able to reflectively inspect those same classes!
> >> But how?  We ran into similar problems trying to port java agents at
> >> Google
> >> to jdk9.
> > <snip>
> > On Byteman, Andrew Dinn has been working with us on jigsaw-dev on the
> > agent support. From the stack trace then I suspect the issue you are
> > running into is that Byteman has also changed to use the new reflection
> > API (java.lang.invoke) and is running into a long standing check to
> > prevent full power lookups to full privileged classes from leaking.
> > Andrew brought this up on jigsaw-dev [1] a few days ago and we could
> > probably move that thread to core-libs-dev.
>
> This discussion really ought to be happening on the Byteman forum but
> anyway ...
>
> Yes, Alan is right that this is exactly what is going on. Byteman on
> jdk9 (the 4.0.0-BETA release series) now uses method handles in place of
> reflection. Unfortunately, it is limited by a slightly arbitrary
> restriction on the use of method handles in java.* and sun.* packages (a
> blunt instrument to provide some security guarantees).
>
> This is being addressed on two fronts. I am in the process of adding
> unit tests to complete a workaround which remedies this problem by
> falling back to reflection in the specific cases where the restriction
> applies (yes, that means there is probably going to be another
> 4.0.0-BETA release before jdk9 goes live %-/ ).
>
> Meanwhile, Mandy Chung has kindly offered to look into the security
> considerations that are at play and come up with a less restrictive
> policy which enforces the security needs more accurately. At that point
> I will probably remove the fallback -- in part because I hope that by
> then both reflection and method handles will employ a common blacklist
> of inaccessible methods. I think it would make sense for them both to
> offer equivalent access and for that access to take security seriously.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>