From claes.redestad at oracle.com  Mon Jan  2 11:25:16 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 2 Jan 2017 12:25:16 +0100
Subject: RFR: 8172048: Re-examine use of AtomicReference in
	java.security.Policy
In-Reply-To: <978ff508-a07f-9778-efde-52d19d1f31d2@gmail.com>
References: <a69399a5-7138-4fdd-234e-6a241a020a4f@oracle.com>
	<978ff508-a07f-9778-efde-52d19d1f31d2@gmail.com>
Message-ID: <be59fd9a-1822-3cb6-09ad-373919f6e98a@oracle.com>

<dropped security-libs>

Hi Peter,

agreed, it appears this assert could be replaced by a test - similar to 
what was already
done for VarHandle.AccessMode[1] - which might increase robustness of 
early use of
VarHandles and give our core reflection libraries the freedom to use 
VarHandles.

Paul?

/Claes

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

On 12/28/2016 01:07 AM, Peter Levart wrote:
> Hi Claes,
>
> A nice find! This is certainly a straightforward and low-risk fix for 
> breaking the initialization cycle problem with JDK-8062389.
>
> Related to VarHandles, the call trace of the initialization cycle also 
> includes the following part of code in VarHandle:
>
>
>         AccessMode(final String methodName, AccessType at) {
>             this.methodName = methodName;
>             this.at = at;
>
>             // Assert that return type is correct
>             // Otherwise, when disabled avoid using reflection
>             assert at.returnType == getReturnType(methodName);
>         }
>
> ...
>
>         private static Class<?> getReturnType(String name) {
>             try {
>                 Method m = VarHandle.class.getMethod(name, 
> Object[].class);
>                 return m.getReturnType();
>             }
>             catch (Exception e) {
>                 throw newInternalError(e);
>             }
>         }
>
>
> ... where enabling assertions (tests enable assertions) causes the 
> initialization of VarHandle(s) to involve reflection. This is also a 
> place that could be made more robust, perhaps by devising a special 
> test that verifies method return types, instead of embedding the check 
> into the AccessMode constructor...
>
> Regards, Peter
>
>
> On 12/27/2016 03:04 PM, Claes Redestad wrote:
>> Hi,
>>
>> since java.util.concurrent.AtomicReference was changed to use a
>> VarHandle internally, using it from within the security libraries can
>> lead to hard to diagnose bootstrap cycles (since VarHandles has to do
>> doPrivileged calls during setup). The need to initialize VarHandles is
>> also cause for a small startup regression for any application run with
>> a security manager.
>>
>> The use of AtomicReference in java.security.Policy is not really
>> motivated, though, since only the .get/.set methods are used, thus a
>> rather straight-forward fix is to convert the code to use a volatile
>> reference instead with identical semantics:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172048
>> Webrev: http://cr.openjdk.java.net/~redestad/8172048/webrev.01/
>>
>> While a rather insignificant startup improvement in and off itself,
>> this would help to unblock the attempted fix to resolve
>> https://bugs.openjdk.java.net/browse/JDK-8062389
>>
>> Thanks!
>>
>> /Claes
>


From claes.redestad at oracle.com  Mon Jan  2 11:45:01 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 2 Jan 2017 12:45:01 +0100
Subject: RFR: 8172048: Re-examine use of AtomicReference in
	java.security.Policy
In-Reply-To: <f203f1f3-496b-4759-e854-5015b4642ae8@oracle.com>
References: <a69399a5-7138-4fdd-234e-6a241a020a4f@oracle.com>
	<016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com>
	<d4e603c0-b518-027d-8293-aed627a2a369@oracle.com>
	<f203f1f3-496b-4759-e854-5015b4642ae8@oracle.com>
Message-ID: <52141bb3-2bde-8871-6d71-d62434d5d024@oracle.com>

On 12/31/2016 12:45 AM, David Holmes wrote:
> I'll let you think about it so more. I'll be back in the office on 
> Tuesday :)

After giving it some thought I think it's better to just document the need
for some hygiene in the field declaration:

http://cr.openjdk.java.net/~redestad/8172048/webrev.02

Thanks!

/Claes

From chris.hegarty at oracle.com  Mon Jan  2 17:02:17 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 2 Jan 2017 17:02:17 +0000
Subject: RFR: 8172048: Re-examine use of AtomicReference in
	java.security.Policy
In-Reply-To: <52141bb3-2bde-8871-6d71-d62434d5d024@oracle.com>
References: <a69399a5-7138-4fdd-234e-6a241a020a4f@oracle.com>
	<016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com>
	<d4e603c0-b518-027d-8293-aed627a2a369@oracle.com>
	<f203f1f3-496b-4759-e854-5015b4642ae8@oracle.com>
	<52141bb3-2bde-8871-6d71-d62434d5d024@oracle.com>
Message-ID: <4FD22BA4-B420-49C7-B5DF-2BD414029A5A@oracle.com>


> On 2 Jan 2017, at 11:45, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> On 12/31/2016 12:45 AM, David Holmes wrote:
>> I'll let you think about it so more. I'll be back in the office on Tuesday :)
> 
> After giving it some thought I think it's better to just document the need
> for some hygiene in the field declaration:
> 
> http://cr.openjdk.java.net/~redestad/8172048/webrev.02

Looks good Claes.

Minor suggestion: "For correctness COMMA care must ?"

-Chris.

From claes.redestad at oracle.com  Mon Jan  2 17:49:02 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 2 Jan 2017 18:49:02 +0100
Subject: RFR: 8172048: Re-examine use of AtomicReference in
	java.security.Policy
In-Reply-To: <4FD22BA4-B420-49C7-B5DF-2BD414029A5A@oracle.com>
References: <a69399a5-7138-4fdd-234e-6a241a020a4f@oracle.com>
	<016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com>
	<d4e603c0-b518-027d-8293-aed627a2a369@oracle.com>
	<f203f1f3-496b-4759-e854-5015b4642ae8@oracle.com>
	<52141bb3-2bde-8871-6d71-d62434d5d024@oracle.com>
	<4FD22BA4-B420-49C7-B5DF-2BD414029A5A@oracle.com>
Message-ID: <1d875de3-6b32-4333-e3dc-09719b30402a@oracle.com>



On 2017-01-02 18:02, Chris Hegarty wrote:
>
>> On 2 Jan 2017, at 11:45, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> On 12/31/2016 12:45 AM, David Holmes wrote:
>>> I'll let you think about it so more. I'll be back in the office on Tuesday :)
>>
>> After giving it some thought I think it's better to just document the need
>> for some hygiene in the field declaration:
>>
>> http://cr.openjdk.java.net/~redestad/8172048/webrev.02
>
> Looks good Claes.

Thanks, Chris!

>
> Minor suggestion: "For correctness COMMA care must ?"

Done. I won't bother to generate a new webrev for this, though. :-)

/Claes

From david.holmes at oracle.com  Mon Jan  2 23:46:45 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Jan 2017 09:46:45 +1000
Subject: RFR: 8172048: Re-examine use of AtomicReference in
	java.security.Policy
In-Reply-To: <52141bb3-2bde-8871-6d71-d62434d5d024@oracle.com>
References: <a69399a5-7138-4fdd-234e-6a241a020a4f@oracle.com>
	<016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com>
	<d4e603c0-b518-027d-8293-aed627a2a369@oracle.com>
	<f203f1f3-496b-4759-e854-5015b4642ae8@oracle.com>
	<52141bb3-2bde-8871-6d71-d62434d5d024@oracle.com>
Message-ID: <0824397d-63f8-0f00-55f5-585edbbc2400@oracle.com>

On 2/01/2017 9:45 PM, Claes Redestad wrote:
> On 12/31/2016 12:45 AM, David Holmes wrote:
>> I'll let you think about it so more. I'll be back in the office on
>> Tuesday :)
>
> After giving it some thought I think it's better to just document the need
> for some hygiene in the field declaration:
>
> http://cr.openjdk.java.net/~redestad/8172048/webrev.02

Looks fine to me!

Thanks,
David

> Thanks!
>
> /Claes

From weijun.wang at oracle.com  Tue Jan  3 03:40:10 2017
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 3 Jan 2017 11:40:10 +0800
Subject: RFR 8170900: Issue with FilePermission::implies for wildcard
	flag(-)
In-Reply-To: <934B4B33-22F8-49A7-BEEE-3CCFEEA4760E@oracle.com>
References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com>
	<171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com>
	<4eb90509-4c28-a3d6-b0c1-f127973bd45a@Oracle.com>
	<934B4B33-22F8-49A7-BEEE-3CCFEEA4760E@oracle.com>
Message-ID: <4B743F06-6FEE-47B5-AA45-47D8D8BEC536@oracle.com>

Ping again.

> On Dec 22, 2016, at 8:23 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
> Hi Roger
> 
>> On Dec 20, 2016, at 11:49 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> 
>> Hi Max,
>> 
>> Comments:
>> 
>> - Is there a better term/phrase to use other than "foo"; it does not appear elsewhere in the @implNote.
> 
> It appears in the spec of this method:
> 
> * <li> <i>p</i>'s pathname is implied by this object's
> *      pathname. For example, "/tmp/*" implies "/tmp/foo", since
> *      "/tmp/*" encompasses all files in the "/tmp" directory,
> *      including the one named "foo".
> 
>>  The use of "cpath" and "npath" implies that someone is reading the source code.
> 
> Not really. They also appears in the @implNote of the spec of FilePermission::<init>(String,String):
> 
> * If the value of the system property is set to {@code true}, {@code path}
> * is canonicalized and stored as a String object named {@code cpath}.
> * This means a relative path is converted to an absolute path, a Windows
> * DOS-style 8.3 path is expanded to a long path, and a symbolic link is
> * resolved to its target, etc.
> * <P>
> * If the value of the system property is set to {@code false}, {@code path}
> * is converted to a {@link java.nio.file.Path} object named {@code npath}
> * after {@link Path#normalize() normalization}. No canonicalization is
> * performed which means the underlying file system is not accessed.
> * If an {@link InvalidPathException} is thrown during the conversion,
> * this {@code FilePermission} will be labeled as invalid.
> 
> I think using the same name in all @implNote is more precise.
> 
>>  The description of the behavior of the implementation should use the same terminology as the spec.
>> 
>> - The use of "Note" weakens the text as specification language.  It can be omitted.
> 
> OK.
> 
> I'll use take Xuelei's advice to expand this line to
> 
>  This means "/-" implies "/foo" but not "foo".
> 
>> 
>> - To make the source version more readable, I would keep each statement on its own line.
> 
> OK.
> 
> Thanks
> Max
> 
>> 
>>   Note that this means "/-" does not imply "foo".
>>   An invalid {@code FilePermission} does not imply any object except for itself.
>> 
>> Thanks, Roger
>> 
>> On 12/20/2016 2:25 AM, Wang Weijun wrote:
>>> Ping again.
>>> 
>>>> On Dec 14, 2016, at 1:53 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
>>>> 
>>>> An clarification is added to FilePermission::implies:
>>>> 
>>>>     * @implNote
>>>>       ....
>>>>     * a simple {@code npath} is recursively inside a wildcard {@code npath}
>>>>     * if and only if {@code simple_npath.relativize(wildcard_npath)}
>>>> -     * is a series of one or more "..". An invalid {@code FilePermission} does
>>>> +     * is a series of one or more "..". Note that this means "/-" does not
>>>> +     * imply "foo". An invalid {@code FilePermission} does
>>>>     * not imply any object except for itself.
>>>> 
>>>> The newly added sentence is
>>>> 
>>>> Note that this means "/-" does not imply "foo".
>>>> 
>>>> JCK has agreed to update their test.
>>>> 
>>>> Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm.
>>>> 
>>>> Thanks
>>>> Max
>>>> 
>> 
> 


From sean.coffey at oracle.com  Tue Jan  3 08:30:39 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 3 Jan 2017 08:30:39 +0000
Subject: Does jvisualvm work in JDK 9?
In-Reply-To: <005601d2617c$c62a8500$527f8f00$@oracle.com>
References: <003001d260c5$816772f0$843658d0$@oracle.com>
	<6d658448-6d59-4e44-d0d3-c84a2734fcdf@gmail.com>
	<005601d2617c$c62a8500$527f8f00$@oracle.com>
Message-ID: <92b64c0c-7150-dc24-341c-5120c6af40d9@oracle.com>

I don't believe jvisualvm will ship bundled with JDK 9 and is due for 
removal. Probably best to download the latest visualvm binaries from the 
VisualVM project website.

See https://blogs.oracle.com/java-platform-group/entry/visual_vm_in_jdk_9

regards,
Sean.

On 29/12/2016 02:39, Frank Yuan wrote:
> Hi Dmitry
>
> Thank you very much for your help!
>
> Unluckily visualvm doesn't work for 147 and 150 as well, I have to give up using this tool in current stage...
>
>
> Frank
>
>
>> -----Original Message-----
>> From: Dmitry Buzdin [mailto:buzdin at gmail.com]
>> Sent: Wednesday, December 28, 2016 4:57 PM
>> To: Frank Yuan; code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
>> Subject: Re: Does jvisualvm work in JDK 9?
>>
>> Hi,
>>
>> I had a similar problem on Mac. Downloaded the latest version of
>> VisualVM (https://visualvm.github.io/) and it did work.
>>
>> It seems that the version bundled with JDK 9 is out of date.
>>
>> Dmitry
>>
>>
>> On 28/12/16 06:47, Frank Yuan wrote:
>>> Hi all
>>>
>>>
>>>
>>> I tried to run jvisualvm in Linux with both b147 and b150(by adding add-opens option), it always quit quietly after showing a
> splash
>>> screen. Does it still work?
>>>
>>>
>>>
>>>
>>>
>>> Thanks
>>>
>>> Frank
>>>
>


From frank.yuan at oracle.com  Tue Jan  3 08:44:39 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 3 Jan 2017 16:44:39 +0800
Subject: Does jvisualvm work in JDK 9?
In-Reply-To: <92b64c0c-7150-dc24-341c-5120c6af40d9@oracle.com>
References: <003001d260c5$816772f0$843658d0$@oracle.com>
	<6d658448-6d59-4e44-d0d3-c84a2734fcdf@gmail.com>
	<005601d2617c$c62a8500$527f8f00$@oracle.com>
	<92b64c0c-7150-dc24-341c-5120c6af40d9@oracle.com>
Message-ID: <00b701d2659d$a122a9c0$e367fd40$@oracle.com>

Thank you for tne clarification!

Frank

> -----Original Message-----
> From: Se?n Coffey [mailto:sean.coffey at oracle.com]
> Subject: Re: Does jvisualvm work in JDK 9?
> 
> I don't believe jvisualvm will ship bundled with JDK 9 and is due for
> removal. Probably best to download the latest visualvm binaries from the
> VisualVM project website.
> 
> See https://blogs.oracle.com/java-platform-group/entry/visual_vm_in_jdk_9
> 
> regards,
> Sean.
> 
> On 29/12/2016 02:39, Frank Yuan wrote:
> > Hi Dmitry
> >
> > Thank you very much for your help!
> >
> > Unluckily visualvm doesn't work for 147 and 150 as well, I have to give up using this tool in current stage...
> >
> >
> > Frank
> >
> >
> >> -----Original Message-----
> >> From: Dmitry Buzdin [mailto:buzdin at gmail.com]
> >> Sent: Wednesday, December 28, 2016 4:57 PM
> >> To: Frank Yuan; code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> >> Subject: Re: Does jvisualvm work in JDK 9?
> >>
> >> Hi,
> >>
> >> I had a similar problem on Mac. Downloaded the latest version of
> >> VisualVM (https://visualvm.github.io/) and it did work.
> >>
> >> It seems that the version bundled with JDK 9 is out of date.
> >>
> >> Dmitry
> >>
> >>
> >> On 28/12/16 06:47, Frank Yuan wrote:
> >>> Hi all
> >>>
> >>>
> >>>
> >>> I tried to run jvisualvm in Linux with both b147 and b150(by adding add-opens option), it always quit quietly after showing a
> > splash
> >>> screen. Does it still work?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Thanks
> >>>
> >>> Frank
> >>>
> >



From chris.hegarty at oracle.com  Tue Jan  3 11:25:13 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 3 Jan 2017 11:25:13 +0000
Subject: RFR: 8071566 Improve testing for multi-version JAR file maker tool
In-Reply-To: <12CA06E6-0BCE-4A10-90CD-4968ED1B6FC5@oracle.com>
References: <12CA06E6-0BCE-4A10-90CD-4968ED1B6FC5@oracle.com>
Message-ID: <47195B93-30EA-41B0-AEDE-C88111979003@oracle.com>

Andrey,

> On 30 Dec 2016, at 14:11, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
> 
> Hi,
> 
> Following tests for Jar tool were added:
> 
> Tests for API validator. Jar tool should detect API changes between releases. 
> Test for custom manifest file. 
> Test for version format in --release option 
> 
> Also refactoring of existing tests was made:
> 1. Common base class ?MRTestBase.java? was extracted. 
> 2. Result and process builders were substituted by existing library classes jdk/test/lib/process/*
> 
> Please review.
> 
> Review: http://cr.openjdk.java.net/~anazarov/8071566/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8071566 <https://bugs.openjdk.java.net/browse/JDK-8071566>

I think the changes are generally ok. A few comments:

1) The webrev shows ApiValidatorTest.java  (was test/tools/jar/multiRelease/Basic.java).
    I assume ApiValidatorTest.java is just a new file, and not Basic.java copied.
    These files should have no relationship in mercurial.

2) Style. The existing style is a little confused to me.
    Please check line length, <= 80 chars where possible
    Align dots ( fluid method invocations ) where possible
    Align method arguments where possible, and makes sense

3) Where deleting files/directories, please use FileUtils from the test library.

-Chris.

From claes.redestad at oracle.com  Tue Jan  3 14:46:53 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 3 Jan 2017 15:46:53 +0100
Subject: RFR: 8170785: Excessive allocation in ParseUtil.encodePath
Message-ID: <7ae2434a-da5b-ec52-c4cc-0dc8631c6eb1@oracle.com>

Hi,

some users reports high allocation rates in ParseUtil.encodePath,
regardless of whether paths actually need to be encoded or not.
Since this is a commonly used utility it makes sense.

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

This patch provides a semantically neutral fast-path for cases when
the path does not need to be encoded (up to 5x speedup), reduces
allocation when the string has a prefix that does not need to be
encoded (1-2x speedup) and no regression when using a separator
that's not '/' or the first char needs encoding.

Interpreted performance is not affected much either: small positive
when no encoding is needed, neutral or negligible regression
otherwise.

Thanks!

/Claes

From peter.levart at gmail.com  Tue Jan  3 16:52:35 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 3 Jan 2017 17:52:35 +0100
Subject: RFR 8172190: Re-apply the fix for bugs 8062389, 8029459, 8061950
In-Reply-To: <7a95546d-4b5b-190b-46db-3a6f3168eece@gmail.com>
References: <C13D1340-C38B-4B6A-B80A-DA5A5CEC1891@oracle.com>
	<ac24d255-09a6-7c29-37f3-eeaf2139f100@gmail.com>
	<221ca324-be41-9c74-89be-606e31ae93d3@gmail.com>
	<98DA94D5-F43B-491C-8DE7-EE2FF030920B@oracle.com>
	<47940b37-b09c-0888-d031-beefe9f5bcab@oracle.com>
	<09F19C0B-B0D8-4FF2-BD53-080EAAEA8974@oracle.com>
	<ef0bd907-1805-f306-e89c-95ec1e3acfff@oracle.com>
	<7a95546d-4b5b-190b-46db-3a6f3168eece@gmail.com>
Message-ID: <0a5e77dd-3b3d-0231-138f-8b03699eeea1@gmail.com>

Hi,

Now that initialization cycle has been broken by Claes' fix for:

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

I prepared a revised fix for issues described in the following bugs:

     https://bugs.openjdk.java.net/browse/JDK-8062389
     https://bugs.openjdk.java.net/browse/JDK-8029459
     https://bugs.openjdk.java.net/browse/JDK-8061950

...now tracked by bug:

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

The revised webrev is here:

http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.10/

The incremental change from webrev.09 is the following:

http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.09to10/


Besides fixing one failing test (StarInheritance) that now has to 
account for new behavior of Class.getMethods(), some tests also failed 
because of the changed behavior (not throwing NPE) when passing null 
'name' parameter to Class.get[Declared][Method|Field] methods. This was 
a straight bug introduced by me and caught by tests which I haven't 
re-run after introducing it. I apologize for that and promise to be more 
careful in the future. In original code the NPE was thrown by private 
Class.searchFields and searchMethods in the part of code where the 
'name' parameter was interned. I replaced interning and reference 
comparison with equality comparison, which is faster and does not trash 
the String interning cache with names that are later not found as 
members of classes, but I forgot to introduce explicit nonNull check for 
the 'name' argument.

I now intentionally inserted the nonNull checks in front of the security 
checks in public-facing methods although this introduces a little 
behavioral change. I choose that because:

- The javadocs list NullPointerException before the SecurityException 
(for example in getField):

      * @throws NullPointerException if {@code name} is {@code null}
      * @throws SecurityException
      *         If a security manager, <i>s</i>, is present and
      *         the caller's class loader is not the same as or an
      *         ancestor of the class loader for the current class and
      *         invocation of {@link SecurityManager#checkPackageAccess
      *         s.checkPackageAccess()} denies access to the package
      *         of this class.

- I think it is more correct for methods to 1st check parameters before 
throwing any other state related exceptions.

But if you think this behavioral change is not justified, I can reverse 
the order of checks and prepare new webrev.

I have successfully executed java/lang tests and all tier 1 tests that 
failed when webrev.09 was pushed, mentioned in:

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


But don't take my word for it. Can someone please run webrev.10 through 
the tests on Oracle side before confirming the change?


Thanks,

Peter Levart


On 12/26/2016 07:31 PM, Peter Levart wrote:
> Hi,
>
> I see there remaining failures are not trivial to fix in a hurry. So I 
> think it's better to just backout this change and than prepare new fix...
>
> I'm pushing this backout now.
>
> Regards, Peter
>
>
> On 12/26/2016 06:55 PM, Claes Redestad wrote:
>> Hi,
>>
>> many of the tier 1 failures listed seems to fail due to a cyclic
>> bootstrap dependency on the new PublicMethods -> Policy.isSet() ->
>> ... -> PublicMethods that appears in all tests which install a
>> security manager.
>>
>> It turns out the dependency is only there (Policy.isSet) to ensure the
>> VM has booted to a state where System.getProperty will return actual
>> values to feed into sun.security.util.Debug (the state of which does
>> not in any way vary with Policy), and could be replaced by the new
>> VM.isBooted() (or VM.initLevel() > 1):
>>
>> http://cr.openjdk.java.net/~redestad/scratch/8171988.01/
>>
>> With this most test failures disappear, but there are still 5 tests
>> in java/lang/Class which fail with a message more directly related to
>> the changes:
>>
>> expected java.lang.NullPointerException for null -- FAILED
>>
>> Perhaps problem list these 5 together with the above change as a fix to
>> this issue?
>>
>> Thanks!
>>
>> /Claes
>>
>> On 2016-12-26 18:30, Chris Hegarty wrote:
>>>
>>>> On 26 Dec 2016, at 16:26, joe darcy <joe.darcy at oracle.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> Assuming we'll want to revisit this work at some point, there are 
>>>> some advantages to anti-delta-ing the code changes now, but just 
>>>> problem listing the tests in terms of making a less confusing history.
>>>
>>> My preference is to anti-delta. There are just too many tests 
>>> failing, ~35 across all platforms and tiers.
>>>
>>> Peter,
>>>   Let me know if you need any help pushing this.
>>>
>>> -Chris.
>>>
>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>>
>>>> On 12/26/2016 1:58 AM, Chris Hegarty wrote:
>>>>>> On 26 Dec 2016, at 09:35, Peter Levart <peter.levart at gmail.com> 
>>>>>> wrote:
>>>>>>
>>>>>> Hi Jeff,
>>>>>>
>>>>>> I've been told that the latest change I pushed causes some tests 
>>>>>> to fail, so I prepared a backout patch for 8062389, 8029459, 
>>>>>> 8061950:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/ 
>>>>>> <http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/> 
>>>>>>
>>>>> I just grabbed the webrev patch, applied it to a local repo, then
>>>>> compared that against a repo that had been updated to the
>>>>> change prior to your push. They are identical, so this appears
>>>>> to be an accurate anti-delta.
>>>>>
>>>>> Maybe file a new bug, or just make it clear in the synopsis of
>>>>> 8171988 that it is an anti-delta.
>>>>>
>>>>>
>>>>>> From the stacktrace of the bug report, it seems an early 
>>>>>> initialization issue with VarHandle(s) involved. Can you shed 
>>>>>> some light into what tests are failing?
>>>>> I?ll post a few comments in 8171988 with sample failures.
>>>>>
>>>>> -Chris.
>>>>>
>>>>>> But first let us backout that change.
>>>>>>
>>>>>> Regards, Peter
>>>>>>
>>>>>>> On 12/26/2016 10:09 AM, Peter Levart wrote:
>>>>>>> Hi Jeff,
>>>>>>>
>>>>>>> I'm taking a look at this...
>>>>>>>
>>>>>>> Regards, Peter
>>>>>>>
>>>>>>>> On 12/26/2016 06:14 AM, Jeff Dinkins wrote:
>>>>>>>> Hi Peter -
>>>>>>>>
>>>>>>>> I just received mail from out SQE manager, saying that your 
>>>>>>>> last changeset has caused our test harness to hiccup.  I don?t 
>>>>>>>> have much more detail besides the below bug, but I?m wondering 
>>>>>>>> if you could do us a huge favor and roll your change back for 
>>>>>>>> now while it?s debugged (and so we can get our automated tests 
>>>>>>>> going again).
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171988 
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8171988>
>>>>>>>>
>>>>>>>> thanks!
>>>>>>>>
>>>>>>>> -jeff
>>>>>>>>
>>>>
>>>
>


From claes.redestad at oracle.com  Tue Jan  3 17:15:40 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 3 Jan 2017 18:15:40 +0100
Subject: RFR 8172190: Re-apply the fix for bugs 8062389, 8029459, 8061950
In-Reply-To: <0a5e77dd-3b3d-0231-138f-8b03699eeea1@gmail.com>
References: <C13D1340-C38B-4B6A-B80A-DA5A5CEC1891@oracle.com>
	<ac24d255-09a6-7c29-37f3-eeaf2139f100@gmail.com>
	<221ca324-be41-9c74-89be-606e31ae93d3@gmail.com>
	<98DA94D5-F43B-491C-8DE7-EE2FF030920B@oracle.com>
	<47940b37-b09c-0888-d031-beefe9f5bcab@oracle.com>
	<09F19C0B-B0D8-4FF2-BD53-080EAAEA8974@oracle.com>
	<ef0bd907-1805-f306-e89c-95ec1e3acfff@oracle.com>
	<7a95546d-4b5b-190b-46db-3a6f3168eece@gmail.com>
	<0a5e77dd-3b3d-0231-138f-8b03699eeea1@gmail.com>
Message-ID: <43c44b23-2026-e5c6-5ea8-f926a605966f@oracle.com>

Hi Peter,

letting you know I've submitted a build and test job for this to run 
over night.

Thanks!

/Claes

On 01/03/2017 05:52 PM, Peter Levart wrote:
> Hi,
>
> Now that initialization cycle has been broken by Claes' fix for:
>
>      https://bugs.openjdk.java.net/browse/JDK-8172048
>
> I prepared a revised fix for issues described in the following bugs:
>
>     https://bugs.openjdk.java.net/browse/JDK-8062389
>     https://bugs.openjdk.java.net/browse/JDK-8029459
>     https://bugs.openjdk.java.net/browse/JDK-8061950
>
> ...now tracked by bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-8172190
>
> The revised webrev is here:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.10/ 
>
>
> The incremental change from webrev.09 is the following:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.09to10/ 
>
>
>
> Besides fixing one failing test (StarInheritance) that now has to 
> account for new behavior of Class.getMethods(), some tests also failed 
> because of the changed behavior (not throwing NPE) when passing null 
> 'name' parameter to Class.get[Declared][Method|Field] methods. This 
> was a straight bug introduced by me and caught by tests which I 
> haven't re-run after introducing it. I apologize for that and promise 
> to be more careful in the future. In original code the NPE was thrown 
> by private Class.searchFields and searchMethods in the part of code 
> where the 'name' parameter was interned. I replaced interning and 
> reference comparison with equality comparison, which is faster and 
> does not trash the String interning cache with names that are later 
> not found as members of classes, but I forgot to introduce explicit 
> nonNull check for the 'name' argument.
>
> I now intentionally inserted the nonNull checks in front of the 
> security checks in public-facing methods although this introduces a 
> little behavioral change. I choose that because:
>
> - The javadocs list NullPointerException before the SecurityException 
> (for example in getField):
>
>      * @throws NullPointerException if {@code name} is {@code null}
>      * @throws SecurityException
>      *         If a security manager, <i>s</i>, is present and
>      *         the caller's class loader is not the same as or an
>      *         ancestor of the class loader for the current class and
>      *         invocation of {@link SecurityManager#checkPackageAccess
>      *         s.checkPackageAccess()} denies access to the package
>      *         of this class.
>
> - I think it is more correct for methods to 1st check parameters 
> before throwing any other state related exceptions.
>
> But if you think this behavioral change is not justified, I can 
> reverse the order of checks and prepare new webrev.
>
> I have successfully executed java/lang tests and all tier 1 tests that 
> failed when webrev.09 was pushed, mentioned in:
>
>     https://bugs.openjdk.java.net/browse/JDK-8171988
>
>
> But don't take my word for it. Can someone please run webrev.10 
> through the tests on Oracle side before confirming the change?
>
>
> Thanks,
>
> Peter Levart
>
>
> On 12/26/2016 07:31 PM, Peter Levart wrote:
>> Hi,
>>
>> I see there remaining failures are not trivial to fix in a hurry. So 
>> I think it's better to just backout this change and than prepare new 
>> fix...
>>
>> I'm pushing this backout now.
>>
>> Regards, Peter
>>
>>
>> On 12/26/2016 06:55 PM, Claes Redestad wrote:
>>> Hi,
>>>
>>> many of the tier 1 failures listed seems to fail due to a cyclic
>>> bootstrap dependency on the new PublicMethods -> Policy.isSet() ->
>>> ... -> PublicMethods that appears in all tests which install a
>>> security manager.
>>>
>>> It turns out the dependency is only there (Policy.isSet) to ensure the
>>> VM has booted to a state where System.getProperty will return actual
>>> values to feed into sun.security.util.Debug (the state of which does
>>> not in any way vary with Policy), and could be replaced by the new
>>> VM.isBooted() (or VM.initLevel() > 1):
>>>
>>> http://cr.openjdk.java.net/~redestad/scratch/8171988.01/
>>>
>>> With this most test failures disappear, but there are still 5 tests
>>> in java/lang/Class which fail with a message more directly related to
>>> the changes:
>>>
>>> expected java.lang.NullPointerException for null -- FAILED
>>>
>>> Perhaps problem list these 5 together with the above change as a fix to
>>> this issue?
>>>
>>> Thanks!
>>>
>>> /Claes
>>>
>>> On 2016-12-26 18:30, Chris Hegarty wrote:
>>>>
>>>>> On 26 Dec 2016, at 16:26, joe darcy <joe.darcy at oracle.com> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Assuming we'll want to revisit this work at some point, there are 
>>>>> some advantages to anti-delta-ing the code changes now, but just 
>>>>> problem listing the tests in terms of making a less confusing 
>>>>> history.
>>>>
>>>> My preference is to anti-delta. There are just too many tests 
>>>> failing, ~35 across all platforms and tiers.
>>>>
>>>> Peter,
>>>>   Let me know if you need any help pushing this.
>>>>
>>>> -Chris.
>>>>
>>>>
>>>>> Thanks,
>>>>>
>>>>> -Joe
>>>>>
>>>>>
>>>>> On 12/26/2016 1:58 AM, Chris Hegarty wrote:
>>>>>>> On 26 Dec 2016, at 09:35, Peter Levart <peter.levart at gmail.com> 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Jeff,
>>>>>>>
>>>>>>> I've been told that the latest change I pushed causes some tests 
>>>>>>> to fail, so I prepared a backout patch for 8062389, 8029459, 
>>>>>>> 8061950:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/ 
>>>>>>> <http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/> 
>>>>>>>
>>>>>> I just grabbed the webrev patch, applied it to a local repo, then
>>>>>> compared that against a repo that had been updated to the
>>>>>> change prior to your push. They are identical, so this appears
>>>>>> to be an accurate anti-delta.
>>>>>>
>>>>>> Maybe file a new bug, or just make it clear in the synopsis of
>>>>>> 8171988 that it is an anti-delta.
>>>>>>
>>>>>>
>>>>>>> From the stacktrace of the bug report, it seems an early 
>>>>>>> initialization issue with VarHandle(s) involved. Can you shed 
>>>>>>> some light into what tests are failing?
>>>>>> I?ll post a few comments in 8171988 with sample failures.
>>>>>>
>>>>>> -Chris.
>>>>>>
>>>>>>> But first let us backout that change.
>>>>>>>
>>>>>>> Regards, Peter
>>>>>>>
>>>>>>>> On 12/26/2016 10:09 AM, Peter Levart wrote:
>>>>>>>> Hi Jeff,
>>>>>>>>
>>>>>>>> I'm taking a look at this...
>>>>>>>>
>>>>>>>> Regards, Peter
>>>>>>>>
>>>>>>>>> On 12/26/2016 06:14 AM, Jeff Dinkins wrote:
>>>>>>>>> Hi Peter -
>>>>>>>>>
>>>>>>>>> I just received mail from out SQE manager, saying that your 
>>>>>>>>> last changeset has caused our test harness to hiccup.  I don?t 
>>>>>>>>> have much more detail besides the below bug, but I?m wondering 
>>>>>>>>> if you could do us a huge favor and roll your change back for 
>>>>>>>>> now while it?s debugged (and so we can get our automated tests 
>>>>>>>>> going again).
>>>>>>>>>
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171988 
>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8171988>
>>>>>>>>>
>>>>>>>>> thanks!
>>>>>>>>>
>>>>>>>>> -jeff
>>>>>>>>>
>>>>>
>>>>
>>
>


From paul.sandoz at oracle.com  Tue Jan  3 18:18:44 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Jan 2017 10:18:44 -0800
Subject: RFR: 8172048: Re-examine use of AtomicReference in
	java.security.Policy
In-Reply-To: <be59fd9a-1822-3cb6-09ad-373919f6e98a@oracle.com>
References: <a69399a5-7138-4fdd-234e-6a241a020a4f@oracle.com>
	<978ff508-a07f-9778-efde-52d19d1f31d2@gmail.com>
	<be59fd9a-1822-3cb6-09ad-373919f6e98a@oracle.com>
Message-ID: <2A05F1BB-35FD-4713-A61A-AA89C6D45FB4@oracle.com>


> On 2 Jan 2017, at 03:25, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> <dropped security-libs>
> 
> Hi Peter,
> 
> agreed, it appears this assert could be replaced by a test - similar to what was already
> done for VarHandle.AccessMode[1] - which might increase robustness of early use of
> VarHandles and give our core reflection libraries the freedom to use VarHandles.
> 
> Paul?
> 

Agreed, i?ll replace the assert with a test:

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

Paul.

> /Claes
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8160439
> 


From Roger.Riggs at Oracle.com  Tue Jan  3 18:23:25 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 3 Jan 2017 13:23:25 -0500
Subject: RFR 8170900: Issue with FilePermission::implies for wildcard
	flag(-)
In-Reply-To: <4B743F06-6FEE-47B5-AA45-47D8D8BEC536@oracle.com>
References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com>
	<171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com>
	<4eb90509-4c28-a3d6-b0c1-f127973bd45a@Oracle.com>
	<934B4B33-22F8-49A7-BEEE-3CCFEEA4760E@oracle.com>
	<4B743F06-6FEE-47B5-AA45-47D8D8BEC536@oracle.com>
Message-ID: <843981be-dcf8-7dd4-3ef2-adeffc8fca8d@Oracle.com>

Hi Max,

Sorry for the delay.
Since this not part of the specification of the behavior I'm ok with the 
informal descriptions.

Roger


On 1/2/2017 10:40 PM, Wang Weijun wrote:
> Ping again.
>
>> On Dec 22, 2016, at 8:23 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
>>
>> Hi Roger
>>
>>> On Dec 20, 2016, at 11:49 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>
>>> Hi Max,
>>>
>>> Comments:
>>>
>>> - Is there a better term/phrase to use other than "foo"; it does not appear elsewhere in the @implNote.
>> It appears in the spec of this method:
>>
>> * <li> <i>p</i>'s pathname is implied by this object's
>> *      pathname. For example, "/tmp/*" implies "/tmp/foo", since
>> *      "/tmp/*" encompasses all files in the "/tmp" directory,
>> *      including the one named "foo".
>>
>>>   The use of "cpath" and "npath" implies that someone is reading the source code.
>> Not really. They also appears in the @implNote of the spec of FilePermission::<init>(String,String):
>>
>> * If the value of the system property is set to {@code true}, {@code path}
>> * is canonicalized and stored as a String object named {@code cpath}.
>> * This means a relative path is converted to an absolute path, a Windows
>> * DOS-style 8.3 path is expanded to a long path, and a symbolic link is
>> * resolved to its target, etc.
>> * <P>
>> * If the value of the system property is set to {@code false}, {@code path}
>> * is converted to a {@link java.nio.file.Path} object named {@code npath}
>> * after {@link Path#normalize() normalization}. No canonicalization is
>> * performed which means the underlying file system is not accessed.
>> * If an {@link InvalidPathException} is thrown during the conversion,
>> * this {@code FilePermission} will be labeled as invalid.
>>
>> I think using the same name in all @implNote is more precise.
>>
>>>   The description of the behavior of the implementation should use the same terminology as the spec.
>>>
>>> - The use of "Note" weakens the text as specification language.  It can be omitted.
>> OK.
>>
>> I'll use take Xuelei's advice to expand this line to
>>
>>   This means "/-" implies "/foo" but not "foo".
>>
>>> - To make the source version more readable, I would keep each statement on its own line.
>> OK.
>>
>> Thanks
>> Max
>>
>>>    Note that this means "/-" does not imply "foo".
>>>    An invalid {@code FilePermission} does not imply any object except for itself.
>>>
>>> Thanks, Roger
>>>
>>> On 12/20/2016 2:25 AM, Wang Weijun wrote:
>>>> Ping again.
>>>>
>>>>> On Dec 14, 2016, at 1:53 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
>>>>>
>>>>> An clarification is added to FilePermission::implies:
>>>>>
>>>>>      * @implNote
>>>>>        ....
>>>>>      * a simple {@code npath} is recursively inside a wildcard {@code npath}
>>>>>      * if and only if {@code simple_npath.relativize(wildcard_npath)}
>>>>> -     * is a series of one or more "..". An invalid {@code FilePermission} does
>>>>> +     * is a series of one or more "..". Note that this means "/-" does not
>>>>> +     * imply "foo". An invalid {@code FilePermission} does
>>>>>      * not imply any object except for itself.
>>>>>
>>>>> The newly added sentence is
>>>>>
>>>>> Note that this means "/-" does not imply "foo".
>>>>>
>>>>> JCK has agreed to update their test.
>>>>>
>>>>> Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm.
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>


From mandy.chung at oracle.com  Tue Jan  3 21:03:56 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 3 Jan 2017 13:03:56 -0800
Subject: Review Request: jdeps --require and --check should detect the
	specified module in the image
Message-ID: <05B30791-D3EB-4D90-AD7F-CD1CE919D50B@oracle.com>

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172212/webrev.00/

This is a simple patch that fixes jdeps in analyzing modules linked in the image. It fixes the following commands which are currently not working properly.

$ jdeps -I -?require jdk.compiler
$ jdeps -?check jdk.compiler

This patch changes not to require classes or ?-add-modules be specified, if it?s a module in the image.  This patch also fixes when ?-list-deps is used with -m and prints the result if the source is a named module.

Mandy

From Roger.Riggs at Oracle.com  Tue Jan  3 21:22:08 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 3 Jan 2017 16:22:08 -0500
Subject: RFR: 8170785: Excessive allocation in ParseUtil.encodePath
In-Reply-To: <7ae2434a-da5b-ec52-c4cc-0dc8631c6eb1@oracle.com>
References: <7ae2434a-da5b-ec52-c4cc-0dc8631c6eb1@oracle.com>
Message-ID: <aec49ffa-5b02-02e2-b304-668569860ff0@Oracle.com>

Hi Claes,

So Windows didn't suffer from having the '\' separator.

ParseUtil:

firstEncodeIndex:121:
   'a' - 'z' seems more frequent than '/' or '.'; does it improve the 
stats to move that range to the beginning of the if.
   (yes the compiler can re-order).

line 125:
     Since 127 is known to need encoding it could be >= 0x007f

line  136: I suppose the arraycopy intrinsic already optimizes length == 0;

Line 134:  I question the math on  * 2 + 16 -index;  (But this is 
pre-existing code)
    if there were lots of characters that needed encoding it might be 
possible to overflow the array since 1 char is replaced by at least 3 
and up to 9.
    16 seems like a questionable fudge factor; but perhaps it has not 
been a problem in practice.

$.02, Roger



On 1/3/2017 9:46 AM, Claes Redestad wrote:
> Hi,
>
> some users reports high allocation rates in ParseUtil.encodePath,
> regardless of whether paths actually need to be encoded or not.
> Since this is a commonly used utility it makes sense.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8170785/webrev.01
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170785
>
> This patch provides a semantically neutral fast-path for cases when
> the path does not need to be encoded (up to 5x speedup), reduces
> allocation when the string has a prefix that does not need to be
> encoded (1-2x speedup) and no regression when using a separator
> that's not '/' or the first char needs encoding.
>
> Interpreted performance is not affected much either: small positive
> when no encoding is needed, neutral or negligible regression
> otherwise.
>
> Thanks!
>
> /Claes


From paul.sandoz at oracle.com  Tue Jan  3 22:21:53 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Jan 2017 14:21:53 -0800
Subject: Review Request: jdeps --require and --check should detect the
	specified module in the image
In-Reply-To: <05B30791-D3EB-4D90-AD7F-CD1CE919D50B@oracle.com>
References: <05B30791-D3EB-4D90-AD7F-CD1CE919D50B@oracle.com>
Message-ID: <14662205-919F-4755-906A-5FDEF987E516@oracle.com>

Hi,

Minor stuff:

JdepsTask
?

 845         private Comparator<Deque<Archive>> comparator() {
 846             Function<Deque<Archive>, String> name = deque -> deque.peekFirst().getName();
 847             ToIntFunction<Deque<Archive>> length = Deque::size;
 848
 849             return Comparator.comparing(name)
 850                              .thenComparingInt(length)
 851                              .thenComparing(this::toInversePath);
 852         }

If you like you can use a type witness, effectively the same declaration as for the function above:

return Comparator.<Deque<Archive>, String>
  comparing(deque -> deque.peekFirst().getName())
  .thenComparingInt(Deque::size)
  .thenComparing(this::toInversePath);


ModuleTest
?

 153         System.err.println("Test: " + data.name());

Code dropping?


 154         // jdeps --module-path <modulepath> -m root paths
 155         String cmd = String.format("jdeps --module-path %s --add-modules %s %s%n",
 156             MODS_DIR, roots.stream().collect(Collectors.joining(",")),
 157             Arrays.toString(paths));

Is the use of Arrays.toString correct here?

Paul.

> On 3 Jan 2017, at 13:03, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172212/webrev.00/
> 
> This is a simple patch that fixes jdeps in analyzing modules linked in the image. It fixes the following commands which are currently not working properly.
> 
> $ jdeps -I -?require jdk.compiler
> $ jdeps -?check jdk.compiler
> 
> This patch changes not to require classes or ?-add-modules be specified, if it?s a module in the image.  This patch also fixes when ?-list-deps is used with -m and prints the result if the source is a named module.
> 
> Mandy


From mandy.chung at oracle.com  Tue Jan  3 22:45:51 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 3 Jan 2017 14:45:51 -0800
Subject: Review Request: jdeps --require and --check should detect the
	specified module in the image
In-Reply-To: <14662205-919F-4755-906A-5FDEF987E516@oracle.com>
References: <05B30791-D3EB-4D90-AD7F-CD1CE919D50B@oracle.com>
	<14662205-919F-4755-906A-5FDEF987E516@oracle.com>
Message-ID: <8AD80F03-BDC6-4D69-AC87-7CF19219C679@oracle.com>


> On Jan 3, 2017, at 2:21 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Minor stuff:
> 
> JdepsTask
> ?
> 
> 845         private Comparator<Deque<Archive>> comparator() {
> 846             Function<Deque<Archive>, String> name = deque -> deque.peekFirst().getName();
> 847             ToIntFunction<Deque<Archive>> length = Deque::size;
> 848
> 849             return Comparator.comparing(name)
> 850                              .thenComparingInt(length)
> 851                              .thenComparing(this::toInversePath);
> 852         }
> 
> If you like you can use a type witness, effectively the same declaration as for the function above:
> 
> return Comparator.<Deque<Archive>, String>
>  comparing(deque -> deque.peekFirst().getName())
>  .thenComparingInt(Deque::size)
>  .thenComparing(this::toInversePath);
> 

I like this. Thanks for the suggestion.
> 
> ModuleTest
> ?
> 
> 153         System.err.println("Test: " + data.name());
> 
> Code dropping?

Left-over debugging code.  Removed.

> 
> 
> 154         // jdeps --module-path <modulepath> -m root paths
> 155         String cmd = String.format("jdeps --module-path %s --add-modules %s %s%n",
> 156             MODS_DIR, roots.stream().collect(Collectors.joining(",")),
> 157             Arrays.toString(paths));
> 
> Is the use of Arrays.toString correct here?
> 

Hmm..  why the test is passing with ?[]? in the command line?  I will check that out.  In any case, no need to modify this file.  I have reverted it.

Mandy

> Paul.
> 
>> On 3 Jan 2017, at 13:03, Mandy Chung <mandy.chung at oracle.com> wrote:
>> 
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172212/webrev.00/
>> 
>> This is a simple patch that fixes jdeps in analyzing modules linked in the image. It fixes the following commands which are currently not working properly.
>> 
>> $ jdeps -I -?require jdk.compiler
>> $ jdeps -?check jdk.compiler
>> 
>> This patch changes not to require classes or ?-add-modules be specified, if it?s a module in the image.  This patch also fixes when ?-list-deps is used with -m and prints the result if the source is a named module.
>> 
>> Mandy
> 


From lance.andersen at oracle.com  Tue Jan  3 22:50:57 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 3 Jan 2017 17:50:57 -0500
Subject: Review Request: jdeps --require and --check should detect the
	specified module in the image
In-Reply-To: <8AD80F03-BDC6-4D69-AC87-7CF19219C679@oracle.com>
References: <05B30791-D3EB-4D90-AD7F-CD1CE919D50B@oracle.com>
	<14662205-919F-4755-906A-5FDEF987E516@oracle.com>
	<8AD80F03-BDC6-4D69-AC87-7CF19219C679@oracle.com>
Message-ID: <AC25C9C9-0962-446A-91E5-B2A138900773@oracle.com>

Hi Mandy

I saw the revised webrev.01 and it looks fine


> On Jan 3, 2017, at 5:45 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
>> 
>> On Jan 3, 2017, at 2:21 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>> Hi,
>> 
>> Minor stuff:
>> 
>> JdepsTask
>> ?
>> 
>> 845         private Comparator<Deque<Archive>> comparator() {
>> 846             Function<Deque<Archive>, String> name = deque -> deque.peekFirst().getName();
>> 847             ToIntFunction<Deque<Archive>> length = Deque::size;
>> 848
>> 849             return Comparator.comparing(name)
>> 850                              .thenComparingInt(length)
>> 851                              .thenComparing(this::toInversePath);
>> 852         }
>> 
>> If you like you can use a type witness, effectively the same declaration as for the function above:
>> 
>> return Comparator.<Deque<Archive>, String>
>> comparing(deque -> deque.peekFirst().getName())
>> .thenComparingInt(Deque::size)
>> .thenComparing(this::toInversePath);
>> 
> 
> I like this. Thanks for the suggestion.
>> 
>> ModuleTest
>> ?
>> 
>> 153         System.err.println("Test: " + data.name());
>> 
>> Code dropping?
> 
> Left-over debugging code.  Removed.
> 
>> 
>> 
>> 154         // jdeps --module-path <modulepath> -m root paths
>> 155         String cmd = String.format("jdeps --module-path %s --add-modules %s %s%n",
>> 156             MODS_DIR, roots.stream().collect(Collectors.joining(",")),
>> 157             Arrays.toString(paths));
>> 
>> Is the use of Arrays.toString correct here?
>> 
> 
> Hmm..  why the test is passing with ?[]? in the command line?  I will check that out.  In any case, no need to modify this file.  I have reverted it.
> 
> Mandy
> 
>> Paul.
>> 
>>> On 3 Jan 2017, at 13:03, Mandy Chung <mandy.chung at oracle.com> wrote:
>>> 
>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172212/webrev.00/
>>> 
>>> This is a simple patch that fixes jdeps in analyzing modules linked in the image. It fixes the following commands which are currently not working properly.
>>> 
>>> $ jdeps -I -?require jdk.compiler
>>> $ jdeps -?check jdk.compiler
>>> 
>>> This patch changes not to require classes or ?-add-modules be specified, if it?s a module in the image.  This patch also fixes when ?-list-deps is used with -m and prints the result if the source is a named module.
>>> 
>>> Mandy

 <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 claes.redestad at oracle.com  Tue Jan  3 22:52:55 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 3 Jan 2017 23:52:55 +0100
Subject: RFR: 8170785: Excessive allocation in ParseUtil.encodePath
In-Reply-To: <aec49ffa-5b02-02e2-b304-668569860ff0@Oracle.com>
References: <7ae2434a-da5b-ec52-c4cc-0dc8631c6eb1@oracle.com>
	<aec49ffa-5b02-02e2-b304-668569860ff0@Oracle.com>
Message-ID: <00629ee8-ed4c-3352-1a36-ff8a35cd82b6@oracle.com>

Hi Roger,

On 2017-01-03 22:22, Roger Riggs wrote:
> Hi Claes,
>
> So Windows didn't suffer from having the '\' separator.

relatively speaking Windows won't see any speed-up when dealing
with file system paths, but most places where we see encodePath in
profiles is actually not files: jar/runtime image paths, HTTP etc...

Thus Windows shouldn't be left too far behind for typical workloads. :-)

>
> ParseUtil:
>
> firstEncodeIndex:121:
>   'a' - 'z' seems more frequent than '/' or '.'; does it improve the
> stats to move that range to the beginning of the if.
>   (yes the compiler can re-order).
>
> line 125:
>     Since 127 is known to need encoding it could be >= 0x007f
>
> line  136: I suppose the arraycopy intrinsic already optimizes length == 0;
>
> Line 134:  I question the math on  * 2 + 16 -index;  (But this is
> pre-existing code)
>    if there were lots of characters that needed encoding it might be
> possible to overflow the array since 1 char is replaced by at least 3
> and up to 9.
>    16 seems like a questionable fudge factor; but perhaps it has not
> been a problem in practice.

As the main objective here is to get rid of the allocations while not
regressing throughput when they can't be avoided I resisted *most*
urges to micro-optimize. :-)

The weird heuristic with len * 2 + 16 is ugly, yes, but I prefer to
leave it mostly alone and perhaps revisit this for a throughput
performance enhancement in the future.

'/' can actually be rather frequent in paths, and while '.' is likely
less common and should have been inserted after a-z, adding the check
improved performance of encoding to-be-rather-common paths like
"/java.base/bla/bla/bla/" remarkably while not visibly regressing
anything else.

What is clear from micros is that having to load and call into the
BitSet has a relatively large overhead compared to an extra comparison
(which is likely why there are separate checks for a-z, A-Z and 0-9 in
the first place).

I should actually see if we can't remove the BitSet entirely: I think
the java.net.URI approach with final long masks and a simple shift and
check might be more efficient and relatively easy to duplicate here.

Thanks!

/Claes

>
> $.02, Roger
>
>
>
> On 1/3/2017 9:46 AM, Claes Redestad wrote:
>> Hi,
>>
>> some users reports high allocation rates in ParseUtil.encodePath,
>> regardless of whether paths actually need to be encoded or not.
>> Since this is a commonly used utility it makes sense.
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8170785/webrev.01
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170785
>>
>> This patch provides a semantically neutral fast-path for cases when
>> the path does not need to be encoded (up to 5x speedup), reduces
>> allocation when the string has a prefix that does not need to be
>> encoded (1-2x speedup) and no regression when using a separator
>> that's not '/' or the first char needs encoding.
>>
>> Interpreted performance is not affected much either: small positive
>> when no encoding is needed, neutral or negligible regression
>> otherwise.
>>
>> Thanks!
>>
>> /Claes
>

From mandy.chung at oracle.com  Tue Jan  3 22:55:35 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 3 Jan 2017 14:55:35 -0800
Subject: Review Request: jdeps --require and --check should detect the
	specified module in the image
In-Reply-To: <8AD80F03-BDC6-4D69-AC87-7CF19219C679@oracle.com>
References: <05B30791-D3EB-4D90-AD7F-CD1CE919D50B@oracle.com>
	<14662205-919F-4755-906A-5FDEF987E516@oracle.com>
	<8AD80F03-BDC6-4D69-AC87-7CF19219C679@oracle.com>
Message-ID: <C026737B-D639-47D9-BEC0-E19DC15AF9C3@oracle.com>


> On Jan 3, 2017, at 2:45 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> 
>> 
>> 154         // jdeps --module-path <modulepath> -m root paths
>> 155         String cmd = String.format("jdeps --module-path %s --add-modules %s %s%n",
>> 156             MODS_DIR, roots.stream().collect(Collectors.joining(",")),
>> 157             Arrays.toString(paths));
>> 
>> Is the use of Arrays.toString correct here?
>> 
> 
> Hmm..  why the test is passing with ?[]? in the command line?  I will check that out.

It was correct since this string is used only for printing to the output.  The jdeps command is built programmatically in the test.

> In any case, no need to modify this file.  I have reverted it.
> 

Updated webrev:

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172212/webrev.01/

Mandy

From paul.sandoz at oracle.com  Tue Jan  3 22:57:48 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Jan 2017 14:57:48 -0800
Subject: Review Request: jdeps --require and --check should detect the
	specified module in the image
In-Reply-To: <C026737B-D639-47D9-BEC0-E19DC15AF9C3@oracle.com>
References: <05B30791-D3EB-4D90-AD7F-CD1CE919D50B@oracle.com>
	<14662205-919F-4755-906A-5FDEF987E516@oracle.com>
	<8AD80F03-BDC6-4D69-AC87-7CF19219C679@oracle.com>
	<C026737B-D639-47D9-BEC0-E19DC15AF9C3@oracle.com>
Message-ID: <B6785C13-1095-470D-B52C-06C0A5CB7D71@oracle.com>


> On 3 Jan 2017, at 14:55, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> On Jan 3, 2017, at 2:45 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>> 
>> 
>>> 
>>> 
>>> 154         // jdeps --module-path <modulepath> -m root paths
>>> 155         String cmd = String.format("jdeps --module-path %s --add-modules %s %s%n",
>>> 156             MODS_DIR, roots.stream().collect(Collectors.joining(",")),
>>> 157             Arrays.toString(paths));
>>> 
>>> Is the use of Arrays.toString correct here?
>>> 
>> 
>> Hmm..  why the test is passing with ?[]? in the command line?  I will check that out.
> 
> It was correct since this string is used only for printing to the output.  The jdeps command is built programmatically in the test.
> 

Ok.


>> In any case, no need to modify this file.  I have reverted it.
>> 
> 
> Updated webrev:
> 
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172212/webrev.01/
> 

+1

Paul.

From mandy.chung at oracle.com  Tue Jan  3 23:59:24 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 3 Jan 2017 15:59:24 -0800
Subject: Review Request: JDK-8172215 java launcher no longer accepts -cp ""
	empty string
Message-ID: <5BB8D5D6-BBDC-4FDA-990E-8FF15C8A1E34@oracle.com>

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172215/webrev.00/

This fixes the regression caused by JDK-8168836 such that java -cp ?? would be accepted. It?s surprise that no launcher test covering such test case.  Now it?s added in JavaClassPathTest.

This patch also renames the testlibrary ModuleSourceBuilder to ModuleInfoMaker as Alan suggested.

Mandy

From joe.darcy at oracle.com  Wed Jan  4 00:27:57 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 3 Jan 2017 16:27:57 -0800
Subject: JDK 9 RFR of JDK-8172200: Mark StressLoopback.java as intermittently
	failing
Message-ID: <6d696e1a-e728-cbbe-a275-9f7b218e6313@oracle.com>

Hello,

The test

java/nio/channels/AsynchronousSocketChannel/StressLoopback.java

intermittently fails on Solaris x64 on one of our testing systems. The 
test should be marked accordingly. Please review the patch below which 
does this.

Thanks,

-Joe

diff -r d27bab22ff62 
test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java
--- 
a/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java 
Mon Jan 02 22:45:34 2017 +0100
+++ 
b/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java 
Tue Jan 03 16:26:21 2017 -0800
@@ -26,7 +26,7 @@
   * @summary Stress test connections through the loopback interface
   * @run main StressLoopback
   * @run main/othervm -Djdk.net.useFastTcpLoopback StressLoopback
- * @key randomness
+ * @key randomness intermittent
   */

  import java.nio.ByteBuffer;


From lance.andersen at oracle.com  Wed Jan  4 00:57:09 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 3 Jan 2017 19:57:09 -0500
Subject: JDK 9 RFR of JDK-8172200: Mark StressLoopback.java as
	intermittently failing
In-Reply-To: <6d696e1a-e728-cbbe-a275-9f7b218e6313@oracle.com>
References: <6d696e1a-e728-cbbe-a275-9f7b218e6313@oracle.com>
Message-ID: <ADEFD2C9-78AC-4189-A359-1C2435171922@oracle.com>

+1
> On Jan 3, 2017, at 7:27 PM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> The test
> 
> java/nio/channels/AsynchronousSocketChannel/StressLoopback.java
> 
> intermittently fails on Solaris x64 on one of our testing systems. The test should be marked accordingly. Please review the patch below which does this.
> 
> Thanks,
> 
> -Joe
> 
> diff -r d27bab22ff62 test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java
> --- a/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java Mon Jan 02 22:45:34 2017 +0100
> +++ b/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java Tue Jan 03 16:26:21 2017 -0800
> @@ -26,7 +26,7 @@
>  * @summary Stress test connections through the loopback interface
>  * @run main StressLoopback
>  * @run main/othervm -Djdk.net.useFastTcpLoopback StressLoopback
> - * @key randomness
> + * @key randomness intermittent
>  */
> 
> import java.nio.ByteBuffer;
> 

 <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  Wed Jan  4 01:12:00 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Jan 2017 17:12:00 -0800
Subject: RFR 8172201 Replace assert of return type in VarHandle.AccessMode
	with test
Message-ID: <321464F6-F246-43EF-985C-519BC1741479@oracle.com>

Hi,

Please review the following which removes an assert statement from the constructor of VarHandle.AccessMode and replaces it with a test:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8172201-vh-accessmode-return-type-assert/webrev/jdk.patch <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8172201-vh-accessmode-return-type-assert/webrev/jdk.patch>

The execution of the assert statement, with it?s use of core reflection, could potentially interfere with the execution of other tests and result in circular dependency issues if assertions are enabled.

Thanks,
Paul.

From paul.sandoz at oracle.com  Wed Jan  4 01:23:33 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 3 Jan 2017 17:23:33 -0800
Subject: Review Request: JDK-8172215 java launcher no longer accepts -cp
	"" empty string
In-Reply-To: <5BB8D5D6-BBDC-4FDA-990E-8FF15C8A1E34@oracle.com>
References: <5BB8D5D6-BBDC-4FDA-990E-8FF15C8A1E34@oracle.com>
Message-ID: <59E624FA-EC93-4D45-9E7E-3D9661E0DC75@oracle.com>


> On 3 Jan 2017, at 15:59, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172215/webrev.00/
> 
> This fixes the regression caused by JDK-8168836 such that java -cp ?? would be accepted. It?s surprise that no launcher test covering such test case.  Now it?s added in JavaClassPathTest.
> 
> This patch also renames the testlibrary ModuleSourceBuilder to ModuleInfoMaker as Alan suggested.
> 

 213     private static boolean isWindows = System.getProperty("os.name?)

Make it final and rename to IS_WINDOWS ?

Paul.

From mandy.chung at oracle.com  Wed Jan  4 01:41:55 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 3 Jan 2017 17:41:55 -0800
Subject: RFR 8172201 Replace assert of return type in VarHandle.AccessMode
	with test
In-Reply-To: <321464F6-F246-43EF-985C-519BC1741479@oracle.com>
References: <321464F6-F246-43EF-985C-519BC1741479@oracle.com>
Message-ID: <95512F6A-AB29-47E1-9B7C-E9DB925CB9DD@oracle.com>


> On Jan 3, 2017, at 5:12 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Please review the following which removes an assert statement from the constructor of VarHandle.AccessMode and replaces it with a test:
> 
>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8172201-vh-accessmode-return-type-assert/webrev/jdk.patch

This looks fine.

Mandy


From brian.burkhalter at oracle.com  Wed Jan  4 01:50:02 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 3 Jan 2017 17:50:02 -0800
Subject: JDK 9 RFR of JDK-8172200: Mark StressLoopback.java as
	intermittently failing
In-Reply-To: <6d696e1a-e728-cbbe-a275-9f7b218e6313@oracle.com>
References: <6d696e1a-e728-cbbe-a275-9f7b218e6313@oracle.com>
Message-ID: <ACD865C6-A37A-4C90-B91E-21D17DB8E2AC@oracle.com>

Hi Joe,

Looks fine.

Brian

On Jan 3, 2017, at 4:27 PM, joe darcy <joe.darcy at oracle.com> wrote:

> java/nio/channels/AsynchronousSocketChannel/StressLoopback.java
> 
> intermittently fails on Solaris x64 on one of our testing systems. The test should be marked accordingly. Please review the patch below which does this.
> 
> --- a/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java Mon Jan 02 22:45:34 2017 +0100
> +++ b/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java Tue Jan 03 16:26:21 2017 -0800
> @@ -26,7 +26,7 @@
>  * @summary Stress test connections through the loopback interface
>  * @run main StressLoopback
>  * @run main/othervm -Djdk.net.useFastTcpLoopback StressLoopback
> - * @key randomness
> + * @key randomness intermittent
>  */

From mandy.chung at oracle.com  Wed Jan  4 02:03:39 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 3 Jan 2017 18:03:39 -0800
Subject: Review Request: JDK-8172215 java launcher no longer accepts -cp
	"" empty string
In-Reply-To: <59E624FA-EC93-4D45-9E7E-3D9661E0DC75@oracle.com>
References: <5BB8D5D6-BBDC-4FDA-990E-8FF15C8A1E34@oracle.com>
	<59E624FA-EC93-4D45-9E7E-3D9661E0DC75@oracle.com>
Message-ID: <D37641BF-31CB-44AB-912D-1EB14A444D2D@oracle.com>


> On Jan 3, 2017, at 5:23 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 
>> On 3 Jan 2017, at 15:59, Mandy Chung <mandy.chung at oracle.com> wrote:
>> 
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172215/webrev.00/
>> 
>> This fixes the regression caused by JDK-8168836 such that java -cp ?? would be accepted. It?s surprise that no launcher test covering such test case.  Now it?s added in JavaClassPathTest.
>> 
>> This patch also renames the testlibrary ModuleSourceBuilder to ModuleInfoMaker as Alan suggested.
>> 
> 
> 213     private static boolean isWindows = System.getProperty("os.name?)
> 
> Make it final and rename to IS_WINDOWS ?


Sure. Updated in place.

Mandy


From huaming.li at oracle.com  Wed Jan  4 02:55:29 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 4 Jan 2017 10:55:29 +0800
Subject: RFR of JDK-8030175:
	java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due
	to timeout
In-Reply-To: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
Message-ID: <cafc55ae-a51b-2970-adf5-9884c94b2c99@oracle.com>

Is some one available to review the patch?

Thank you
-Hamlin

On 2016/12/26 16:51, Hamlin Li wrote:
> Would you please review the below patches?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
> webrev (version A): http://cr.openjdk.java.net/~mli/8030175/webrev.00/
> webrev (version B): 
> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>
>
> There are 2 versions to be reviewed.
>
> In version A, just use RegistryRunner to replace rmiregistry.
> In version B, refactor sun.rmi.registry.RegistryImpl to improve the 
> testability of RMI code, and create/use RMIRegistryRunner to simulate 
> rmiregistry.
>
> Thank you
> -Hamlin


From david.holmes at oracle.com  Wed Jan  4 03:11:27 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Jan 2017 13:11:27 +1000
Subject: MethodHandle initialization process - problem with JVM TI early VM
	start event
Message-ID: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>

We have encountered a crash in a JVM TI test, starting with b148, that 
is caused by the attempted use of MethodRefs and invoke_dynamic within 
class loading that occurs from the "early VM start" JVM TI event 
callback - which happens before the VM and core classes are fully 
initialized. The class being loaded/initialized is in java.base and so 
this is allowed. The class, java.net.Authenticator, was changed in b148 
to have static initialization involving method refs and hence the 
problem was introduced.

I've included a stack dump below.

It is far from clear to me where responsibility for this lies, or even 
how to narrow that down. Is it in the code of MethodHandleNatives? Or is 
it in the VM linking/resolution code?

Thoughts appreciated. :)

Thanks,
David
-----


--------------- T H R E A D ---------------

Current thread (0x00007ff99c01c000): JavaThread "Unknown thread" 
[_thread_in_vm, id=31105, stack(0x00007ff9a5584000,0x00007ff9a5684000)]

Stack: [0x00007ff9a5584000,0x00007ff9a5684000], sp=0x00007ff9a56809e0, 
free space=1010k
Native frames: (J=compiled Java code, A=aot compiled Java code, 
j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x16b1932] VMError::report_and_die(int, char const*, char 
const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char cons
t*, int, unsigned long)+0x162
V [libjvm.so+0x16b26af] VMError::report_and_die(Thread*, char const*, 
int, char const*, char const*, __va_list_tag*)+0x2f
V [libjvm.so+0xaa0fed] report_vm_error(char const*, int, char const*, 
char const*, ...)+0xdd
V [libjvm.so+0x110fbd6] 
LinkResolver::runtime_resolve_virtual_method(CallInfo&, methodHandle 
const&, KlassHandle, Handle, KlassHandle, bool, Th
read*)+0x1f6
V [libjvm.so+0x11128b5] LinkResolver::resolve_invokevirtual(CallInfo&, 
Handle, constantPoolHandle const&, int, Thread*)+0x185
V [libjvm.so+0x1113c5b] LinkResolver::resolve_invoke(CallInfo&, Handle, 
constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0xab
V [libjvm.so+0xdea7da] InterpreterRuntime::resolve_invoke(JavaThread*, 
Bytecodes::Code)+0x23a
V [libjvm.so+0xdf69bb] 
InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0xeb
j java.lang.invoke.MethodHandleNatives.<clinit>()V+2 java.base
v ~StubRoutines::call_stub
V [libjvm.so+0xe15970] JavaCalls::call_helper(JavaValue*, methodHandle 
const&, JavaCallArguments*, Thread*)+0x950
V [libjvm.so+0xdcd15c] 
InstanceKlass::call_class_initializer_impl(instanceKlassHandle, 
Thread*)+0x15c
V [libjvm.so+0xdcd2a3] InstanceKlass::call_class_initializer(Thread*)+0x83
V [libjvm.so+0xdcd762] 
InstanceKlass::initialize_impl(instanceKlassHandle, Thread*) [clone 
.part.160]+0x4a2
V [libjvm.so+0xdcdd2b] 
InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x13b
V [libjvm.so+0xdcde72] InstanceKlass::initialize(Thread*)+0x102
V [libjvm.so+0x110dd0c] LinkResolver::resolve_static_call(CallInfo&, 
LinkInfo const&, bool, Thread*)+0x14c
V [libjvm.so+0xe13e3a] JavaCalls::call_static(JavaValue*, KlassHandle, 
Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x13a
V [libjvm.so+0x15bd833] 
SystemDictionary::find_method_handle_type(Symbol*, KlassHandle, 
Thread*)+0x10f3
V [libjvm.so+0x15be1c6] 
SystemDictionary::link_method_handle_constant(KlassHandle, int, 
KlassHandle, Symbol*, Symbol*, Thread*)+0x596
V [libjvm.so+0xa8ad46] 
ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int, 
int, Thread*)+0x7d6
V [libjvm.so+0xa8b7ad] 
ConstantPool::resolve_bootstrap_specifier_at_impl(constantPoolHandle 
const&, int, Thread*)+0x16d
V [libjvm.so+0x11135db] LinkResolver::resolve_invokedynamic(CallInfo&, 
constantPoolHandle const&, int, Thread*)+0x71b
V [libjvm.so+0x1113d2e] LinkResolver::resolve_invoke(CallInfo&, Handle, 
constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x17e
V [libjvm.so+0xdebb64] 
InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x274
V [libjvm.so+0xdf69a8] 
InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0xd8
j java.net.Authenticator.<clinit>()V+0 java.base
v ~StubRoutines::call_stub
V [libjvm.so+0xe15970] JavaCalls::call_helper(JavaValue*, methodHandle 
const&, JavaCallArguments*, Thread*)+0x950
V [libjvm.so+0xdcd15c] 
InstanceKlass::call_class_initializer_impl(instanceKlassHandle, 
Thread*)+0x15c
V [libjvm.so+0xdcd2a3] InstanceKlass::call_class_initializer(Thread*)+0x83
V [libjvm.so+0xdcd762] 
InstanceKlass::initialize_impl(instanceKlassHandle, Thread*) [clone 
.part.160]+0x4a2
V [libjvm.so+0xdcdd2b] 
InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x13b
V [libjvm.so+0xdcde72] InstanceKlass::initialize(Thread*)+0x102
V [libjvm.so+0xf331f2] find_class_from_class_loader(JNIEnv_*, Symbol*, 
unsigned char, Handle, Handle, unsigned char, Thread*)+0x122
V [libjvm.so+0xec0369] jni_FindClass+0x5e9
C [libjckjvmti.so+0x60d69] vmse00101_VMStart+0x2b
V [libjvm.so+0x107ce3b] JvmtiExport::post_early_vm_start()+0xcb
V [libjvm.so+0x16150ee] Threads::create_vm(JavaVMInitArgs*, bool*)+0x4de

From david.holmes at oracle.com  Wed Jan  4 04:59:37 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Jan 2017 14:59:37 +1000
Subject: Review Request: JDK-8172215 java launcher no longer accepts -cp
	"" empty string
In-Reply-To: <D37641BF-31CB-44AB-912D-1EB14A444D2D@oracle.com>
References: <5BB8D5D6-BBDC-4FDA-990E-8FF15C8A1E34@oracle.com>
	<59E624FA-EC93-4D45-9E7E-3D9661E0DC75@oracle.com>
	<D37641BF-31CB-44AB-912D-1EB14A444D2D@oracle.com>
Message-ID: <b778f7e8-008b-48e0-39fa-d60b1303552b@oracle.com>

On 4/01/2017 12:03 PM, Mandy Chung wrote:
>
>> On Jan 3, 2017, at 5:23 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>
>>
>>> On 3 Jan 2017, at 15:59, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>
>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172215/webrev.00/
>>>
>>> This fixes the regression caused by JDK-8168836 such that java -cp ?? would be accepted. It?s surprise that no launcher test covering such test case.  Now it?s added in JavaClassPathTest.
>>>
>>> This patch also renames the testlibrary ModuleSourceBuilder to ModuleInfoMaker as Alan suggested.
>>>
>>
>> 213     private static boolean isWindows = System.getProperty("os.name?)
>>
>> Make it final and rename to IS_WINDOWS ?
>
>
> Sure. Updated in place.

It isn't final. :)

Functional fix looks good.

Thanks,
David

> Mandy
>

From david.holmes at oracle.com  Wed Jan  4 07:03:44 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Jan 2017 17:03:44 +1000
Subject: MethodHandle initialization process - problem with JVM TI early
	VM start event
In-Reply-To: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
References: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
Message-ID: <bf064b64-6c67-a895-bab3-b3d6f3a1e854@oracle.com>

Looking further into this the crash occurs because java.lang.Class has 
not been initialized yet. Logging shows we go straight from initializing 
Object to initializing java.net.Authenticator then to 
java.lang.invoke.MethodHandleNatives.

[3.484s][debug][vtables ] Initializing: java/lang/invoke/MethodHandleNatives
[3.484s][trace][vtables ] copy vtable from java.lang.Object to 
java.lang.invoke.MethodHandleNatives size 5
[3.484s][info ][class,init ] 2 Initializing 
'java/lang/invoke/MethodHandleNatives' (0x000000080000c608)
[3.485s][debug][class,resolve ] java.lang.invoke.MethodHandleNatives 
java.lang.Class MethodHandleNatives.java:44
[3.485s][trace][vtables ] invokevirtual resolved method: 
caller-class:java.lang.invoke.MethodHandleNatives, 
compile-time-class:java.lang.Class, 
method:java.lang.Class.desiredAssertionStatus()Z, 
method_holder:java.lang.Class, access_flags: public
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:1295

But why we are not implicitly initializing java.lang.Class before the 
invokevirtual processing?

The clinit for MethodHandleNatives starts with:

  static {};
     descriptor: ()V
     flags: (0x0008) ACC_STATIC
     Code:
       stack=3, locals=2, args_size=0
          0: ldc #160 // class java/lang/invoke/MethodHandleNatives
          2: invokevirtual #161 // Method 
java/lang/Class.desiredAssertionStatus:()Z

A class must be initialized before we may invoke a method on it, or 
obtain an instance - so why is nothing ensuring java.lang.Class is 
initialized?

David
-----

On 4/01/2017 1:11 PM, David Holmes wrote:
> We have encountered a crash in a JVM TI test, starting with b148, that
> is caused by the attempted use of MethodRefs and invoke_dynamic within
> class loading that occurs from the "early VM start" JVM TI event
> callback - which happens before the VM and core classes are fully
> initialized. The class being loaded/initialized is in java.base and so
> this is allowed. The class, java.net.Authenticator, was changed in b148
> to have static initialization involving method refs and hence the
> problem was introduced.
>
> I've included a stack dump below.
>
> It is far from clear to me where responsibility for this lies, or even
> how to narrow that down. Is it in the code of MethodHandleNatives? Or is
> it in the VM linking/resolution code?
>
> Thoughts appreciated. :)
>
> Thanks,
> David
> -----
>
>
> --------------- T H R E A D ---------------
>
> Current thread (0x00007ff99c01c000): JavaThread "Unknown thread"
> [_thread_in_vm, id=31105, stack(0x00007ff9a5584000,0x00007ff9a5684000)]
>
> Stack: [0x00007ff9a5584000,0x00007ff9a5684000], sp=0x00007ff9a56809e0,
> free space=1010k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0x16b1932] VMError::report_and_die(int, char const*, char
> const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char cons
> t*, int, unsigned long)+0x162
> V [libjvm.so+0x16b26af] VMError::report_and_die(Thread*, char const*,
> int, char const*, char const*, __va_list_tag*)+0x2f
> V [libjvm.so+0xaa0fed] report_vm_error(char const*, int, char const*,
> char const*, ...)+0xdd
> V [libjvm.so+0x110fbd6]
> LinkResolver::runtime_resolve_virtual_method(CallInfo&, methodHandle
> const&, KlassHandle, Handle, KlassHandle, bool, Th
> read*)+0x1f6
> V [libjvm.so+0x11128b5] LinkResolver::resolve_invokevirtual(CallInfo&,
> Handle, constantPoolHandle const&, int, Thread*)+0x185
> V [libjvm.so+0x1113c5b] LinkResolver::resolve_invoke(CallInfo&, Handle,
> constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0xab
> V [libjvm.so+0xdea7da] InterpreterRuntime::resolve_invoke(JavaThread*,
> Bytecodes::Code)+0x23a
> V [libjvm.so+0xdf69bb]
> InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0xeb
> j java.lang.invoke.MethodHandleNatives.<clinit>()V+2 java.base
> v ~StubRoutines::call_stub
> V [libjvm.so+0xe15970] JavaCalls::call_helper(JavaValue*, methodHandle
> const&, JavaCallArguments*, Thread*)+0x950
> V [libjvm.so+0xdcd15c]
> InstanceKlass::call_class_initializer_impl(instanceKlassHandle,
> Thread*)+0x15c
> V [libjvm.so+0xdcd2a3] InstanceKlass::call_class_initializer(Thread*)+0x83
> V [libjvm.so+0xdcd762]
> InstanceKlass::initialize_impl(instanceKlassHandle, Thread*) [clone
> .part.160]+0x4a2
> V [libjvm.so+0xdcdd2b]
> InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x13b
> V [libjvm.so+0xdcde72] InstanceKlass::initialize(Thread*)+0x102
> V [libjvm.so+0x110dd0c] LinkResolver::resolve_static_call(CallInfo&,
> LinkInfo const&, bool, Thread*)+0x14c
> V [libjvm.so+0xe13e3a] JavaCalls::call_static(JavaValue*, KlassHandle,
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x13a
> V [libjvm.so+0x15bd833]
> SystemDictionary::find_method_handle_type(Symbol*, KlassHandle,
> Thread*)+0x10f3
> V [libjvm.so+0x15be1c6]
> SystemDictionary::link_method_handle_constant(KlassHandle, int,
> KlassHandle, Symbol*, Symbol*, Thread*)+0x596
> V [libjvm.so+0xa8ad46]
> ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int,
> int, Thread*)+0x7d6
> V [libjvm.so+0xa8b7ad]
> ConstantPool::resolve_bootstrap_specifier_at_impl(constantPoolHandle
> const&, int, Thread*)+0x16d
> V [libjvm.so+0x11135db] LinkResolver::resolve_invokedynamic(CallInfo&,
> constantPoolHandle const&, int, Thread*)+0x71b
> V [libjvm.so+0x1113d2e] LinkResolver::resolve_invoke(CallInfo&, Handle,
> constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x17e
> V [libjvm.so+0xdebb64]
> InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x274
> V [libjvm.so+0xdf69a8]
> InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0xd8
> j java.net.Authenticator.<clinit>()V+0 java.base
> v ~StubRoutines::call_stub
> V [libjvm.so+0xe15970] JavaCalls::call_helper(JavaValue*, methodHandle
> const&, JavaCallArguments*, Thread*)+0x950
> V [libjvm.so+0xdcd15c]
> InstanceKlass::call_class_initializer_impl(instanceKlassHandle,
> Thread*)+0x15c
> V [libjvm.so+0xdcd2a3] InstanceKlass::call_class_initializer(Thread*)+0x83
> V [libjvm.so+0xdcd762]
> InstanceKlass::initialize_impl(instanceKlassHandle, Thread*) [clone
> .part.160]+0x4a2
> V [libjvm.so+0xdcdd2b]
> InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x13b
> V [libjvm.so+0xdcde72] InstanceKlass::initialize(Thread*)+0x102
> V [libjvm.so+0xf331f2] find_class_from_class_loader(JNIEnv_*, Symbol*,
> unsigned char, Handle, Handle, unsigned char, Thread*)+0x122
> V [libjvm.so+0xec0369] jni_FindClass+0x5e9
> C [libjckjvmti.so+0x60d69] vmse00101_VMStart+0x2b
> V [libjvm.so+0x107ce3b] JvmtiExport::post_early_vm_start()+0xcb
> V [libjvm.so+0x16150ee] Threads::create_vm(JavaVMInitArgs*, bool*)+0x4de

From peter.levart at gmail.com  Wed Jan  4 07:16:01 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 4 Jan 2017 08:16:01 +0100
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
Message-ID: <0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>

Hi David,

On 12/26/2016 10:16 PM, David Holmes wrote:
> Hi Peter,
>
> I know this is response to the problems with your other recent change, 
> but this is an enhancement in my opinion, not a bug fix, and the time 
> for enhancements is passed - though there is still a process to 
> request them. I do not like to see last minutes changes like this 
> where not enough due diligence may be done to identify all the 
> ramifications.

Since the initialization cycle has now been broken by fix/simplification 
(JDK-8172048), there is no imminent need to pursue this one at this 
time, but...

>
> The Class.getMethod() fixes seem to have overstepped the line in that 
> regard as well, in my opinion. Anything that potentially changes 
> initialization order is fragile and risky and requires additional 
> testing.

...I was surprised that this actually happened at first. The 
initialization cycle was apparently introduced by my introduction of new 
class (java.lang.PublicMethods$Key) which in its <clinit> requests 
ReflectionFactory which does a permission check and all that is 
triggered from assertion in java.lang.invoke.VarHandle$AccessMode 
constructor which uses Class::getMethod to verify the assertion condition...

Here's the stack trace, repeated here for clarity:

  Error occurred during initialization of VM
java.lang.ExceptionInInitializerError
at 
java.lang.PublicMethods$MethodList.filter(java.base at 9-internal/PublicMethods.java:151)
at java.lang.Class.getMethodsRecursive(java.base at 9-internal/Class.java:3191)
at java.lang.Class.getMethod0(java.base at 9-internal/Class.java:3175)
at java.lang.Class.getMethod(java.base at 9-internal/Class.java:2036)
at 
java.lang.invoke.VarHandle$AccessMode.getReturnType(java.base at 9-internal/VarHandle.java:1826)
at 
java.lang.invoke.VarHandle$AccessMode.<init>(java.base at 9-internal/VarHandle.java:1792)
at 
java.lang.invoke.VarHandle$AccessMode.<clinit>(java.base at 9-internal/VarHandle.java:1590)
at 
java.lang.invoke.VarForm.linkFromStatic(java.base at 9-internal/VarForm.java:127)
at java.lang.invoke.VarForm.<init>(java.base at 9-internal/VarForm.java:50)
at 
java.lang.invoke.VarHandleObjects$FieldInstanceReadOnly.<clinit>(java.base at 9-internal/VarHandleObjects.java:84)
at 
java.lang.invoke.VarHandles.makeFieldHandle(java.base at 9-internal/VarHandles.java:38)
at 
java.lang.invoke.MethodHandles$Lookup.getFieldVarHandleCommon(java.base at 9-internal/MethodHandles.java:2241)
at 
java.lang.invoke.MethodHandles$Lookup.getFieldVarHandle(java.base at 9-internal/MethodHandles.java:2201)
at 
java.lang.invoke.MethodHandles$Lookup.findVarHandle(java.base at 9-internal/MethodHandles.java:1361)
at 
java.util.concurrent.atomic.AtomicReference.<clinit>(java.base at 9-internal/AtomicReference.java:57)
at java.security.Policy.<clinit>(java.base at 9-internal/Policy.java:111)
at 
java.security.AccessControlContext.getDebug(java.base at 9-internal/AccessControlContext.java:110)
at 
java.security.AccessControlContext.checkPermission(java.base at 9-internal/AccessControlContext.java:398)
at 
java.security.AccessController.checkPermission(java.base at 9-internal/AccessController.java:894)
at 
java.lang.SecurityManager.checkPermission(java.base at 9-internal/SecurityManager.java:548)
at 
java.lang.SecurityManager.checkPropertyAccess(java.base at 9-internal/SecurityManager.java:1292)
at java.lang.System.getProperty(java.base at 9-internal/System.java:761)
at 
java.lang.ClassLoader.initSystemClassLoader(java.base at 9-internal/ClassLoader.java:1902)
at java.lang.System.initPhase3(java.base at 9-internal/System.java:1979)
Caused by: java.lang.NullPointerException
at java.security.Policy.isSet(java.base at 9-internal/Policy.java:126)
at 
java.security.AccessControlContext.getDebug(java.base at 9-internal/AccessControlContext.java:110)
at 
java.security.AccessController.checkPermission(java.base at 9-internal/AccessController.java:871)
at 
java.lang.SecurityManager.checkPermission(java.base at 9-internal/SecurityManager.java:548)
at 
jdk.internal.reflect.ReflectionFactory.getReflectionFactory(java.base at 9-internal/ReflectionFactory.java:132)
at 
jdk.internal.reflect.ReflectionFactory$GetReflectionFactoryAction.run(java.base at 9-internal/ReflectionFactory.java:106)
at 
jdk.internal.reflect.ReflectionFactory$GetReflectionFactoryAction.run(java.base at 9-internal/ReflectionFactory.java:103)
at 
java.security.AccessController.doPrivileged(java.base at 9-internal/Native 
Method)
at 
java.lang.PublicMethods$Key.<clinit>(java.base at 9-internal/PublicMethods.java:90)
at 
java.lang.PublicMethods$MethodList.filter(java.base at 9-internal/PublicMethods.java:151)
at java.lang.Class.getMethodsRecursive(java.base at 9-internal/Class.java:3191)
at java.lang.Class.getMethod0(java.base at 9-internal/Class.java:3175)
at java.lang.Class.getMethod(java.base at 9-internal/Class.java:2036)
at 
java.lang.invoke.VarHandle$AccessMode.getReturnType(java.base at 9-internal/VarHandle.java:1826)
at 
java.lang.invoke.VarHandle$AccessMode.<init>(java.base at 9-internal/VarHandle.java:1792)
at 
java.lang.invoke.VarHandle$AccessMode.<clinit>(java.base at 9-internal/VarHandle.java:1590)
at 
java.lang.invoke.VarForm.linkFromStatic(java.base at 9-internal/VarForm.java:127)
at java.lang.invoke.VarForm.<init>(java.base at 9-internal/VarForm.java:50)
at 
java.lang.invoke.VarHandleObjects$FieldInstanceReadOnly.<clinit>(java.base at 9-internal/VarHandleObjects.java:84)
at 
java.lang.invoke.VarHandles.makeFieldHandle(java.base at 9-internal/VarHandles.java:38)
at 
java.lang.invoke.MethodHandles$Lookup.getFieldVarHandleCommon(java.base at 9-internal/MethodHandles.java:2241)
at 
java.lang.invoke.MethodHandles$Lookup.getFieldVarHandle(java.base at 9-internal/MethodHandles.java:2201)
at 
java.lang.invoke.MethodHandles$Lookup.findVarHandle(java.base at 9-internal/MethodHandles.java:1361)
at 
java.util.concurrent.atomic.AtomicReference.<clinit>(java.base at 9-internal/AtomicReference.java:57)
at java.security.Policy.<clinit>(java.base at 9-internal/Policy.java:111)
at 
java.security.AccessControlContext.getDebug(java.base at 9-internal/AccessControlContext.java:110)
at 
java.security.AccessControlContext.checkPermission(java.base at 9-internal/AccessControlContext.java:398)
at 
java.security.AccessController.checkPermission(java.base at 9-internal/AccessController.java:894)
at 
java.lang.SecurityManager.checkPermission(java.base at 9-internal/SecurityManager.java:548)
at 
java.lang.SecurityManager.checkPropertyAccess(java.base at 9-internal/SecurityManager.java:1292)
at java.lang.System.getProperty(java.base at 9-internal/System.java:761)
at 
java.lang.ClassLoader.initSystemClassLoader(java.base at 9-internal/ClassLoader.java:1902)
at java.lang.System.initPhase3(java.base at 9-internal/System.java:1979)


But even before my change, Class::getMethod needed access to 
ReflectionFactory instance. To remind: each reflective object (Method, 
Field, Constructor) is copied before handed out of a public method such 
as Class::getMethod. Copying is performed by ReflectionFactory. 
ReflectionFactory in java.lang.Class is obtained lazily:

     // Fetches the factory for reflective objects
     private static ReflectionFactory getReflectionFactory() {
         if (reflectionFactory == null) {
             reflectionFactory =
                 java.security.AccessController.doPrivileged
                     (new ReflectionFactory.GetReflectionFactoryAction());
         }
         return reflectionFactory;
     }
     private static ReflectionFactory reflectionFactory;

...so the only way for this to not cause the same problem is for 
Class.reflectionFactory field to be initialized before SecurityManager 
is set.

Was this pure luck and we were just waiting for a situation where this 
was not the case?

It is good that this danger is now past as java.security.Policy does not 
need AtomicReference any more.

Regards, Peter

>
> That said, I am an admirer of your work on OpenJDK! :)
>
> Cheers,
> David
>
>
> On 27/12/2016 5:29 AM, Peter Levart wrote:
>> Hi,
>>
>> There are 2 ReflectionFactory classes in JDK 9. The old one is
>> sun.reflect.ReflectionFactory which ended in jdk.unsupported module and
>> to which access is restricted with SecurityManager. There is also new
>> jdk.internal.reflect.ReflectionFactory which is used internally by JDK,
>> is exported to internal modules only but still uses SecurityManager to
>> restrict access to itself. I checked all usages and they all use
>> AccessControler.doPrivileged() for obtaining the instance of
>> jdk.internal.reflect.ReflectionFactory, which somehow defeats the
>> purpose of SecurityManager access checks in this API.
>>
>> I think this could be simplified by removing the SecurityManager check
>> from jdk.internal.reflect.ReflectionFactory#getReflectionFactory static
>> method and change all usages to invoke this method directly without
>> doPrivileged(). There are already two sensitive internal APIs exposed
>> without SecurityManager checks: jdk.internal.misc.Unsafe#getUnsafe and
>> various jdk.internal.misc.SharedSecrets#getXxxAccess methods. So why
>> wouldn't internal ReflectionFactory be exposed the same way?
>>
>> This would make obtaining the ReflectionFactory more robust and not
>> sensitive to bootstrap issues that surfaced recently after my push of a
>> fix for issues 8062389, 8029459, 8061950.
>>
>> So, what do you think? Is this a worthwhile cleanup and simplification?
>>
>> Regards, Peter
>>


From david.holmes at oracle.com  Wed Jan  4 07:27:39 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Jan 2017 17:27:39 +1000
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
Message-ID: <a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>

Hi Peter,

 > ...so the only way for this to not cause the same problem is for
 > Class.reflectionFactory field to be initialized before SecurityManager
 > is set.
 >
 > Was this pure luck and we were just waiting for a situation where this
 > was not the case?

I don't know. If you run with -Xlog:class+init=trace you will see the 
normal initialization order, and can then compare with and without a 
security manager; with and without assertions enabled etc etc.

I'm getting more and more paranoid about initialization order 
dependencies and the overall fragility of it all (eg that no class 
initialized before java.lang.Class can use assertions).

And its even worse when you consider that JVM TI can totally change 
initialization order in unexpected ways that can lead to total breakage.

Cheers,
David


On 4/01/2017 5:16 PM, Peter Levart wrote:
> Hi David,
>
> On 12/26/2016 10:16 PM, David Holmes wrote:
>> Hi Peter,
>>
>> I know this is response to the problems with your other recent change,
>> but this is an enhancement in my opinion, not a bug fix, and the time
>> for enhancements is passed - though there is still a process to
>> request them. I do not like to see last minutes changes like this
>> where not enough due diligence may be done to identify all the
>> ramifications.
>
> Since the initialization cycle has now been broken by fix/simplification
> (JDK-8172048), there is no imminent need to pursue this one at this
> time, but...
>
>>
>> The Class.getMethod() fixes seem to have overstepped the line in that
>> regard as well, in my opinion. Anything that potentially changes
>> initialization order is fragile and risky and requires additional
>> testing.
>
> ...I was surprised that this actually happened at first. The
> initialization cycle was apparently introduced by my introduction of new
> class (java.lang.PublicMethods$Key) which in its <clinit> requests
> ReflectionFactory which does a permission check and all that is
> triggered from assertion in java.lang.invoke.VarHandle$AccessMode
> constructor which uses Class::getMethod to verify the assertion
> condition...
>
> Here's the stack trace, repeated here for clarity:
>
>  Error occurred during initialization of VM
> java.lang.ExceptionInInitializerError
> at
> java.lang.PublicMethods$MethodList.filter(java.base at 9-internal/PublicMethods.java:151)
>
> at
> java.lang.Class.getMethodsRecursive(java.base at 9-internal/Class.java:3191)
> at java.lang.Class.getMethod0(java.base at 9-internal/Class.java:3175)
> at java.lang.Class.getMethod(java.base at 9-internal/Class.java:2036)
> at
> java.lang.invoke.VarHandle$AccessMode.getReturnType(java.base at 9-internal/VarHandle.java:1826)
>
> at
> java.lang.invoke.VarHandle$AccessMode.<init>(java.base at 9-internal/VarHandle.java:1792)
>
> at
> java.lang.invoke.VarHandle$AccessMode.<clinit>(java.base at 9-internal/VarHandle.java:1590)
>
> at
> java.lang.invoke.VarForm.linkFromStatic(java.base at 9-internal/VarForm.java:127)
>
> at java.lang.invoke.VarForm.<init>(java.base at 9-internal/VarForm.java:50)
> at
> java.lang.invoke.VarHandleObjects$FieldInstanceReadOnly.<clinit>(java.base at 9-internal/VarHandleObjects.java:84)
>
> at
> java.lang.invoke.VarHandles.makeFieldHandle(java.base at 9-internal/VarHandles.java:38)
>
> at
> java.lang.invoke.MethodHandles$Lookup.getFieldVarHandleCommon(java.base at 9-internal/MethodHandles.java:2241)
>
> at
> java.lang.invoke.MethodHandles$Lookup.getFieldVarHandle(java.base at 9-internal/MethodHandles.java:2201)
>
> at
> java.lang.invoke.MethodHandles$Lookup.findVarHandle(java.base at 9-internal/MethodHandles.java:1361)
>
> at
> java.util.concurrent.atomic.AtomicReference.<clinit>(java.base at 9-internal/AtomicReference.java:57)
>
> at java.security.Policy.<clinit>(java.base at 9-internal/Policy.java:111)
> at
> java.security.AccessControlContext.getDebug(java.base at 9-internal/AccessControlContext.java:110)
>
> at
> java.security.AccessControlContext.checkPermission(java.base at 9-internal/AccessControlContext.java:398)
>
> at
> java.security.AccessController.checkPermission(java.base at 9-internal/AccessController.java:894)
>
> at
> java.lang.SecurityManager.checkPermission(java.base at 9-internal/SecurityManager.java:548)
>
> at
> java.lang.SecurityManager.checkPropertyAccess(java.base at 9-internal/SecurityManager.java:1292)
>
> at java.lang.System.getProperty(java.base at 9-internal/System.java:761)
> at
> java.lang.ClassLoader.initSystemClassLoader(java.base at 9-internal/ClassLoader.java:1902)
>
> at java.lang.System.initPhase3(java.base at 9-internal/System.java:1979)
> Caused by: java.lang.NullPointerException
> at java.security.Policy.isSet(java.base at 9-internal/Policy.java:126)
> at
> java.security.AccessControlContext.getDebug(java.base at 9-internal/AccessControlContext.java:110)
>
> at
> java.security.AccessController.checkPermission(java.base at 9-internal/AccessController.java:871)
>
> at
> java.lang.SecurityManager.checkPermission(java.base at 9-internal/SecurityManager.java:548)
>
> at
> jdk.internal.reflect.ReflectionFactory.getReflectionFactory(java.base at 9-internal/ReflectionFactory.java:132)
>
> at
> jdk.internal.reflect.ReflectionFactory$GetReflectionFactoryAction.run(java.base at 9-internal/ReflectionFactory.java:106)
>
> at
> jdk.internal.reflect.ReflectionFactory$GetReflectionFactoryAction.run(java.base at 9-internal/ReflectionFactory.java:103)
>
> at
> java.security.AccessController.doPrivileged(java.base at 9-internal/Native
> Method)
> at
> java.lang.PublicMethods$Key.<clinit>(java.base at 9-internal/PublicMethods.java:90)
>
> at
> java.lang.PublicMethods$MethodList.filter(java.base at 9-internal/PublicMethods.java:151)
>
> at
> java.lang.Class.getMethodsRecursive(java.base at 9-internal/Class.java:3191)
> at java.lang.Class.getMethod0(java.base at 9-internal/Class.java:3175)
> at java.lang.Class.getMethod(java.base at 9-internal/Class.java:2036)
> at
> java.lang.invoke.VarHandle$AccessMode.getReturnType(java.base at 9-internal/VarHandle.java:1826)
>
> at
> java.lang.invoke.VarHandle$AccessMode.<init>(java.base at 9-internal/VarHandle.java:1792)
>
> at
> java.lang.invoke.VarHandle$AccessMode.<clinit>(java.base at 9-internal/VarHandle.java:1590)
>
> at
> java.lang.invoke.VarForm.linkFromStatic(java.base at 9-internal/VarForm.java:127)
>
> at java.lang.invoke.VarForm.<init>(java.base at 9-internal/VarForm.java:50)
> at
> java.lang.invoke.VarHandleObjects$FieldInstanceReadOnly.<clinit>(java.base at 9-internal/VarHandleObjects.java:84)
>
> at
> java.lang.invoke.VarHandles.makeFieldHandle(java.base at 9-internal/VarHandles.java:38)
>
> at
> java.lang.invoke.MethodHandles$Lookup.getFieldVarHandleCommon(java.base at 9-internal/MethodHandles.java:2241)
>
> at
> java.lang.invoke.MethodHandles$Lookup.getFieldVarHandle(java.base at 9-internal/MethodHandles.java:2201)
>
> at
> java.lang.invoke.MethodHandles$Lookup.findVarHandle(java.base at 9-internal/MethodHandles.java:1361)
>
> at
> java.util.concurrent.atomic.AtomicReference.<clinit>(java.base at 9-internal/AtomicReference.java:57)
>
> at java.security.Policy.<clinit>(java.base at 9-internal/Policy.java:111)
> at
> java.security.AccessControlContext.getDebug(java.base at 9-internal/AccessControlContext.java:110)
>
> at
> java.security.AccessControlContext.checkPermission(java.base at 9-internal/AccessControlContext.java:398)
>
> at
> java.security.AccessController.checkPermission(java.base at 9-internal/AccessController.java:894)
>
> at
> java.lang.SecurityManager.checkPermission(java.base at 9-internal/SecurityManager.java:548)
>
> at
> java.lang.SecurityManager.checkPropertyAccess(java.base at 9-internal/SecurityManager.java:1292)
>
> at java.lang.System.getProperty(java.base at 9-internal/System.java:761)
> at
> java.lang.ClassLoader.initSystemClassLoader(java.base at 9-internal/ClassLoader.java:1902)
>
> at java.lang.System.initPhase3(java.base at 9-internal/System.java:1979)
>
>
> But even before my change, Class::getMethod needed access to
> ReflectionFactory instance. To remind: each reflective object (Method,
> Field, Constructor) is copied before handed out of a public method such
> as Class::getMethod. Copying is performed by ReflectionFactory.
> ReflectionFactory in java.lang.Class is obtained lazily:
>
>     // Fetches the factory for reflective objects
>     private static ReflectionFactory getReflectionFactory() {
>         if (reflectionFactory == null) {
>             reflectionFactory =
>                 java.security.AccessController.doPrivileged
>                     (new ReflectionFactory.GetReflectionFactoryAction());
>         }
>         return reflectionFactory;
>     }
>     private static ReflectionFactory reflectionFactory;
>
> ...so the only way for this to not cause the same problem is for
> Class.reflectionFactory field to be initialized before SecurityManager
> is set.
>
> Was this pure luck and we were just waiting for a situation where this
> was not the case?
>
> It is good that this danger is now past as java.security.Policy does not
> need AtomicReference any more.
>
> Regards, Peter
>
>>
>> That said, I am an admirer of your work on OpenJDK! :)
>>
>> Cheers,
>> David
>>
>>
>> On 27/12/2016 5:29 AM, Peter Levart wrote:
>>> Hi,
>>>
>>> There are 2 ReflectionFactory classes in JDK 9. The old one is
>>> sun.reflect.ReflectionFactory which ended in jdk.unsupported module and
>>> to which access is restricted with SecurityManager. There is also new
>>> jdk.internal.reflect.ReflectionFactory which is used internally by JDK,
>>> is exported to internal modules only but still uses SecurityManager to
>>> restrict access to itself. I checked all usages and they all use
>>> AccessControler.doPrivileged() for obtaining the instance of
>>> jdk.internal.reflect.ReflectionFactory, which somehow defeats the
>>> purpose of SecurityManager access checks in this API.
>>>
>>> I think this could be simplified by removing the SecurityManager check
>>> from jdk.internal.reflect.ReflectionFactory#getReflectionFactory static
>>> method and change all usages to invoke this method directly without
>>> doPrivileged(). There are already two sensitive internal APIs exposed
>>> without SecurityManager checks: jdk.internal.misc.Unsafe#getUnsafe and
>>> various jdk.internal.misc.SharedSecrets#getXxxAccess methods. So why
>>> wouldn't internal ReflectionFactory be exposed the same way?
>>>
>>> This would make obtaining the ReflectionFactory more robust and not
>>> sensitive to bootstrap issues that surfaced recently after my push of a
>>> fix for issues 8062389, 8029459, 8061950.
>>>
>>> So, what do you think? Is this a worthwhile cleanup and simplification?
>>>
>>> Regards, Peter
>>>
>

From Alan.Bateman at oracle.com  Wed Jan  4 08:45:38 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 4 Jan 2017 08:45:38 +0000
Subject: MethodHandle initialization process - problem with JVM TI early
	VM start event
In-Reply-To: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
References: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
Message-ID: <a19f2dfc-0aaf-1a63-d098-4c9ccbf96c24@oracle.com>

On 04/01/2017 03:11, David Holmes wrote:

> We have encountered a crash in a JVM TI test, starting with b148, that 
> is caused by the attempted use of MethodRefs and invoke_dynamic within 
> class loading that occurs from the "early VM start" JVM TI event 
> callback - which happens before the VM and core classes are fully 
> initialized. The class being loaded/initialized is in java.base and so 
> this is allowed. The class, java.net.Authenticator, was changed in 
> b148 to have static initialization involving method refs and hence the 
> problem was introduced.
>
> I've included a stack dump below.
>
> It is far from clear to me where responsibility for this lies, or even 
> how to narrow that down. Is it in the code of MethodHandleNatives? Or 
> is it in the VM linking/resolution code?
>
> Thoughts appreciated. :)
Ugh, this looks like the callback for the VMStart event is triggering 
the execution of arbitrary code via its initializer. When the 
can_generate_early_vmstart capability is enabled then the VMStart event 
is posted before the system classes are initialized (before 
Threads::initialize_java_lang_classes is called). If the callbacks uses 
JNI FindClass to load classes in java.base (it's restricted to java.base 
in this phase) then it will trigger the execution of random bytecode 
with all sort of consequences. Even if the system classes are 
initialized then it can still cause all sorts of issues - e.g. 
triggering code in classes such as ResourceBundle and elsewhere that 
depend on the system class loader to be initialized. For the specific 
crash then it looks like MethodHandleNatives has asserts and so 
Class::desiredAssertionStatus will be invoked to test if assertions are 
enabled but, as I say, there are lots of other reasons that would cause 
random classes in java.base to fail when invoked before the system 
classes are initialized.

The reason this event is called so early is to allow native (not java) 
agents get other events during startup. Also it's not new that this 
event is posted before the system classes are initialized, you'll see 
the same with JDK 8 and older because VMStart was always posted very 
early. In JDK 9 then the VMStart is only posted early when the 
can_generate_early_vmstart capability is enabled. This chage.

As regards fixing this then I don't think it would be unreasonable to 
put some restrictions on what can be done in the VMStart callback when 
can_generate_early_vmstart capability is enabled. Maybe it could be just 
further re-wording of the paragraph on what can be done in this phase 
rather than trying to enforce it.

-Alan

From david.holmes at oracle.com  Wed Jan  4 10:39:54 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Jan 2017 20:39:54 +1000
Subject: MethodHandle initialization process - problem with JVM TI early
	VM start event
In-Reply-To: <a19f2dfc-0aaf-1a63-d098-4c9ccbf96c24@oracle.com>
References: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
	<a19f2dfc-0aaf-1a63-d098-4c9ccbf96c24@oracle.com>
Message-ID: <6e9159e6-4ef0-01b7-5f9f-d949c846f57b@oracle.com>

Hi Alan,

On 4/01/2017 6:45 PM, Alan Bateman wrote:
> On 04/01/2017 03:11, David Holmes wrote:
>
>> We have encountered a crash in a JVM TI test, starting with b148, that
>> is caused by the attempted use of MethodRefs and invoke_dynamic within
>> class loading that occurs from the "early VM start" JVM TI event
>> callback - which happens before the VM and core classes are fully
>> initialized. The class being loaded/initialized is in java.base and so
>> this is allowed. The class, java.net.Authenticator, was changed in
>> b148 to have static initialization involving method refs and hence the
>> problem was introduced.
>>
>> I've included a stack dump below.
>>
>> It is far from clear to me where responsibility for this lies, or even
>> how to narrow that down. Is it in the code of MethodHandleNatives? Or
>> is it in the VM linking/resolution code?
>>
>> Thoughts appreciated. :)
> Ugh, this looks like the callback for the VMStart event is triggering
> the execution of arbitrary code via its initializer. When the
> can_generate_early_vmstart capability is enabled then the VMStart event
> is posted before the system classes are initialized (before
> Threads::initialize_java_lang_classes is called). If the callbacks uses
> JNI FindClass to load classes in java.base (it's restricted to java.base
> in this phase) then it will trigger the execution of random bytecode
> with all sort of consequences. Even if the system classes are
> initialized then it can still cause all sorts of issues - e.g.
> triggering code in classes such as ResourceBundle and elsewhere that
> depend on the system class loader to be initialized. For the specific
> crash then it looks like MethodHandleNatives has asserts and so
> Class::desiredAssertionStatus will be invoked to test if assertions are
> enabled but, as I say, there are lots of other reasons that would cause
> random classes in java.base to fail when invoked before the system
> classes are initialized.

Right.

> The reason this event is called so early is to allow native (not java)
> agents get other events during startup. Also it's not new that this
> event is posted before the system classes are initialized, you'll see
> the same with JDK 8 and older because VMStart was always posted very
> early. In JDK 9 then the VMStart is only posted early when the
> can_generate_early_vmstart capability is enabled. This chage.
>
> As regards fixing this then I don't think it would be unreasonable to
> put some restrictions on what can be done in the VMStart callback when
> can_generate_early_vmstart capability is enabled. Maybe it could be just
> further re-wording of the paragraph on what can be done in this phase
> rather than trying to enforce it.

That is my thought too, that the spec needs to give less of the 
impression that it's okay to access java.base classes at this early VM 
start event, and basically say that any form of class-loading is not 
guaranteed to succeed and will quite likely crash the JVM.

The test can then be modified accordingly.

Thanks,
David

> -Alan

From Alan.Bateman at oracle.com  Wed Jan  4 12:15:30 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 4 Jan 2017 12:15:30 +0000
Subject: MethodHandle initialization process - problem with JVM TI early
	VM start event
In-Reply-To: <6e9159e6-4ef0-01b7-5f9f-d949c846f57b@oracle.com>
References: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
	<a19f2dfc-0aaf-1a63-d098-4c9ccbf96c24@oracle.com>
	<6e9159e6-4ef0-01b7-5f9f-d949c846f57b@oracle.com>
Message-ID: <85144bff-a1b4-bb64-c138-8bec26ea5323@oracle.com>

On 04/01/2017 10:39, David Holmes wrote:

>
> That is my thought too, that the spec needs to give less of the 
> impression that it's okay to access java.base classes at this early VM 
> start event, and basically say that any form of class-loading is not 
> guaranteed to succeed and will quite likely crash the JVM.
The JVM TI spec has always allowed agents to call any JNI function in 
the start phase. I don't think there was any intention to have agents 
load and execute arbitrary java code but this wasn't fully spelled out. 
For JDK 9 then we attempt to preserve this compatibility for existing 
agents by deferring the start phase until after the module system is 
initialized (initPhase2). This has the side effect that they miss out on 
some interesting events during startup. They can of course replay at 
least some of them with GenerateEvents but it's not enough for some 
agents. So this is the reason for the can_generate_early_vmstart 
capability and it's intended for agents that take an oath of carefulness.

So for the spec update then I think the restrictions can be mostly 
limited to when the can_generate_early_vmstart capability is enabled. 
Ideally we should avoid introducing yet another event that signals the 
point in the start phase when it's safe to do things, agents can use the 
VMInit for that.

-Alan

From Alan.Bateman at oracle.com  Wed Jan  4 14:57:15 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 4 Jan 2017 14:57:15 +0000
Subject: Review Request: JDK-8172215 java launcher no longer accepts -cp
	"" empty string
In-Reply-To: <D37641BF-31CB-44AB-912D-1EB14A444D2D@oracle.com>
References: <5BB8D5D6-BBDC-4FDA-990E-8FF15C8A1E34@oracle.com>
	<59E624FA-EC93-4D45-9E7E-3D9661E0DC75@oracle.com>
	<D37641BF-31CB-44AB-912D-1EB14A444D2D@oracle.com>
Message-ID: <7f332a88-3f85-4b60-6cd7-9277e298beda@oracle.com>

On 04/01/2017 02:03, Mandy Chung wrote:

>> On Jan 3, 2017, at 5:23 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>
>>
>>> On 3 Jan 2017, at 15:59, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>
>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172215/webrev.00/
>>>
>>> This fixes the regression caused by JDK-8168836 such that java -cp ?? would be accepted. It?s surprise that no launcher test covering such test case.  Now it?s added in JavaClassPathTest.
>>>
>>> This patch also renames the testlibrary ModuleSourceBuilder to ModuleInfoMaker as Alan suggested.
>>>
>> 213     private static boolean isWindows = System.getProperty("os.name?)
>>
>> Make it final and rename to IS_WINDOWS ?
>
> Sure. Updated in place.
>
>
The change to libjli/java.c looks good and good to have more test 
coverage for these corner cases in JavaClassPathTest.java.

For IS_WINDOWS then having is final and simply doing 
System.getProperty("os.name").startsWith("Windows") should be fine.

-Alan

From Roger.Riggs at Oracle.com  Wed Jan  4 15:41:44 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 4 Jan 2017 10:41:44 -0500
Subject: JDK 9 RFR of JDK-8172200: Mark StressLoopback.java as
	intermittently failing
In-Reply-To: <6d696e1a-e728-cbbe-a275-9f7b218e6313@oracle.com>
References: <6d696e1a-e728-cbbe-a275-9f7b218e6313@oracle.com>
Message-ID: <a26ac141-e165-2291-29fc-9bcf73604235@Oracle.com>

Looks fine Joe.


On 1/3/2017 7:27 PM, joe darcy wrote:
> Hello,
>
> The test
>
> java/nio/channels/AsynchronousSocketChannel/StressLoopback.java
>
> intermittently fails on Solaris x64 on one of our testing systems. The 
> test should be marked accordingly. Please review the patch below which 
> does this.
>
> Thanks,
>
> -Joe
>
> diff -r d27bab22ff62 
> test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java
> --- 
> a/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java 
> Mon Jan 02 22:45:34 2017 +0100
> +++ 
> b/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java 
> Tue Jan 03 16:26:21 2017 -0800
> @@ -26,7 +26,7 @@
>   * @summary Stress test connections through the loopback interface
>   * @run main StressLoopback
>   * @run main/othervm -Djdk.net.useFastTcpLoopback StressLoopback
> - * @key randomness
> + * @key randomness intermittent
>   */
>
>  import java.nio.ByteBuffer;
>


From Roger.Riggs at Oracle.com  Wed Jan  4 15:57:50 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 4 Jan 2017 10:57:50 -0500
Subject: RFR: 8170785: Excessive allocation in ParseUtil.encodePath
In-Reply-To: <00629ee8-ed4c-3352-1a36-ff8a35cd82b6@oracle.com>
References: <7ae2434a-da5b-ec52-c4cc-0dc8631c6eb1@oracle.com>
	<aec49ffa-5b02-02e2-b304-668569860ff0@Oracle.com>
	<00629ee8-ed4c-3352-1a36-ff8a35cd82b6@oracle.com>
Message-ID: <194b11ab-54e2-f265-9ee6-687b0be9c303@Oracle.com>

Hi Claes,

ok, I didn't spot any bugs so its fine as is.


On 1/3/2017 5:52 PM, Claes Redestad wrote:
> Hi Roger,
>
> On 2017-01-03 22:22, Roger Riggs wrote:
>> Hi Claes,
>>
>> So Windows didn't suffer from having the '\' separator.
>
> relatively speaking Windows won't see any speed-up when dealing
> with file system paths, but most places where we see encodePath in
> profiles is actually not files: jar/runtime image paths, HTTP etc...
>
> Thus Windows shouldn't be left too far behind for typical workloads. :-)
>
>>
>> ParseUtil:
>>
>> firstEncodeIndex:121:
>>   'a' - 'z' seems more frequent than '/' or '.'; does it improve the
>> stats to move that range to the beginning of the if.
>>   (yes the compiler can re-order).
>>
>> line 125:
>>     Since 127 is known to need encoding it could be >= 0x007f
>>
>> line  136: I suppose the arraycopy intrinsic already optimizes length 
>> == 0;
>>
>> Line 134:  I question the math on  * 2 + 16 -index;  (But this is
>> pre-existing code)
>>    if there were lots of characters that needed encoding it might be
>> possible to overflow the array since 1 char is replaced by at least 3
>> and up to 9.
>>    16 seems like a questionable fudge factor; but perhaps it has not
>> been a problem in practice.
>
> As the main objective here is to get rid of the allocations while not
> regressing throughput when they can't be avoided I resisted *most*
> urges to micro-optimize. :-)
>
> The weird heuristic with len * 2 + 16 is ugly, yes, but I prefer to
> leave it mostly alone and perhaps revisit this for a throughput
> performance enhancement in the future.
>
> '/' can actually be rather frequent in paths, and while '.' is likely
> less common and should have been inserted after a-z, adding the check
> improved performance of encoding to-be-rather-common paths like
> "/java.base/bla/bla/bla/" remarkably while not visibly regressing
> anything else.
>
> What is clear from micros is that having to load and call into the
> BitSet has a relatively large overhead compared to an extra comparison
> (which is likely why there are separate checks for a-z, A-Z and 0-9 in
> the first place).
A good optimizer should be able to bisect and get the result efficiently 
given the constant values.
>
> I should actually see if we can't remove the BitSet entirely: I think
> the java.net.URI approach with final long masks and a simple shift and
> check might be more efficient and relatively easy to duplicate here.
A couple of fixed 64-bit compile time bitmasks computed from the set of 
encoded chars would be pretty efficient and compact too.
I did wonder if there was a way to have a common utility for the encoding;
but that's probably something to save for later.

Roger
>
> Thanks!
>
> /Claes
>
>>
>> $.02, Roger
>>
>>
>>
>> On 1/3/2017 9:46 AM, Claes Redestad wrote:
>>> Hi,
>>>
>>> some users reports high allocation rates in ParseUtil.encodePath,
>>> regardless of whether paths actually need to be encoded or not.
>>> Since this is a commonly used utility it makes sense.
>>>
>>> Webrev: http://cr.openjdk.java.net/~redestad/8170785/webrev.01
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170785
>>>
>>> This patch provides a semantically neutral fast-path for cases when
>>> the path does not need to be encoded (up to 5x speedup), reduces
>>> allocation when the string has a prefix that does not need to be
>>> encoded (1-2x speedup) and no regression when using a separator
>>> that's not '/' or the first char needs encoding.
>>>
>>> Interpreted performance is not affected much either: small positive
>>> when no encoding is needed, neutral or negligible regression
>>> otherwise.
>>>
>>> Thanks!
>>>
>>> /Claes
>>


From claes.redestad at oracle.com  Wed Jan  4 16:30:22 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 4 Jan 2017 17:30:22 +0100
Subject: RFR 8172190: Re-apply the fix for bugs 8062389, 8029459, 8061950
In-Reply-To: <43c44b23-2026-e5c6-5ea8-f926a605966f@oracle.com>
References: <C13D1340-C38B-4B6A-B80A-DA5A5CEC1891@oracle.com>
	<ac24d255-09a6-7c29-37f3-eeaf2139f100@gmail.com>
	<221ca324-be41-9c74-89be-606e31ae93d3@gmail.com>
	<98DA94D5-F43B-491C-8DE7-EE2FF030920B@oracle.com>
	<47940b37-b09c-0888-d031-beefe9f5bcab@oracle.com>
	<09F19C0B-B0D8-4FF2-BD53-080EAAEA8974@oracle.com>
	<ef0bd907-1805-f306-e89c-95ec1e3acfff@oracle.com>
	<7a95546d-4b5b-190b-46db-3a6f3168eece@gmail.com>
	<0a5e77dd-3b3d-0231-138f-8b03699eeea1@gmail.com>
	<43c44b23-2026-e5c6-5ea8-f926a605966f@oracle.com>
Message-ID: <6ccde80c-7d68-ac48-9683-462fbac2470a@oracle.com>

Hi,

no new failures - seems good to go unless someone objects to the
NPE behavior change.

Thanks!

/Claes

On 2017-01-03 18:15, Claes Redestad wrote:
> Hi Peter,
>
> letting you know I've submitted a build and test job for this to run
> over night.
>
> Thanks!
>
> /Claes
>
> On 01/03/2017 05:52 PM, Peter Levart wrote:
>> Hi,
>>
>> Now that initialization cycle has been broken by Claes' fix for:
>>
>>      https://bugs.openjdk.java.net/browse/JDK-8172048
>>
>> I prepared a revised fix for issues described in the following bugs:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8062389
>>     https://bugs.openjdk.java.net/browse/JDK-8029459
>>     https://bugs.openjdk.java.net/browse/JDK-8061950
>>
>> ...now tracked by bug:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8172190
>>
>> The revised webrev is here:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.10/
>>
>>
>> The incremental change from webrev.09 is the following:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.09to10/
>>
>>
>>
>> Besides fixing one failing test (StarInheritance) that now has to
>> account for new behavior of Class.getMethods(), some tests also failed
>> because of the changed behavior (not throwing NPE) when passing null
>> 'name' parameter to Class.get[Declared][Method|Field] methods. This
>> was a straight bug introduced by me and caught by tests which I
>> haven't re-run after introducing it. I apologize for that and promise
>> to be more careful in the future. In original code the NPE was thrown
>> by private Class.searchFields and searchMethods in the part of code
>> where the 'name' parameter was interned. I replaced interning and
>> reference comparison with equality comparison, which is faster and
>> does not trash the String interning cache with names that are later
>> not found as members of classes, but I forgot to introduce explicit
>> nonNull check for the 'name' argument.
>>
>> I now intentionally inserted the nonNull checks in front of the
>> security checks in public-facing methods although this introduces a
>> little behavioral change. I choose that because:
>>
>> - The javadocs list NullPointerException before the SecurityException
>> (for example in getField):
>>
>>      * @throws NullPointerException if {@code name} is {@code null}
>>      * @throws SecurityException
>>      *         If a security manager, <i>s</i>, is present and
>>      *         the caller's class loader is not the same as or an
>>      *         ancestor of the class loader for the current class and
>>      *         invocation of {@link SecurityManager#checkPackageAccess
>>      *         s.checkPackageAccess()} denies access to the package
>>      *         of this class.
>>
>> - I think it is more correct for methods to 1st check parameters
>> before throwing any other state related exceptions.
>>
>> But if you think this behavioral change is not justified, I can
>> reverse the order of checks and prepare new webrev.
>>
>> I have successfully executed java/lang tests and all tier 1 tests that
>> failed when webrev.09 was pushed, mentioned in:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8171988
>>
>>
>> But don't take my word for it. Can someone please run webrev.10
>> through the tests on Oracle side before confirming the change?
>>
>>
>> Thanks,
>>
>> Peter Levart
>>
>>
>> On 12/26/2016 07:31 PM, Peter Levart wrote:
>>> Hi,
>>>
>>> I see there remaining failures are not trivial to fix in a hurry. So
>>> I think it's better to just backout this change and than prepare new
>>> fix...
>>>
>>> I'm pushing this backout now.
>>>
>>> Regards, Peter
>>>
>>>
>>> On 12/26/2016 06:55 PM, Claes Redestad wrote:
>>>> Hi,
>>>>
>>>> many of the tier 1 failures listed seems to fail due to a cyclic
>>>> bootstrap dependency on the new PublicMethods -> Policy.isSet() ->
>>>> ... -> PublicMethods that appears in all tests which install a
>>>> security manager.
>>>>
>>>> It turns out the dependency is only there (Policy.isSet) to ensure the
>>>> VM has booted to a state where System.getProperty will return actual
>>>> values to feed into sun.security.util.Debug (the state of which does
>>>> not in any way vary with Policy), and could be replaced by the new
>>>> VM.isBooted() (or VM.initLevel() > 1):
>>>>
>>>> http://cr.openjdk.java.net/~redestad/scratch/8171988.01/
>>>>
>>>> With this most test failures disappear, but there are still 5 tests
>>>> in java/lang/Class which fail with a message more directly related to
>>>> the changes:
>>>>
>>>> expected java.lang.NullPointerException for null -- FAILED
>>>>
>>>> Perhaps problem list these 5 together with the above change as a fix to
>>>> this issue?
>>>>
>>>> Thanks!
>>>>
>>>> /Claes
>>>>
>>>> On 2016-12-26 18:30, Chris Hegarty wrote:
>>>>>
>>>>>> On 26 Dec 2016, at 16:26, joe darcy <joe.darcy at oracle.com> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Assuming we'll want to revisit this work at some point, there are
>>>>>> some advantages to anti-delta-ing the code changes now, but just
>>>>>> problem listing the tests in terms of making a less confusing
>>>>>> history.
>>>>>
>>>>> My preference is to anti-delta. There are just too many tests
>>>>> failing, ~35 across all platforms and tiers.
>>>>>
>>>>> Peter,
>>>>>   Let me know if you need any help pushing this.
>>>>>
>>>>> -Chris.
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>>
>>>>>> On 12/26/2016 1:58 AM, Chris Hegarty wrote:
>>>>>>>> On 26 Dec 2016, at 09:35, Peter Levart <peter.levart at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Jeff,
>>>>>>>>
>>>>>>>> I've been told that the latest change I pushed causes some tests
>>>>>>>> to fail, so I prepared a backout patch for 8062389, 8029459,
>>>>>>>> 8061950:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/
>>>>>>>> <http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/>
>>>>>>>>
>>>>>>> I just grabbed the webrev patch, applied it to a local repo, then
>>>>>>> compared that against a repo that had been updated to the
>>>>>>> change prior to your push. They are identical, so this appears
>>>>>>> to be an accurate anti-delta.
>>>>>>>
>>>>>>> Maybe file a new bug, or just make it clear in the synopsis of
>>>>>>> 8171988 that it is an anti-delta.
>>>>>>>
>>>>>>>
>>>>>>>> From the stacktrace of the bug report, it seems an early
>>>>>>>> initialization issue with VarHandle(s) involved. Can you shed
>>>>>>>> some light into what tests are failing?
>>>>>>> I?ll post a few comments in 8171988 with sample failures.
>>>>>>>
>>>>>>> -Chris.
>>>>>>>
>>>>>>>> But first let us backout that change.
>>>>>>>>
>>>>>>>> Regards, Peter
>>>>>>>>
>>>>>>>>> On 12/26/2016 10:09 AM, Peter Levart wrote:
>>>>>>>>> Hi Jeff,
>>>>>>>>>
>>>>>>>>> I'm taking a look at this...
>>>>>>>>>
>>>>>>>>> Regards, Peter
>>>>>>>>>
>>>>>>>>>> On 12/26/2016 06:14 AM, Jeff Dinkins wrote:
>>>>>>>>>> Hi Peter -
>>>>>>>>>>
>>>>>>>>>> I just received mail from out SQE manager, saying that your
>>>>>>>>>> last changeset has caused our test harness to hiccup.  I don?t
>>>>>>>>>> have much more detail besides the below bug, but I?m wondering
>>>>>>>>>> if you could do us a huge favor and roll your change back for
>>>>>>>>>> now while it?s debugged (and so we can get our automated tests
>>>>>>>>>> going again).
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171988
>>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8171988>
>>>>>>>>>>
>>>>>>>>>> thanks!
>>>>>>>>>>
>>>>>>>>>> -jeff
>>>>>>>>>>
>>>>>>
>>>>>
>>>
>>
>

From claes.redestad at oracle.com  Wed Jan  4 17:29:48 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 4 Jan 2017 18:29:48 +0100
Subject: RFR: 8170785: Excessive allocation in ParseUtil.encodePath
In-Reply-To: <194b11ab-54e2-f265-9ee6-687b0be9c303@Oracle.com>
References: <7ae2434a-da5b-ec52-c4cc-0dc8631c6eb1@oracle.com>
	<aec49ffa-5b02-02e2-b304-668569860ff0@Oracle.com>
	<00629ee8-ed4c-3352-1a36-ff8a35cd82b6@oracle.com>
	<194b11ab-54e2-f265-9ee6-687b0be9c303@Oracle.com>
Message-ID: <0d7b3654-7229-5ad0-50cb-545ce68de412@oracle.com>

Hi Roger,

On 2017-01-04 16:57, Roger Riggs wrote:
> Hi Claes,
>
> ok, I didn't spot any bugs so its fine as is.

thanks!

>
>
> On 1/3/2017 5:52 PM, Claes Redestad wrote:
>> Hi Roger,
>>
>> On 2017-01-03 22:22, Roger Riggs wrote:
>>> Hi Claes,
>>>
>>> So Windows didn't suffer from having the '\' separator.
>>
>> relatively speaking Windows won't see any speed-up when dealing
>> with file system paths, but most places where we see encodePath in
>> profiles is actually not files: jar/runtime image paths, HTTP etc...
>>
>> Thus Windows shouldn't be left too far behind for typical workloads. :-)
>>
>>>
>>> ParseUtil:
>>>
>>> firstEncodeIndex:121:
>>>   'a' - 'z' seems more frequent than '/' or '.'; does it improve the
>>> stats to move that range to the beginning of the if.
>>>   (yes the compiler can re-order).
>>>
>>> line 125:
>>>     Since 127 is known to need encoding it could be >= 0x007f
>>>
>>> line  136: I suppose the arraycopy intrinsic already optimizes length
>>> == 0;
>>>
>>> Line 134:  I question the math on  * 2 + 16 -index;  (But this is
>>> pre-existing code)
>>>    if there were lots of characters that needed encoding it might be
>>> possible to overflow the array since 1 char is replaced by at least 3
>>> and up to 9.
>>>    16 seems like a questionable fudge factor; but perhaps it has not
>>> been a problem in practice.
>>
>> As the main objective here is to get rid of the allocations while not
>> regressing throughput when they can't be avoided I resisted *most*
>> urges to micro-optimize. :-)
>>
>> The weird heuristic with len * 2 + 16 is ugly, yes, but I prefer to
>> leave it mostly alone and perhaps revisit this for a throughput
>> performance enhancement in the future.
>>
>> '/' can actually be rather frequent in paths, and while '.' is likely
>> less common and should have been inserted after a-z, adding the check
>> improved performance of encoding to-be-rather-common paths like
>> "/java.base/bla/bla/bla/" remarkably while not visibly regressing
>> anything else.
>>
>> What is clear from micros is that having to load and call into the
>> BitSet has a relatively large overhead compared to an extra comparison
>> (which is likely why there are separate checks for a-z, A-Z and 0-9 in
>> the first place).
> A good optimizer should be able to bisect and get the result efficiently
> given the constant values.
>>
>> I should actually see if we can't remove the BitSet entirely: I think
>> the java.net.URI approach with final long masks and a simple shift and
>> check might be more efficient and relatively easy to duplicate here.
> A couple of fixed 64-bit compile time bitmasks computed from the set of
> encoded chars would be pretty efficient and compact too.
> I did wonder if there was a way to have a common utility for the encoding;
> but that's probably something to save for later.

Right, there are facilities for this in ParseUtil already (see match,
lowMask, highMask etc), and while not (javac) compile time constants
right now they probably could be.

Tested applying this approach to replace the BitSet, which seem to
improve thrpt slightly in isolation, but calling match is still quite a
bit slower than the sequence of range checks (c >= 'a' && c <= 'z')
etc, so in the end it wouldn't really change that much.

I'll defer further investigation to the future and go ahead and push
the patch as-is.

Thanks!

/Claes

>
> Roger
>>
>> Thanks!
>>
>> /Claes
>>
>>>
>>> $.02, Roger
>>>
>>>
>>>
>>> On 1/3/2017 9:46 AM, Claes Redestad wrote:
>>>> Hi,
>>>>
>>>> some users reports high allocation rates in ParseUtil.encodePath,
>>>> regardless of whether paths actually need to be encoded or not.
>>>> Since this is a commonly used utility it makes sense.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~redestad/8170785/webrev.01
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170785
>>>>
>>>> This patch provides a semantically neutral fast-path for cases when
>>>> the path does not need to be encoded (up to 5x speedup), reduces
>>>> allocation when the string has a prefix that does not need to be
>>>> encoded (1-2x speedup) and no regression when using a separator
>>>> that's not '/' or the first char needs encoding.
>>>>
>>>> Interpreted performance is not affected much either: small positive
>>>> when no encoding is needed, neutral or negligible regression
>>>> otherwise.
>>>>
>>>> Thanks!
>>>>
>>>> /Claes
>>>
>

From mandy.chung at oracle.com  Wed Jan  4 17:49:28 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 4 Jan 2017 09:49:28 -0800
Subject: Review Request: JDK-8172215 java launcher no longer accepts -cp
	"" empty string
In-Reply-To: <7f332a88-3f85-4b60-6cd7-9277e298beda@oracle.com>
References: <5BB8D5D6-BBDC-4FDA-990E-8FF15C8A1E34@oracle.com>
	<59E624FA-EC93-4D45-9E7E-3D9661E0DC75@oracle.com>
	<D37641BF-31CB-44AB-912D-1EB14A444D2D@oracle.com>
	<7f332a88-3f85-4b60-6cd7-9277e298beda@oracle.com>
Message-ID: <C53E8D63-F954-4EFA-AE73-F7D75A2ABFDB@oracle.com>


> On Jan 4, 2017, at 6:57 AM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> On 04/01/2017 02:03, Mandy Chung wrote:
> 
>>> On Jan 3, 2017, at 5:23 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>> 
>>> 
>>>> On 3 Jan 2017, at 15:59, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>> 
>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8172215/webrev.00/
>>>> 
>>>> This fixes the regression caused by JDK-8168836 such that java -cp ?? would be accepted. It?s surprise that no launcher test covering such test case.  Now it?s added in JavaClassPathTest.
>>>> 
>>>> This patch also renames the testlibrary ModuleSourceBuilder to ModuleInfoMaker as Alan suggested.
>>>> 
>>> 213     private static boolean isWindows = System.getProperty("os.name?)
>>> 
>>> Make it final and rename to IS_WINDOWS ?
>> 
>> Sure. Updated in place.
>> 
>> 
> The change to libjli/java.c looks good and good to have more test coverage for these corner cases in JavaClassPathTest.java.
> 
> For IS_WINDOWS then having is final and simply doing System.getProperty("os.name").startsWith("Windows") should be fine.

Updated.
Mandy


From lance.andersen at oracle.com  Wed Jan  4 19:52:06 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 4 Jan 2017 14:52:06 -0500
Subject: RFR: 8172254: Typo in DriverManager implNote
Message-ID: <1EB2F828-CFC7-453E-9852-D324E1C4A34E@oracle.com>

Hi all,

The following bug addresses a typo which was not caught via the build process:

??????
ljanders$ hg diff
diff -r d27bab22ff62 src/java.sql/share/classes/java/sql/DriverManager.java
--- a/src/java.sql/share/classes/java/sql/DriverManager.java	Mon Jan 02 22:45:34 2017 +0100
+++ b/src/java.sql/share/classes/java/sql/DriverManager.java	Wed Jan 04 14:46:16 2017 -0500
@@ -64,7 +64,7 @@
  *</ul>
  *
  *<P>
- * @ImplNote
+ * @implNote
  * {@code DriverManager} initialization is done lazily and looks up service
  * providers using the thread context class loader.  The drivers loaded and
  * available to an application will depend on the thread context class loader of
ljanders-mac:jdk ljanders$ 

????????

This prevented the @implNote from being generated.

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 mandy.chung at oracle.com  Wed Jan  4 19:54:03 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 4 Jan 2017 11:54:03 -0800
Subject: RFR: 8172254: Typo in DriverManager implNote
In-Reply-To: <1EB2F828-CFC7-453E-9852-D324E1C4A34E@oracle.com>
References: <1EB2F828-CFC7-453E-9852-D324E1C4A34E@oracle.com>
Message-ID: <F6C35578-56C5-431D-AAE0-6F593D95E16B@oracle.com>


> On Jan 4, 2017, at 11:52 AM, Lance Andersen <lance.andersen at oracle.com> wrote:
> 
> Hi all,
> 
> The following bug addresses a typo which was not caught via the build process:
> 

Does javadoc generate a warning?

The patch looks good.

Mandy

> ??????
> ljanders$ hg diff
> diff -r d27bab22ff62 src/java.sql/share/classes/java/sql/DriverManager.java
> --- a/src/java.sql/share/classes/java/sql/DriverManager.java	Mon Jan 02 22:45:34 2017 +0100
> +++ b/src/java.sql/share/classes/java/sql/DriverManager.java	Wed Jan 04 14:46:16 2017 -0500
> @@ -64,7 +64,7 @@
>  *</ul>
>  *
>  *<P>
> - * @ImplNote
> + * @implNote
>  * {@code DriverManager} initialization is done lazily and looks up service
>  * providers using the thread context class loader.  The drivers loaded and
>  * available to an application will depend on the thread context class loader of
> ljanders-mac:jdk ljanders$ 
> 
> ????????
> 
> This prevented the @implNote from being generated.
> 
> 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 Alan.Bateman at oracle.com  Wed Jan  4 19:54:39 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 4 Jan 2017 19:54:39 +0000
Subject: RFR: 8172254: Typo in DriverManager implNote
In-Reply-To: <1EB2F828-CFC7-453E-9852-D324E1C4A34E@oracle.com>
References: <1EB2F828-CFC7-453E-9852-D324E1C4A34E@oracle.com>
Message-ID: <20e3387d-604e-1f89-99b4-47f3a1e8a934@oracle.com>



On 04/01/2017 19:52, Lance Andersen wrote:
> Hi all,
>
> The following bug addresses a typo which was not caught via the build process:
>
> ??????
> ljanders$ hg diff
> diff -r d27bab22ff62 src/java.sql/share/classes/java/sql/DriverManager.java
> --- a/src/java.sql/share/classes/java/sql/DriverManager.java	Mon Jan 02 22:45:34 2017 +0100
> +++ b/src/java.sql/share/classes/java/sql/DriverManager.java	Wed Jan 04 14:46:16 2017 -0500
> @@ -64,7 +64,7 @@
>    *</ul>
>    *
>    *<P>
> - * @ImplNote
> + * @implNote
>
Looks fine.

-Alan

From lance.andersen at oracle.com  Wed Jan  4 19:55:30 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 4 Jan 2017 14:55:30 -0500
Subject: RFR: 8172254: Typo in DriverManager implNote
In-Reply-To: <F6C35578-56C5-431D-AAE0-6F593D95E16B@oracle.com>
References: <1EB2F828-CFC7-453E-9852-D324E1C4A34E@oracle.com>
	<F6C35578-56C5-431D-AAE0-6F593D95E16B@oracle.com>
Message-ID: <889625DD-3E5B-41C1-B083-B14715F2F0DE@oracle.com>


> On Jan 4, 2017, at 2:54 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> On Jan 4, 2017, at 11:52 AM, Lance Andersen <lance.andersen at oracle.com> wrote:
>> 
>> Hi all,
>> 
>> The following bug addresses a typo which was not caught via the build process:
>> 
> 
> Does javadoc generate a warning?
No it does not which is why I missed it when I did the build.
> 
> The patch looks good.

Thank you
> 
> Mandy
> 
>> ??????
>> ljanders$ hg diff
>> diff -r d27bab22ff62 src/java.sql/share/classes/java/sql/DriverManager.java
>> --- a/src/java.sql/share/classes/java/sql/DriverManager.java	Mon Jan 02 22:45:34 2017 +0100
>> +++ b/src/java.sql/share/classes/java/sql/DriverManager.java	Wed Jan 04 14:46:16 2017 -0500
>> @@ -64,7 +64,7 @@
>> *</ul>
>> *
>> *<P>
>> - * @ImplNote
>> + * @implNote
>> * {@code DriverManager} initialization is done lazily and looks up service
>> * providers using the thread context class loader.  The drivers loaded and
>> * available to an application will depend on the thread context class loader of
>> ljanders-mac:jdk ljanders$ 
>> 
>> ????????
>> 
>> This prevented the @implNote from being generated.
>> 
>> 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>
>> 
>> 
>> 
> 

 <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  Wed Jan  4 20:18:51 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 4 Jan 2017 15:18:51 -0500
Subject: RFR of JDK-8030175:
	java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due
	to timeout
In-Reply-To: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
Message-ID: <827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>

Hi Hamlin,

The original issue with timeout may be due to heavily loaded systems and 
short timeouts.
15 sec is not enough on an overloaded system to wait for a process to 
start and then die.

There is no indication in this issue about port-in-use; that would be a 
different issue.


Common comments to both A and B.

I'll need more time to look at B; it would be cleaner to use A if it can 
address the issue.
The alternative is to duplicate the code in run() in the TestLibrary and 
not modify the RegistryImpl.


JavaVM:
  - Document the new methods.

Line 232: Document the exception that may be thrown from exitValue.


RMID:
Line 204, 222: when adding new functions to the test library please add 
documentation for the methods.
There are now many variations of the methods that differ only by the 
number arguments.
It would be better if the name included some hint as to the additional 
functionality.

typo:  "additionalOptions" -> "add*i*tionalOptions"

REGISTRY:
   - Document the new methods.

   - The name should be more indicative of its function and should NOT 
be all caps;  RMID is an acronym where the caps make sense.

   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating code to 
wait for the subprocess.

   - If the subprocesses are in an unknown state it would be useful to 
print diagnostic info from the subprocess before terminating.
     Line 106:

  - Line 124:
  - I think I would have promoted the shutdown method to JavaVM instead 
of creating a new cleanup method
    to keep the code simpler.

    ** The cleanup method never calls super.cleanup() so the process is 
never destroyed!.

AltSecurityManager.java:

  - Line 61: the empty constructor can be removed entirely.

  - Line 80: change the message to say the exception did not occur.
     As written it implies it may have occurred but was not caught.

  - Line 86: typo "a unexpected" -> "an unexpected"

- Line 90: remove the printStackTrace; it is not useful and is a red 
flag in .jtr files

  - Line 125: I don't see that cleanup is better than destroy; If there 
are doubts about destroy
    then destroy should be fixed not avoided.

Roger




On 12/26/2016 3:51 AM, Hamlin Li wrote:
> Would you please review the below patches?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
> webrev (version A): http://cr.openjdk.java.net/~mli/8030175/webrev.00/
> webrev (version B): 
> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>
>
> There are 2 versions to be reviewed.
>
> In version A, just use RegistryRunner to replace rmiregistry.
> In version B, refactor sun.rmi.registry.RegistryImpl to improve the 
> testability of RMI code, and create/use RMIRegistryRunner to simulate 
> rmiregistry.
>
> Thank you
> -Hamlin


From david.holmes at oracle.com  Thu Jan  5 02:01:32 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Jan 2017 12:01:32 +1000
Subject: MethodHandle initialization process - problem with JVM TI early
	VM start event
In-Reply-To: <85144bff-a1b4-bb64-c138-8bec26ea5323@oracle.com>
References: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
	<a19f2dfc-0aaf-1a63-d098-4c9ccbf96c24@oracle.com>
	<6e9159e6-4ef0-01b7-5f9f-d949c846f57b@oracle.com>
	<85144bff-a1b4-bb64-c138-8bec26ea5323@oracle.com>
Message-ID: <ee6a64b4-fd11-4d55-73f4-9c9dc6daf397@oracle.com>

Hi Alan,

On 4/01/2017 10:15 PM, Alan Bateman wrote:
> On 04/01/2017 10:39, David Holmes wrote:
>
>>
>> That is my thought too, that the spec needs to give less of the
>> impression that it's okay to access java.base classes at this early VM
>> start event, and basically say that any form of class-loading is not
>> guaranteed to succeed and will quite likely crash the JVM.
> The JVM TI spec has always allowed agents to call any JNI function in
> the start phase. I don't think there was any intention to have agents
> load and execute arbitrary java code but this wasn't fully spelled out.

Yes the spec has always been completely broken in this regard IMHO.

> For JDK 9 then we attempt to preserve this compatibility for existing
> agents by deferring the start phase until after the module system is
> initialized (initPhase2). This has the side effect that they miss out on
> some interesting events during startup. They can of course replay at
> least some of them with GenerateEvents but it's not enough for some
> agents. So this is the reason for the can_generate_early_vmstart
> capability and it's intended for agents that take an oath of carefulness.

Understood.

> So for the spec update then I think the restrictions can be mostly
> limited to when the can_generate_early_vmstart capability is enabled.
> Ideally we should avoid introducing yet another event that signals the
> point in the start phase when it's safe to do things, agents can use the
> VMInit for that.

My precise intent is to modify the text that was added in regard to the 
can_generate_early_vmstart capability, and further reduce expectations 
about what can be expected to work at that time. I have filed a new bug 
to make this correction to the JVM TI spec:

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

Thanks,
David

> -Alan

From mandy.chung at oracle.com  Thu Jan  5 02:05:00 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 4 Jan 2017 18:05:00 -0800
Subject: RFR 8172190: Re-apply the fix for bugs 8062389, 8029459, 8061950
In-Reply-To: <6ccde80c-7d68-ac48-9683-462fbac2470a@oracle.com>
References: <C13D1340-C38B-4B6A-B80A-DA5A5CEC1891@oracle.com>
	<ac24d255-09a6-7c29-37f3-eeaf2139f100@gmail.com>
	<221ca324-be41-9c74-89be-606e31ae93d3@gmail.com>
	<98DA94D5-F43B-491C-8DE7-EE2FF030920B@oracle.com>
	<47940b37-b09c-0888-d031-beefe9f5bcab@oracle.com>
	<09F19C0B-B0D8-4FF2-BD53-080EAAEA8974@oracle.com>
	<ef0bd907-1805-f306-e89c-95ec1e3acfff@oracle.com>
	<7a95546d-4b5b-190b-46db-3a6f3168eece@gmail.com>
	<0a5e77dd-3b3d-0231-138f-8b03699eeea1@gmail.com>
	<43c44b23-2026-e5c6-5ea8-f926a605966f@oracle.com>
	<6ccde80c-7d68-ac48-9683-462fbac2470a@oracle.com>
Message-ID: <9B1041A6-A9A8-4A90-BEAD-F5EF7C1B5B0B@oracle.com>

I reviewed webrev.09to10.  The NPE check is fine.  I also ran the core tests and no surprise found.

Mandy

> On Jan 4, 2017, at 8:30 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> no new failures - seems good to go unless someone objects to the
> NPE behavior change.
> 
> Thanks!
> 
> /Claes
> 
> On 2017-01-03 18:15, Claes Redestad wrote:
>> Hi Peter,
>> 
>> letting you know I've submitted a build and test job for this to run
>> over night.
>> 
>> Thanks!
>> 
>> /Claes
>> 
>> On 01/03/2017 05:52 PM, Peter Levart wrote:
>>> Hi,
>>> 
>>> Now that initialization cycle has been broken by Claes' fix for:
>>> 
>>>     https://bugs.openjdk.java.net/browse/JDK-8172048
>>> 
>>> I prepared a revised fix for issues described in the following bugs:
>>> 
>>>    https://bugs.openjdk.java.net/browse/JDK-8062389
>>>    https://bugs.openjdk.java.net/browse/JDK-8029459
>>>    https://bugs.openjdk.java.net/browse/JDK-8061950
>>> 
>>> ...now tracked by bug:
>>> 
>>>    https://bugs.openjdk.java.net/browse/JDK-8172190
>>> 
>>> The revised webrev is here:
>>> 
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.10/
>>> 
>>> 
>>> The incremental change from webrev.09 is the following:
>>> 
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.09to10/
>>> 
>>> 
>>> 
>>> Besides fixing one failing test (StarInheritance) that now has to
>>> account for new behavior of Class.getMethods(), some tests also failed
>>> because of the changed behavior (not throwing NPE) when passing null
>>> 'name' parameter to Class.get[Declared][Method|Field] methods. This
>>> was a straight bug introduced by me and caught by tests which I
>>> haven't re-run after introducing it. I apologize for that and promise
>>> to be more careful in the future. In original code the NPE was thrown
>>> by private Class.searchFields and searchMethods in the part of code
>>> where the 'name' parameter was interned. I replaced interning and
>>> reference comparison with equality comparison, which is faster and
>>> does not trash the String interning cache with names that are later
>>> not found as members of classes, but I forgot to introduce explicit
>>> nonNull check for the 'name' argument.
>>> 
>>> I now intentionally inserted the nonNull checks in front of the
>>> security checks in public-facing methods although this introduces a
>>> little behavioral change. I choose that because:
>>> 
>>> - The javadocs list NullPointerException before the SecurityException
>>> (for example in getField):
>>> 
>>>     * @throws NullPointerException if {@code name} is {@code null}
>>>     * @throws SecurityException
>>>     *         If a security manager, <i>s</i>, is present and
>>>     *         the caller's class loader is not the same as or an
>>>     *         ancestor of the class loader for the current class and
>>>     *         invocation of {@link SecurityManager#checkPackageAccess
>>>     *         s.checkPackageAccess()} denies access to the package
>>>     *         of this class.
>>> 
>>> - I think it is more correct for methods to 1st check parameters
>>> before throwing any other state related exceptions.
>>> 
>>> But if you think this behavioral change is not justified, I can
>>> reverse the order of checks and prepare new webrev.
>>> 
>>> I have successfully executed java/lang tests and all tier 1 tests that
>>> failed when webrev.09 was pushed, mentioned in:
>>> 
>>>    https://bugs.openjdk.java.net/browse/JDK-8171988
>>> 
>>> 
>>> But don't take my word for it. Can someone please run webrev.10
>>> through the tests on Oracle side before confirming the change?
>>> 
>>> 
>>> Thanks,
>>> 
>>> Peter Levart
>>> 

From huaming.li at oracle.com  Thu Jan  5 03:21:40 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Thu, 5 Jan 2017 11:21:40 +0800
Subject: RFR of JDK-8030175:
	java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due
	to timeout
In-Reply-To: <827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
Message-ID: <0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>

Hi Roger,

Thank you for reviewing, please check comments inline.


On 2017/1/5 4:18, Roger Riggs wrote:
> Hi Hamlin,
>
> The original issue with timeout may be due to heavily loaded systems 
> and short timeouts.
> 15 sec is not enough on an overloaded system to wait for a process to 
> start and then die.
>
> There is no indication in this issue about port-in-use; that would be 
> a different issue.
Agree, I put 2 fixes in one patch together as there is no port in use 
issue reported, but by reviewing the code, potential port in use issue 
could happen some time in the future.
>
>
> Common comments to both A and B.
>
> I'll need more time to look at B; it would be cleaner to use A if it 
> can address the issue.
> The alternative is to duplicate the code in run() in the TestLibrary 
> and not modify the RegistryImpl.
I prefer B, because
   1. Although A looks cleaner but B is simulating more like rmiregistry.
   2. There are some other issue for example JDK-7146543, JDK-8030950, 
JDK-8038772, fix based on version B works well, but fix based on version 
A fails.
   3. Impact of RegistryImpl modification is minimal. ( May we could 
make Registry run(String args[]) private and access it in test by 
reflection? )
   4. Although it's simple to duplicate the code in run() in the 
TestLibrary, but seems it's not a good design choice. (let's call it 
version C.)
   5. For JDK-8170728, the fix will need to modify 
sun.rmi.registry.RegistryImpl anyway.


Thank you for detailed review comments below.
As we have several options, I will wait for your further comments on 
choice of version A/B/C, then send out new webrev, hope I only need to 
send out one version :-).

Thank you
-Hamlin
>
>
> JavaVM:
>  - Document the new methods.
>
> Line 232: Document the exception that may be thrown from exitValue.
>
>
> RMID:
> Line 204, 222: when adding new functions to the test library please 
> add documentation for the methods.
> There are now many variations of the methods that differ only by the 
> number arguments.
> It would be better if the name included some hint as to the additional 
> functionality.
>
> typo:  "additionalOptions" -> "add*i*tionalOptions"
>
> REGISTRY:
>   - Document the new methods.
>
>   - The name should be more indicative of its function and should NOT 
> be all caps;  RMID is an acronym where the caps make sense.
>
>   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating code 
> to wait for the subprocess.
>
>   - If the subprocesses are in an unknown state it would be useful to 
> print diagnostic info from the subprocess before terminating.
>     Line 106:
>
>  - Line 124:
>  - I think I would have promoted the shutdown method to JavaVM instead 
> of creating a new cleanup method
>    to keep the code simpler.
>
>    ** The cleanup method never calls super.cleanup() so the process is 
> never destroyed!.
>
> AltSecurityManager.java:
>
>  - Line 61: the empty constructor can be removed entirely.
>
>  - Line 80: change the message to say the exception did not occur.
>     As written it implies it may have occurred but was not caught.
>
>  - Line 86: typo "a unexpected" -> "an unexpected"
>
> - Line 90: remove the printStackTrace; it is not useful and is a red 
> flag in .jtr files
>
>  - Line 125: I don't see that cleanup is better than destroy; If there 
> are doubts about destroy
>    then destroy should be fixed not avoided.
>
> Roger
>
>
>
>
> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>> Would you please review the below patches?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>> webrev (version A): http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>> webrev (version B): 
>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>
>>
>> There are 2 versions to be reviewed.
>>
>> In version A, just use RegistryRunner to replace rmiregistry.
>> In version B, refactor sun.rmi.registry.RegistryImpl to improve the 
>> testability of RMI code, and create/use RMIRegistryRunner to simulate 
>> rmiregistry.
>>
>> Thank you
>> -Hamlin
>


From stzdzyhs at gmail.com  Thu Jan  5 04:02:11 2017
From: stzdzyhs at gmail.com (chen zero)
Date: Thu, 5 Jan 2017 12:02:11 +0800
Subject: About JDK-6772009
Message-ID: <CAF0BZZQAWcqb6rBGsVxZCbi9L99sEMJjiHFwHT1V_7QSFTtW+Q@mail.gmail.com>

Hi,
About the JDK-6772009, https://bugs.openjdk.java.net/browse/JDK-6772009
after some testing, I think the reason is because:

in the run() function,
public final void run() {
     .......

     /*
      * in the main thread, two threads are un-interrupted, others threads
are interrupted.
      * this line, however, can not guarantee that only "un-interrupted"
threads can go in,
      * but also interrupted threads can go in,
      * so, the "completed" will not always == 2, might be > 2
      */
     if (n <= 0) {
         lock.lock();
         try {
             ++completed;
         }
         finally {
             lock.unlock();
         }
     }
     ........
}


because the mixing of BrokenBarrierException or InterruptedException that
make the test case very complex,
I change the code of this test case in attachment, please review.

Thanks.
chenzero

From david.holmes at oracle.com  Thu Jan  5 04:20:35 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Jan 2017 14:20:35 +1000
Subject: About JDK-6772009
In-Reply-To: <CAF0BZZQAWcqb6rBGsVxZCbi9L99sEMJjiHFwHT1V_7QSFTtW+Q@mail.gmail.com>
References: <CAF0BZZQAWcqb6rBGsVxZCbi9L99sEMJjiHFwHT1V_7QSFTtW+Q@mail.gmail.com>
Message-ID: <be65c24d-d446-1fc8-4792-ba847ddd7ad3@oracle.com>

Hi chenzero,

Attachments get stripped from the mailing lists so you'll need to 
include your patch inline, or else get someone to host it for you on 
cr.openjdk.java.net

Thanks,
David

On 5/01/2017 2:02 PM, chen zero wrote:
> Hi,
> About the JDK-6772009, https://bugs.openjdk.java.net/browse/JDK-6772009
> after some testing, I think the reason is because:
>
> in the run() function,
> public final void run() {
>      .......
>
>      /*
>       * in the main thread, two threads are un-interrupted, others threads
> are interrupted.
>       * this line, however, can not guarantee that only "un-interrupted"
> threads can go in,
>       * but also interrupted threads can go in,
>       * so, the "completed" will not always == 2, might be > 2
>       */
>      if (n <= 0) {
>          lock.lock();
>          try {
>              ++completed;
>          }
>          finally {
>              lock.unlock();
>          }
>      }
>      ........
> }
>
>
> because the mixing of BrokenBarrierException or InterruptedException that
> make the test case very complex,
> I change the code of this test case in attachment, please review.
>
> Thanks.
> chenzero
>

From stzdzyhs at gmail.com  Thu Jan  5 04:39:23 2017
From: stzdzyhs at gmail.com (chen zero)
Date: Thu, 5 Jan 2017 12:39:23 +0800
Subject: About JDK-6772009
In-Reply-To: <be65c24d-d446-1fc8-4792-ba847ddd7ad3@oracle.com>
References: <CAF0BZZQAWcqb6rBGsVxZCbi9L99sEMJjiHFwHT1V_7QSFTtW+Q@mail.gmail.com>
	<be65c24d-d446-1fc8-4792-ba847ddd7ad3@oracle.com>
Message-ID: <CAF0BZZSCaAKdhYAYxX=sWXCyKDD90XHAZX9ZxB-kwMnoQ3YxBg@mail.gmail.com>

Hi David,
Thank you for reminding.
I post the code here.


import java.util.Arrays;
import java.util.Collections;
import java.util.Random;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.locks.ReentrantLock;

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

public final class CancelledLockLoops {
    static final Random rng = new Random();
    static boolean print = false;
    //static final int ITERS = 1000000;
    static final int ITERS = 10000000;

    static final long TIMEOUT = 100;

    public static void main(String[] args) throws Exception {
        int maxThreads = 5;
        if (args.length > 0) {
            maxThreads = Integer.parseInt(args[0]);
        }

        print = true;

        for (int i = 2; i <= maxThreads; i += (i+1) >>> 1) {
            System.out.print("Threads: " + i);

            try {
                new ReentrantLockLoop(i).test();
            }
            catch (BrokenBarrierException bb) {
                // OK, ignore
                bb.printStackTrace();
            }
            Thread.sleep(TIMEOUT);
        }
    }

    static final class ReentrantLockLoop implements Runnable {
        private int v = rng.nextInt();
        private int completed;
        private volatile int result = 17;
        private final ReentrantLock lock = new ReentrantLock();
        private final LoopHelpers.BarrierTimer timer = new
LoopHelpers.BarrierTimer();
        private final CyclicBarrier barrier;
        private final int nthreads;

        ReentrantLockLoop(int nthreads) {
            this.nthreads = nthreads;
            barrier = new CyclicBarrier(nthreads+1, timer);
        }

        void checkBarrierStatus() {
            if(this.barrier.isBroken()) {
                throw new Error("barrier is broken !!!");
            }
        }

        final void test() throws Exception {
            checkBarrierStatus();

            timer.run();

            Thread[] threads = new Thread[nthreads];
            for (int i = 0; i < threads.length; ++i) {
                threads[i] = new Thread(this, "th"+i);
            }

            for (int i = 0; i < threads.length; ++i) {
                threads[i].start();
            }

            Thread[] cancels =  (Thread[])(threads.clone());

            Collections.shuffle(Arrays.asList(cancels), rng);
            Thread.sleep(TIMEOUT);
            for (int i = 0; i < cancels.length-2; ++i) {
                cancels[i].interrupt();
                // make sure all OK even when cancellations spaced out
                if ((i & 3) == 0) {
                    Thread.sleep(1 + rng.nextInt(10));
                }
            }

            Thread.sleep(TIMEOUT);

            try {
                // in here, the barrier might be broken because some
working threads is interrupted.
                // so, catching the BrokenBarrierException to let testcase
continue running
                barrier.await();
            }
            catch(BrokenBarrierException e) {
                // nop
            }

            if (print) {
                // since the barrier might be broken ( the barrier action
will not run),
                // running here to ensure time is set.
                timer.run();
                long time = timer.getTime();
                double secs = (double)(time) / 1000000000.0;
                System.out.println("\t " + secs + "s run time");
            }

            int c;
            lock.lock();
            //System.out.println("main to verify completed.....");

            try {
                c = completed;
            }
            finally {
                lock.unlock();
            }
            // here the completed should not < 2, it can not guarantee that
always == 2.
            if (c < 2) {
                throw new Error("Completed < 2 : " + c);
            }

            int r = result;
            if (r == 0) { // avoid overoptimization
                System.out.println("useless result: " + r);
            }
        }

        public final void run() {
            try {
                checkBarrierStatus();

                int sum = v;
                int x = 0;
                int n = ITERS;
                do {
                    try {
                        lock.lockInterruptibly();
                    }
                    catch (InterruptedException ie) {
                        break;
                    }
                    try {
                        v = x = LoopHelpers.compute1(v);
                    }
                    finally {
                        lock.unlock();
                    }
                    sum += LoopHelpers.compute2(x);
                } while (n-- > 0);

                /*
                 * in the main thread, two threads are un-interrupted,
others threads are interrupted.
                 * this line, however, can not guarantee that only
"un-interrupted" threads can go in,
                 * but also interrupted threads can go in,
                 * so, the "completed" will not always == 2, might be > 2
                 */
                if (n < 0) {
                    lock.lock();
                    try {
                        ++completed;
                    }
                    finally {
                        lock.unlock();
                    }
                }

                result += sum;
                barrier.await();
            }
            catch(BrokenBarrierException ex) {
                //ex.printStackTrace();
            }
            catch(InterruptedException ex) {
                //ex.printStackTrace();
            }
            catch (Exception ex) {
                ex.printStackTrace();
                return;
            }
        }
    }

}


On Thu, Jan 5, 2017 at 12:20 PM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi chenzero,
>
> Attachments get stripped from the mailing lists so you'll need to include
> your patch inline, or else get someone to host it for you on
> cr.openjdk.java.net
>
> Thanks,
> David
> .....
>

From david.holmes at oracle.com  Thu Jan  5 04:42:16 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Jan 2017 14:42:16 +1000
Subject: About JDK-6772009
In-Reply-To: <be65c24d-d446-1fc8-4792-ba847ddd7ad3@oracle.com>
References: <CAF0BZZQAWcqb6rBGsVxZCbi9L99sEMJjiHFwHT1V_7QSFTtW+Q@mail.gmail.com>
	<be65c24d-d446-1fc8-4792-ba847ddd7ad3@oracle.com>
Message-ID: <f1c609e0-2faa-556b-f1d4-448c58925562@oracle.com>

I think the bug in that test is that it only sets the "interrupted" flag 
if it encounters InterruptedException, but it may also have detected the 
interruption in the loop condition and then would incorrectly follow the 
!interrupted path.

David

On 5/01/2017 2:20 PM, David Holmes wrote:
> Hi chenzero,
>
> Attachments get stripped from the mailing lists so you'll need to
> include your patch inline, or else get someone to host it for you on
> cr.openjdk.java.net
>
> Thanks,
> David
>
> On 5/01/2017 2:02 PM, chen zero wrote:
>> Hi,
>> About the JDK-6772009, https://bugs.openjdk.java.net/browse/JDK-6772009
>> after some testing, I think the reason is because:
>>
>> in the run() function,
>> public final void run() {
>>      .......
>>
>>      /*
>>       * in the main thread, two threads are un-interrupted, others
>> threads
>> are interrupted.
>>       * this line, however, can not guarantee that only "un-interrupted"
>> threads can go in,
>>       * but also interrupted threads can go in,
>>       * so, the "completed" will not always == 2, might be > 2
>>       */
>>      if (n <= 0) {
>>          lock.lock();
>>          try {
>>              ++completed;
>>          }
>>          finally {
>>              lock.unlock();
>>          }
>>      }
>>      ........
>> }
>>
>>
>> because the mixing of BrokenBarrierException or InterruptedException that
>> make the test case very complex,
>> I change the code of this test case in attachment, please review.
>>
>> Thanks.
>> chenzero
>>

From david.holmes at oracle.com  Thu Jan  5 04:48:47 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Jan 2017 14:48:47 +1000
Subject: About JDK-6772009
In-Reply-To: <CAF0BZZSCaAKdhYAYxX=sWXCyKDD90XHAZX9ZxB-kwMnoQ3YxBg@mail.gmail.com>
References: <CAF0BZZQAWcqb6rBGsVxZCbi9L99sEMJjiHFwHT1V_7QSFTtW+Q@mail.gmail.com>
	<be65c24d-d446-1fc8-4792-ba847ddd7ad3@oracle.com>
	<CAF0BZZSCaAKdhYAYxX=sWXCyKDD90XHAZX9ZxB-kwMnoQ3YxBg@mail.gmail.com>
Message-ID: <86b875a3-b21a-0a26-61d0-4cb74a316981@oracle.com>

Hi,

You seem to be looking at an older version of the test code.

As I said in my previous mail I think the problem is that an interrupted 
thread can follow this path:

    if (!interrupted) {
       if (print)
          System.out.printf("completed after %d millis%n", 
                           NANOSECONDS.toMillis(System.nanoTime() - 
startTime));
       lock.lock();
       try {
          ++completed;
       }
       finally {
          lock.unlock();
       }
     }

because interrupted is only set when InterruptedException is caught:

while (!done || Thread.currentThread().isInterrupted()) {
     try {
         lock.lockInterruptibly();
     }
     catch (InterruptedException ie) {
         interrupted = true;

but we can also exit the loop due to interruption, without recording the 
fact we were interrupted. In which case the completed count will be too 
high.

Cheers,
David

On 5/01/2017 2:39 PM, chen zero wrote:
> Hi David,
> Thank you for reminding.
> I post the code here.
>
>
> import java.util.Arrays;
> import java.util.Collections;
> import java.util.Random;
> import java.util.concurrent.BrokenBarrierException;
> import java.util.concurrent.CyclicBarrier;
> import java.util.concurrent.locks.ReentrantLock;
>
> // https://bugs.openjdk.java.net/browse/JDK-6772009
>
> public final class CancelledLockLoops {
>     static final Random rng = new Random();
>     static boolean print = false;
>     //static final int ITERS = 1000000;
>     static final int ITERS = 10000000;
>
>     static final long TIMEOUT = 100;
>
>     public static void main(String[] args) throws Exception {
>         int maxThreads = 5;
>         if (args.length > 0) {
>             maxThreads = Integer.parseInt(args[0]);
>         }
>
>         print = true;
>
>         for (int i = 2; i <= maxThreads; i += (i+1) >>> 1) {
>             System.out.print("Threads: " + i);
>
>             try {
>                 new ReentrantLockLoop(i).test();
>             }
>             catch (BrokenBarrierException bb) {
>                 // OK, ignore
>                 bb.printStackTrace();
>             }
>             Thread.sleep(TIMEOUT);
>         }
>     }
>
>     static final class ReentrantLockLoop implements Runnable {
>         private int v = rng.nextInt();
>         private int completed;
>         private volatile int result = 17;
>         private final ReentrantLock lock = new ReentrantLock();
>         private final LoopHelpers.BarrierTimer timer = new
> LoopHelpers.BarrierTimer();
>         private final CyclicBarrier barrier;
>         private final int nthreads;
>
>         ReentrantLockLoop(int nthreads) {
>             this.nthreads = nthreads;
>             barrier = new CyclicBarrier(nthreads+1, timer);
>         }
>
>         void checkBarrierStatus() {
>             if(this.barrier.isBroken()) {
>                 throw new Error("barrier is broken !!!");
>             }
>         }
>
>         final void test() throws Exception {
>             checkBarrierStatus();
>
>             timer.run();
>
>             Thread[] threads = new Thread[nthreads];
>             for (int i = 0; i < threads.length; ++i) {
>                 threads[i] = new Thread(this, "th"+i);
>             }
>
>             for (int i = 0; i < threads.length; ++i) {
>                 threads[i].start();
>             }
>
>             Thread[] cancels =  (Thread[])(threads.clone());
>
>             Collections.shuffle(Arrays.asList(cancels), rng);
>             Thread.sleep(TIMEOUT);
>             for (int i = 0; i < cancels.length-2; ++i) {
>                 cancels[i].interrupt();
>                 // make sure all OK even when cancellations spaced out
>                 if ((i & 3) == 0) {
>                     Thread.sleep(1 + rng.nextInt(10));
>                 }
>             }
>
>             Thread.sleep(TIMEOUT);
>
>             try {
>                 // in here, the barrier might be broken because some
> working threads is interrupted.
>                 // so, catching the BrokenBarrierException to let
> testcase continue running
>                 barrier.await();
>             }
>             catch(BrokenBarrierException e) {
>                 // nop
>             }
>
>             if (print) {
>                 // since the barrier might be broken ( the barrier
> action will not run),
>                 // running here to ensure time is set.
>                 timer.run();
>                 long time = timer.getTime();
>                 double secs = (double)(time) / 1000000000.0;
>                 System.out.println("\t " + secs + "s run time");
>             }
>
>             int c;
>             lock.lock();
>             //System.out.println("main to verify completed.....");
>
>             try {
>                 c = completed;
>             }
>             finally {
>                 lock.unlock();
>             }
>             // here the completed should not < 2, it can not guarantee
> that always == 2.
>             if (c < 2) {
>                 throw new Error("Completed < 2 : " + c);
>             }
>
>             int r = result;
>             if (r == 0) { // avoid overoptimization
>                 System.out.println("useless result: " + r);
>             }
>         }
>
>         public final void run() {
>             try {
>                 checkBarrierStatus();
>
>                 int sum = v;
>                 int x = 0;
>                 int n = ITERS;
>                 do {
>                     try {
>                         lock.lockInterruptibly();
>                     }
>                     catch (InterruptedException ie) {
>                         break;
>                     }
>                     try {
>                         v = x = LoopHelpers.compute1(v);
>                     }
>                     finally {
>                         lock.unlock();
>                     }
>                     sum += LoopHelpers.compute2(x);
>                 } while (n-- > 0);
>
>                 /*
>                  * in the main thread, two threads are un-interrupted,
> others threads are interrupted.
>                  * this line, however, can not guarantee that only
> "un-interrupted" threads can go in,
>                  * but also interrupted threads can go in,
>                  * so, the "completed" will not always == 2, might be > 2
>                  */
>                 if (n < 0) {
>                     lock.lock();
>                     try {
>                         ++completed;
>                     }
>                     finally {
>                         lock.unlock();
>                     }
>                 }
>
>                 result += sum;
>                 barrier.await();
>             }
>             catch(BrokenBarrierException ex) {
>                 //ex.printStackTrace();
>             }
>             catch(InterruptedException ex) {
>                 //ex.printStackTrace();
>             }
>             catch (Exception ex) {
>                 ex.printStackTrace();
>                 return;
>             }
>         }
>     }
>
> }
>
>
> On Thu, Jan 5, 2017 at 12:20 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi chenzero,
>
>     Attachments get stripped from the mailing lists so you'll need to
>     include your patch inline, or else get someone to host it for you on
>     cr.openjdk.java.net <http://cr.openjdk.java.net>
>
>     Thanks,
>     David
>     .....
>

From stzdzyhs at gmail.com  Thu Jan  5 05:20:32 2017
From: stzdzyhs at gmail.com (chen zero)
Date: Thu, 5 Jan 2017 13:20:32 +0800
Subject: About JDK-6772009
In-Reply-To: <86b875a3-b21a-0a26-61d0-4cb74a316981@oracle.com>
References: <CAF0BZZQAWcqb6rBGsVxZCbi9L99sEMJjiHFwHT1V_7QSFTtW+Q@mail.gmail.com>
	<be65c24d-d446-1fc8-4792-ba847ddd7ad3@oracle.com>
	<CAF0BZZSCaAKdhYAYxX=sWXCyKDD90XHAZX9ZxB-kwMnoQ3YxBg@mail.gmail.com>
	<86b875a3-b21a-0a26-61d0-4cb74a316981@oracle.com>
Message-ID: <CAF0BZZQ+-Y=vqRRZb4LN0UGS69hXAQKpHORDkwm3-goZ9COZLQ@mail.gmail.com>

Yes, the problem is related to the interrupt, timing and combine with
BrokenBarrierException, the whole testcase very complex.
so, I change the testcase as following:
    in the main:
          left 2 thread Un-interrupt.
          wait on the barrier. // if wait return, that means all threads
end.
          verify completed > 2

   in the working thread:
         try lock  and do calculation....
         if interrupted, skip calculation
         wait on the barrier.

yes, the barrier will be only wait 1 time, (in original code the barrier
will wait 2 times),
in my testing, sometime, in the 2nd time wait, BrokenBarrierException will
be thrown, however, it's not catch and make
the whole test case skipped.
anyway, two times wait on barrier are very complex....
so, only 1 time wait on barrier and in my testing, anything is as expected
:)

My code is from from jdk8u branch from git, and I compare with the code
posted in the JiRA, also same.


On Thu, Jan 5, 2017 at 12:48 PM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi,
>
> You seem to be looking at an older version of the test code.
>
> As I said in my previous mail I think the problem is that an interrupted
> thread can follow this path:
>
>    if (!interrupted) {
>       if (print)
>          System.out.printf("completed after %d millis%n",
>          NANOSECONDS.toMillis(System.nanoTime() - startTime));
>       lock.lock();
>       try {
>          ++completed;
>       }
>       finally {
>          lock.unlock();
>       }
>     }
>
> because interrupted is only set when InterruptedException is caught:
>
> while (!done || Thread.currentThread().isInterrupted()) {
>     try {
>         lock.lockInterruptibly();
>     }
>     catch (InterruptedException ie) {
>         interrupted = true;
>
> but we can also exit the loop due to interruption, without recording the
> fact we were interrupted. In which case the completed count will be too
> high.
>
> Cheers,
> David
>
>
> On 5/01/2017 2:39 PM, chen zero wrote:
>
>> Hi David,
>> Thank you for reminding.
>> I post the code here.
>>
>>
>> import java.util.Arrays;
>> import java.util.Collections;
>> import java.util.Random;
>> import java.util.concurrent.BrokenBarrierException;
>> import java.util.concurrent.CyclicBarrier;
>> import java.util.concurrent.locks.ReentrantLock;
>>
>> // https://bugs.openjdk.java.net/browse/JDK-6772009
>>
>> public final class CancelledLockLoops {
>>     static final Random rng = new Random();
>>     static boolean print = false;
>>     //static final int ITERS = 1000000;
>>     static final int ITERS = 10000000;
>>
>>     static final long TIMEOUT = 100;
>>
>>     public static void main(String[] args) throws Exception {
>>         int maxThreads = 5;
>>         if (args.length > 0) {
>>             maxThreads = Integer.parseInt(args[0]);
>>         }
>>
>>         print = true;
>>
>>         for (int i = 2; i <= maxThreads; i += (i+1) >>> 1) {
>>             System.out.print("Threads: " + i);
>>
>>             try {
>>                 new ReentrantLockLoop(i).test();
>>             }
>>             catch (BrokenBarrierException bb) {
>>                 // OK, ignore
>>                 bb.printStackTrace();
>>             }
>>             Thread.sleep(TIMEOUT);
>>         }
>>     }
>>
>>     static final class ReentrantLockLoop implements Runnable {
>>         private int v = rng.nextInt();
>>         private int completed;
>>         private volatile int result = 17;
>>         private final ReentrantLock lock = new ReentrantLock();
>>         private final LoopHelpers.BarrierTimer timer = new
>> LoopHelpers.BarrierTimer();
>>         private final CyclicBarrier barrier;
>>         private final int nthreads;
>>
>>         ReentrantLockLoop(int nthreads) {
>>             this.nthreads = nthreads;
>>             barrier = new CyclicBarrier(nthreads+1, timer);
>>         }
>>
>>         void checkBarrierStatus() {
>>             if(this.barrier.isBroken()) {
>>                 throw new Error("barrier is broken !!!");
>>             }
>>         }
>>
>>         final void test() throws Exception {
>>             checkBarrierStatus();
>>
>>             timer.run();
>>
>>             Thread[] threads = new Thread[nthreads];
>>             for (int i = 0; i < threads.length; ++i) {
>>                 threads[i] = new Thread(this, "th"+i);
>>             }
>>
>>             for (int i = 0; i < threads.length; ++i) {
>>                 threads[i].start();
>>             }
>>
>>             Thread[] cancels =  (Thread[])(threads.clone());
>>
>>             Collections.shuffle(Arrays.asList(cancels), rng);
>>             Thread.sleep(TIMEOUT);
>>             for (int i = 0; i < cancels.length-2; ++i) {
>>                 cancels[i].interrupt();
>>                 // make sure all OK even when cancellations spaced out
>>                 if ((i & 3) == 0) {
>>                     Thread.sleep(1 + rng.nextInt(10));
>>                 }
>>             }
>>
>>             Thread.sleep(TIMEOUT);
>>
>>             try {
>>                 // in here, the barrier might be broken because some
>> working threads is interrupted.
>>                 // so, catching the BrokenBarrierException to let
>> testcase continue running
>>                 barrier.await();
>>             }
>>             catch(BrokenBarrierException e) {
>>                 // nop
>>             }
>>
>>             if (print) {
>>                 // since the barrier might be broken ( the barrier
>> action will not run),
>>                 // running here to ensure time is set.
>>                 timer.run();
>>                 long time = timer.getTime();
>>                 double secs = (double)(time) / 1000000000.0;
>>                 System.out.println("\t " + secs + "s run time");
>>             }
>>
>>             int c;
>>             lock.lock();
>>             //System.out.println("main to verify completed.....");
>>
>>             try {
>>                 c = completed;
>>             }
>>             finally {
>>                 lock.unlock();
>>             }
>>             // here the completed should not < 2, it can not guarantee
>> that always == 2.
>>             if (c < 2) {
>>                 throw new Error("Completed < 2 : " + c);
>>             }
>>
>>             int r = result;
>>             if (r == 0) { // avoid overoptimization
>>                 System.out.println("useless result: " + r);
>>             }
>>         }
>>
>>         public final void run() {
>>             try {
>>                 checkBarrierStatus();
>>
>>                 int sum = v;
>>                 int x = 0;
>>                 int n = ITERS;
>>                 do {
>>                     try {
>>                         lock.lockInterruptibly();
>>                     }
>>                     catch (InterruptedException ie) {
>>                         break;
>>                     }
>>                     try {
>>                         v = x = LoopHelpers.compute1(v);
>>                     }
>>                     finally {
>>                         lock.unlock();
>>                     }
>>                     sum += LoopHelpers.compute2(x);
>>                 } while (n-- > 0);
>>
>>                 /*
>>                  * in the main thread, two threads are un-interrupted,
>> others threads are interrupted.
>>                  * this line, however, can not guarantee that only
>> "un-interrupted" threads can go in,
>>                  * but also interrupted threads can go in,
>>                  * so, the "completed" will not always == 2, might be > 2
>>                  */
>>                 if (n < 0) {
>>                     lock.lock();
>>                     try {
>>                         ++completed;
>>                     }
>>                     finally {
>>                         lock.unlock();
>>                     }
>>                 }
>>
>>                 result += sum;
>>                 barrier.await();
>>             }
>>             catch(BrokenBarrierException ex) {
>>                 //ex.printStackTrace();
>>             }
>>             catch(InterruptedException ex) {
>>                 //ex.printStackTrace();
>>             }
>>             catch (Exception ex) {
>>                 ex.printStackTrace();
>>                 return;
>>             }
>>         }
>>     }
>>
>> }
>>
>>
>> On Thu, Jan 5, 2017 at 12:20 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi chenzero,
>>
>>     Attachments get stripped from the mailing lists so you'll need to
>>     include your patch inline, or else get someone to host it for you on
>>     cr.openjdk.java.net <http://cr.openjdk.java.net>
>>
>>     Thanks,
>>     David
>>     .....
>>
>>

From david.holmes at oracle.com  Thu Jan  5 05:25:40 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Jan 2017 15:25:40 +1000
Subject: About JDK-6772009
In-Reply-To: <CAF0BZZQ+-Y=vqRRZb4LN0UGS69hXAQKpHORDkwm3-goZ9COZLQ@mail.gmail.com>
References: <CAF0BZZQAWcqb6rBGsVxZCbi9L99sEMJjiHFwHT1V_7QSFTtW+Q@mail.gmail.com>
	<be65c24d-d446-1fc8-4792-ba847ddd7ad3@oracle.com>
	<CAF0BZZSCaAKdhYAYxX=sWXCyKDD90XHAZX9ZxB-kwMnoQ3YxBg@mail.gmail.com>
	<86b875a3-b21a-0a26-61d0-4cb74a316981@oracle.com>
	<CAF0BZZQ+-Y=vqRRZb4LN0UGS69hXAQKpHORDkwm3-goZ9COZLQ@mail.gmail.com>
Message-ID: <1b3438bf-d56f-e265-439c-549eea5ef31a@oracle.com>

Any fix would have to be applied to the current code in JDK 9.

But as this is java.util.concurrent testing Martin Buchholz will likely 
jump in as he and Doug Lea maintain the external versions of these tests.

I don't think BrokenBarrierException should be an issue in current test.

David

On 5/01/2017 3:20 PM, chen zero wrote:
>
> Yes, the problem is related to the interrupt, timing and combine with
> BrokenBarrierException, the whole testcase very complex.
> so, I change the testcase as following:
>     in the main:
>           left 2 thread Un-interrupt.
>           wait on the barrier. // if wait return, that means all threads
> end.
>           verify completed > 2
>
>    in the working thread:
>          try lock  and do calculation....
>          if interrupted, skip calculation
>          wait on the barrier.
>
> yes, the barrier will be only wait 1 time, (in original code the barrier
> will wait 2 times),
> in my testing, sometime, in the 2nd time wait, BrokenBarrierException
> will be thrown, however, it's not catch and make
> the whole test case skipped.
> anyway, two times wait on barrier are very complex....
> so, only 1 time wait on barrier and in my testing, anything is as
> expected :)
>
> My code is from from jdk8u branch from git, and I compare with the code
> posted in the JiRA, also same.
>
>
> On Thu, Jan 5, 2017 at 12:48 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi,
>
>     You seem to be looking at an older version of the test code.
>
>     As I said in my previous mail I think the problem is that an
>     interrupted thread can follow this path:
>
>        if (!interrupted) {
>           if (print)
>              System.out.printf("completed after %d millis%n",
>                    NANOSECONDS.toMillis(System.nanoTime() - startTime));
>           lock.lock();
>           try {
>              ++completed;
>           }
>           finally {
>              lock.unlock();
>           }
>         }
>
>     because interrupted is only set when InterruptedException is caught:
>
>     while (!done || Thread.currentThread().isInterrupted()) {
>         try {
>             lock.lockInterruptibly();
>         }
>         catch (InterruptedException ie) {
>             interrupted = true;
>
>     but we can also exit the loop due to interruption, without recording
>     the fact we were interrupted. In which case the completed count will
>     be too high.
>
>     Cheers,
>     David
>
>
>     On 5/01/2017 2:39 PM, chen zero wrote:
>
>         Hi David,
>         Thank you for reminding.
>         I post the code here.
>
>
>         import java.util.Arrays;
>         import java.util.Collections;
>         import java.util.Random;
>         import java.util.concurrent.BrokenBarrierException;
>         import java.util.concurrent.CyclicBarrier;
>         import java.util.concurrent.locks.ReentrantLock;
>
>         // https://bugs.openjdk.java.net/browse/JDK-6772009
>         <https://bugs.openjdk.java.net/browse/JDK-6772009>
>
>         public final class CancelledLockLoops {
>             static final Random rng = new Random();
>             static boolean print = false;
>             //static final int ITERS = 1000000;
>             static final int ITERS = 10000000;
>
>             static final long TIMEOUT = 100;
>
>             public static void main(String[] args) throws Exception {
>                 int maxThreads = 5;
>                 if (args.length > 0) {
>                     maxThreads = Integer.parseInt(args[0]);
>                 }
>
>                 print = true;
>
>                 for (int i = 2; i <= maxThreads; i += (i+1) >>> 1) {
>                     System.out.print("Threads: " + i);
>
>                     try {
>                         new ReentrantLockLoop(i).test();
>                     }
>                     catch (BrokenBarrierException bb) {
>                         // OK, ignore
>                         bb.printStackTrace();
>                     }
>                     Thread.sleep(TIMEOUT);
>                 }
>             }
>
>             static final class ReentrantLockLoop implements Runnable {
>                 private int v = rng.nextInt();
>                 private int completed;
>                 private volatile int result = 17;
>                 private final ReentrantLock lock = new ReentrantLock();
>                 private final LoopHelpers.BarrierTimer timer = new
>         LoopHelpers.BarrierTimer();
>                 private final CyclicBarrier barrier;
>                 private final int nthreads;
>
>                 ReentrantLockLoop(int nthreads) {
>                     this.nthreads = nthreads;
>                     barrier = new CyclicBarrier(nthreads+1, timer);
>                 }
>
>                 void checkBarrierStatus() {
>                     if(this.barrier.isBroken()) {
>                         throw new Error("barrier is broken !!!");
>                     }
>                 }
>
>                 final void test() throws Exception {
>                     checkBarrierStatus();
>
>                     timer.run();
>
>                     Thread[] threads = new Thread[nthreads];
>                     for (int i = 0; i < threads.length; ++i) {
>                         threads[i] = new Thread(this, "th"+i);
>                     }
>
>                     for (int i = 0; i < threads.length; ++i) {
>                         threads[i].start();
>                     }
>
>                     Thread[] cancels =  (Thread[])(threads.clone());
>
>                     Collections.shuffle(Arrays.asList(cancels), rng);
>                     Thread.sleep(TIMEOUT);
>                     for (int i = 0; i < cancels.length-2; ++i) {
>                         cancels[i].interrupt();
>                         // make sure all OK even when cancellations
>         spaced out
>                         if ((i & 3) == 0) {
>                             Thread.sleep(1 + rng.nextInt(10));
>                         }
>                     }
>
>                     Thread.sleep(TIMEOUT);
>
>                     try {
>                         // in here, the barrier might be broken because some
>         working threads is interrupted.
>                         // so, catching the BrokenBarrierException to let
>         testcase continue running
>                         barrier.await();
>                     }
>                     catch(BrokenBarrierException e) {
>                         // nop
>                     }
>
>                     if (print) {
>                         // since the barrier might be broken ( the barrier
>         action will not run),
>                         // running here to ensure time is set.
>                         timer.run();
>                         long time = timer.getTime();
>                         double secs = (double)(time) / 1000000000.0;
>                         System.out.println("\t " + secs + "s run time");
>                     }
>
>                     int c;
>                     lock.lock();
>                     //System.out.println("main to verify completed.....");
>
>                     try {
>                         c = completed;
>                     }
>                     finally {
>                         lock.unlock();
>                     }
>                     // here the completed should not < 2, it can not
>         guarantee
>         that always == 2.
>                     if (c < 2) {
>                         throw new Error("Completed < 2 : " + c);
>                     }
>
>                     int r = result;
>                     if (r == 0) { // avoid overoptimization
>                         System.out.println("useless result: " + r);
>                     }
>                 }
>
>                 public final void run() {
>                     try {
>                         checkBarrierStatus();
>
>                         int sum = v;
>                         int x = 0;
>                         int n = ITERS;
>                         do {
>                             try {
>                                 lock.lockInterruptibly();
>                             }
>                             catch (InterruptedException ie) {
>                                 break;
>                             }
>                             try {
>                                 v = x = LoopHelpers.compute1(v);
>                             }
>                             finally {
>                                 lock.unlock();
>                             }
>                             sum += LoopHelpers.compute2(x);
>                         } while (n-- > 0);
>
>                         /*
>                          * in the main thread, two threads are
>         un-interrupted,
>         others threads are interrupted.
>                          * this line, however, can not guarantee that only
>         "un-interrupted" threads can go in,
>                          * but also interrupted threads can go in,
>                          * so, the "completed" will not always == 2,
>         might be > 2
>                          */
>                         if (n < 0) {
>                             lock.lock();
>                             try {
>                                 ++completed;
>                             }
>                             finally {
>                                 lock.unlock();
>                             }
>                         }
>
>                         result += sum;
>                         barrier.await();
>                     }
>                     catch(BrokenBarrierException ex) {
>                         //ex.printStackTrace();
>                     }
>                     catch(InterruptedException ex) {
>                         //ex.printStackTrace();
>                     }
>                     catch (Exception ex) {
>                         ex.printStackTrace();
>                         return;
>                     }
>                 }
>             }
>
>         }
>
>
>         On Thu, Jan 5, 2017 at 12:20 PM, David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>> wrote:
>
>             Hi chenzero,
>
>             Attachments get stripped from the mailing lists so you'll
>         need to
>             include your patch inline, or else get someone to host it
>         for you on
>             cr.openjdk.java.net <http://cr.openjdk.java.net>
>         <http://cr.openjdk.java.net>
>
>             Thanks,
>             David
>             .....
>
>

From peter.levart at gmail.com  Thu Jan  5 06:55:54 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 5 Jan 2017 07:55:54 +0100
Subject: RFR 8172190: Re-apply the fix for bugs 8062389, 8029459, 8061950
In-Reply-To: <9B1041A6-A9A8-4A90-BEAD-F5EF7C1B5B0B@oracle.com>
References: <C13D1340-C38B-4B6A-B80A-DA5A5CEC1891@oracle.com>
	<ac24d255-09a6-7c29-37f3-eeaf2139f100@gmail.com>
	<221ca324-be41-9c74-89be-606e31ae93d3@gmail.com>
	<98DA94D5-F43B-491C-8DE7-EE2FF030920B@oracle.com>
	<47940b37-b09c-0888-d031-beefe9f5bcab@oracle.com>
	<09F19C0B-B0D8-4FF2-BD53-080EAAEA8974@oracle.com>
	<ef0bd907-1805-f306-e89c-95ec1e3acfff@oracle.com>
	<7a95546d-4b5b-190b-46db-3a6f3168eece@gmail.com>
	<0a5e77dd-3b3d-0231-138f-8b03699eeea1@gmail.com>
	<43c44b23-2026-e5c6-5ea8-f926a605966f@oracle.com>
	<6ccde80c-7d68-ac48-9683-462fbac2470a@oracle.com>
	<9B1041A6-A9A8-4A90-BEAD-F5EF7C1B5B0B@oracle.com>
Message-ID: <1a4d1122-fbb3-375f-2082-55f46f17ba50@gmail.com>

Thanks Mandy, Claes,

This is for real now ;-)

Regards, Peter

On 01/05/2017 03:05 AM, Mandy Chung wrote:
> I reviewed webrev.09to10.  The NPE check is fine.  I also ran the core tests and no surprise found.
>
> Mandy
>
>> On Jan 4, 2017, at 8:30 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Hi,
>>
>> no new failures - seems good to go unless someone objects to the
>> NPE behavior change.
>>
>> Thanks!
>>
>> /Claes
>>
>> On 2017-01-03 18:15, Claes Redestad wrote:
>>> Hi Peter,
>>>
>>> letting you know I've submitted a build and test job for this to run
>>> over night.
>>>
>>> Thanks!
>>>
>>> /Claes
>>>
>>> On 01/03/2017 05:52 PM, Peter Levart wrote:
>>>> Hi,
>>>>
>>>> Now that initialization cycle has been broken by Claes' fix for:
>>>>
>>>>      https://bugs.openjdk.java.net/browse/JDK-8172048
>>>>
>>>> I prepared a revised fix for issues described in the following bugs:
>>>>
>>>>     https://bugs.openjdk.java.net/browse/JDK-8062389
>>>>     https://bugs.openjdk.java.net/browse/JDK-8029459
>>>>     https://bugs.openjdk.java.net/browse/JDK-8061950
>>>>
>>>> ...now tracked by bug:
>>>>
>>>>     https://bugs.openjdk.java.net/browse/JDK-8172190
>>>>
>>>> The revised webrev is here:
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.10/
>>>>
>>>>
>>>> The incremental change from webrev.09 is the following:
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.09to10/
>>>>
>>>>
>>>>
>>>> Besides fixing one failing test (StarInheritance) that now has to
>>>> account for new behavior of Class.getMethods(), some tests also failed
>>>> because of the changed behavior (not throwing NPE) when passing null
>>>> 'name' parameter to Class.get[Declared][Method|Field] methods. This
>>>> was a straight bug introduced by me and caught by tests which I
>>>> haven't re-run after introducing it. I apologize for that and promise
>>>> to be more careful in the future. In original code the NPE was thrown
>>>> by private Class.searchFields and searchMethods in the part of code
>>>> where the 'name' parameter was interned. I replaced interning and
>>>> reference comparison with equality comparison, which is faster and
>>>> does not trash the String interning cache with names that are later
>>>> not found as members of classes, but I forgot to introduce explicit
>>>> nonNull check for the 'name' argument.
>>>>
>>>> I now intentionally inserted the nonNull checks in front of the
>>>> security checks in public-facing methods although this introduces a
>>>> little behavioral change. I choose that because:
>>>>
>>>> - The javadocs list NullPointerException before the SecurityException
>>>> (for example in getField):
>>>>
>>>>      * @throws NullPointerException if {@code name} is {@code null}
>>>>      * @throws SecurityException
>>>>      *         If a security manager, <i>s</i>, is present and
>>>>      *         the caller's class loader is not the same as or an
>>>>      *         ancestor of the class loader for the current class and
>>>>      *         invocation of {@link SecurityManager#checkPackageAccess
>>>>      *         s.checkPackageAccess()} denies access to the package
>>>>      *         of this class.
>>>>
>>>> - I think it is more correct for methods to 1st check parameters
>>>> before throwing any other state related exceptions.
>>>>
>>>> But if you think this behavioral change is not justified, I can
>>>> reverse the order of checks and prepare new webrev.
>>>>
>>>> I have successfully executed java/lang tests and all tier 1 tests that
>>>> failed when webrev.09 was pushed, mentioned in:
>>>>
>>>>     https://bugs.openjdk.java.net/browse/JDK-8171988
>>>>
>>>>
>>>> But don't take my word for it. Can someone please run webrev.10
>>>> through the tests on Oracle side before confirming the change?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Peter Levart
>>>>


From martinrb at google.com  Thu Jan  5 18:20:54 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 5 Jan 2017 10:20:54 -0800
Subject: About JDK-6772009
In-Reply-To: <CAF0BZZQ+-Y=vqRRZb4LN0UGS69hXAQKpHORDkwm3-goZ9COZLQ@mail.gmail.com>
References: <CAF0BZZQAWcqb6rBGsVxZCbi9L99sEMJjiHFwHT1V_7QSFTtW+Q@mail.gmail.com>
	<be65c24d-d446-1fc8-4792-ba847ddd7ad3@oracle.com>
	<CAF0BZZSCaAKdhYAYxX=sWXCyKDD90XHAZX9ZxB-kwMnoQ3YxBg@mail.gmail.com>
	<86b875a3-b21a-0a26-61d0-4cb74a316981@oracle.com>
	<CAF0BZZQ+-Y=vqRRZb4LN0UGS69hXAQKpHORDkwm3-goZ9COZLQ@mail.gmail.com>
Message-ID: <CA+kOe0-REcrf0+=AaJ83wkoBXJWZzzdx6-1J-4SgR2ba2u_W+w@mail.gmail.com>

jtreg CancelledLockLoops is not a great test.  There have been changes to
it in jdk9 and it is not known to fail currently.

But chen, why are you working on this test?  If you see it failing, try
simply replacing with the jdk9 version.  Otherwise, I'd like to see such
tests replaced with more focused understandable correctness tests rather
than patched.

On Wed, Jan 4, 2017 at 9:20 PM, chen zero <stzdzyhs at gmail.com> wrote:

> Yes, the problem is related to the interrupt, timing and combine with
> BrokenBarrierException, the whole testcase very complex.
> so, I change the testcase as following:
>     in the main:
>           left 2 thread Un-interrupt.
>           wait on the barrier. // if wait return, that means all threads
> end.
>           verify completed > 2
>
>    in the working thread:
>          try lock  and do calculation....
>          if interrupted, skip calculation
>          wait on the barrier.
>
> yes, the barrier will be only wait 1 time, (in original code the barrier
> will wait 2 times),
> in my testing, sometime, in the 2nd time wait, BrokenBarrierException will
> be thrown, however, it's not catch and make
> the whole test case skipped.
> anyway, two times wait on barrier are very complex....
> so, only 1 time wait on barrier and in my testing, anything is as expected
> :)
>
> My code is from from jdk8u branch from git, and I compare with the code
> posted in the JiRA, also same.
>
>
> On Thu, Jan 5, 2017 at 12:48 PM, David Holmes <david.holmes at oracle.com>
> wrote:
>
> > Hi,
> >
> > You seem to be looking at an older version of the test code.
> >
> > As I said in my previous mail I think the problem is that an interrupted
> > thread can follow this path:
> >
> >    if (!interrupted) {
> >       if (print)
> >          System.out.printf("completed after %d millis%n",
> >          NANOSECONDS.toMillis(System.nanoTime() - startTime));
> >       lock.lock();
> >       try {
> >          ++completed;
> >       }
> >       finally {
> >          lock.unlock();
> >       }
> >     }
> >
> > because interrupted is only set when InterruptedException is caught:
> >
> > while (!done || Thread.currentThread().isInterrupted()) {
> >     try {
> >         lock.lockInterruptibly();
> >     }
> >     catch (InterruptedException ie) {
> >         interrupted = true;
> >
> > but we can also exit the loop due to interruption, without recording the
> > fact we were interrupted. In which case the completed count will be too
> > high.
> >
> > Cheers,
> > David
> >
> >
> > On 5/01/2017 2:39 PM, chen zero wrote:
> >
> >> Hi David,
> >> Thank you for reminding.
> >> I post the code here.
> >>
> >>
> >> import java.util.Arrays;
> >> import java.util.Collections;
> >> import java.util.Random;
> >> import java.util.concurrent.BrokenBarrierException;
> >> import java.util.concurrent.CyclicBarrier;
> >> import java.util.concurrent.locks.ReentrantLock;
> >>
> >> // https://bugs.openjdk.java.net/browse/JDK-6772009
> >>
> >> public final class CancelledLockLoops {
> >>     static final Random rng = new Random();
> >>     static boolean print = false;
> >>     //static final int ITERS = 1000000;
> >>     static final int ITERS = 10000000;
> >>
> >>     static final long TIMEOUT = 100;
> >>
> >>     public static void main(String[] args) throws Exception {
> >>         int maxThreads = 5;
> >>         if (args.length > 0) {
> >>             maxThreads = Integer.parseInt(args[0]);
> >>         }
> >>
> >>         print = true;
> >>
> >>         for (int i = 2; i <= maxThreads; i += (i+1) >>> 1) {
> >>             System.out.print("Threads: " + i);
> >>
> >>             try {
> >>                 new ReentrantLockLoop(i).test();
> >>             }
> >>             catch (BrokenBarrierException bb) {
> >>                 // OK, ignore
> >>                 bb.printStackTrace();
> >>             }
> >>             Thread.sleep(TIMEOUT);
> >>         }
> >>     }
> >>
> >>     static final class ReentrantLockLoop implements Runnable {
> >>         private int v = rng.nextInt();
> >>         private int completed;
> >>         private volatile int result = 17;
> >>         private final ReentrantLock lock = new ReentrantLock();
> >>         private final LoopHelpers.BarrierTimer timer = new
> >> LoopHelpers.BarrierTimer();
> >>         private final CyclicBarrier barrier;
> >>         private final int nthreads;
> >>
> >>         ReentrantLockLoop(int nthreads) {
> >>             this.nthreads = nthreads;
> >>             barrier = new CyclicBarrier(nthreads+1, timer);
> >>         }
> >>
> >>         void checkBarrierStatus() {
> >>             if(this.barrier.isBroken()) {
> >>                 throw new Error("barrier is broken !!!");
> >>             }
> >>         }
> >>
> >>         final void test() throws Exception {
> >>             checkBarrierStatus();
> >>
> >>             timer.run();
> >>
> >>             Thread[] threads = new Thread[nthreads];
> >>             for (int i = 0; i < threads.length; ++i) {
> >>                 threads[i] = new Thread(this, "th"+i);
> >>             }
> >>
> >>             for (int i = 0; i < threads.length; ++i) {
> >>                 threads[i].start();
> >>             }
> >>
> >>             Thread[] cancels =  (Thread[])(threads.clone());
> >>
> >>             Collections.shuffle(Arrays.asList(cancels), rng);
> >>             Thread.sleep(TIMEOUT);
> >>             for (int i = 0; i < cancels.length-2; ++i) {
> >>                 cancels[i].interrupt();
> >>                 // make sure all OK even when cancellations spaced out
> >>                 if ((i & 3) == 0) {
> >>                     Thread.sleep(1 + rng.nextInt(10));
> >>                 }
> >>             }
> >>
> >>             Thread.sleep(TIMEOUT);
> >>
> >>             try {
> >>                 // in here, the barrier might be broken because some
> >> working threads is interrupted.
> >>                 // so, catching the BrokenBarrierException to let
> >> testcase continue running
> >>                 barrier.await();
> >>             }
> >>             catch(BrokenBarrierException e) {
> >>                 // nop
> >>             }
> >>
> >>             if (print) {
> >>                 // since the barrier might be broken ( the barrier
> >> action will not run),
> >>                 // running here to ensure time is set.
> >>                 timer.run();
> >>                 long time = timer.getTime();
> >>                 double secs = (double)(time) / 1000000000.0;
> >>                 System.out.println("\t " + secs + "s run time");
> >>             }
> >>
> >>             int c;
> >>             lock.lock();
> >>             //System.out.println("main to verify completed.....");
> >>
> >>             try {
> >>                 c = completed;
> >>             }
> >>             finally {
> >>                 lock.unlock();
> >>             }
> >>             // here the completed should not < 2, it can not guarantee
> >> that always == 2.
> >>             if (c < 2) {
> >>                 throw new Error("Completed < 2 : " + c);
> >>             }
> >>
> >>             int r = result;
> >>             if (r == 0) { // avoid overoptimization
> >>                 System.out.println("useless result: " + r);
> >>             }
> >>         }
> >>
> >>         public final void run() {
> >>             try {
> >>                 checkBarrierStatus();
> >>
> >>                 int sum = v;
> >>                 int x = 0;
> >>                 int n = ITERS;
> >>                 do {
> >>                     try {
> >>                         lock.lockInterruptibly();
> >>                     }
> >>                     catch (InterruptedException ie) {
> >>                         break;
> >>                     }
> >>                     try {
> >>                         v = x = LoopHelpers.compute1(v);
> >>                     }
> >>                     finally {
> >>                         lock.unlock();
> >>                     }
> >>                     sum += LoopHelpers.compute2(x);
> >>                 } while (n-- > 0);
> >>
> >>                 /*
> >>                  * in the main thread, two threads are un-interrupted,
> >> others threads are interrupted.
> >>                  * this line, however, can not guarantee that only
> >> "un-interrupted" threads can go in,
> >>                  * but also interrupted threads can go in,
> >>                  * so, the "completed" will not always == 2, might be >
> 2
> >>                  */
> >>                 if (n < 0) {
> >>                     lock.lock();
> >>                     try {
> >>                         ++completed;
> >>                     }
> >>                     finally {
> >>                         lock.unlock();
> >>                     }
> >>                 }
> >>
> >>                 result += sum;
> >>                 barrier.await();
> >>             }
> >>             catch(BrokenBarrierException ex) {
> >>                 //ex.printStackTrace();
> >>             }
> >>             catch(InterruptedException ex) {
> >>                 //ex.printStackTrace();
> >>             }
> >>             catch (Exception ex) {
> >>                 ex.printStackTrace();
> >>                 return;
> >>             }
> >>         }
> >>     }
> >>
> >> }
> >>
> >>
> >> On Thu, Jan 5, 2017 at 12:20 PM, David Holmes <david.holmes at oracle.com
> >> <mailto:david.holmes at oracle.com>> wrote:
> >>
> >>     Hi chenzero,
> >>
> >>     Attachments get stripped from the mailing lists so you'll need to
> >>     include your patch inline, or else get someone to host it for you on
> >>     cr.openjdk.java.net <http://cr.openjdk.java.net>
> >>
> >>     Thanks,
> >>     David
> >>     .....
> >>
> >>
>

From jharwell at fuller.edu  Thu Jan  5 05:58:31 2017
From: jharwell at fuller.edu (Jeff Harwell)
Date: Wed, 4 Jan 2017 21:58:31 -0800
Subject: [PATCH] JDK-8081450: GZIPInputStream prematurely infers end-of-stream
Message-ID: <CAH7zfs1a+ds-w7xKPCfrvefRi8BoTZLbv35WD5xtzTUbDT2Zug@mail.gmail.com>

Greetings,

## Problem

I have been working with Common Crawl
<http://commoncrawl.org/the-data/get-started/> archives which are files
consisting of 50,000 to 55,000 small GZIP'd files concatenated together and
made available through Amazon S3. When decompressing these files on the fly
using GZIPInputStream it consistently ends prematurely as per bug
JDK-8081450 <https://bugs.openjdk.java.net/browse/JDK-8081450>. Details on
what I was trying to do and some demonstration code can be found on Stack
Overflow
<http://stackoverflow.com/questions/41400810/gzipinputstream-closes-prematurely-when-decompressing-httpinputstream>.


## Root Cause

The root cause seems to be line 231 in GZIPInputStream.java
<http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/0e4fc29a5ce4/src/share/classes/java/util/zip/GZIPInputStream.java>
method readTrailer()

if (this.in.available() > 0 || n > 26) {
>
>
where *this.in <http://this.in>* is the input stream passed to the
constructor. readTrailer() calls available() to determine if there are
bytes left in the input stream that should be checked to see if there is an
additional GZIP file in the stream. Some input streams, like
ByteArrayInputStream which is used in the itreg test
GZIPInputStreamRead.java
<http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/0e4fc29a5ce4/test/java/util/zip/GZIP/GZIPInputStreamRead.java>,
return the number of bytes available to read. However, input streams like
SequenceInputStream or HTTPInputStream will return 0 if a blocking IO call
is needed to refill the buffer. For these types of input streams when the
last thing in the read buffer is the end of a GZIP file the method
.available() will return 0 and GZIPInputStream will end prematurely instead
of continuing even if the stream is not closed.

## Proposed Solution

After a brief review of InputStream subclasses it seems impossible in
general to check if more bytes are available in an input stream without
trying to read the stream. So instead of checking available() just assume
that there is another GZIP file in the stream and call readHeader(). If the
input stream is in fact empty readHeader() properly handles the end of the
stream.

## Patch and jtreg test

The attached file *GZIPInputStream.java.patch.txt* implements the proposed
solution. The patch was applied against the jdk8u jdk repository changeset
12039:e5b1823a897e (Dec 20).

The attached file *GZIPHttpStreamRead.java* is a jtreg test that is a
modified copy of the existing GZIPInputStreamRead.java test. In this test
the ByteArrayInputStream is wrapped in a very poor mock of an
HTTPInputStream. The mock always returns 0 when available() is called which
causes the test to fail eventually when reading the randomly generated
concatenated GZIP files.

The attached file *GZIPBufferEndsAtBoundry.java* is a jtreg test using an
input stream that intentionally returns only the first complete GZIP file
in a concatenated GZIP stream and then available() returns zero. It will
not return any content from the next GZIP file until read() is called
again. This is my attempt to explicitly reproduce the root cause.

Before the patch is applied the two new tests fail. After the patch is
applied the two new tests succeed and the other four tests still succeed.

The patch also addresses the demonstration code submitted in the bug report
for JDK-8081450 <https://bugs.openjdk.java.net/browse/JDK-8081450>. After
the patch is applied the demonstration code returns "hello world" as
expected.

## Work Around

This problem is not too difficult to work around. I created a subclass of
InputStream that wrapped the HTTPInputStream but overrode .available() so
that it always return a number > 0. Then GZIPInputStream always read to the
end of the stream correctly. Example work around code is in my answer on Stack
Overflow
<http://stackoverflow.com/questions/41400810/gzipinputstream-closes-prematurely-when-decompressing-httpinputstream>
.

Thank you,

Jeff Harwell
-------------- next part --------------
# HG changeset patch
# User Jeff Harwell <jharwell at fuller.edu>
# Date 1483565634 28800
#      Wed Jan 04 13:33:54 2017 -0800
# Node ID 97437f51e996766c89de2e0a8662f58e3c0d45cd
# Parent  a0c6f393b603a858ea970e3cd1d256ffd3be6789
Patched GZIPInputStream to pass new Test Suite

diff --git a/src/share/classes/java/util/zip/GZIPInputStream.java b/src/share/classes/java/util/zip/GZIPInputStream.java
--- a/src/share/classes/java/util/zip/GZIPInputStream.java
+++ b/src/share/classes/java/util/zip/GZIPInputStream.java
@@ -224,23 +224,28 @@
             (readUInt(in) != (inf.getBytesWritten() & 0xffffffffL)))
             throw new ZipException("Corrupt GZIP trailer");
 
-        // If there are more bytes available in "in" or
-        // the leftover in the "inf" is > 26 bytes:
-        // this.trailer(8) + next.header.min(10) + next.trailer(8)
-        // try concatenated case
-        if (this.in.available() > 0 || n > 26) {
-            int m = 8;                  // this.trailer
-            try {
-                m += readHeader(in);    // next.header
-            } catch (IOException ze) {
-                return true;  // ignore any malformed, do nothing
-            }
-            inf.reset();
-            if (n > m)
-                inf.setInput(buf, len - n + m, n - m);
-            return false;
+        // We cannot know if the input stream has remaining bytes so
+        // assume that it does and try to read the next header. If there isn't
+        // one we will get a EOFException (see this.readUByte). Catch 
+        // this exception and return true (eos reached)
+        int m = 8;                     // this.trailer
+        try {
+            m += readHeader(in);       // next.header
+        } catch (EOFException ze) {
+            // We are at the end of the stream
+            return true;
+        } catch (IOException ze) {
+            // We were not at the end of the stream but what was 
+            // left in the stream didn't make any sense, ignore it
+            // we already have what we came for
+            return true;
         }
-        return true;
+        // We found a valid header for an additional GZIP file
+        inf.reset();
+        if (n > m) {
+            inf.setInput(buf, len - n + m, n - m);
+        }
+        return false; // there is more GZIP data, keep going (concatenated gzip data set)
     }
 
     /*

From paul.sandoz at oracle.com  Thu Jan  5 19:01:29 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 5 Jan 2017 11:01:29 -0800
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
Message-ID: <EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>

Hi,

I encountered some circularity issues with security manager and VarHandles, specifically when attempting to use the new MethodHandles.privateLookupIn, so say ThreadLocalRandom has access to fields in Thread [1].

When running with a security manager ThreadLocalRandom clinit depends on various security stuff that eventually depends on ConcurrentSkipListMap which depends on ThreadLocalRandom, whose static state has not been fully initialzed.

The current security permission check in MethodHandles.privateLookupIn may be a too blunt and possibly should be refined along similar lines to Lookup.checkSecurityManager e.g. no check should be needed for classes within the same module (since this is a refined/controlled/principled form of setAccessible, plus no pounding on final fields). That would solve the problem in this case. But, the general point remains, and i have not thought too hard if there are other ways to solve this.

Paul.

[1] http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8160710-thread-to-tlr/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8160710-thread-to-tlr/webrev/>

> On 3 Jan 2017, at 23:27, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Peter,
> 
> > ...so the only way for this to not cause the same problem is for
> > Class.reflectionFactory field to be initialized before SecurityManager
> > is set.
> >
> > Was this pure luck and we were just waiting for a situation where this
> > was not the case?
> 
> I don't know. If you run with -Xlog:class+init=trace you will see the normal initialization order, and can then compare with and without a security manager; with and without assertions enabled etc etc.
> 
> I'm getting more and more paranoid about initialization order dependencies and the overall fragility of it all (eg that no class initialized before java.lang.Class can use assertions).
> 
> And its even worse when you consider that JVM TI can totally change initialization order in unexpected ways that can lead to total breakage.
> 
> Cheers,
> David
> 
> 
> On 4/01/2017 5:16 PM, Peter Levart wrote:
>> Hi David,
>> 
>> On 12/26/2016 10:16 PM, David Holmes wrote:
>>> Hi Peter,
>>> 
>>> I know this is response to the problems with your other recent change,
>>> but this is an enhancement in my opinion, not a bug fix, and the time
>>> for enhancements is passed - though there is still a process to
>>> request them. I do not like to see last minutes changes like this
>>> where not enough due diligence may be done to identify all the
>>> ramifications.
>> 
>> Since the initialization cycle has now been broken by fix/simplification
>> (JDK-8172048), there is no imminent need to pursue this one at this
>> time, but...
>> 
>>> 
>>> The Class.getMethod() fixes seem to have overstepped the line in that
>>> regard as well, in my opinion. Anything that potentially changes
>>> initialization order is fragile and risky and requires additional
>>> testing.
>> 
>> ...I was surprised that this actually happened at first. The
>> initialization cycle was apparently introduced by my introduction of new
>> class (java.lang.PublicMethods$Key) which in its <clinit> requests
>> ReflectionFactory which does a permission check and all that is
>> triggered from assertion in java.lang.invoke.VarHandle$AccessMode
>> constructor which uses Class::getMethod to verify the assertion
>> condition...
>> 
>> Here's the stack trace, repeated here for clarity:
>> 
>> Error occurred during initialization of VM
>> java.lang.ExceptionInInitializerError
>> at
>> java.lang.PublicMethods$MethodList.filter(java.base at 9-internal/PublicMethods.java:151)
>> 
>> at
>> java.lang.Class.getMethodsRecursive(java.base at 9-internal/Class.java:3191)
>> at java.lang.Class.getMethod0(java.base at 9-internal/Class.java:3175)
>> at java.lang.Class.getMethod(java.base at 9-internal/Class.java:2036)
>> at
>> java.lang.invoke.VarHandle$AccessMode.getReturnType(java.base at 9-internal/VarHandle.java:1826)
>> 
>> at
>> java.lang.invoke.VarHandle$AccessMode.<init>(java.base at 9-internal/VarHandle.java:1792)
>> 
>> at
>> java.lang.invoke.VarHandle$AccessMode.<clinit>(java.base at 9-internal/VarHandle.java:1590)
>> 
>> at
>> java.lang.invoke.VarForm.linkFromStatic(java.base at 9-internal/VarForm.java:127)
>> 
>> at java.lang.invoke.VarForm.<init>(java.base at 9-internal/VarForm.java:50)
>> at
>> java.lang.invoke.VarHandleObjects$FieldInstanceReadOnly.<clinit>(java.base at 9-internal/VarHandleObjects.java:84)
>> 
>> at
>> java.lang.invoke.VarHandles.makeFieldHandle(java.base at 9-internal/VarHandles.java:38)
>> 
>> at
>> java.lang.invoke.MethodHandles$Lookup.getFieldVarHandleCommon(java.base at 9-internal/MethodHandles.java:2241)
>> 
>> at
>> java.lang.invoke.MethodHandles$Lookup.getFieldVarHandle(java.base at 9-internal/MethodHandles.java:2201)
>> 
>> at
>> java.lang.invoke.MethodHandles$Lookup.findVarHandle(java.base at 9-internal/MethodHandles.java:1361)
>> 
>> at
>> java.util.concurrent.atomic.AtomicReference.<clinit>(java.base at 9-internal/AtomicReference.java:57)
>> 
>> at java.security.Policy.<clinit>(java.base at 9-internal/Policy.java:111)
>> at
>> java.security.AccessControlContext.getDebug(java.base at 9-internal/AccessControlContext.java:110)
>> 
>> at
>> java.security.AccessControlContext.checkPermission(java.base at 9-internal/AccessControlContext.java:398)
>> 
>> at
>> java.security.AccessController.checkPermission(java.base at 9-internal/AccessController.java:894)
>> 
>> at
>> java.lang.SecurityManager.checkPermission(java.base at 9-internal/SecurityManager.java:548)
>> 
>> at
>> java.lang.SecurityManager.checkPropertyAccess(java.base at 9-internal/SecurityManager.java:1292)
>> 
>> at java.lang.System.getProperty(java.base at 9-internal/System.java:761)
>> at
>> java.lang.ClassLoader.initSystemClassLoader(java.base at 9-internal/ClassLoader.java:1902)
>> 
>> at java.lang.System.initPhase3(java.base at 9-internal/System.java:1979)
>> Caused by: java.lang.NullPointerException
>> at java.security.Policy.isSet(java.base at 9-internal/Policy.java:126)
>> at
>> java.security.AccessControlContext.getDebug(java.base at 9-internal/AccessControlContext.java:110)
>> 
>> at
>> java.security.AccessController.checkPermission(java.base at 9-internal/AccessController.java:871)
>> 
>> at
>> java.lang.SecurityManager.checkPermission(java.base at 9-internal/SecurityManager.java:548)
>> 
>> at
>> jdk.internal.reflect.ReflectionFactory.getReflectionFactory(java.base at 9-internal/ReflectionFactory.java:132)
>> 
>> at
>> jdk.internal.reflect.ReflectionFactory$GetReflectionFactoryAction.run(java.base at 9-internal/ReflectionFactory.java:106)
>> 
>> at
>> jdk.internal.reflect.ReflectionFactory$GetReflectionFactoryAction.run(java.base at 9-internal/ReflectionFactory.java:103)
>> 
>> at
>> java.security.AccessController.doPrivileged(java.base at 9-internal/Native
>> Method)
>> at
>> java.lang.PublicMethods$Key.<clinit>(java.base at 9-internal/PublicMethods.java:90)
>> 
>> at
>> java.lang.PublicMethods$MethodList.filter(java.base at 9-internal/PublicMethods.java:151)
>> 
>> at
>> java.lang.Class.getMethodsRecursive(java.base at 9-internal/Class.java:3191)
>> at java.lang.Class.getMethod0(java.base at 9-internal/Class.java:3175)
>> at java.lang.Class.getMethod(java.base at 9-internal/Class.java:2036)
>> at
>> java.lang.invoke.VarHandle$AccessMode.getReturnType(java.base at 9-internal/VarHandle.java:1826)
>> 
>> at
>> java.lang.invoke.VarHandle$AccessMode.<init>(java.base at 9-internal/VarHandle.java:1792)
>> 
>> at
>> java.lang.invoke.VarHandle$AccessMode.<clinit>(java.base at 9-internal/VarHandle.java:1590)
>> 
>> at
>> java.lang.invoke.VarForm.linkFromStatic(java.base at 9-internal/VarForm.java:127)
>> 
>> at java.lang.invoke.VarForm.<init>(java.base at 9-internal/VarForm.java:50)
>> at
>> java.lang.invoke.VarHandleObjects$FieldInstanceReadOnly.<clinit>(java.base at 9-internal/VarHandleObjects.java:84)
>> 
>> at
>> java.lang.invoke.VarHandles.makeFieldHandle(java.base at 9-internal/VarHandles.java:38)
>> 
>> at
>> java.lang.invoke.MethodHandles$Lookup.getFieldVarHandleCommon(java.base at 9-internal/MethodHandles.java:2241)
>> 
>> at
>> java.lang.invoke.MethodHandles$Lookup.getFieldVarHandle(java.base at 9-internal/MethodHandles.java:2201)
>> 
>> at
>> java.lang.invoke.MethodHandles$Lookup.findVarHandle(java.base at 9-internal/MethodHandles.java:1361)
>> 
>> at
>> java.util.concurrent.atomic.AtomicReference.<clinit>(java.base at 9-internal/AtomicReference.java:57)
>> 
>> at java.security.Policy.<clinit>(java.base at 9-internal/Policy.java:111)
>> at
>> java.security.AccessControlContext.getDebug(java.base at 9-internal/AccessControlContext.java:110)
>> 
>> at
>> java.security.AccessControlContext.checkPermission(java.base at 9-internal/AccessControlContext.java:398)
>> 
>> at
>> java.security.AccessController.checkPermission(java.base at 9-internal/AccessController.java:894)
>> 
>> at
>> java.lang.SecurityManager.checkPermission(java.base at 9-internal/SecurityManager.java:548)
>> 
>> at
>> java.lang.SecurityManager.checkPropertyAccess(java.base at 9-internal/SecurityManager.java:1292)
>> 
>> at java.lang.System.getProperty(java.base at 9-internal/System.java:761)
>> at
>> java.lang.ClassLoader.initSystemClassLoader(java.base at 9-internal/ClassLoader.java:1902)
>> 
>> at java.lang.System.initPhase3(java.base at 9-internal/System.java:1979)
>> 
>> 
>> But even before my change, Class::getMethod needed access to
>> ReflectionFactory instance. To remind: each reflective object (Method,
>> Field, Constructor) is copied before handed out of a public method such
>> as Class::getMethod. Copying is performed by ReflectionFactory.
>> ReflectionFactory in java.lang.Class is obtained lazily:
>> 
>>    // Fetches the factory for reflective objects
>>    private static ReflectionFactory getReflectionFactory() {
>>        if (reflectionFactory == null) {
>>            reflectionFactory =
>>                java.security.AccessController.doPrivileged
>>                    (new ReflectionFactory.GetReflectionFactoryAction());
>>        }
>>        return reflectionFactory;
>>    }
>>    private static ReflectionFactory reflectionFactory;
>> 
>> ...so the only way for this to not cause the same problem is for
>> Class.reflectionFactory field to be initialized before SecurityManager
>> is set.
>> 
>> Was this pure luck and we were just waiting for a situation where this
>> was not the case?
>> 
>> It is good that this danger is now past as java.security.Policy does not
>> need AtomicReference any more.
>> 
>> Regards, Peter
>> 
>>> 
>>> That said, I am an admirer of your work on OpenJDK! :)
>>> 
>>> Cheers,
>>> David
>>> 
>>> 
>>> On 27/12/2016 5:29 AM, Peter Levart wrote:
>>>> Hi,
>>>> 
>>>> There are 2 ReflectionFactory classes in JDK 9. The old one is
>>>> sun.reflect.ReflectionFactory which ended in jdk.unsupported module and
>>>> to which access is restricted with SecurityManager. There is also new
>>>> jdk.internal.reflect.ReflectionFactory which is used internally by JDK,
>>>> is exported to internal modules only but still uses SecurityManager to
>>>> restrict access to itself. I checked all usages and they all use
>>>> AccessControler.doPrivileged() for obtaining the instance of
>>>> jdk.internal.reflect.ReflectionFactory, which somehow defeats the
>>>> purpose of SecurityManager access checks in this API.
>>>> 
>>>> I think this could be simplified by removing the SecurityManager check
>>>> from jdk.internal.reflect.ReflectionFactory#getReflectionFactory static
>>>> method and change all usages to invoke this method directly without
>>>> doPrivileged(). There are already two sensitive internal APIs exposed
>>>> without SecurityManager checks: jdk.internal.misc.Unsafe#getUnsafe and
>>>> various jdk.internal.misc.SharedSecrets#getXxxAccess methods. So why
>>>> wouldn't internal ReflectionFactory be exposed the same way?
>>>> 
>>>> This would make obtaining the ReflectionFactory more robust and not
>>>> sensitive to bootstrap issues that surfaced recently after my push of a
>>>> fix for issues 8062389, 8029459, 8061950.
>>>> 
>>>> So, what do you think? Is this a worthwhile cleanup and simplification?
>>>> 
>>>> Regards, Peter
>>>> 
>> 


From Roger.Riggs at Oracle.com  Thu Jan  5 22:15:32 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 5 Jan 2017 17:15:32 -0500
Subject: RFR of JDK-8030175:
	java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due
	to timeout
In-Reply-To: <0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
	<0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
Message-ID: <5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>

Hi Hamlin,

There are too many issues being mixed together...

Comments on B) RegistryImpl:

Refactoring of RegistryImpl Main should be clean and clearly separated.

365: static void RegistryImpl run():

-  The signature of run should be run(int port) and documented as 
needing to be run in its
    own thread since it changes Thread context classloader and that it 
sets a securityManager.
    Leave it to main to parse and choose a port number.

-  The comments should be functional as to the purpose of the code and 
not referencing a particular bug.
    (Regardless of prior example).

  - The comment about getting the exact port is out of place because the 
port number cannot be
    retrieved from the returned RegistryImpl.  IF that's why this 
refactoring is needed, then
    perhaps there should be a getPort method that extracts it from the 
created UnicastServerRef.

423: static void main(String[] args):

  - Parsing of args should be left in main(); avoiding the question 
about why NumberFormat is handled.

  - Either main or run should set a security manager; but not both.

Roger




On 1/4/2017 10:21 PM, Hamlin Li wrote:
> Hi Roger,
>
> Thank you for reviewing, please check comments inline.
>
>
> On 2017/1/5 4:18, Roger Riggs wrote:
>> Hi Hamlin,
>>
>> The original issue with timeout may be due to heavily loaded systems 
>> and short timeouts.
>> 15 sec is not enough on an overloaded system to wait for a process to 
>> start and then die.
>>
>> There is no indication in this issue about port-in-use; that would be 
>> a different issue.
> Agree, I put 2 fixes in one patch together as there is no port in use 
> issue reported, but by reviewing the code, potential port in use issue 
> could happen some time in the future.
Best to keep 1-1 to avoid complicating the discussion and increasing 
code complexity.
>>
>>
>> Common comments to both A and B.
>>
>> I'll need more time to look at B; it would be cleaner to use A if it 
>> can address the issue.
>> The alternative is to duplicate the code in run() in the TestLibrary 
>> and not modify the RegistryImpl.
> I prefer B, because
>   1. Although A looks cleaner but B is simulating more like rmiregistry.
>   2. There are some other issue for example JDK-7146543, JDK-8030950, 
> JDK-8038772, fix based on version B works well, but fix based on 
> version A fails.
>   3. Impact of RegistryImpl modification is minimal. ( May we could 
> make Registry run(String args[]) private and access it in test by 
> reflection? )
>   4. Although it's simple to duplicate the code in run() in the 
> TestLibrary, but seems it's not a good design choice. (let's call it 
> version C.)
>   5. For JDK-8170728, the fix will need to modify 
> sun.rmi.registry.RegistryImpl anyway.
>
>
> Thank you for detailed review comments below.
> As we have several options, I will wait for your further comments on 
> choice of version A/B/C, then send out new webrev, hope I only need to 
> send out one version :-).
>
> Thank you
> -Hamlin
>>
>>
>> JavaVM:
>>  - Document the new methods.
>>
>> Line 232: Document the exception that may be thrown from exitValue.
>>
>>
>> RMID:
>> Line 204, 222: when adding new functions to the test library please 
>> add documentation for the methods.
>> There are now many variations of the methods that differ only by the 
>> number arguments.
>> It would be better if the name included some hint as to the 
>> additional functionality.
>>
>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>
>> REGISTRY:
>>   - Document the new methods.
>>
>>   - The name should be more indicative of its function and should NOT 
>> be all caps;  RMID is an acronym where the caps make sense.
>>
>>   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating code 
>> to wait for the subprocess.
>>
>>   - If the subprocesses are in an unknown state it would be useful to 
>> print diagnostic info from the subprocess before terminating.
>>     Line 106:
>>
>>  - Line 124:
>>  - I think I would have promoted the shutdown method to JavaVM 
>> instead of creating a new cleanup method
>>    to keep the code simpler.
>>
>>    ** The cleanup method never calls super.cleanup() so the process 
>> is never destroyed!.
>>
>> AltSecurityManager.java:
>>
>>  - Line 61: the empty constructor can be removed entirely.
>>
>>  - Line 80: change the message to say the exception did not occur.
>>     As written it implies it may have occurred but was not caught.
>>
>>  - Line 86: typo "a unexpected" -> "an unexpected"
>>
>> - Line 90: remove the printStackTrace; it is not useful and is a red 
>> flag in .jtr files
>>
>>  - Line 125: I don't see that cleanup is better than destroy; If 
>> there are doubts about destroy
>>    then destroy should be fixed not avoided.
>>
>> Roger
>>
>>
>>
>>
>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>> Would you please review the below patches?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>> webrev (version A): http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>> webrev (version B): 
>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>>
>>>
>>> There are 2 versions to be reviewed.
>>>
>>> In version A, just use RegistryRunner to replace rmiregistry.
>>> In version B, refactor sun.rmi.registry.RegistryImpl to improve the 
>>> testability of RMI code, and create/use RMIRegistryRunner to 
>>> simulate rmiregistry.
>>>
>>> Thank you
>>> -Hamlin
>>
>


From stzdzyhs at gmail.com  Fri Jan  6 01:23:55 2017
From: stzdzyhs at gmail.com (chen zero)
Date: Fri, 6 Jan 2017 09:23:55 +0800
Subject: About JDK-6772009
In-Reply-To: <CA+kOe0-REcrf0+=AaJ83wkoBXJWZzzdx6-1J-4SgR2ba2u_W+w@mail.gmail.com>
References: <CAF0BZZQAWcqb6rBGsVxZCbi9L99sEMJjiHFwHT1V_7QSFTtW+Q@mail.gmail.com>
	<be65c24d-d446-1fc8-4792-ba847ddd7ad3@oracle.com>
	<CAF0BZZSCaAKdhYAYxX=sWXCyKDD90XHAZX9ZxB-kwMnoQ3YxBg@mail.gmail.com>
	<86b875a3-b21a-0a26-61d0-4cb74a316981@oracle.com>
	<CAF0BZZQ+-Y=vqRRZb4LN0UGS69hXAQKpHORDkwm3-goZ9COZLQ@mail.gmail.com>
	<CA+kOe0-REcrf0+=AaJ83wkoBXJWZzzdx6-1J-4SgR2ba2u_W+w@mail.gmail.com>
Message-ID: <CAF0BZZRGhmfB1rNb7jhnw+aJky9GZSMhYyG6Hnw6ZERgyafnBQ@mail.gmail.com>

Hi Martin,
I just curious and to get self more familiar with java.
and that's what I try to do, simplify the test case, only waiting 1 round
on the barrier
In my previous email, I said I saw BrokenCarrierException, however, it's
very rare to occur, and even I can not reproduce it now.
anyway, I will see the latest code in jdk9....
Thanks,
chenzero

On Fri, Jan 6, 2017 at 2:20 AM, Martin Buchholz <martinrb at google.com> wrote:

> jtreg CancelledLockLoops is not a great test.  There have been changes to
> it in jdk9 and it is not known to fail currently.
>
> But chen, why are you working on this test?  If you see it failing, try
> simply replacing with the jdk9 version.  Otherwise, I'd like to see such
> tests replaced with more focused understandable correctness tests rather
> than patched.
>
> On Wed, Jan 4, 2017 at 9:20 PM, chen zero <stzdzyhs at gmail.com> wrote:
>
>> Yes, the problem is related to the interrupt, timing and combine with
>> BrokenBarrierException, the whole testcase very complex.
>> so, I change the testcase as following:
>>     in the main:
>>           left 2 thread Un-interrupt.
>>           wait on the barrier. // if wait return, that means all threads
>> end.
>>           verify completed > 2
>>
>>    in the working thread:
>>          try lock  and do calculation....
>>          if interrupted, skip calculation
>>          wait on the barrier.
>>
>> yes, the barrier will be only wait 1 time, (in original code the barrier
>> will wait 2 times),
>> in my testing, sometime, in the 2nd time wait, BrokenBarrierException will
>> be thrown, however, it's not catch and make
>> the whole test case skipped.
>> anyway, two times wait on barrier are very complex....
>> so, only 1 time wait on barrier and in my testing, anything is as expected
>> :)
>>
>> My code is from from jdk8u branch from git, and I compare with the code
>> posted in the JiRA, also same.
>>
>>
>> On Thu, Jan 5, 2017 at 12:48 PM, David Holmes <david.holmes at oracle.com>
>> wrote:
>>
>> > Hi,
>> >
>> > You seem to be looking at an older version of the test code.
>> >
>> > As I said in my previous mail I think the problem is that an interrupted
>> > thread can follow this path:
>> >
>> >    if (!interrupted) {
>> >       if (print)
>> >          System.out.printf("completed after %d millis%n",
>> >          NANOSECONDS.toMillis(System.nanoTime() - startTime));
>> >       lock.lock();
>> >       try {
>> >          ++completed;
>> >       }
>> >       finally {
>> >          lock.unlock();
>> >       }
>> >     }
>> >
>> > because interrupted is only set when InterruptedException is caught:
>> >
>> > while (!done || Thread.currentThread().isInterrupted()) {
>> >     try {
>> >         lock.lockInterruptibly();
>> >     }
>> >     catch (InterruptedException ie) {
>> >         interrupted = true;
>> >
>> > but we can also exit the loop due to interruption, without recording the
>> > fact we were interrupted. In which case the completed count will be too
>> > high.
>> >
>> > Cheers,
>> > David
>> >
>> >
>> > On 5/01/2017 2:39 PM, chen zero wrote:
>> >
>> >> Hi David,
>> >> Thank you for reminding.
>> >> I post the code here.
>> >>
>> >>
>> >> import java.util.Arrays;
>> >> import java.util.Collections;
>> >> import java.util.Random;
>> >> import java.util.concurrent.BrokenBarrierException;
>> >> import java.util.concurrent.CyclicBarrier;
>> >> import java.util.concurrent.locks.ReentrantLock;
>> >>
>> >> // https://bugs.openjdk.java.net/browse/JDK-6772009
>> >>
>> >> public final class CancelledLockLoops {
>> >>     static final Random rng = new Random();
>> >>     static boolean print = false;
>> >>     //static final int ITERS = 1000000;
>> >>     static final int ITERS = 10000000;
>> >>
>> >>     static final long TIMEOUT = 100;
>> >>
>> >>     public static void main(String[] args) throws Exception {
>> >>         int maxThreads = 5;
>> >>         if (args.length > 0) {
>> >>             maxThreads = Integer.parseInt(args[0]);
>> >>         }
>> >>
>> >>         print = true;
>> >>
>> >>         for (int i = 2; i <= maxThreads; i += (i+1) >>> 1) {
>> >>             System.out.print("Threads: " + i);
>> >>
>> >>             try {
>> >>                 new ReentrantLockLoop(i).test();
>> >>             }
>> >>             catch (BrokenBarrierException bb) {
>> >>                 // OK, ignore
>> >>                 bb.printStackTrace();
>> >>             }
>> >>             Thread.sleep(TIMEOUT);
>> >>         }
>> >>     }
>> >>
>> >>     static final class ReentrantLockLoop implements Runnable {
>> >>         private int v = rng.nextInt();
>> >>         private int completed;
>> >>         private volatile int result = 17;
>> >>         private final ReentrantLock lock = new ReentrantLock();
>> >>         private final LoopHelpers.BarrierTimer timer = new
>> >> LoopHelpers.BarrierTimer();
>> >>         private final CyclicBarrier barrier;
>> >>         private final int nthreads;
>> >>
>> >>         ReentrantLockLoop(int nthreads) {
>> >>             this.nthreads = nthreads;
>> >>             barrier = new CyclicBarrier(nthreads+1, timer);
>> >>         }
>> >>
>> >>         void checkBarrierStatus() {
>> >>             if(this.barrier.isBroken()) {
>> >>                 throw new Error("barrier is broken !!!");
>> >>             }
>> >>         }
>> >>
>> >>         final void test() throws Exception {
>> >>             checkBarrierStatus();
>> >>
>> >>             timer.run();
>> >>
>> >>             Thread[] threads = new Thread[nthreads];
>> >>             for (int i = 0; i < threads.length; ++i) {
>> >>                 threads[i] = new Thread(this, "th"+i);
>> >>             }
>> >>
>> >>             for (int i = 0; i < threads.length; ++i) {
>> >>                 threads[i].start();
>> >>             }
>> >>
>> >>             Thread[] cancels =  (Thread[])(threads.clone());
>> >>
>> >>             Collections.shuffle(Arrays.asList(cancels), rng);
>> >>             Thread.sleep(TIMEOUT);
>> >>             for (int i = 0; i < cancels.length-2; ++i) {
>> >>                 cancels[i].interrupt();
>> >>                 // make sure all OK even when cancellations spaced out
>> >>                 if ((i & 3) == 0) {
>> >>                     Thread.sleep(1 + rng.nextInt(10));
>> >>                 }
>> >>             }
>> >>
>> >>             Thread.sleep(TIMEOUT);
>> >>
>> >>             try {
>> >>                 // in here, the barrier might be broken because some
>> >> working threads is interrupted.
>> >>                 // so, catching the BrokenBarrierException to let
>> >> testcase continue running
>> >>                 barrier.await();
>> >>             }
>> >>             catch(BrokenBarrierException e) {
>> >>                 // nop
>> >>             }
>> >>
>> >>             if (print) {
>> >>                 // since the barrier might be broken ( the barrier
>> >> action will not run),
>> >>                 // running here to ensure time is set.
>> >>                 timer.run();
>> >>                 long time = timer.getTime();
>> >>                 double secs = (double)(time) / 1000000000.0;
>> >>                 System.out.println("\t " + secs + "s run time");
>> >>             }
>> >>
>> >>             int c;
>> >>             lock.lock();
>> >>             //System.out.println("main to verify completed.....");
>> >>
>> >>             try {
>> >>                 c = completed;
>> >>             }
>> >>             finally {
>> >>                 lock.unlock();
>> >>             }
>> >>             // here the completed should not < 2, it can not guarantee
>> >> that always == 2.
>> >>             if (c < 2) {
>> >>                 throw new Error("Completed < 2 : " + c);
>> >>             }
>> >>
>> >>             int r = result;
>> >>             if (r == 0) { // avoid overoptimization
>> >>                 System.out.println("useless result: " + r);
>> >>             }
>> >>         }
>> >>
>> >>         public final void run() {
>> >>             try {
>> >>                 checkBarrierStatus();
>> >>
>> >>                 int sum = v;
>> >>                 int x = 0;
>> >>                 int n = ITERS;
>> >>                 do {
>> >>                     try {
>> >>                         lock.lockInterruptibly();
>> >>                     }
>> >>                     catch (InterruptedException ie) {
>> >>                         break;
>> >>                     }
>> >>                     try {
>> >>                         v = x = LoopHelpers.compute1(v);
>> >>                     }
>> >>                     finally {
>> >>                         lock.unlock();
>> >>                     }
>> >>                     sum += LoopHelpers.compute2(x);
>> >>                 } while (n-- > 0);
>> >>
>> >>                 /*
>> >>                  * in the main thread, two threads are un-interrupted,
>> >> others threads are interrupted.
>> >>                  * this line, however, can not guarantee that only
>> >> "un-interrupted" threads can go in,
>> >>                  * but also interrupted threads can go in,
>> >>                  * so, the "completed" will not always == 2, might be
>> > 2
>> >>                  */
>> >>                 if (n < 0) {
>> >>                     lock.lock();
>> >>                     try {
>> >>                         ++completed;
>> >>                     }
>> >>                     finally {
>> >>                         lock.unlock();
>> >>                     }
>> >>                 }
>> >>
>> >>                 result += sum;
>> >>                 barrier.await();
>> >>             }
>> >>             catch(BrokenBarrierException ex) {
>> >>                 //ex.printStackTrace();
>> >>             }
>> >>             catch(InterruptedException ex) {
>> >>                 //ex.printStackTrace();
>> >>             }
>> >>             catch (Exception ex) {
>> >>                 ex.printStackTrace();
>> >>                 return;
>> >>             }
>> >>         }
>> >>     }
>> >>
>> >> }
>> >>
>> >>
>> >> On Thu, Jan 5, 2017 at 12:20 PM, David Holmes <david.holmes at oracle.com
>> >> <mailto:david.holmes at oracle.com>> wrote:
>> >>
>> >>     Hi chenzero,
>> >>
>> >>     Attachments get stripped from the mailing lists so you'll need to
>> >>     include your patch inline, or else get someone to host it for you
>> on
>> >>     cr.openjdk.java.net <http://cr.openjdk.java.net>
>> >>
>> >>     Thanks,
>> >>     David
>> >>     .....
>> >>
>> >>
>>
>
>

From huaming.li at oracle.com  Fri Jan  6 01:55:21 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 6 Jan 2017 09:55:21 +0800
Subject: RFR of JDK-8030175:
	java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due
	to timeout
In-Reply-To: <5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
	<0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
	<5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
Message-ID: <644724ce-9020-0f3f-49cd-a0112c1f729e@oracle.com>



On 2017/1/6 6:15, Roger Riggs wrote:
>
>
> On 1/4/2017 10:21 PM, Hamlin Li wrote:
>> Hi Roger,
>>
>> Thank you for reviewing, please check comments inline.
>>
>>
>> On 2017/1/5 4:18, Roger Riggs wrote:
>>> Hi Hamlin,
>>>
>>> The original issue with timeout may be due to heavily loaded systems 
>>> and short timeouts.
>>> 15 sec is not enough on an overloaded system to wait for a process 
>>> to start and then die.
>>>
>>> There is no indication in this issue about port-in-use; that would 
>>> be a different issue.
>> Agree, I put 2 fixes in one patch together as there is no port in use 
>> issue reported, but by reviewing the code, potential port in use 
>> issue could happen some time in the future.
> Best to keep 1-1 to avoid complicating the discussion and increasing 
> code complexity.
Hi Roger,

Got it, the new webrev for timeout issue is at: 
http://cr.openjdk.java.net/~mli/8030175/webrev.01/

I just created another bug 
https://bugs.openjdk.java.net/browse/JDK-8172314 to track the "port in 
use" bug, will send out separate webrev in another thread later.

Thank you
-Hamlin
>>>
>>>
>>> Common comments to both A and B.
>>>
>>> I'll need more time to look at B; it would be cleaner to use A if it 
>>> can address the issue.
>>> The alternative is to duplicate the code in run() in the TestLibrary 
>>> and not modify the RegistryImpl.
>> I prefer B, because
>>   1. Although A looks cleaner but B is simulating more like rmiregistry.
>>   2. There are some other issue for example JDK-7146543, JDK-8030950, 
>> JDK-8038772, fix based on version B works well, but fix based on 
>> version A fails.
>>   3. Impact of RegistryImpl modification is minimal. ( May we could 
>> make Registry run(String args[]) private and access it in test by 
>> reflection? )
>>   4. Although it's simple to duplicate the code in run() in the 
>> TestLibrary, but seems it's not a good design choice. (let's call it 
>> version C.)
>>   5. For JDK-8170728, the fix will need to modify 
>> sun.rmi.registry.RegistryImpl anyway.
>>
>>
>> Thank you for detailed review comments below.
>> As we have several options, I will wait for your further comments on 
>> choice of version A/B/C, then send out new webrev, hope I only need 
>> to send out one version :-).
>>
>> Thank you
>> -Hamlin
>>>
>>>
>>> JavaVM:
>>>  - Document the new methods.
>>>
>>> Line 232: Document the exception that may be thrown from exitValue.
>>>
>>>
>>> RMID:
>>> Line 204, 222: when adding new functions to the test library please 
>>> add documentation for the methods.
>>> There are now many variations of the methods that differ only by the 
>>> number arguments.
>>> It would be better if the name included some hint as to the 
>>> additional functionality.
>>>
>>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>>
>>> REGISTRY:
>>>   - Document the new methods.
>>>
>>>   - The name should be more indicative of its function and should 
>>> NOT be all caps;  RMID is an acronym where the caps make sense.
>>>
>>>   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating code 
>>> to wait for the subprocess.
>>>
>>>   - If the subprocesses are in an unknown state it would be useful 
>>> to print diagnostic info from the subprocess before terminating.
>>>     Line 106:
>>>
>>>  - Line 124:
>>>  - I think I would have promoted the shutdown method to JavaVM 
>>> instead of creating a new cleanup method
>>>    to keep the code simpler.
>>>
>>>    ** The cleanup method never calls super.cleanup() so the process 
>>> is never destroyed!.
>>>
>>> AltSecurityManager.java:
>>>
>>>  - Line 61: the empty constructor can be removed entirely.
>>>
>>>  - Line 80: change the message to say the exception did not occur.
>>>     As written it implies it may have occurred but was not caught.
>>>
>>>  - Line 86: typo "a unexpected" -> "an unexpected"
>>>
>>> - Line 90: remove the printStackTrace; it is not useful and is a red 
>>> flag in .jtr files
>>>
>>>  - Line 125: I don't see that cleanup is better than destroy; If 
>>> there are doubts about destroy
>>>    then destroy should be fixed not avoided.
>>>
>>> Roger
>>>
>>>
>>>
>>>
>>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>>> Would you please review the below patches?
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>>> webrev (version A): http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>>> webrev (version B): 
>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>>>
>>>>
>>>> There are 2 versions to be reviewed.
>>>>
>>>> In version A, just use RegistryRunner to replace rmiregistry.
>>>> In version B, refactor sun.rmi.registry.RegistryImpl to improve the 
>>>> testability of RMI code, and create/use RMIRegistryRunner to 
>>>> simulate rmiregistry.
>>>>
>>>> Thank you
>>>> -Hamlin
>>>
>>
>


From martinrb at google.com  Fri Jan  6 04:27:30 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 5 Jan 2017 20:27:30 -0800
Subject: About JDK-6772009
In-Reply-To: <CAF0BZZRGhmfB1rNb7jhnw+aJky9GZSMhYyG6Hnw6ZERgyafnBQ@mail.gmail.com>
References: <CAF0BZZQAWcqb6rBGsVxZCbi9L99sEMJjiHFwHT1V_7QSFTtW+Q@mail.gmail.com>
	<be65c24d-d446-1fc8-4792-ba847ddd7ad3@oracle.com>
	<CAF0BZZSCaAKdhYAYxX=sWXCyKDD90XHAZX9ZxB-kwMnoQ3YxBg@mail.gmail.com>
	<86b875a3-b21a-0a26-61d0-4cb74a316981@oracle.com>
	<CAF0BZZQ+-Y=vqRRZb4LN0UGS69hXAQKpHORDkwm3-goZ9COZLQ@mail.gmail.com>
	<CA+kOe0-REcrf0+=AaJ83wkoBXJWZzzdx6-1J-4SgR2ba2u_W+w@mail.gmail.com>
	<CAF0BZZRGhmfB1rNb7jhnw+aJky9GZSMhYyG6Hnw6ZERgyafnBQ@mail.gmail.com>
Message-ID: <CA+kOe0-1vb76hbG_rb7iYOiJkj6YUbmQUDUD0mKy8f=+hD+mLA@mail.gmail.com>

Hi chen,

The latest versions of the code lives in jsr166 CVS
http://g.oswego.edu/dl/concurrency-interest/
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/jtreg/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java?view=co
There's been work to make tests more robust that has was focused on jdk9.
There's lots of good concurrent code to study, even tests, but I don't
recommend the "Loops" jtreg tests.

On Thu, Jan 5, 2017 at 5:23 PM, chen zero <stzdzyhs at gmail.com> wrote:

> Hi Martin,
> I just curious and to get self more familiar with java.
> and that's what I try to do, simplify the test case, only waiting 1 round
> on the barrier
> In my previous email, I said I saw BrokenCarrierException, however, it's
> very rare to occur, and even I can not reproduce it now.
> anyway, I will see the latest code in jdk9....
> Thanks,
> chenzero
>
> On Fri, Jan 6, 2017 at 2:20 AM, Martin Buchholz <martinrb at google.com>
> wrote:
>
>> jtreg CancelledLockLoops is not a great test.  There have been changes to
>> it in jdk9 and it is not known to fail currently.
>>
>> But chen, why are you working on this test?  If you see it failing, try
>> simply replacing with the jdk9 version.  Otherwise, I'd like to see such
>> tests replaced with more focused understandable correctness tests rather
>> than patched.
>>
>> On Wed, Jan 4, 2017 at 9:20 PM, chen zero <stzdzyhs at gmail.com> wrote:
>>
>>> Yes, the problem is related to the interrupt, timing and combine with
>>> BrokenBarrierException, the whole testcase very complex.
>>> so, I change the testcase as following:
>>>     in the main:
>>>           left 2 thread Un-interrupt.
>>>           wait on the barrier. // if wait return, that means all threads
>>> end.
>>>           verify completed > 2
>>>
>>>    in the working thread:
>>>          try lock  and do calculation....
>>>          if interrupted, skip calculation
>>>          wait on the barrier.
>>>
>>> yes, the barrier will be only wait 1 time, (in original code the barrier
>>> will wait 2 times),
>>> in my testing, sometime, in the 2nd time wait, BrokenBarrierException
>>> will
>>> be thrown, however, it's not catch and make
>>> the whole test case skipped.
>>> anyway, two times wait on barrier are very complex....
>>> so, only 1 time wait on barrier and in my testing, anything is as
>>> expected
>>> :)
>>>
>>> My code is from from jdk8u branch from git, and I compare with the code
>>> posted in the JiRA, also same.
>>>
>>>
>>> On Thu, Jan 5, 2017 at 12:48 PM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > You seem to be looking at an older version of the test code.
>>> >
>>> > As I said in my previous mail I think the problem is that an
>>> interrupted
>>> > thread can follow this path:
>>> >
>>> >    if (!interrupted) {
>>> >       if (print)
>>> >          System.out.printf("completed after %d millis%n",
>>> >          NANOSECONDS.toMillis(System.nanoTime() - startTime));
>>> >       lock.lock();
>>> >       try {
>>> >          ++completed;
>>> >       }
>>> >       finally {
>>> >          lock.unlock();
>>> >       }
>>> >     }
>>> >
>>> > because interrupted is only set when InterruptedException is caught:
>>> >
>>> > while (!done || Thread.currentThread().isInterrupted()) {
>>> >     try {
>>> >         lock.lockInterruptibly();
>>> >     }
>>> >     catch (InterruptedException ie) {
>>> >         interrupted = true;
>>> >
>>> > but we can also exit the loop due to interruption, without recording
>>> the
>>> > fact we were interrupted. In which case the completed count will be too
>>> > high.
>>> >
>>> > Cheers,
>>> > David
>>> >
>>> >
>>> > On 5/01/2017 2:39 PM, chen zero wrote:
>>> >
>>> >> Hi David,
>>> >> Thank you for reminding.
>>> >> I post the code here.
>>> >>
>>> >>
>>> >> import java.util.Arrays;
>>> >> import java.util.Collections;
>>> >> import java.util.Random;
>>> >> import java.util.concurrent.BrokenBarrierException;
>>> >> import java.util.concurrent.CyclicBarrier;
>>> >> import java.util.concurrent.locks.ReentrantLock;
>>> >>
>>> >> // https://bugs.openjdk.java.net/browse/JDK-6772009
>>> >>
>>> >> public final class CancelledLockLoops {
>>> >>     static final Random rng = new Random();
>>> >>     static boolean print = false;
>>> >>     //static final int ITERS = 1000000;
>>> >>     static final int ITERS = 10000000;
>>> >>
>>> >>     static final long TIMEOUT = 100;
>>> >>
>>> >>     public static void main(String[] args) throws Exception {
>>> >>         int maxThreads = 5;
>>> >>         if (args.length > 0) {
>>> >>             maxThreads = Integer.parseInt(args[0]);
>>> >>         }
>>> >>
>>> >>         print = true;
>>> >>
>>> >>         for (int i = 2; i <= maxThreads; i += (i+1) >>> 1) {
>>> >>             System.out.print("Threads: " + i);
>>> >>
>>> >>             try {
>>> >>                 new ReentrantLockLoop(i).test();
>>> >>             }
>>> >>             catch (BrokenBarrierException bb) {
>>> >>                 // OK, ignore
>>> >>                 bb.printStackTrace();
>>> >>             }
>>> >>             Thread.sleep(TIMEOUT);
>>> >>         }
>>> >>     }
>>> >>
>>> >>     static final class ReentrantLockLoop implements Runnable {
>>> >>         private int v = rng.nextInt();
>>> >>         private int completed;
>>> >>         private volatile int result = 17;
>>> >>         private final ReentrantLock lock = new ReentrantLock();
>>> >>         private final LoopHelpers.BarrierTimer timer = new
>>> >> LoopHelpers.BarrierTimer();
>>> >>         private final CyclicBarrier barrier;
>>> >>         private final int nthreads;
>>> >>
>>> >>         ReentrantLockLoop(int nthreads) {
>>> >>             this.nthreads = nthreads;
>>> >>             barrier = new CyclicBarrier(nthreads+1, timer);
>>> >>         }
>>> >>
>>> >>         void checkBarrierStatus() {
>>> >>             if(this.barrier.isBroken()) {
>>> >>                 throw new Error("barrier is broken !!!");
>>> >>             }
>>> >>         }
>>> >>
>>> >>         final void test() throws Exception {
>>> >>             checkBarrierStatus();
>>> >>
>>> >>             timer.run();
>>> >>
>>> >>             Thread[] threads = new Thread[nthreads];
>>> >>             for (int i = 0; i < threads.length; ++i) {
>>> >>                 threads[i] = new Thread(this, "th"+i);
>>> >>             }
>>> >>
>>> >>             for (int i = 0; i < threads.length; ++i) {
>>> >>                 threads[i].start();
>>> >>             }
>>> >>
>>> >>             Thread[] cancels =  (Thread[])(threads.clone());
>>> >>
>>> >>             Collections.shuffle(Arrays.asList(cancels), rng);
>>> >>             Thread.sleep(TIMEOUT);
>>> >>             for (int i = 0; i < cancels.length-2; ++i) {
>>> >>                 cancels[i].interrupt();
>>> >>                 // make sure all OK even when cancellations spaced out
>>> >>                 if ((i & 3) == 0) {
>>> >>                     Thread.sleep(1 + rng.nextInt(10));
>>> >>                 }
>>> >>             }
>>> >>
>>> >>             Thread.sleep(TIMEOUT);
>>> >>
>>> >>             try {
>>> >>                 // in here, the barrier might be broken because some
>>> >> working threads is interrupted.
>>> >>                 // so, catching the BrokenBarrierException to let
>>> >> testcase continue running
>>> >>                 barrier.await();
>>> >>             }
>>> >>             catch(BrokenBarrierException e) {
>>> >>                 // nop
>>> >>             }
>>> >>
>>> >>             if (print) {
>>> >>                 // since the barrier might be broken ( the barrier
>>> >> action will not run),
>>> >>                 // running here to ensure time is set.
>>> >>                 timer.run();
>>> >>                 long time = timer.getTime();
>>> >>                 double secs = (double)(time) / 1000000000.0;
>>> >>                 System.out.println("\t " + secs + "s run time");
>>> >>             }
>>> >>
>>> >>             int c;
>>> >>             lock.lock();
>>> >>             //System.out.println("main to verify completed.....");
>>> >>
>>> >>             try {
>>> >>                 c = completed;
>>> >>             }
>>> >>             finally {
>>> >>                 lock.unlock();
>>> >>             }
>>> >>             // here the completed should not < 2, it can not guarantee
>>> >> that always == 2.
>>> >>             if (c < 2) {
>>> >>                 throw new Error("Completed < 2 : " + c);
>>> >>             }
>>> >>
>>> >>             int r = result;
>>> >>             if (r == 0) { // avoid overoptimization
>>> >>                 System.out.println("useless result: " + r);
>>> >>             }
>>> >>         }
>>> >>
>>> >>         public final void run() {
>>> >>             try {
>>> >>                 checkBarrierStatus();
>>> >>
>>> >>                 int sum = v;
>>> >>                 int x = 0;
>>> >>                 int n = ITERS;
>>> >>                 do {
>>> >>                     try {
>>> >>                         lock.lockInterruptibly();
>>> >>                     }
>>> >>                     catch (InterruptedException ie) {
>>> >>                         break;
>>> >>                     }
>>> >>                     try {
>>> >>                         v = x = LoopHelpers.compute1(v);
>>> >>                     }
>>> >>                     finally {
>>> >>                         lock.unlock();
>>> >>                     }
>>> >>                     sum += LoopHelpers.compute2(x);
>>> >>                 } while (n-- > 0);
>>> >>
>>> >>                 /*
>>> >>                  * in the main thread, two threads are un-interrupted,
>>> >> others threads are interrupted.
>>> >>                  * this line, however, can not guarantee that only
>>> >> "un-interrupted" threads can go in,
>>> >>                  * but also interrupted threads can go in,
>>> >>                  * so, the "completed" will not always == 2, might be
>>> > 2
>>> >>                  */
>>> >>                 if (n < 0) {
>>> >>                     lock.lock();
>>> >>                     try {
>>> >>                         ++completed;
>>> >>                     }
>>> >>                     finally {
>>> >>                         lock.unlock();
>>> >>                     }
>>> >>                 }
>>> >>
>>> >>                 result += sum;
>>> >>                 barrier.await();
>>> >>             }
>>> >>             catch(BrokenBarrierException ex) {
>>> >>                 //ex.printStackTrace();
>>> >>             }
>>> >>             catch(InterruptedException ex) {
>>> >>                 //ex.printStackTrace();
>>> >>             }
>>> >>             catch (Exception ex) {
>>> >>                 ex.printStackTrace();
>>> >>                 return;
>>> >>             }
>>> >>         }
>>> >>     }
>>> >>
>>> >> }
>>> >>
>>> >>
>>> >> On Thu, Jan 5, 2017 at 12:20 PM, David Holmes <
>>> david.holmes at oracle.com
>>> >> <mailto:david.holmes at oracle.com>> wrote:
>>> >>
>>> >>     Hi chenzero,
>>> >>
>>> >>     Attachments get stripped from the mailing lists so you'll need to
>>> >>     include your patch inline, or else get someone to host it for you
>>> on
>>> >>     cr.openjdk.java.net <http://cr.openjdk.java.net>
>>> >>
>>> >>     Thanks,
>>> >>     David
>>> >>     .....
>>> >>
>>> >>
>>>
>>
>>
>

From felix.yang at oracle.com  Fri Jan  6 06:20:55 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Fri, 6 Jan 2017 14:20:55 +0800
Subject: RFR 8075884, new tests to check runtime usage with Multi-Release jars
Message-ID: <b797746d-ba2e-f156-220c-b09b1b911c3a@oracle.com>

Hi there,

     please review the following new tests to check runtime usage with 
Multi-Release jars.

Bug:

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

Webrev:

     http://cr.openjdk.java.net/~xiaofeya/8075884/webrev.00/

Thanks,

Felix


From stzdzyhs at gmail.com  Fri Jan  6 08:52:58 2017
From: stzdzyhs at gmail.com (chen zero)
Date: Fri, 6 Jan 2017 16:52:58 +0800
Subject: About JDK-6772009
In-Reply-To: <CA+kOe0-1vb76hbG_rb7iYOiJkj6YUbmQUDUD0mKy8f=+hD+mLA@mail.gmail.com>
References: <CAF0BZZQAWcqb6rBGsVxZCbi9L99sEMJjiHFwHT1V_7QSFTtW+Q@mail.gmail.com>
	<be65c24d-d446-1fc8-4792-ba847ddd7ad3@oracle.com>
	<CAF0BZZSCaAKdhYAYxX=sWXCyKDD90XHAZX9ZxB-kwMnoQ3YxBg@mail.gmail.com>
	<86b875a3-b21a-0a26-61d0-4cb74a316981@oracle.com>
	<CAF0BZZQ+-Y=vqRRZb4LN0UGS69hXAQKpHORDkwm3-goZ9COZLQ@mail.gmail.com>
	<CA+kOe0-REcrf0+=AaJ83wkoBXJWZzzdx6-1J-4SgR2ba2u_W+w@mail.gmail.com>
	<CAF0BZZRGhmfB1rNb7jhnw+aJky9GZSMhYyG6Hnw6ZERgyafnBQ@mail.gmail.com>
	<CA+kOe0-1vb76hbG_rb7iYOiJkj6YUbmQUDUD0mKy8f=+hD+mLA@mail.gmail.com>
Message-ID: <CAF0BZZR7TRPwsu+hdOm1_4RwbfALYRXWtWz5DAm-T+G2+rnyMw@mail.gmail.com>

Hi Martin,
Thanks for the very useful links!
?I will study those first...
Regards,
chenzero


On Fri, Jan 6, 2017 at 12:27 PM, Martin Buchholz <martinrb at google.com>
wrote:

> Hi chen,
>
> The latest versions of the code lives in jsr166 CVS
> http://g.oswego.edu/dl/concurrency-interest/
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/
> test/jtreg/util/concurrent/locks/ReentrantLock/
> CancelledLockLoops.java?view=co
> There's been work to make tests more robust that has was focused on jdk9.
> There's lots of good concurrent code to study, even tests, but I don't
> recommend the "Loops" jtreg tests.
>
> On Thu, Jan 5, 2017 at 5:23 PM, chen zero <stzdzyhs at gmail.com> wrote:
>
>> Hi Martin,
>> I just curious and to get self more familiar with java.
>> and that's what I try to do, simplify the test case, only waiting 1 round
>> on the barrier
>> In my previous email, I said I saw BrokenCarrierException, however, it's
>> very rare to occur, and even I can not reproduce it now.
>> anyway, I will see the latest code in jdk9....
>> Thanks,
>> chenzero
>>
>> On Fri, Jan 6, 2017 at 2:20 AM, Martin Buchholz <martinrb at google.com>
>> wrote:
>>
>>> jtreg CancelledLockLoops is not a great test.  There have been changes
>>> to it in jdk9 and it is not known to fail currently.
>>>
>>> But chen, why are you working on this test?  If you see it failing, try
>>> simply replacing with the jdk9 version.  Otherwise, I'd like to see such
>>> tests replaced with more focused understandable correctness tests rather
>>> than patched.
>>>
>>> On Wed, Jan 4, 2017 at 9:20 PM, chen zero <stzdzyhs at gmail.com> wrote:
>>>
>>>> Yes, the problem is related to the interrupt, timing and combine with
>>>> BrokenBarrierException, the whole testcase very complex.
>>>> so, I change the testcase as following:
>>>>     in the main:
>>>>           left 2 thread Un-interrupt.
>>>>           wait on the barrier. // if wait return, that means all threads
>>>> end.
>>>>           verify completed > 2
>>>>
>>>>    in the working thread:
>>>>          try lock  and do calculation....
>>>>          if interrupted, skip calculation
>>>>          wait on the barrier.
>>>>
>>>> yes, the barrier will be only wait 1 time, (in original code the barrier
>>>> will wait 2 times),
>>>> in my testing, sometime, in the 2nd time wait, BrokenBarrierException
>>>> will
>>>> be thrown, however, it's not catch and make
>>>> the whole test case skipped.
>>>> anyway, two times wait on barrier are very complex....
>>>> so, only 1 time wait on barrier and in my testing, anything is as
>>>> expected
>>>> :)
>>>>
>>>> My code is from from jdk8u branch from git, and I compare with the code
>>>> posted in the JiRA, also same.
>>>>
>>>>
>>>> On Thu, Jan 5, 2017 at 12:48 PM, David Holmes <david.holmes at oracle.com>
>>>> wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > You seem to be looking at an older version of the test code.
>>>> >
>>>> > As I said in my previous mail I think the problem is that an
>>>> interrupted
>>>> > thread can follow this path:
>>>> >
>>>> >    if (!interrupted) {
>>>> >       if (print)
>>>> >          System.out.printf("completed after %d millis%n",
>>>> >          NANOSECONDS.toMillis(System.nanoTime() - startTime));
>>>> >       lock.lock();
>>>> >       try {
>>>> >          ++completed;
>>>> >       }
>>>> >       finally {
>>>> >          lock.unlock();
>>>> >       }
>>>> >     }
>>>> >
>>>> > because interrupted is only set when InterruptedException is caught:
>>>> >
>>>> > while (!done || Thread.currentThread().isInterrupted()) {
>>>> >     try {
>>>> >         lock.lockInterruptibly();
>>>> >     }
>>>> >     catch (InterruptedException ie) {
>>>> >         interrupted = true;
>>>> >
>>>> > but we can also exit the loop due to interruption, without recording
>>>> the
>>>> > fact we were interrupted. In which case the completed count will be
>>>> too
>>>> > high.
>>>> >
>>>> > Cheers,
>>>> > David
>>>> >
>>>> >
>>>> > On 5/01/2017 2:39 PM, chen zero wrote:
>>>> >
>>>> >> Hi David,
>>>> >> Thank you for reminding.
>>>> >> I post the code here.
>>>> >>
>>>> >>
>>>> >> import java.util.Arrays;
>>>> >> import java.util.Collections;
>>>> >> import java.util.Random;
>>>> >> import java.util.concurrent.BrokenBarrierException;
>>>> >> import java.util.concurrent.CyclicBarrier;
>>>> >> import java.util.concurrent.locks.ReentrantLock;
>>>> >>
>>>> >> // https://bugs.openjdk.java.net/browse/JDK-6772009
>>>> >>
>>>> >> public final class CancelledLockLoops {
>>>> >>     static final Random rng = new Random();
>>>> >>     static boolean print = false;
>>>> >>     //static final int ITERS = 1000000;
>>>> >>     static final int ITERS = 10000000;
>>>> >>
>>>> >>     static final long TIMEOUT = 100;
>>>> >>
>>>> >>     public static void main(String[] args) throws Exception {
>>>> >>         int maxThreads = 5;
>>>> >>         if (args.length > 0) {
>>>> >>             maxThreads = Integer.parseInt(args[0]);
>>>> >>         }
>>>> >>
>>>> >>         print = true;
>>>> >>
>>>> >>         for (int i = 2; i <= maxThreads; i += (i+1) >>> 1) {
>>>> >>             System.out.print("Threads: " + i);
>>>> >>
>>>> >>             try {
>>>> >>                 new ReentrantLockLoop(i).test();
>>>> >>             }
>>>> >>             catch (BrokenBarrierException bb) {
>>>> >>                 // OK, ignore
>>>> >>                 bb.printStackTrace();
>>>> >>             }
>>>> >>             Thread.sleep(TIMEOUT);
>>>> >>         }
>>>> >>     }
>>>> >>
>>>> >>     static final class ReentrantLockLoop implements Runnable {
>>>> >>         private int v = rng.nextInt();
>>>> >>         private int completed;
>>>> >>         private volatile int result = 17;
>>>> >>         private final ReentrantLock lock = new ReentrantLock();
>>>> >>         private final LoopHelpers.BarrierTimer timer = new
>>>> >> LoopHelpers.BarrierTimer();
>>>> >>         private final CyclicBarrier barrier;
>>>> >>         private final int nthreads;
>>>> >>
>>>> >>         ReentrantLockLoop(int nthreads) {
>>>> >>             this.nthreads = nthreads;
>>>> >>             barrier = new CyclicBarrier(nthreads+1, timer);
>>>> >>         }
>>>> >>
>>>> >>         void checkBarrierStatus() {
>>>> >>             if(this.barrier.isBroken()) {
>>>> >>                 throw new Error("barrier is broken !!!");
>>>> >>             }
>>>> >>         }
>>>> >>
>>>> >>         final void test() throws Exception {
>>>> >>             checkBarrierStatus();
>>>> >>
>>>> >>             timer.run();
>>>> >>
>>>> >>             Thread[] threads = new Thread[nthreads];
>>>> >>             for (int i = 0; i < threads.length; ++i) {
>>>> >>                 threads[i] = new Thread(this, "th"+i);
>>>> >>             }
>>>> >>
>>>> >>             for (int i = 0; i < threads.length; ++i) {
>>>> >>                 threads[i].start();
>>>> >>             }
>>>> >>
>>>> >>             Thread[] cancels =  (Thread[])(threads.clone());
>>>> >>
>>>> >>             Collections.shuffle(Arrays.asList(cancels), rng);
>>>> >>             Thread.sleep(TIMEOUT);
>>>> >>             for (int i = 0; i < cancels.length-2; ++i) {
>>>> >>                 cancels[i].interrupt();
>>>> >>                 // make sure all OK even when cancellations spaced
>>>> out
>>>> >>                 if ((i & 3) == 0) {
>>>> >>                     Thread.sleep(1 + rng.nextInt(10));
>>>> >>                 }
>>>> >>             }
>>>> >>
>>>> >>             Thread.sleep(TIMEOUT);
>>>> >>
>>>> >>             try {
>>>> >>                 // in here, the barrier might be broken because some
>>>> >> working threads is interrupted.
>>>> >>                 // so, catching the BrokenBarrierException to let
>>>> >> testcase continue running
>>>> >>                 barrier.await();
>>>> >>             }
>>>> >>             catch(BrokenBarrierException e) {
>>>> >>                 // nop
>>>> >>             }
>>>> >>
>>>> >>             if (print) {
>>>> >>                 // since the barrier might be broken ( the barrier
>>>> >> action will not run),
>>>> >>                 // running here to ensure time is set.
>>>> >>                 timer.run();
>>>> >>                 long time = timer.getTime();
>>>> >>                 double secs = (double)(time) / 1000000000.0;
>>>> >>                 System.out.println("\t " + secs + "s run time");
>>>> >>             }
>>>> >>
>>>> >>             int c;
>>>> >>             lock.lock();
>>>> >>             //System.out.println("main to verify completed.....");
>>>> >>
>>>> >>             try {
>>>> >>                 c = completed;
>>>> >>             }
>>>> >>             finally {
>>>> >>                 lock.unlock();
>>>> >>             }
>>>> >>             // here the completed should not < 2, it can not
>>>> guarantee
>>>> >> that always == 2.
>>>> >>             if (c < 2) {
>>>> >>                 throw new Error("Completed < 2 : " + c);
>>>> >>             }
>>>> >>
>>>> >>             int r = result;
>>>> >>             if (r == 0) { // avoid overoptimization
>>>> >>                 System.out.println("useless result: " + r);
>>>> >>             }
>>>> >>         }
>>>> >>
>>>> >>         public final void run() {
>>>> >>             try {
>>>> >>                 checkBarrierStatus();
>>>> >>
>>>> >>                 int sum = v;
>>>> >>                 int x = 0;
>>>> >>                 int n = ITERS;
>>>> >>                 do {
>>>> >>                     try {
>>>> >>                         lock.lockInterruptibly();
>>>> >>                     }
>>>> >>                     catch (InterruptedException ie) {
>>>> >>                         break;
>>>> >>                     }
>>>> >>                     try {
>>>> >>                         v = x = LoopHelpers.compute1(v);
>>>> >>                     }
>>>> >>                     finally {
>>>> >>                         lock.unlock();
>>>> >>                     }
>>>> >>                     sum += LoopHelpers.compute2(x);
>>>> >>                 } while (n-- > 0);
>>>> >>
>>>> >>                 /*
>>>> >>                  * in the main thread, two threads are
>>>> un-interrupted,
>>>> >> others threads are interrupted.
>>>> >>                  * this line, however, can not guarantee that only
>>>> >> "un-interrupted" threads can go in,
>>>> >>                  * but also interrupted threads can go in,
>>>> >>                  * so, the "completed" will not always == 2, might
>>>> be > 2
>>>> >>                  */
>>>> >>                 if (n < 0) {
>>>> >>                     lock.lock();
>>>> >>                     try {
>>>> >>                         ++completed;
>>>> >>                     }
>>>> >>                     finally {
>>>> >>                         lock.unlock();
>>>> >>                     }
>>>> >>                 }
>>>> >>
>>>> >>                 result += sum;
>>>> >>                 barrier.await();
>>>> >>             }
>>>> >>             catch(BrokenBarrierException ex) {
>>>> >>                 //ex.printStackTrace();
>>>> >>             }
>>>> >>             catch(InterruptedException ex) {
>>>> >>                 //ex.printStackTrace();
>>>> >>             }
>>>> >>             catch (Exception ex) {
>>>> >>                 ex.printStackTrace();
>>>> >>                 return;
>>>> >>             }
>>>> >>         }
>>>> >>     }
>>>> >>
>>>> >> }
>>>> >>
>>>> >>
>>>> >> On Thu, Jan 5, 2017 at 12:20 PM, David Holmes <
>>>> david.holmes at oracle.com
>>>> >> <mailto:david.holmes at oracle.com>> wrote:
>>>> >>
>>>> >>     Hi chenzero,
>>>> >>
>>>> >>     Attachments get stripped from the mailing lists so you'll need to
>>>> >>     include your patch inline, or else get someone to host it for
>>>> you on
>>>> >>     cr.openjdk.java.net <http://cr.openjdk.java.net>
>>>> >>
>>>> >>     Thanks,
>>>> >>     David
>>>> >>     .....
>>>> >>
>>>> >>
>>>>
>>>
>>>
>>
>

From huaming.li at oracle.com  Fri Jan  6 09:59:45 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 6 Jan 2017 17:59:45 +0800
Subject: RFR of JDK-8172347: Refactoring
	src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to
	improve testability of rmiregistry
In-Reply-To: <5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
	<0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
	<5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
Message-ID: <6432c6de-af93-5224-f848-8e2e8f0f7c9f@oracle.com>


On 2017/1/6 6:15, Roger Riggs wrote:
> Hi Hamlin,
>
> There are too many issues being mixed together...
>
> Comments on B) RegistryImpl:
>
> Refactoring of RegistryImpl Main should be clean and clearly separated.
Hi Roger,

Thank you for reviewing.
Not sure if I understood you correctly, I created a new bug to track 
refactoring of RegistryImpl, I will send out separate reviews for 
AltSecurityManager in JDK-8172314, JDK-8030175. Please let me know if 
you did not mean it.

bug: https://bugs.openjdk.java.net/browse/JDK-8172347
webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.00/, fix all the 
below points.

Thank you
-Hamlin
>
> 365: static void RegistryImpl run():
>
> -  The signature of run should be run(int port) and documented as 
> needing to be run in its
>    own thread since it changes Thread context classloader and that it 
> sets a securityManager.
>    Leave it to main to parse and choose a port number.
>
> -  The comments should be functional as to the purpose of the code and 
> not referencing a particular bug.
>    (Regardless of prior example).
>
>  - The comment about getting the exact port is out of place because 
> the port number cannot be
>    retrieved from the returned RegistryImpl.  IF that's why this 
> refactoring is needed, then
>    perhaps there should be a getPort method that extracts it from the 
> created UnicastServerRef.
>
> 423: static void main(String[] args):
>
>  - Parsing of args should be left in main(); avoiding the question 
> about why NumberFormat is handled.
>
>  - Either main or run should set a security manager; but not both.
>
> Roger
>
>
>
>
> On 1/4/2017 10:21 PM, Hamlin Li wrote:
>> Hi Roger,
>>
>> Thank you for reviewing, please check comments inline.
>>
>>
>> On 2017/1/5 4:18, Roger Riggs wrote:
>>> Hi Hamlin,
>>>
>>> The original issue with timeout may be due to heavily loaded systems 
>>> and short timeouts.
>>> 15 sec is not enough on an overloaded system to wait for a process 
>>> to start and then die.
>>>
>>> There is no indication in this issue about port-in-use; that would 
>>> be a different issue.
>> Agree, I put 2 fixes in one patch together as there is no port in use 
>> issue reported, but by reviewing the code, potential port in use 
>> issue could happen some time in the future.
> Best to keep 1-1 to avoid complicating the discussion and increasing 
> code complexity.
>>>
>>>
>>> Common comments to both A and B.
>>>
>>> I'll need more time to look at B; it would be cleaner to use A if it 
>>> can address the issue.
>>> The alternative is to duplicate the code in run() in the TestLibrary 
>>> and not modify the RegistryImpl.
>> I prefer B, because
>>   1. Although A looks cleaner but B is simulating more like rmiregistry.
>>   2. There are some other issue for example JDK-7146543, JDK-8030950, 
>> JDK-8038772, fix based on version B works well, but fix based on 
>> version A fails.
>>   3. Impact of RegistryImpl modification is minimal. ( May we could 
>> make Registry run(String args[]) private and access it in test by 
>> reflection? )
>>   4. Although it's simple to duplicate the code in run() in the 
>> TestLibrary, but seems it's not a good design choice. (let's call it 
>> version C.)
>>   5. For JDK-8170728, the fix will need to modify 
>> sun.rmi.registry.RegistryImpl anyway.
>>
>>
>> Thank you for detailed review comments below.
>> As we have several options, I will wait for your further comments on 
>> choice of version A/B/C, then send out new webrev, hope I only need 
>> to send out one version :-).
>>
>> Thank you
>> -Hamlin
>>>
>>>
>>> JavaVM:
>>>  - Document the new methods.
>>>
>>> Line 232: Document the exception that may be thrown from exitValue.
>>>
>>>
>>> RMID:
>>> Line 204, 222: when adding new functions to the test library please 
>>> add documentation for the methods.
>>> There are now many variations of the methods that differ only by the 
>>> number arguments.
>>> It would be better if the name included some hint as to the 
>>> additional functionality.
>>>
>>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>>
>>> REGISTRY:
>>>   - Document the new methods.
>>>
>>>   - The name should be more indicative of its function and should 
>>> NOT be all caps;  RMID is an acronym where the caps make sense.
>>>
>>>   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating code 
>>> to wait for the subprocess.
>>>
>>>   - If the subprocesses are in an unknown state it would be useful 
>>> to print diagnostic info from the subprocess before terminating.
>>>     Line 106:
>>>
>>>  - Line 124:
>>>  - I think I would have promoted the shutdown method to JavaVM 
>>> instead of creating a new cleanup method
>>>    to keep the code simpler.
>>>
>>>    ** The cleanup method never calls super.cleanup() so the process 
>>> is never destroyed!.
>>>
>>> AltSecurityManager.java:
>>>
>>>  - Line 61: the empty constructor can be removed entirely.
>>>
>>>  - Line 80: change the message to say the exception did not occur.
>>>     As written it implies it may have occurred but was not caught.
>>>
>>>  - Line 86: typo "a unexpected" -> "an unexpected"
>>>
>>> - Line 90: remove the printStackTrace; it is not useful and is a red 
>>> flag in .jtr files
>>>
>>>  - Line 125: I don't see that cleanup is better than destroy; If 
>>> there are doubts about destroy
>>>    then destroy should be fixed not avoided.
>>>
>>> Roger
>>>
>>>
>>>
>>>
>>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>>> Would you please review the below patches?
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>>> webrev (version A): http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>>> webrev (version B): 
>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>>>
>>>>
>>>> There are 2 versions to be reviewed.
>>>>
>>>> In version A, just use RegistryRunner to replace rmiregistry.
>>>> In version B, refactor sun.rmi.registry.RegistryImpl to improve the 
>>>> testability of RMI code, and create/use RMIRegistryRunner to 
>>>> simulate rmiregistry.
>>>>
>>>> Thank you
>>>> -Hamlin
>>>
>>
>


From huaming.li at oracle.com  Fri Jan  6 10:54:11 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 6 Jan 2017 18:54:11 +0800
Subject: RFR of JDK-8172314:
	java/rmi/registry/altSecurityManager/AltSecurityManager.java fails with
	"port in use"
In-Reply-To: <827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
Message-ID: <73ae6663-8d57-6542-cddc-9c70327d8a64@oracle.com>

Hi Roger,

Thank you for reviewing, please check comments inline.

This is a bug separated from JDK-8030175

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

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


On 2017/1/5 4:18, Roger Riggs wrote:
> Hi Hamlin,
>
> The original issue with timeout may be due to heavily loaded systems 
> and short timeouts.
> 15 sec is not enough on an overloaded system to wait for a process to 
> start and then die.
>
> There is no indication in this issue about port-in-use; that would be 
> a different issue.
>
>
> Common comments to both A and B.
>
> I'll need more time to look at B; it would be cleaner to use A if it 
> can address the issue.
> The alternative is to duplicate the code in run() in the TestLibrary 
> and not modify the RegistryImpl.
>
>
> JavaVM:
>  - Document the new methods.
>
> Line 232: Document the exception that may be thrown from exitValue.
Fixed.
>
>
> RMID:
> Line 204, 222: when adding new functions to the test library please 
> add documentation for the methods.
> There are now many variations of the methods that differ only by the 
> number arguments.
> It would be better if the name included some hint as to the additional 
> functionality.
>
> typo:  "additionalOptions" -> "add*i*tionalOptions"
Fixed.
>
> REGISTRY:
>   - Document the new methods.
>
>   - The name should be more indicative of its function and should NOT 
> be all caps;  RMID is an acronym where the caps make sense.
above fixed.
>
>   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating code 
> to wait for the subprocess.
Not quite get your point.
>
>   - If the subprocesses are in an unknown state it would be useful to 
> print diagnostic info from the subprocess before terminating.
>     Line 106:
Not quite get your point. if subprocess vm (either RegistryRunner or 
RMIRegistryRunner) exit before get the port number from its output, that 
means vm exit exceptionally ( for example rmiregistry in 
AltSecurityManager.java is to exit before port number is output ). if 
there are any output generated by vm (rmiregistry), it should have 
already been caught and printed by JavaVM.
>
>  - Line 124:
>  - I think I would have promoted the shutdown method to JavaVM instead 
> of creating a new cleanup method
>    to keep the code simpler.
>
>    ** The cleanup method never calls super.cleanup() so the process is 
> never destroyed!.
RMID.java already has both cleanup and destroy, RMID.cleanup is already 
used by lots of tests, it means destroy + clean up log files, so I add 
cleanup in JavaVM, cleanup can be used for both RMID and RegistryVM as a 
JavaVM instance. To avoid misunderstanding, I added some comments for 
cleanup in JavaVM.java. and removed RegistryVM.shutdown, which is 
useless and misleading.
> AltSecurityManager.java:
>
>  - Line 61: the empty constructor can be removed entirely.
>
>  - Line 80: change the message to say the exception did not occur.
>     As written it implies it may have occurred but was not caught.
>
>  - Line 86: typo "a unexpected" -> "an unexpected"
>
> - Line 90: remove the printStackTrace; it is not useful and is a red 
> flag in .jtr files
above fixed.
>
>  - Line 125: I don't see that cleanup is better than destroy; If there 
> are doubts about destroy
>    then destroy should be fixed not avoided.
Same reason as above for your comment in REGISTRY(now RegistryVM).

Thank you
-Hamlin
>
> Roger
>
>
>
>
> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>> Would you please review the below patches?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>> webrev (version A): http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>> webrev (version B): 
>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>
>>
>> There are 2 versions to be reviewed.
>>
>> In version A, just use RegistryRunner to replace rmiregistry.
>> In version B, refactor sun.rmi.registry.RegistryImpl to improve the 
>> testability of RMI code, and create/use RMIRegistryRunner to simulate 
>> rmiregistry.
>>
>> Thank you
>> -Hamlin
>


From paul.sandoz at oracle.com  Fri Jan  6 19:26:47 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 6 Jan 2017 11:26:47 -0800
Subject: RFR 8075884,
	new tests to check runtime usage with Multi-Release jars
In-Reply-To: <b797746d-ba2e-f156-220c-b09b1b911c3a@oracle.com>
References: <b797746d-ba2e-f156-220c-b09b1b911c3a@oracle.com>
Message-ID: <757BE8AF-9D33-4AFA-8433-CBF085521BF7@oracle.com>

Hi Felix,

Generally looks good.

RuntimeTest
?

  78     @BeforeTest
  79     protected void setUpTest() throws Throwable {

Can you use @BeforeClass? since i believe the jar files only need to be created once for all tests.

(And i presume it just overwrites any existing files that were previously generated.)


 172         if (mainVersionActual != mainVersionExpected) {
 173             throw new AssertionError(
 174                     "Test failed: Expected Main class version: "
 175                             + mainVersionExpected + " Actual version: "
 176                             + mainVersionActual);
 177         }

You can use Assert.equals.


 191     @Test(dataProvider = "jarFiles")
 192     void testJjs(String jar, int mainVer, int helperVer, int resVer)
 193             throws Throwable {

What is the rational for testing with jjs? i.e. what does it test beyond the other tests?

Paul.


> On 5 Jan 2017, at 22:20, Felix Yang <felix.yang at oracle.com> wrote:
> 
> Hi there,
> 
>    please review the following new tests to check runtime usage with Multi-Release jars.
> 
> Bug:
> 
>    https://bugs.openjdk.java.net/browse/JDK-8075884
> 
> Webrev:
> 
>    http://cr.openjdk.java.net/~xiaofeya/8075884/webrev.00/
> 
> Thanks,
> 
> Felix
> 


From Roger.Riggs at Oracle.com  Fri Jan  6 20:56:05 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 6 Jan 2017 15:56:05 -0500
Subject: RFR of JDK-8172347: Refactoring
	src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to
	improve testability of rmiregistry
In-Reply-To: <6432c6de-af93-5224-f848-8e2e8f0f7c9f@oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
	<0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
	<5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
	<6432c6de-af93-5224-f848-8e2e8f0f7c9f@oracle.com>
Message-ID: <888af0b3-24ee-826a-7449-f3eece8ab9f8@Oracle.com>

Hi Hamlin,

Yes, that looks better.

On the comments, use the normal javadoc comment conventions for any 
public API.
@param @return, @throw, etc.

I think comments should be direct about what the function does. It does 
not need
to explain why so much.  Or if so, later and in a separate paragraph;  
when reading
the most important information should be first.

Thanks, Roger


On 1/6/2017 4:59 AM, Hamlin Li wrote:
>
> On 2017/1/6 6:15, Roger Riggs wrote:
>> Hi Hamlin,
>>
>> There are too many issues being mixed together...
>>
>> Comments on B) RegistryImpl:
>>
>> Refactoring of RegistryImpl Main should be clean and clearly separated.
> Hi Roger,
>
> Thank you for reviewing.
> Not sure if I understood you correctly, I created a new bug to track 
> refactoring of RegistryImpl, I will send out separate reviews for 
> AltSecurityManager in JDK-8172314, JDK-8030175. Please let me know if 
> you did not mean it.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8172347
> webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.00/, fix all 
> the below points.
>
> Thank you
> -Hamlin
>>
>> 365: static void RegistryImpl run():
>>
>> -  The signature of run should be run(int port) and documented as 
>> needing to be run in its
>>    own thread since it changes Thread context classloader and that it 
>> sets a securityManager.
>>    Leave it to main to parse and choose a port number.
>>
>> -  The comments should be functional as to the purpose of the code 
>> and not referencing a particular bug.
>>    (Regardless of prior example).
>>
>>  - The comment about getting the exact port is out of place because 
>> the port number cannot be
>>    retrieved from the returned RegistryImpl.  IF that's why this 
>> refactoring is needed, then
>>    perhaps there should be a getPort method that extracts it from the 
>> created UnicastServerRef.
>>
>> 423: static void main(String[] args):
>>
>>  - Parsing of args should be left in main(); avoiding the question 
>> about why NumberFormat is handled.
>>
>>  - Either main or run should set a security manager; but not both.
>>
>> Roger
>>
>>
>>
>>
>> On 1/4/2017 10:21 PM, Hamlin Li wrote:
>>> Hi Roger,
>>>
>>> Thank you for reviewing, please check comments inline.
>>>
>>>
>>> On 2017/1/5 4:18, Roger Riggs wrote:
>>>> Hi Hamlin,
>>>>
>>>> The original issue with timeout may be due to heavily loaded 
>>>> systems and short timeouts.
>>>> 15 sec is not enough on an overloaded system to wait for a process 
>>>> to start and then die.
>>>>
>>>> There is no indication in this issue about port-in-use; that would 
>>>> be a different issue.
>>> Agree, I put 2 fixes in one patch together as there is no port in 
>>> use issue reported, but by reviewing the code, potential port in use 
>>> issue could happen some time in the future.
>> Best to keep 1-1 to avoid complicating the discussion and increasing 
>> code complexity.
>>>>
>>>>
>>>> Common comments to both A and B.
>>>>
>>>> I'll need more time to look at B; it would be cleaner to use A if 
>>>> it can address the issue.
>>>> The alternative is to duplicate the code in run() in the 
>>>> TestLibrary and not modify the RegistryImpl.
>>> I prefer B, because
>>>   1. Although A looks cleaner but B is simulating more like 
>>> rmiregistry.
>>>   2. There are some other issue for example JDK-7146543, 
>>> JDK-8030950, JDK-8038772, fix based on version B works well, but fix 
>>> based on version A fails.
>>>   3. Impact of RegistryImpl modification is minimal. ( May we could 
>>> make Registry run(String args[]) private and access it in test by 
>>> reflection? )
>>>   4. Although it's simple to duplicate the code in run() in the 
>>> TestLibrary, but seems it's not a good design choice. (let's call it 
>>> version C.)
>>>   5. For JDK-8170728, the fix will need to modify 
>>> sun.rmi.registry.RegistryImpl anyway.
>>>
>>>
>>> Thank you for detailed review comments below.
>>> As we have several options, I will wait for your further comments on 
>>> choice of version A/B/C, then send out new webrev, hope I only need 
>>> to send out one version :-).
>>>
>>> Thank you
>>> -Hamlin
>>>>
>>>>
>>>> JavaVM:
>>>>  - Document the new methods.
>>>>
>>>> Line 232: Document the exception that may be thrown from exitValue.
>>>>
>>>>
>>>> RMID:
>>>> Line 204, 222: when adding new functions to the test library please 
>>>> add documentation for the methods.
>>>> There are now many variations of the methods that differ only by 
>>>> the number arguments.
>>>> It would be better if the name included some hint as to the 
>>>> additional functionality.
>>>>
>>>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>>>
>>>> REGISTRY:
>>>>   - Document the new methods.
>>>>
>>>>   - The name should be more indicative of its function and should 
>>>> NOT be all caps;  RMID is an acronym where the caps make sense.
>>>>
>>>>   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating 
>>>> code to wait for the subprocess.
>>>>
>>>>   - If the subprocesses are in an unknown state it would be useful 
>>>> to print diagnostic info from the subprocess before terminating.
>>>>     Line 106:
>>>>
>>>>  - Line 124:
>>>>  - I think I would have promoted the shutdown method to JavaVM 
>>>> instead of creating a new cleanup method
>>>>    to keep the code simpler.
>>>>
>>>>    ** The cleanup method never calls super.cleanup() so the process 
>>>> is never destroyed!.
>>>>
>>>> AltSecurityManager.java:
>>>>
>>>>  - Line 61: the empty constructor can be removed entirely.
>>>>
>>>>  - Line 80: change the message to say the exception did not occur.
>>>>     As written it implies it may have occurred but was not caught.
>>>>
>>>>  - Line 86: typo "a unexpected" -> "an unexpected"
>>>>
>>>> - Line 90: remove the printStackTrace; it is not useful and is a 
>>>> red flag in .jtr files
>>>>
>>>>  - Line 125: I don't see that cleanup is better than destroy; If 
>>>> there are doubts about destroy
>>>>    then destroy should be fixed not avoided.
>>>>
>>>> Roger
>>>>
>>>>
>>>>
>>>>
>>>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>>>> Would you please review the below patches?
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>>>> webrev (version A): 
>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>>>> webrev (version B): 
>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>>>>
>>>>>
>>>>> There are 2 versions to be reviewed.
>>>>>
>>>>> In version A, just use RegistryRunner to replace rmiregistry.
>>>>> In version B, refactor sun.rmi.registry.RegistryImpl to improve 
>>>>> the testability of RMI code, and create/use RMIRegistryRunner to 
>>>>> simulate rmiregistry.
>>>>>
>>>>> Thank you
>>>>> -Hamlin
>>>>
>>>
>>
>


From Roger.Riggs at Oracle.com  Fri Jan  6 21:15:16 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 6 Jan 2017 16:15:16 -0500
Subject: RFR of JDK-8030175:
	java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due
	to timeout
In-Reply-To: <644724ce-9020-0f3f-49cd-a0112c1f729e@oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
	<0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
	<5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
	<644724ce-9020-0f3f-49cd-a0112c1f729e@oracle.com>
Message-ID: <cd0e863c-fb22-7b84-8993-c9d4f06336b9@Oracle.com>

Hi Hamlin,

Since it is intermittent, are there any diagnostics that can be added to 
the test in case it fails again.
if not, ok as is.

Thanks, Roger


On 1/5/2017 8:55 PM, Hamlin Li wrote:
>
>
> On 2017/1/6 6:15, Roger Riggs wrote:
>>
>>
>> On 1/4/2017 10:21 PM, Hamlin Li wrote:
>>> Hi Roger,
>>>
>>> Thank you for reviewing, please check comments inline.
>>>
>>>
>>> On 2017/1/5 4:18, Roger Riggs wrote:
>>>> Hi Hamlin,
>>>>
>>>> The original issue with timeout may be due to heavily loaded 
>>>> systems and short timeouts.
>>>> 15 sec is not enough on an overloaded system to wait for a process 
>>>> to start and then die.
>>>>
>>>> There is no indication in this issue about port-in-use; that would 
>>>> be a different issue.
>>> Agree, I put 2 fixes in one patch together as there is no port in 
>>> use issue reported, but by reviewing the code, potential port in use 
>>> issue could happen some time in the future.
>> Best to keep 1-1 to avoid complicating the discussion and increasing 
>> code complexity.
> Hi Roger,
>
> Got it, the new webrev for timeout issue is at: 
> http://cr.openjdk.java.net/~mli/8030175/webrev.01/
>
> I just created another bug 
> https://bugs.openjdk.java.net/browse/JDK-8172314 to track the "port in 
> use" bug, will send out separate webrev in another thread later.
>
> Thank you
> -Hamlin
>>>>
>>>>
>>>> Common comments to both A and B.
>>>>
>>>> I'll need more time to look at B; it would be cleaner to use A if 
>>>> it can address the issue.
>>>> The alternative is to duplicate the code in run() in the 
>>>> TestLibrary and not modify the RegistryImpl.
>>> I prefer B, because
>>>   1. Although A looks cleaner but B is simulating more like 
>>> rmiregistry.
>>>   2. There are some other issue for example JDK-7146543, 
>>> JDK-8030950, JDK-8038772, fix based on version B works well, but fix 
>>> based on version A fails.
>>>   3. Impact of RegistryImpl modification is minimal. ( May we could 
>>> make Registry run(String args[]) private and access it in test by 
>>> reflection? )
>>>   4. Although it's simple to duplicate the code in run() in the 
>>> TestLibrary, but seems it's not a good design choice. (let's call it 
>>> version C.)
>>>   5. For JDK-8170728, the fix will need to modify 
>>> sun.rmi.registry.RegistryImpl anyway.
>>>
>>>
>>> Thank you for detailed review comments below.
>>> As we have several options, I will wait for your further comments on 
>>> choice of version A/B/C, then send out new webrev, hope I only need 
>>> to send out one version :-).
>>>
>>> Thank you
>>> -Hamlin
>>>>
>>>>
>>>> JavaVM:
>>>>  - Document the new methods.
>>>>
>>>> Line 232: Document the exception that may be thrown from exitValue.
>>>>
>>>>
>>>> RMID:
>>>> Line 204, 222: when adding new functions to the test library please 
>>>> add documentation for the methods.
>>>> There are now many variations of the methods that differ only by 
>>>> the number arguments.
>>>> It would be better if the name included some hint as to the 
>>>> additional functionality.
>>>>
>>>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>>>
>>>> REGISTRY:
>>>>   - Document the new methods.
>>>>
>>>>   - The name should be more indicative of its function and should 
>>>> NOT be all caps;  RMID is an acronym where the caps make sense.
>>>>
>>>>   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating 
>>>> code to wait for the subprocess.
>>>>
>>>>   - If the subprocesses are in an unknown state it would be useful 
>>>> to print diagnostic info from the subprocess before terminating.
>>>>     Line 106:
>>>>
>>>>  - Line 124:
>>>>  - I think I would have promoted the shutdown method to JavaVM 
>>>> instead of creating a new cleanup method
>>>>    to keep the code simpler.
>>>>
>>>>    ** The cleanup method never calls super.cleanup() so the process 
>>>> is never destroyed!.
>>>>
>>>> AltSecurityManager.java:
>>>>
>>>>  - Line 61: the empty constructor can be removed entirely.
>>>>
>>>>  - Line 80: change the message to say the exception did not occur.
>>>>     As written it implies it may have occurred but was not caught.
>>>>
>>>>  - Line 86: typo "a unexpected" -> "an unexpected"
>>>>
>>>> - Line 90: remove the printStackTrace; it is not useful and is a 
>>>> red flag in .jtr files
>>>>
>>>>  - Line 125: I don't see that cleanup is better than destroy; If 
>>>> there are doubts about destroy
>>>>    then destroy should be fixed not avoided.
>>>>
>>>> Roger
>>>>
>>>>
>>>>
>>>>
>>>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>>>> Would you please review the below patches?
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>>>> webrev (version A): 
>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>>>> webrev (version B): 
>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>>>>
>>>>>
>>>>> There are 2 versions to be reviewed.
>>>>>
>>>>> In version A, just use RegistryRunner to replace rmiregistry.
>>>>> In version B, refactor sun.rmi.registry.RegistryImpl to improve 
>>>>> the testability of RMI code, and create/use RMIRegistryRunner to 
>>>>> simulate rmiregistry.
>>>>>
>>>>> Thank you
>>>>> -Hamlin
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Fri Jan  6 23:46:07 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 6 Jan 2017 15:46:07 -0800
Subject: Review Request JDK-8170772: ResourceBundle improper caching
	causes tools/javadoc tests intermittently
In-Reply-To: <0f17689a-84a6-7508-6802-6f440de93161@oracle.com>
References: <E9A3FE4E-D5CD-41ED-BA14-7311C99180D8@oracle.com>
	<887b1af3-decf-5a9e-6577-4b2781e8183c@gmail.com>
	<0f17689a-84a6-7508-6802-6f440de93161@oracle.com>
Message-ID: <0759b853-d076-f7ab-28bc-4623615f71c1@oracle.com>

Hi Peter, Daniel, Mandy,

Sorry for the late reply, and thanks for the patch. I went through the 
patch and I did not find any problem with it. Would you want to proceed 
with this?

Naoto

On 12/13/16 2:14 AM, Daniel Fuchs wrote:
> Hi Peter,
>
> This is a bold proposal, I would be frightened to touch at
> this code :-)
>
> Good observations about the simplifications induced by taking
> the caller's module as part of the cache key (in particular
> getting rid of RBClassLoader.INSTANCE).
>
> I have imported your patch (had to fight a bit because it
> includes changes that had already been pushed) and sent it
> through our internal testing system - and haven't seen any
> new failures that seemed linked to resource bundles.
>
> A few observations concerning CacheKey - if I'm not mistaken
> most of the key variables could be made final (in particular
> callerRef and moduleRef) - and since they are required to be
> non null - then getModule() and getCallerModule() could be
> simplified. Not sure whether  making those final might require
> to add a copy constructor to support clone() though?
> It seems CacheKey::setName is never called - but it's probably
> safer to keep it (maybe it's called by tests).
>
> I am not an expert of ResourceBundle - though I had to dive
> into it a few times due it's use in logging. Hopefully others
> will jump on this.
>
> best regards,
>
> -- daniel
>
> On 12/12/16 15:10, Peter Levart wrote:
>> Hi Mandy (once again for the list),
>>
>> On 12/09/2016 05:49 PM, Mandy Chung wrote:
>>> Naoto,  > > Can you review this ResourceBundle caching fix?  The
>>> caller module
>>> may be different than the specified module to >
>> ResourceBundle.getBundle(String, Module) method and it should also >
>> part of the cache key. > >
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170772/webrev.00/ > >
>> The new test shows the issue there and the first loading of the >
>> resource bundle of a specific module (success or fail) will be put in >
>> the cache and used by subsequent calls. > > Thanks Mandy
>>
>>
>> I think that now callerModule is part of CacheKey, caching logic could
>> be simplified. 1st the getBundleImpl method in line 1629:
>>
>>     private static ResourceBundle getBundleImpl(String baseName,
>>                                                 Locale locale,
>>                                                 Class<?> caller,
>>                                                 ClassLoader loader,
>>                                                 Control control) {
>>         if (caller != null && caller.getModule().isNamed()) {
>>             Module module = caller.getModule();
>>             ClassLoader ml = getLoader(module);
>>             // get resource bundles for a named module only
>>             // if loader is the module's class loader
>>             if (loader == ml || (ml == null && loader ==
>> RBClassLoader.INSTANCE)) {
>>                 return getBundleImpl(module, module, loader, baseName,
>> locale, control);
>>             }
>>         }
>>         // find resource bundles from unnamed module
>>         Module unnamedModule = loader != null
>>             ? loader.getUnnamedModule()
>>             : ClassLoader.getSystemClassLoader().getUnnamedModule();
>>
>>         if (caller == null) {
>>             throw new InternalError("null caller");
>>         }
>>
>>         Module callerModule = caller.getModule();
>>         return getBundleImpl(callerModule, unnamedModule, loader,
>> baseName, locale, control);
>>     }
>>
>>
>> ... could be cleaned up a bit without changing its semantics:
>>
>>     private static ResourceBundle getBundleImpl(String baseName,
>>                                                 Locale locale,
>>                                                 Class<?> caller,
>>                                                 ClassLoader loader,
>>                                                 Control control) {
>>         if (caller == null) {
>>             throw new InternalError("null caller");
>>         }
>>         Module callerModule = caller.getModule();
>>
>>         if (callerModule.isNamed()) {
>>             ClassLoader ml = getLoader(callerModule);
>>             // get resource bundles for a named module only
>>             // if loader is the module's class loader
>>             if (loader == ml || (ml == null && loader ==
>> RBClassLoader.INSTANCE)) {
>>                 return getBundleImpl(callerModule, callerModule, loader,
>> baseName, locale, control);
>>             }
>>         }
>>
>>         // find resource bundles from unnamed module
>>         Module unnamedModule = loader != null
>>             ? loader.getUnnamedModule()
>>             : ClassLoader.getSystemClassLoader().getUnnamedModule();
>>
>>         return getBundleImpl(callerModule, unnamedModule, loader,
>> baseName, locale, control);
>>     }
>>
>>
>> Next, I checked all callers of this method (there are 3 of them in
>> lines: 1367, 1589, 1615) and all of them guard against passing a null
>> 'loader' to this method:
>>
>>     @CallerSensitive
>>     public static ResourceBundle getBundle(String baseName, Locale
>> locale,
>>                                            ClassLoader loader)
>>     {
>>         if (loader == null) {
>>             throw new NullPointerException();
>>         }
>>         Class<?> caller = Reflection.getCallerClass();
>>         return getBundleImpl(baseName, locale, caller, loader,
>> getDefaultControl(caller, baseName));
>>     }
>>
>> ...
>>
>>     @CallerSensitive
>>     public static ResourceBundle getBundle(String baseName, Locale
>> targetLocale,
>>                                            ClassLoader loader, Control
>> control) {
>>         if (loader == null || control == null) {
>>             throw new NullPointerException();
>>         }
>>         Class<?> caller = Reflection.getCallerClass();
>>         checkNamedModule(caller);
>>         return getBundleImpl(baseName, targetLocale, caller, loader,
>> control);
>>     }
>>
>> ...
>>
>>     private static ResourceBundle getBundleImpl(String baseName,
>>                                                 Locale locale,
>>                                                 Class<?> caller,
>>                                                 Control control) {
>>         return getBundleImpl(baseName, locale, caller,
>> getLoader(caller), control);
>>     }
>>
>>     private static ClassLoader getLoader(Class<?> caller) {
>>         ClassLoader cl = caller == null ? null : caller.getClassLoader();
>>         if (cl == null) {
>>             // When the caller's loader is the boot class loader, cl is
>> null
>>             // here. In that case, ClassLoader.getSystemClassLoader() may
>>             // return the same class loader that the application is
>>             // using. We therefore use a wrapper ClassLoader to create a
>>             // separate scope for bundles loaded on behalf of the Java
>>             // runtime so that these bundles cannot be returned from the
>>             // cache to the application (5048280).
>>             cl = RBClassLoader.INSTANCE;
>>         }
>>         return cl;
>>     }
>>
>>
>> Therefore the above method can be simplified further:
>>
>>     private static ResourceBundle getBundleImpl(String baseName,
>>                                                 Locale locale,
>>                                                 Class<?> caller,
>>                                                 ClassLoader loader,
>>                                                 Control control) {
>>         if (caller == null) {
>>             throw new InternalError("null caller");
>>         }
>>         if (loader == null) {
>>             throw new InternalError("null loader");
>>         }
>>         Module callerModule = caller.getModule();
>>
>>         if (callerModule.isNamed()) {
>>             ClassLoader ml = getLoader(callerModule);
>>             // get resource bundles for a named module only
>>             // if loader is the module's class loader
>>             if (loader == ml || (ml == null && loader ==
>> RBClassLoader.INSTANCE)) {
>>                 return getBundleImpl(callerModule, callerModule, loader,
>> baseName, locale, control);
>>             }
>>         }
>>
>>         // find resource bundles from unnamed module
>>         Module unnamedModule = loader.getUnnamedModule();
>>         return getBundleImpl(callerModule, unnamedModule, loader,
>> baseName, locale, control);
>>     }
>>
>>
>>
>> ...here we can see that (callerModule, module, loader) triple passed to
>> downstream getBundleImpl is either (callerModule, callerModule,
>> callerModule's class loader) - with a RBClassLoader.INSTANCE substitute
>> for bootstrap class loader, when the callerModule is a named module and
>> requested loader is the callerModule's loader, or (callerModule,
>> loader's unnamed module, loader) when loader is not callerModule's
>> loader or callerModule is unnamed.
>>
>> other two callers of the downstream getBundleImpl are the
>> JavaUtilResourceBundleAccess method:
>>
>>                 public ResourceBundle getBundle(String baseName, Locale
>> locale, Module module) {
>>                     // use the given module as the caller to bypass the
>> access check
>>                     return getBundleImpl(module, module,
>> getLoader(module),
>>                                          baseName, locale,
>> Control.INSTANCE);
>>                 }
>>
>> ...which is used in logging - the module passed here can be either named
>> or unnamed;
>>
>> ... and a method invoked from new JDK 9 public getBundle() methods
>> taking explicit Module argument:
>>
>>     private static ResourceBundle getBundleFromModule(Class<?> caller,
>>                                                       Module module,
>>                                                       String baseName,
>>                                                       Locale locale,
>>                                                       Control control) {
>>         Objects.requireNonNull(module);
>>         Module callerModule = caller.getModule();
>>         if (callerModule != module) {
>>             SecurityManager sm = System.getSecurityManager();
>>             if (sm != null) {
>>                 sm.checkPermission(GET_CLASSLOADER_PERMISSION);
>>             }
>>         }
>>         return getBundleImpl(callerModule, module, getLoader(module),
>> baseName, locale, control);
>>     }
>>
>> In all of these cases, the loader passed to downstream getBundleImpl is
>> the module's (2nd argument 'module') class loader (or a special
>> substitute for bootstrap loader).
>>
>> Considering all this, I think class loader is not needed any more as the
>> CacheKey component. The distinction between scopes of system class
>> loader (when the caller is not a bootstrap class) and the
>> RBClassLoader.INSTANCE (when the caller is the bootstrap class) is also
>> not needed any more since the callerModule is now part of CacheKey.
>>
>> I modified your patch (just ResourceBundle.java) to include all these
>> simplifications and some cleanup:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.01/
>>
>>
>>
>>
>> This modification also contains a re-interpretation of clearCache()
>> methods. Both existing clearCahe() methods together with the additional
>> @since 9 method contain the following wording:
>>
>> "Removes all resource bundles from the cache that have been loaded by
>> the caller's / given module..."
>>
>> What does it meant for a bundle to be loaded *by* some module? I think
>> the right interpretation is that this is the caller module (the one that
>> invokes ResourceBundle.getBundle() method). The module that calls
>> ResourceBundle.getBundle() is usually also the module that is
>> responsible for clearing the cache of entries that were cached by its
>> loading requests, isn't it?
>>
>> So, what do you think?
>>
>> Regards, Peter
>>
>

From mandy.chung at oracle.com  Sat Jan  7 04:41:18 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 6 Jan 2017 20:41:18 -0800
Subject: Review Request JDK-8170772: ResourceBundle improper caching
	causes tools/javadoc tests intermittently
In-Reply-To: <0759b853-d076-f7ab-28bc-4623615f71c1@oracle.com>
References: <E9A3FE4E-D5CD-41ED-BA14-7311C99180D8@oracle.com>
	<887b1af3-decf-5a9e-6577-4b2781e8183c@gmail.com>
	<0f17689a-84a6-7508-6802-6f440de93161@oracle.com>
	<0759b853-d076-f7ab-28bc-4623615f71c1@oracle.com>
Message-ID: <8295D13D-74F9-4119-98FB-D43BD1C6012B@oracle.com>

Thanks for looking through this, Naoto.

This has been pushed and resolved in jdk-9+149.

Mandy

> On Jan 6, 2017, at 3:46 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Hi Peter, Daniel, Mandy,
> 
> Sorry for the late reply, and thanks for the patch. I went through the patch and I did not find any problem with it. Would you want to proceed with this?
> 
> Naoto
> 
> On 12/13/16 2:14 AM, Daniel Fuchs wrote:
>> Hi Peter,
>> 
>> This is a bold proposal, I would be frightened to touch at
>> this code :-)
>> 
>> Good observations about the simplifications induced by taking
>> the caller's module as part of the cache key (in particular
>> getting rid of RBClassLoader.INSTANCE).
>> 
>> I have imported your patch (had to fight a bit because it
>> includes changes that had already been pushed) and sent it
>> through our internal testing system - and haven't seen any
>> new failures that seemed linked to resource bundles.
>> 
>> A few observations concerning CacheKey - if I'm not mistaken
>> most of the key variables could be made final (in particular
>> callerRef and moduleRef) - and since they are required to be
>> non null - then getModule() and getCallerModule() could be
>> simplified. Not sure whether  making those final might require
>> to add a copy constructor to support clone() though?
>> It seems CacheKey::setName is never called - but it's probably
>> safer to keep it (maybe it's called by tests).
>> 
>> I am not an expert of ResourceBundle - though I had to dive
>> into it a few times due it's use in logging. Hopefully others
>> will jump on this.
>> 
>> best regards,
>> 
>> -- daniel
>> 
>> On 12/12/16 15:10, Peter Levart wrote:
>>> Hi Mandy (once again for the list),
>>> 
>>> On 12/09/2016 05:49 PM, Mandy Chung wrote:
>>>> Naoto,  > > Can you review this ResourceBundle caching fix?  The
>>>> caller module
>>>> may be different than the specified module to >
>>> ResourceBundle.getBundle(String, Module) method and it should also >
>>> part of the cache key. > >
>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170772/webrev.00/ > >
>>> The new test shows the issue there and the first loading of the >
>>> resource bundle of a specific module (success or fail) will be put in >
>>> the cache and used by subsequent calls. > > Thanks Mandy
>>> 
>>> 
>>> I think that now callerModule is part of CacheKey, caching logic could
>>> be simplified. 1st the getBundleImpl method in line 1629:
>>> 
>>>    private static ResourceBundle getBundleImpl(String baseName,
>>>                                                Locale locale,
>>>                                                Class<?> caller,
>>>                                                ClassLoader loader,
>>>                                                Control control) {
>>>        if (caller != null && caller.getModule().isNamed()) {
>>>            Module module = caller.getModule();
>>>            ClassLoader ml = getLoader(module);
>>>            // get resource bundles for a named module only
>>>            // if loader is the module's class loader
>>>            if (loader == ml || (ml == null && loader ==
>>> RBClassLoader.INSTANCE)) {
>>>                return getBundleImpl(module, module, loader, baseName,
>>> locale, control);
>>>            }
>>>        }
>>>        // find resource bundles from unnamed module
>>>        Module unnamedModule = loader != null
>>>            ? loader.getUnnamedModule()
>>>            : ClassLoader.getSystemClassLoader().getUnnamedModule();
>>> 
>>>        if (caller == null) {
>>>            throw new InternalError("null caller");
>>>        }
>>> 
>>>        Module callerModule = caller.getModule();
>>>        return getBundleImpl(callerModule, unnamedModule, loader,
>>> baseName, locale, control);
>>>    }
>>> 
>>> 
>>> ... could be cleaned up a bit without changing its semantics:
>>> 
>>>    private static ResourceBundle getBundleImpl(String baseName,
>>>                                                Locale locale,
>>>                                                Class<?> caller,
>>>                                                ClassLoader loader,
>>>                                                Control control) {
>>>        if (caller == null) {
>>>            throw new InternalError("null caller");
>>>        }
>>>        Module callerModule = caller.getModule();
>>> 
>>>        if (callerModule.isNamed()) {
>>>            ClassLoader ml = getLoader(callerModule);
>>>            // get resource bundles for a named module only
>>>            // if loader is the module's class loader
>>>            if (loader == ml || (ml == null && loader ==
>>> RBClassLoader.INSTANCE)) {
>>>                return getBundleImpl(callerModule, callerModule, loader,
>>> baseName, locale, control);
>>>            }
>>>        }
>>> 
>>>        // find resource bundles from unnamed module
>>>        Module unnamedModule = loader != null
>>>            ? loader.getUnnamedModule()
>>>            : ClassLoader.getSystemClassLoader().getUnnamedModule();
>>> 
>>>        return getBundleImpl(callerModule, unnamedModule, loader,
>>> baseName, locale, control);
>>>    }
>>> 
>>> 
>>> Next, I checked all callers of this method (there are 3 of them in
>>> lines: 1367, 1589, 1615) and all of them guard against passing a null
>>> 'loader' to this method:
>>> 
>>>    @CallerSensitive
>>>    public static ResourceBundle getBundle(String baseName, Locale
>>> locale,
>>>                                           ClassLoader loader)
>>>    {
>>>        if (loader == null) {
>>>            throw new NullPointerException();
>>>        }
>>>        Class<?> caller = Reflection.getCallerClass();
>>>        return getBundleImpl(baseName, locale, caller, loader,
>>> getDefaultControl(caller, baseName));
>>>    }
>>> 
>>> ...
>>> 
>>>    @CallerSensitive
>>>    public static ResourceBundle getBundle(String baseName, Locale
>>> targetLocale,
>>>                                           ClassLoader loader, Control
>>> control) {
>>>        if (loader == null || control == null) {
>>>            throw new NullPointerException();
>>>        }
>>>        Class<?> caller = Reflection.getCallerClass();
>>>        checkNamedModule(caller);
>>>        return getBundleImpl(baseName, targetLocale, caller, loader,
>>> control);
>>>    }
>>> 
>>> ...
>>> 
>>>    private static ResourceBundle getBundleImpl(String baseName,
>>>                                                Locale locale,
>>>                                                Class<?> caller,
>>>                                                Control control) {
>>>        return getBundleImpl(baseName, locale, caller,
>>> getLoader(caller), control);
>>>    }
>>> 
>>>    private static ClassLoader getLoader(Class<?> caller) {
>>>        ClassLoader cl = caller == null ? null : caller.getClassLoader();
>>>        if (cl == null) {
>>>            // When the caller's loader is the boot class loader, cl is
>>> null
>>>            // here. In that case, ClassLoader.getSystemClassLoader() may
>>>            // return the same class loader that the application is
>>>            // using. We therefore use a wrapper ClassLoader to create a
>>>            // separate scope for bundles loaded on behalf of the Java
>>>            // runtime so that these bundles cannot be returned from the
>>>            // cache to the application (5048280).
>>>            cl = RBClassLoader.INSTANCE;
>>>        }
>>>        return cl;
>>>    }
>>> 
>>> 
>>> Therefore the above method can be simplified further:
>>> 
>>>    private static ResourceBundle getBundleImpl(String baseName,
>>>                                                Locale locale,
>>>                                                Class<?> caller,
>>>                                                ClassLoader loader,
>>>                                                Control control) {
>>>        if (caller == null) {
>>>            throw new InternalError("null caller");
>>>        }
>>>        if (loader == null) {
>>>            throw new InternalError("null loader");
>>>        }
>>>        Module callerModule = caller.getModule();
>>> 
>>>        if (callerModule.isNamed()) {
>>>            ClassLoader ml = getLoader(callerModule);
>>>            // get resource bundles for a named module only
>>>            // if loader is the module's class loader
>>>            if (loader == ml || (ml == null && loader ==
>>> RBClassLoader.INSTANCE)) {
>>>                return getBundleImpl(callerModule, callerModule, loader,
>>> baseName, locale, control);
>>>            }
>>>        }
>>> 
>>>        // find resource bundles from unnamed module
>>>        Module unnamedModule = loader.getUnnamedModule();
>>>        return getBundleImpl(callerModule, unnamedModule, loader,
>>> baseName, locale, control);
>>>    }
>>> 
>>> 
>>> 
>>> ...here we can see that (callerModule, module, loader) triple passed to
>>> downstream getBundleImpl is either (callerModule, callerModule,
>>> callerModule's class loader) - with a RBClassLoader.INSTANCE substitute
>>> for bootstrap class loader, when the callerModule is a named module and
>>> requested loader is the callerModule's loader, or (callerModule,
>>> loader's unnamed module, loader) when loader is not callerModule's
>>> loader or callerModule is unnamed.
>>> 
>>> other two callers of the downstream getBundleImpl are the
>>> JavaUtilResourceBundleAccess method:
>>> 
>>>                public ResourceBundle getBundle(String baseName, Locale
>>> locale, Module module) {
>>>                    // use the given module as the caller to bypass the
>>> access check
>>>                    return getBundleImpl(module, module,
>>> getLoader(module),
>>>                                         baseName, locale,
>>> Control.INSTANCE);
>>>                }
>>> 
>>> ...which is used in logging - the module passed here can be either named
>>> or unnamed;
>>> 
>>> ... and a method invoked from new JDK 9 public getBundle() methods
>>> taking explicit Module argument:
>>> 
>>>    private static ResourceBundle getBundleFromModule(Class<?> caller,
>>>                                                      Module module,
>>>                                                      String baseName,
>>>                                                      Locale locale,
>>>                                                      Control control) {
>>>        Objects.requireNonNull(module);
>>>        Module callerModule = caller.getModule();
>>>        if (callerModule != module) {
>>>            SecurityManager sm = System.getSecurityManager();
>>>            if (sm != null) {
>>>                sm.checkPermission(GET_CLASSLOADER_PERMISSION);
>>>            }
>>>        }
>>>        return getBundleImpl(callerModule, module, getLoader(module),
>>> baseName, locale, control);
>>>    }
>>> 
>>> In all of these cases, the loader passed to downstream getBundleImpl is
>>> the module's (2nd argument 'module') class loader (or a special
>>> substitute for bootstrap loader).
>>> 
>>> Considering all this, I think class loader is not needed any more as the
>>> CacheKey component. The distinction between scopes of system class
>>> loader (when the caller is not a bootstrap class) and the
>>> RBClassLoader.INSTANCE (when the caller is the bootstrap class) is also
>>> not needed any more since the callerModule is now part of CacheKey.
>>> 
>>> I modified your patch (just ResourceBundle.java) to include all these
>>> simplifications and some cleanup:
>>> 
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.01/
>>> 
>>> 
>>> 
>>> 
>>> This modification also contains a re-interpretation of clearCache()
>>> methods. Both existing clearCahe() methods together with the additional
>>> @since 9 method contain the following wording:
>>> 
>>> "Removes all resource bundles from the cache that have been loaded by
>>> the caller's / given module..."
>>> 
>>> What does it meant for a bundle to be loaded *by* some module? I think
>>> the right interpretation is that this is the caller module (the one that
>>> invokes ResourceBundle.getBundle() method). The module that calls
>>> ResourceBundle.getBundle() is usually also the module that is
>>> responsible for clearing the cache of entries that were cached by its
>>> loading requests, isn't it?
>>> 
>>> So, what do you think?
>>> 
>>> Regards, Peter
>>> 
>> 


From peter.levart at gmail.com  Sat Jan  7 06:57:16 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 7 Jan 2017 07:57:16 +0100
Subject: Review Request JDK-8170772: ResourceBundle improper caching
	causes tools/javadoc tests intermittently
In-Reply-To: <8295D13D-74F9-4119-98FB-D43BD1C6012B@oracle.com>
References: <E9A3FE4E-D5CD-41ED-BA14-7311C99180D8@oracle.com>
	<887b1af3-decf-5a9e-6577-4b2781e8183c@gmail.com>
	<0f17689a-84a6-7508-6802-6f440de93161@oracle.com>
	<0759b853-d076-f7ab-28bc-4623615f71c1@oracle.com>
	<8295D13D-74F9-4119-98FB-D43BD1C6012B@oracle.com>
Message-ID: <88089e10-bcb6-cec8-d33f-3324207be47c@gmail.com>

Hi Mandy, Naoto,

I think Mandy's original proposal has been pushed, but the 
simplification of CacheKey is still open:

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

as well as the re-examination of clearCahe methods:

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

Were you thinking of those two issues Naoto?


Regards, Peter

On 01/07/2017 05:41 AM, Mandy Chung wrote:
> Thanks for looking through this, Naoto.
>
> This has been pushed and resolved in jdk-9+149.
>
> Mandy
>
>> On Jan 6, 2017, at 3:46 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>
>> Hi Peter, Daniel, Mandy,
>>
>> Sorry for the late reply, and thanks for the patch. I went through the patch and I did not find any problem with it. Would you want to proceed with this?
>>
>> Naoto
>>
>> On 12/13/16 2:14 AM, Daniel Fuchs wrote:
>>> Hi Peter,
>>>
>>> This is a bold proposal, I would be frightened to touch at
>>> this code :-)
>>>
>>> Good observations about the simplifications induced by taking
>>> the caller's module as part of the cache key (in particular
>>> getting rid of RBClassLoader.INSTANCE).
>>>
>>> I have imported your patch (had to fight a bit because it
>>> includes changes that had already been pushed) and sent it
>>> through our internal testing system - and haven't seen any
>>> new failures that seemed linked to resource bundles.
>>>
>>> A few observations concerning CacheKey - if I'm not mistaken
>>> most of the key variables could be made final (in particular
>>> callerRef and moduleRef) - and since they are required to be
>>> non null - then getModule() and getCallerModule() could be
>>> simplified. Not sure whether  making those final might require
>>> to add a copy constructor to support clone() though?
>>> It seems CacheKey::setName is never called - but it's probably
>>> safer to keep it (maybe it's called by tests).
>>>
>>> I am not an expert of ResourceBundle - though I had to dive
>>> into it a few times due it's use in logging. Hopefully others
>>> will jump on this.
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 12/12/16 15:10, Peter Levart wrote:
>>>> Hi Mandy (once again for the list),
>>>>
>>>> On 12/09/2016 05:49 PM, Mandy Chung wrote:
>>>>> Naoto,  > > Can you review this ResourceBundle caching fix?  The
>>>>> caller module
>>>>> may be different than the specified module to >
>>>> ResourceBundle.getBundle(String, Module) method and it should also >
>>>> part of the cache key. > >
>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170772/webrev.00/ > >
>>>> The new test shows the issue there and the first loading of the >
>>>> resource bundle of a specific module (success or fail) will be put in >
>>>> the cache and used by subsequent calls. > > Thanks Mandy
>>>>
>>>>
>>>> I think that now callerModule is part of CacheKey, caching logic could
>>>> be simplified. 1st the getBundleImpl method in line 1629:
>>>>
>>>>     private static ResourceBundle getBundleImpl(String baseName,
>>>>                                                 Locale locale,
>>>>                                                 Class<?> caller,
>>>>                                                 ClassLoader loader,
>>>>                                                 Control control) {
>>>>         if (caller != null && caller.getModule().isNamed()) {
>>>>             Module module = caller.getModule();
>>>>             ClassLoader ml = getLoader(module);
>>>>             // get resource bundles for a named module only
>>>>             // if loader is the module's class loader
>>>>             if (loader == ml || (ml == null && loader ==
>>>> RBClassLoader.INSTANCE)) {
>>>>                 return getBundleImpl(module, module, loader, baseName,
>>>> locale, control);
>>>>             }
>>>>         }
>>>>         // find resource bundles from unnamed module
>>>>         Module unnamedModule = loader != null
>>>>             ? loader.getUnnamedModule()
>>>>             : ClassLoader.getSystemClassLoader().getUnnamedModule();
>>>>
>>>>         if (caller == null) {
>>>>             throw new InternalError("null caller");
>>>>         }
>>>>
>>>>         Module callerModule = caller.getModule();
>>>>         return getBundleImpl(callerModule, unnamedModule, loader,
>>>> baseName, locale, control);
>>>>     }
>>>>
>>>>
>>>> ... could be cleaned up a bit without changing its semantics:
>>>>
>>>>     private static ResourceBundle getBundleImpl(String baseName,
>>>>                                                 Locale locale,
>>>>                                                 Class<?> caller,
>>>>                                                 ClassLoader loader,
>>>>                                                 Control control) {
>>>>         if (caller == null) {
>>>>             throw new InternalError("null caller");
>>>>         }
>>>>         Module callerModule = caller.getModule();
>>>>
>>>>         if (callerModule.isNamed()) {
>>>>             ClassLoader ml = getLoader(callerModule);
>>>>             // get resource bundles for a named module only
>>>>             // if loader is the module's class loader
>>>>             if (loader == ml || (ml == null && loader ==
>>>> RBClassLoader.INSTANCE)) {
>>>>                 return getBundleImpl(callerModule, callerModule, loader,
>>>> baseName, locale, control);
>>>>             }
>>>>         }
>>>>
>>>>         // find resource bundles from unnamed module
>>>>         Module unnamedModule = loader != null
>>>>             ? loader.getUnnamedModule()
>>>>             : ClassLoader.getSystemClassLoader().getUnnamedModule();
>>>>
>>>>         return getBundleImpl(callerModule, unnamedModule, loader,
>>>> baseName, locale, control);
>>>>     }
>>>>
>>>>
>>>> Next, I checked all callers of this method (there are 3 of them in
>>>> lines: 1367, 1589, 1615) and all of them guard against passing a null
>>>> 'loader' to this method:
>>>>
>>>>     @CallerSensitive
>>>>     public static ResourceBundle getBundle(String baseName, Locale
>>>> locale,
>>>>                                            ClassLoader loader)
>>>>     {
>>>>         if (loader == null) {
>>>>             throw new NullPointerException();
>>>>         }
>>>>         Class<?> caller = Reflection.getCallerClass();
>>>>         return getBundleImpl(baseName, locale, caller, loader,
>>>> getDefaultControl(caller, baseName));
>>>>     }
>>>>
>>>> ...
>>>>
>>>>     @CallerSensitive
>>>>     public static ResourceBundle getBundle(String baseName, Locale
>>>> targetLocale,
>>>>                                            ClassLoader loader, Control
>>>> control) {
>>>>         if (loader == null || control == null) {
>>>>             throw new NullPointerException();
>>>>         }
>>>>         Class<?> caller = Reflection.getCallerClass();
>>>>         checkNamedModule(caller);
>>>>         return getBundleImpl(baseName, targetLocale, caller, loader,
>>>> control);
>>>>     }
>>>>
>>>> ...
>>>>
>>>>     private static ResourceBundle getBundleImpl(String baseName,
>>>>                                                 Locale locale,
>>>>                                                 Class<?> caller,
>>>>                                                 Control control) {
>>>>         return getBundleImpl(baseName, locale, caller,
>>>> getLoader(caller), control);
>>>>     }
>>>>
>>>>     private static ClassLoader getLoader(Class<?> caller) {
>>>>         ClassLoader cl = caller == null ? null : caller.getClassLoader();
>>>>         if (cl == null) {
>>>>             // When the caller's loader is the boot class loader, cl is
>>>> null
>>>>             // here. In that case, ClassLoader.getSystemClassLoader() may
>>>>             // return the same class loader that the application is
>>>>             // using. We therefore use a wrapper ClassLoader to create a
>>>>             // separate scope for bundles loaded on behalf of the Java
>>>>             // runtime so that these bundles cannot be returned from the
>>>>             // cache to the application (5048280).
>>>>             cl = RBClassLoader.INSTANCE;
>>>>         }
>>>>         return cl;
>>>>     }
>>>>
>>>>
>>>> Therefore the above method can be simplified further:
>>>>
>>>>     private static ResourceBundle getBundleImpl(String baseName,
>>>>                                                 Locale locale,
>>>>                                                 Class<?> caller,
>>>>                                                 ClassLoader loader,
>>>>                                                 Control control) {
>>>>         if (caller == null) {
>>>>             throw new InternalError("null caller");
>>>>         }
>>>>         if (loader == null) {
>>>>             throw new InternalError("null loader");
>>>>         }
>>>>         Module callerModule = caller.getModule();
>>>>
>>>>         if (callerModule.isNamed()) {
>>>>             ClassLoader ml = getLoader(callerModule);
>>>>             // get resource bundles for a named module only
>>>>             // if loader is the module's class loader
>>>>             if (loader == ml || (ml == null && loader ==
>>>> RBClassLoader.INSTANCE)) {
>>>>                 return getBundleImpl(callerModule, callerModule, loader,
>>>> baseName, locale, control);
>>>>             }
>>>>         }
>>>>
>>>>         // find resource bundles from unnamed module
>>>>         Module unnamedModule = loader.getUnnamedModule();
>>>>         return getBundleImpl(callerModule, unnamedModule, loader,
>>>> baseName, locale, control);
>>>>     }
>>>>
>>>>
>>>>
>>>> ...here we can see that (callerModule, module, loader) triple passed to
>>>> downstream getBundleImpl is either (callerModule, callerModule,
>>>> callerModule's class loader) - with a RBClassLoader.INSTANCE substitute
>>>> for bootstrap class loader, when the callerModule is a named module and
>>>> requested loader is the callerModule's loader, or (callerModule,
>>>> loader's unnamed module, loader) when loader is not callerModule's
>>>> loader or callerModule is unnamed.
>>>>
>>>> other two callers of the downstream getBundleImpl are the
>>>> JavaUtilResourceBundleAccess method:
>>>>
>>>>                 public ResourceBundle getBundle(String baseName, Locale
>>>> locale, Module module) {
>>>>                     // use the given module as the caller to bypass the
>>>> access check
>>>>                     return getBundleImpl(module, module,
>>>> getLoader(module),
>>>>                                          baseName, locale,
>>>> Control.INSTANCE);
>>>>                 }
>>>>
>>>> ...which is used in logging - the module passed here can be either named
>>>> or unnamed;
>>>>
>>>> ... and a method invoked from new JDK 9 public getBundle() methods
>>>> taking explicit Module argument:
>>>>
>>>>     private static ResourceBundle getBundleFromModule(Class<?> caller,
>>>>                                                       Module module,
>>>>                                                       String baseName,
>>>>                                                       Locale locale,
>>>>                                                       Control control) {
>>>>         Objects.requireNonNull(module);
>>>>         Module callerModule = caller.getModule();
>>>>         if (callerModule != module) {
>>>>             SecurityManager sm = System.getSecurityManager();
>>>>             if (sm != null) {
>>>>                 sm.checkPermission(GET_CLASSLOADER_PERMISSION);
>>>>             }
>>>>         }
>>>>         return getBundleImpl(callerModule, module, getLoader(module),
>>>> baseName, locale, control);
>>>>     }
>>>>
>>>> In all of these cases, the loader passed to downstream getBundleImpl is
>>>> the module's (2nd argument 'module') class loader (or a special
>>>> substitute for bootstrap loader).
>>>>
>>>> Considering all this, I think class loader is not needed any more as the
>>>> CacheKey component. The distinction between scopes of system class
>>>> loader (when the caller is not a bootstrap class) and the
>>>> RBClassLoader.INSTANCE (when the caller is the bootstrap class) is also
>>>> not needed any more since the callerModule is now part of CacheKey.
>>>>
>>>> I modified your patch (just ResourceBundle.java) to include all these
>>>> simplifications and some cleanup:
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.01/
>>>>
>>>>
>>>>
>>>>
>>>> This modification also contains a re-interpretation of clearCache()
>>>> methods. Both existing clearCahe() methods together with the additional
>>>> @since 9 method contain the following wording:
>>>>
>>>> "Removes all resource bundles from the cache that have been loaded by
>>>> the caller's / given module..."
>>>>
>>>> What does it meant for a bundle to be loaded *by* some module? I think
>>>> the right interpretation is that this is the caller module (the one that
>>>> invokes ResourceBundle.getBundle() method). The module that calls
>>>> ResourceBundle.getBundle() is usually also the module that is
>>>> responsible for clearing the cache of entries that were cached by its
>>>> loading requests, isn't it?
>>>>
>>>> So, what do you think?
>>>>
>>>> Regards, Peter
>>>>


From peter.levart at gmail.com  Sat Jan  7 08:26:30 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 7 Jan 2017 09:26:30 +0100
Subject: AnnotationFormatError vs. IllegalArgumentException for invalid
	annotation interface members (methods)
Message-ID: <29dd26b1-bffd-d12b-82e9-76c32f219811@gmail.com>

Hi Joe,

While investigating the fix for:

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

I encountered what I believe is an inconsistency in exception reporting. 
The following jtreg test:


public class AnnotationVerifier {

     @AnnotationWithParameter
     @AnnotationWithVoidReturn
     static class BadAnnotation {
     }

     @Test
     @ExpectedExceptions(IllegalArgumentException.class)
     public void annotationValidationIAE() {
         AnnotationType.getInstance(AnnotationWithParameter.class);
     }

     @Test(expectedExceptions = AnnotationFormatError.class)
     public void annotationValidationAFE() {
BadAnnotation.class.getAnnotation(AnnotationWithVoidReturn.class);
     }
}


...treats methods in an annotation interface differently when they have 
a parameter (it throws IllegalArgumentException because parameter counts 
are checked in AnnotationType constructor) vs. when they have invalid 
return type such as void (it throws AnnotationFormatError when the 
member's default value is retrieved in AnnotationType constructor, but 
AnnotationType does not explicitly check for member return types). I 
believe both situations should result in AnnotationFormatError when such 
annotation is requested.

I'm thinking of moving the validateAnnotationMethods() method from 
AnnotationInvocationHandler where methods are being checked for each 
annotation instance constructed to AnnotationType, where they would be 
checked only once per annotation type and make exception reporting 
consistent for any invalid situation.

What do you think?

Regards, Peter


From peter.levart at gmail.com  Sat Jan  7 08:40:17 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 7 Jan 2017 09:40:17 +0100
Subject: AnnotationFormatError vs. IllegalArgumentException for invalid
	annotation interface members (methods)
In-Reply-To: <29dd26b1-bffd-d12b-82e9-76c32f219811@gmail.com>
References: <29dd26b1-bffd-d12b-82e9-76c32f219811@gmail.com>
Message-ID: <901afb9a-db31-8f1c-c9f6-47e0573d8bd1@gmail.com>



On 01/07/2017 09:26 AM, Peter Levart wrote:
> I'm thinking of moving the validateAnnotationMethods() method from 
> AnnotationInvocationHandler where methods are being checked for each 
> annotation instance constructed to AnnotationType, where they would be 
> checked only once per annotation type and make exception reporting 
> consistent for any invalid situation.

Correction: validateAnnotationMethods() is only invoked from the 
annotation's equals() implementation when some JDK annotation is 
compared with a foreign implementation of annotation (one that is not 
using dynamic Proxy and AnnotationInvocationHandler). Which is a waste I 
think and mostly to late or never. I think the methods should be checked 
in AnnotationType constructor as soon as the 1st annotation of a 
particular type is attempted to be materialized, don't you think?

Regards, Peter


From forax at univ-mlv.fr  Sat Jan  7 13:17:48 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 7 Jan 2017 14:17:48 +0100 (CET)
Subject: ASM6 going native
Message-ID: <184855629.2172143.1483795068430.JavaMail.zimbra@u-pem.fr>

Hi all,
i've played a little with jaotc [1] and i can confirm it works well with ASM :)

If the library code is stripped, ASM6 full is 13 megs in tiered mode and 10 megs in non tiered mode.

--module doesn't seems to work with non-system module but it seems it already has been already reported.

cheers,
R?mi 

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

From huaming.li at oracle.com  Mon Jan  9 07:20:52 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Sun, 8 Jan 2017 23:20:52 -0800
Subject: RFR of JDK-8030175:
	java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due
	to timeout
In-Reply-To: <cd0e863c-fb22-7b84-8993-c9d4f06336b9@Oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
	<0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
	<5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
	<644724ce-9020-0f3f-49cd-a0112c1f729e@oracle.com>
	<cd0e863c-fb22-7b84-8993-c9d4f06336b9@Oracle.com>
Message-ID: <bfddf502-9b5d-58f9-6499-16c84c258426@oracle.com>

Hi Roger,

Both rmid and rmiregistry is running in sub-process, their log have 
already been caught and printed out by JavaVM if something get wrong, so 
for timeout due to long run, there is no more we can do. So I just 
pushed the patch.

Thank you
-Hamlin

On 2017/1/6 13:15, Roger Riggs wrote:
> Hi Hamlin,
>
> Since it is intermittent, are there any diagnostics that can be added 
> to the test in case it fails again.
> if not, ok as is.
>
> Thanks, Roger
>
>
> On 1/5/2017 8:55 PM, Hamlin Li wrote:
>>
>>
>> On 2017/1/6 6:15, Roger Riggs wrote:
>>>
>>>
>>> On 1/4/2017 10:21 PM, Hamlin Li wrote:
>>>> Hi Roger,
>>>>
>>>> Thank you for reviewing, please check comments inline.
>>>>
>>>>
>>>> On 2017/1/5 4:18, Roger Riggs wrote:
>>>>> Hi Hamlin,
>>>>>
>>>>> The original issue with timeout may be due to heavily loaded 
>>>>> systems and short timeouts.
>>>>> 15 sec is not enough on an overloaded system to wait for a process 
>>>>> to start and then die.
>>>>>
>>>>> There is no indication in this issue about port-in-use; that would 
>>>>> be a different issue.
>>>> Agree, I put 2 fixes in one patch together as there is no port in 
>>>> use issue reported, but by reviewing the code, potential port in 
>>>> use issue could happen some time in the future.
>>> Best to keep 1-1 to avoid complicating the discussion and increasing 
>>> code complexity.
>> Hi Roger,
>>
>> Got it, the new webrev for timeout issue is at: 
>> http://cr.openjdk.java.net/~mli/8030175/webrev.01/
>>
>> I just created another bug 
>> https://bugs.openjdk.java.net/browse/JDK-8172314 to track the "port 
>> in use" bug, will send out separate webrev in another thread later.
>>
>> Thank you
>> -Hamlin
>>>>>
>>>>>
>>>>> Common comments to both A and B.
>>>>>
>>>>> I'll need more time to look at B; it would be cleaner to use A if 
>>>>> it can address the issue.
>>>>> The alternative is to duplicate the code in run() in the 
>>>>> TestLibrary and not modify the RegistryImpl.
>>>> I prefer B, because
>>>>   1. Although A looks cleaner but B is simulating more like 
>>>> rmiregistry.
>>>>   2. There are some other issue for example JDK-7146543, 
>>>> JDK-8030950, JDK-8038772, fix based on version B works well, but 
>>>> fix based on version A fails.
>>>>   3. Impact of RegistryImpl modification is minimal. ( May we could 
>>>> make Registry run(String args[]) private and access it in test by 
>>>> reflection? )
>>>>   4. Although it's simple to duplicate the code in run() in the 
>>>> TestLibrary, but seems it's not a good design choice. (let's call 
>>>> it version C.)
>>>>   5. For JDK-8170728, the fix will need to modify 
>>>> sun.rmi.registry.RegistryImpl anyway.
>>>>
>>>>
>>>> Thank you for detailed review comments below.
>>>> As we have several options, I will wait for your further comments 
>>>> on choice of version A/B/C, then send out new webrev, hope I only 
>>>> need to send out one version :-).
>>>>
>>>> Thank you
>>>> -Hamlin
>>>>>
>>>>>
>>>>> JavaVM:
>>>>>  - Document the new methods.
>>>>>
>>>>> Line 232: Document the exception that may be thrown from exitValue.
>>>>>
>>>>>
>>>>> RMID:
>>>>> Line 204, 222: when adding new functions to the test library 
>>>>> please add documentation for the methods.
>>>>> There are now many variations of the methods that differ only by 
>>>>> the number arguments.
>>>>> It would be better if the name included some hint as to the 
>>>>> additional functionality.
>>>>>
>>>>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>>>>
>>>>> REGISTRY:
>>>>>   - Document the new methods.
>>>>>
>>>>>   - The name should be more indicative of its function and should 
>>>>> NOT be all caps;  RMID is an acronym where the caps make sense.
>>>>>
>>>>>   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating 
>>>>> code to wait for the subprocess.
>>>>>
>>>>>   - If the subprocesses are in an unknown state it would be useful 
>>>>> to print diagnostic info from the subprocess before terminating.
>>>>>     Line 106:
>>>>>
>>>>>  - Line 124:
>>>>>  - I think I would have promoted the shutdown method to JavaVM 
>>>>> instead of creating a new cleanup method
>>>>>    to keep the code simpler.
>>>>>
>>>>>    ** The cleanup method never calls super.cleanup() so the 
>>>>> process is never destroyed!.
>>>>>
>>>>> AltSecurityManager.java:
>>>>>
>>>>>  - Line 61: the empty constructor can be removed entirely.
>>>>>
>>>>>  - Line 80: change the message to say the exception did not occur.
>>>>>     As written it implies it may have occurred but was not caught.
>>>>>
>>>>>  - Line 86: typo "a unexpected" -> "an unexpected"
>>>>>
>>>>> - Line 90: remove the printStackTrace; it is not useful and is a 
>>>>> red flag in .jtr files
>>>>>
>>>>>  - Line 125: I don't see that cleanup is better than destroy; If 
>>>>> there are doubts about destroy
>>>>>    then destroy should be fixed not avoided.
>>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>>>>> Would you please review the below patches?
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>>>>> webrev (version A): 
>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>>>>> webrev (version B): 
>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>>>>>
>>>>>>
>>>>>> There are 2 versions to be reviewed.
>>>>>>
>>>>>> In version A, just use RegistryRunner to replace rmiregistry.
>>>>>> In version B, refactor sun.rmi.registry.RegistryImpl to improve 
>>>>>> the testability of RMI code, and create/use RMIRegistryRunner to 
>>>>>> simulate rmiregistry.
>>>>>>
>>>>>> Thank you
>>>>>> -Hamlin
>>>>>
>>>>
>>>
>>
>


From huaming.li at oracle.com  Mon Jan  9 07:56:20 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Sun, 8 Jan 2017 23:56:20 -0800
Subject: RFR of JDK-8172347: Refactoring
	src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to
	improve testability of rmiregistry
In-Reply-To: <888af0b3-24ee-826a-7449-f3eece8ab9f8@Oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
	<0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
	<5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
	<6432c6de-af93-5224-f848-8e2e8f0f7c9f@oracle.com>
	<888af0b3-24ee-826a-7449-f3eece8ab9f8@Oracle.com>
Message-ID: <2eecc91f-019a-024d-a48f-27930137cb09@oracle.com>

Hi Roger,

Thank you for reviewing, please check new webrev: 
http://cr.openjdk.java.net/~mli/8172347/webrev.01/

Thank you
-Hamlin

On 2017/1/6 12:56, Roger Riggs wrote:
> Hi Hamlin,
>
> Yes, that looks better.
>
> On the comments, use the normal javadoc comment conventions for any 
> public API.
> @param @return, @throw, etc.
>
> I think comments should be direct about what the function does. It 
> does not need
> to explain why so much.  Or if so, later and in a separate paragraph;  
> when reading
> the most important information should be first.
>
> Thanks, Roger
>
>
> On 1/6/2017 4:59 AM, Hamlin Li wrote:
>>
>> On 2017/1/6 6:15, Roger Riggs wrote:
>>> Hi Hamlin,
>>>
>>> There are too many issues being mixed together...
>>>
>>> Comments on B) RegistryImpl:
>>>
>>> Refactoring of RegistryImpl Main should be clean and clearly separated.
>> Hi Roger,
>>
>> Thank you for reviewing.
>> Not sure if I understood you correctly, I created a new bug to track 
>> refactoring of RegistryImpl, I will send out separate reviews for 
>> AltSecurityManager in JDK-8172314, JDK-8030175. Please let me know if 
>> you did not mean it.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8172347
>> webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.00/, fix all 
>> the below points.
>>
>> Thank you
>> -Hamlin
>>>
>>> 365: static void RegistryImpl run():
>>>
>>> -  The signature of run should be run(int port) and documented as 
>>> needing to be run in its
>>>    own thread since it changes Thread context classloader and that 
>>> it sets a securityManager.
>>>    Leave it to main to parse and choose a port number.
>>>
>>> -  The comments should be functional as to the purpose of the code 
>>> and not referencing a particular bug.
>>>    (Regardless of prior example).
>>>
>>>  - The comment about getting the exact port is out of place because 
>>> the port number cannot be
>>>    retrieved from the returned RegistryImpl.  IF that's why this 
>>> refactoring is needed, then
>>>    perhaps there should be a getPort method that extracts it from 
>>> the created UnicastServerRef.
>>>
>>> 423: static void main(String[] args):
>>>
>>>  - Parsing of args should be left in main(); avoiding the question 
>>> about why NumberFormat is handled.
>>>
>>>  - Either main or run should set a security manager; but not both.
>>>
>>> Roger
>>>
>>>
>>>
>>>
>>> On 1/4/2017 10:21 PM, Hamlin Li wrote:
>>>> Hi Roger,
>>>>
>>>> Thank you for reviewing, please check comments inline.
>>>>
>>>>
>>>> On 2017/1/5 4:18, Roger Riggs wrote:
>>>>> Hi Hamlin,
>>>>>
>>>>> The original issue with timeout may be due to heavily loaded 
>>>>> systems and short timeouts.
>>>>> 15 sec is not enough on an overloaded system to wait for a process 
>>>>> to start and then die.
>>>>>
>>>>> There is no indication in this issue about port-in-use; that would 
>>>>> be a different issue.
>>>> Agree, I put 2 fixes in one patch together as there is no port in 
>>>> use issue reported, but by reviewing the code, potential port in 
>>>> use issue could happen some time in the future.
>>> Best to keep 1-1 to avoid complicating the discussion and increasing 
>>> code complexity.
>>>>>
>>>>>
>>>>> Common comments to both A and B.
>>>>>
>>>>> I'll need more time to look at B; it would be cleaner to use A if 
>>>>> it can address the issue.
>>>>> The alternative is to duplicate the code in run() in the 
>>>>> TestLibrary and not modify the RegistryImpl.
>>>> I prefer B, because
>>>>   1. Although A looks cleaner but B is simulating more like 
>>>> rmiregistry.
>>>>   2. There are some other issue for example JDK-7146543, 
>>>> JDK-8030950, JDK-8038772, fix based on version B works well, but 
>>>> fix based on version A fails.
>>>>   3. Impact of RegistryImpl modification is minimal. ( May we could 
>>>> make Registry run(String args[]) private and access it in test by 
>>>> reflection? )
>>>>   4. Although it's simple to duplicate the code in run() in the 
>>>> TestLibrary, but seems it's not a good design choice. (let's call 
>>>> it version C.)
>>>>   5. For JDK-8170728, the fix will need to modify 
>>>> sun.rmi.registry.RegistryImpl anyway.
>>>>
>>>>
>>>> Thank you for detailed review comments below.
>>>> As we have several options, I will wait for your further comments 
>>>> on choice of version A/B/C, then send out new webrev, hope I only 
>>>> need to send out one version :-).
>>>>
>>>> Thank you
>>>> -Hamlin
>>>>>
>>>>>
>>>>> JavaVM:
>>>>>  - Document the new methods.
>>>>>
>>>>> Line 232: Document the exception that may be thrown from exitValue.
>>>>>
>>>>>
>>>>> RMID:
>>>>> Line 204, 222: when adding new functions to the test library 
>>>>> please add documentation for the methods.
>>>>> There are now many variations of the methods that differ only by 
>>>>> the number arguments.
>>>>> It would be better if the name included some hint as to the 
>>>>> additional functionality.
>>>>>
>>>>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>>>>
>>>>> REGISTRY:
>>>>>   - Document the new methods.
>>>>>
>>>>>   - The name should be more indicative of its function and should 
>>>>> NOT be all caps;  RMID is an acronym where the caps make sense.
>>>>>
>>>>>   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating 
>>>>> code to wait for the subprocess.
>>>>>
>>>>>   - If the subprocesses are in an unknown state it would be useful 
>>>>> to print diagnostic info from the subprocess before terminating.
>>>>>     Line 106:
>>>>>
>>>>>  - Line 124:
>>>>>  - I think I would have promoted the shutdown method to JavaVM 
>>>>> instead of creating a new cleanup method
>>>>>    to keep the code simpler.
>>>>>
>>>>>    ** The cleanup method never calls super.cleanup() so the 
>>>>> process is never destroyed!.
>>>>>
>>>>> AltSecurityManager.java:
>>>>>
>>>>>  - Line 61: the empty constructor can be removed entirely.
>>>>>
>>>>>  - Line 80: change the message to say the exception did not occur.
>>>>>     As written it implies it may have occurred but was not caught.
>>>>>
>>>>>  - Line 86: typo "a unexpected" -> "an unexpected"
>>>>>
>>>>> - Line 90: remove the printStackTrace; it is not useful and is a 
>>>>> red flag in .jtr files
>>>>>
>>>>>  - Line 125: I don't see that cleanup is better than destroy; If 
>>>>> there are doubts about destroy
>>>>>    then destroy should be fixed not avoided.
>>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>>>>> Would you please review the below patches?
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>>>>> webrev (version A): 
>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>>>>> webrev (version B): 
>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>>>>>
>>>>>>
>>>>>> There are 2 versions to be reviewed.
>>>>>>
>>>>>> In version A, just use RegistryRunner to replace rmiregistry.
>>>>>> In version B, refactor sun.rmi.registry.RegistryImpl to improve 
>>>>>> the testability of RMI code, and create/use RMIRegistryRunner to 
>>>>>> simulate rmiregistry.
>>>>>>
>>>>>> Thank you
>>>>>> -Hamlin
>>>>>
>>>>
>>>
>>
>


From aleksej.efimov at oracle.com  Mon Jan  9 09:34:18 2017
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Mon, 9 Jan 2017 12:34:18 +0300
Subject: [9] RFR: 8159058: SAXParseException when sending soap message
Message-ID: <81835be1-37dc-68d3-b033-2a1a468a79cd@oracle.com>

Hi,

Please, help to review the JDK9 fix for the issue [1] in processing of 
default namespace attribute with empty values (xmlns="") by SAAJ 
implementation:
http://cr.openjdk.java.net/~aefimov/8159058/9/00

Same fix was already integrated into JAXWS-RI and SAAJ-RI standalone 
projects. These changes were backported from standalone projects with 
additional package names changes and regression test addition. Due to 
urgency of this issue I would like to integrate this change into JDK9 
separately from jaxws-ri synchronization process.

The following test sets shows no related/new failures: JDK regression 
tests, JCK jaxws/b tests, standalone saaj-ri tck unit tests.

With Best Regards,
Aleksej

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


From sergei.kovalev at oracle.com  Mon Jan  9 09:45:52 2017
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Mon, 9 Jan 2017 12:45:52 +0300
Subject: RFR(s): 8171958: Several tests from
	java/time/test/java/time/format requiring jdk.localedata for execution
In-Reply-To: <3e978d60-2fed-4106-6d8f-fb64f32dff63@oracle.com>
References: <39bd0f19-5dbd-9790-2d5f-d3cae2a7cf08@oracle.com>
	<5dbbbb52-26fd-bd59-fdc8-ebb94585c7df@oracle.com>
	<3e978d60-2fed-4106-6d8f-fb64f32dff63@oracle.com>
Message-ID: <056de9df-4cb6-c17a-b8b1-6120d4b9389b@oracle.com>

Hi All,

Re-sending request because I'm still looking for reviewers.

In addition for TEST.properties modification I'd like to put citation 
from Jon G. email.

> FWIW, I note your TEST.properties file looks malformed.  It has 2 
> modules entries (line 4, line 7), which by the standard rules of Java 
> properties files, means that "last one wins".
>
> line source
> # Threeten test uses TestNG
> TestNG.dirs = .
> othervm.dirs = tck/java/time/chrono test/java/time/chrono 
> test/java/time/format
> modules = jdk.localedata
> lib.dirs = ../../lib/testlibrary
> lib.build = jdk.testlibrary.RandomFactory
> modules = java.base/java.time:open java.base/java.time.chrono:open 
> java.base/java.time.zone:open
This mean that first modules declaration could be safely removed as I did.


28.12.16 17:20, Sergei Kovalev wrote:
>
> Hi Rachna,
>
> Thank you for the comment. I've reviewed usage of module declaration 
> in TEST.properties file and find that it could be removed without any 
> impact. In both cases (with original and modified TEST.properties 
> file) I get same result.
>
> Test results: passed: 142; failed: 27
>
> The reason of this behavior is the lack of jtreg header in test 
> sources. In case test source has no "@test" tag jtreg ignores all 
> properties that exists in TEST.properties file.
>
> I recreated the review by adding TEST.properties modification: 
> http://cr.openjdk.java.net/~skovalev/8171958/webrev.01/
>
>
> 27.12.16 13:55, Rachna Goel wrote:
>>
>> Hi Sergei,
>>
>> Though I am not a reviewer, But I have one comment on this fix.
>>
>> test/java/time/TEST.properties declares "modules = jdk.localedata" , 
>> so that all tests for java.time can have access to "jdk.localedata" 
>> module.
>>
>> If we are restricting usage of jdk.localedata module for different 
>> tests, then TEST.properties need to be updated as well.
>>
>> Thanks,
>> Rachna
>>
>>
>>
>> On 26/12/16 8:27 PM, Sergei Kovalev wrote:
>>> Hello Team,
>>>
>>> Please review below fix for tests.
>>>
>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8171958
>>> Web review: http://cr.openjdk.java.net/~skovalev/8171958/webrev.00/
>>>
>>> Issue: some tests fails in case of module limitation by 
>>> '--limit-module java.base' command line option.
>>> Root cause: The tests uses locale data that stored in separate 
>>> resource file "jdk.localedata".
>>> Solution: Add declaration of required module. In same cases a test 
>>> file contains many test items, part of which could be executed with 
>>> java.base module only. In this cases we can separate the items and 
>>> extract that items which depend on locale data and run them 
>>> individually. Therefore this proposal contains additional test files 
>>> where added "WithLocale" suffix which demonstrate dependency on 
>>> resources. Alternative solution could be add a required module 
>>> declaration "jdk.localedata" to all files. However this will lead to 
>>> unnecessary test coverage reduction.
>>>
>>
>
> -- 
> With best regards,
> Sergei

-- 
With best regards,
Sergei


From rachna.goel at oracle.com  Mon Jan  9 12:38:32 2017
From: rachna.goel at oracle.com (Rachna Goel)
Date: Mon, 9 Jan 2017 18:08:32 +0530
Subject: RFR(s): 8171958: Several tests from
	java/time/test/java/time/format requiring jdk.localedata for execution
In-Reply-To: <056de9df-4cb6-c17a-b8b1-6120d4b9389b@oracle.com>
References: <39bd0f19-5dbd-9790-2d5f-d3cae2a7cf08@oracle.com>
	<5dbbbb52-26fd-bd59-fdc8-ebb94585c7df@oracle.com>
	<3e978d60-2fed-4106-6d8f-fb64f32dff63@oracle.com>
	<056de9df-4cb6-c17a-b8b1-6120d4b9389b@oracle.com>
Message-ID: <016ac3c8-1526-01c0-6c75-ddc0c26f34ee@oracle.com>

Hi Sergei,

Just for curiosity, what is the purpose of moving package statement down.

Sorry for pointing out, Copyright year needs to be updated to 2017.

Thanks,
Rachna

On 09/01/17 3:15 PM, Sergei Kovalev wrote:
> Hi All,
>
> Re-sending request because I'm still looking for reviewers.
>
> In addition for TEST.properties modification I'd like to put citation 
> from Jon G. email.
>
>> FWIW, I note your TEST.properties file looks malformed.  It has 2 
>> modules entries (line 4, line 7), which by the standard rules of Java 
>> properties files, means that "last one wins".
>>
>> line source
>> # Threeten test uses TestNG
>> TestNG.dirs = .
>> othervm.dirs = tck/java/time/chrono test/java/time/chrono 
>> test/java/time/format
>> modules = jdk.localedata
>> lib.dirs = ../../lib/testlibrary
>> lib.build = jdk.testlibrary.RandomFactory
>> modules = java.base/java.time:open java.base/java.time.chrono:open 
>> java.base/java.time.zone:open
> This mean that first modules declaration could be safely removed as I 
> did.
>
>
> 28.12.16 17:20, Sergei Kovalev wrote:
>>
>> Hi Rachna,
>>
>> Thank you for the comment. I've reviewed usage of module declaration 
>> in TEST.properties file and find that it could be removed without any 
>> impact. In both cases (with original and modified TEST.properties 
>> file) I get same result.
>>
>> Test results: passed: 142; failed: 27
>>
>> The reason of this behavior is the lack of jtreg header in test 
>> sources. In case test source has no "@test" tag jtreg ignores all 
>> properties that exists in TEST.properties file.
>>
>> I recreated the review by adding TEST.properties modification: 
>> http://cr.openjdk.java.net/~skovalev/8171958/webrev.01/
>>
>>
>> 27.12.16 13:55, Rachna Goel wrote:
>>>
>>> Hi Sergei,
>>>
>>> Though I am not a reviewer, But I have one comment on this fix.
>>>
>>> test/java/time/TEST.properties declares "modules = jdk.localedata" , 
>>> so that all tests for java.time can have access to "jdk.localedata" 
>>> module.
>>>
>>> If we are restricting usage of jdk.localedata module for different 
>>> tests, then TEST.properties need to be updated as well.
>>>
>>> Thanks,
>>> Rachna
>>>
>>>
>>>
>>> On 26/12/16 8:27 PM, Sergei Kovalev wrote:
>>>> Hello Team,
>>>>
>>>> Please review below fix for tests.
>>>>
>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8171958
>>>> Web review: http://cr.openjdk.java.net/~skovalev/8171958/webrev.00/
>>>>
>>>> Issue: some tests fails in case of module limitation by 
>>>> '--limit-module java.base' command line option.
>>>> Root cause: The tests uses locale data that stored in separate 
>>>> resource file "jdk.localedata".
>>>> Solution: Add declaration of required module. In same cases a test 
>>>> file contains many test items, part of which could be executed with 
>>>> java.base module only. In this cases we can separate the items and 
>>>> extract that items which depend on locale data and run them 
>>>> individually. Therefore this proposal contains additional test 
>>>> files where added "WithLocale" suffix which demonstrate dependency 
>>>> on resources. Alternative solution could be add a required module 
>>>> declaration "jdk.localedata" to all files. However this will lead 
>>>> to unnecessary test coverage reduction.
>>>>
>>>
>>
>> -- 
>> With best regards,
>> Sergei
>

-- 
Thanks,
Rachna


From Alan.Bateman at oracle.com  Mon Jan  9 13:36:26 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 9 Jan 2017 13:36:26 +0000
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
Message-ID: <d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>

On 05/01/2017 19:01, Paul Sandoz wrote:

> Hi,
>
> I encountered some circularity issues with security manager and VarHandles, specifically when attempting to use the new MethodHandles.privateLookupIn, so say ThreadLocalRandom has access to fields in Thread [1].
>
> When running with a security manager ThreadLocalRandom clinit depends on various security stuff that eventually depends on ConcurrentSkipListMap which depends on ThreadLocalRandom, whose static state has not been fully initialzed.
>
> The current security permission check in MethodHandles.privateLookupIn may be a too blunt and possibly should be refined along similar lines to Lookup.checkSecurityManager e.g. no check should be needed for classes within the same module (since this is a refined/controlled/principled form of setAccessible, plus no pounding on final fields). That would solve the problem in this case. But, the general point remains, and i have not thought too hard if there are other ways to solve this.
>
This would mean inconsistency with setAccessible where you need this 
blunt permission when suppressing access. Also I think 
Lookup.checkSecurityManager will do different checks when you don't have 
a full power lookup so it would mean adjusting the privateLookupIn.

I wonder if we could trigger more of this initialization in initPhase3 
before the security manager is set. I'm sure TLR::current will do but 
that might be too much to do at startup.

-Alan

From mark.sheppard at oracle.com  Mon Jan  9 14:36:29 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Mon, 9 Jan 2017 14:36:29 +0000
Subject: RFR of JDK-8172347: Refactoring
	src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to
	improve testability of rmiregistry
In-Reply-To: <2eecc91f-019a-024d-a48f-27930137cb09@oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
	<0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
	<5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
	<6432c6de-af93-5224-f848-8e2e8f0f7c9f@oracle.com>
	<888af0b3-24ee-826a-7449-f3eece8ab9f8@Oracle.com>
	<2eecc91f-019a-024d-a48f-27930137cb09@oracle.com>
Message-ID: <48bdbd18-f420-e526-2278-0506d02ee443@oracle.com>

Hi Hamlin,

If I read the changes correctly, there would appear to be a side effect 
of your refactor extract method "run", such that the static member variable
registry is no longer set in the main method, and is set in the run 
method ? Thus, invoking run multiple times (, whether that is intended 
or not,) will
see the registry static member variable overwritten, for each call. 
While the current implementation that will occur once only within the 
main method.
So, what's the desired semantics for multiple "run" calls?

  A "run" method is synonymous with Runnable interface, even though this 
run method has a different signature, it's better
to help us unwary avoid confusion!
Also the run method instantiates and returns a RegistryImpl, thus 
exhibiting factory method characteristics.
As such, perhaps a refactor "rename" would be in order, such as create, 
execute, or launch ?

It would be helpful to provide a current summary, or a recap, as to the 
motivation for the refactoring.

Is this complimentary to the constructor RegistryImp(int port) or 
LocateRegistry.createRegistry( ..)  ?


regards
Mark



On 09/01/2017 07:56, Hamlin Li wrote:
> Hi Roger,
>
> Thank you for reviewing, please check new webrev: 
> http://cr.openjdk.java.net/~mli/8172347/webrev.01/
>
> Thank you
> -Hamlin
>
> On 2017/1/6 12:56, Roger Riggs wrote:
>> Hi Hamlin,
>>
>> Yes, that looks better.
>>
>> On the comments, use the normal javadoc comment conventions for any 
>> public API.
>> @param @return, @throw, etc.
>>
>> I think comments should be direct about what the function does. It 
>> does not need
>> to explain why so much.  Or if so, later and in a separate 
>> paragraph;  when reading
>> the most important information should be first.
>>
>> Thanks, Roger
>>
>>
>> On 1/6/2017 4:59 AM, Hamlin Li wrote:
>>>
>>> On 2017/1/6 6:15, Roger Riggs wrote:
>>>> Hi Hamlin,
>>>>
>>>> There are too many issues being mixed together...
>>>>
>>>> Comments on B) RegistryImpl:
>>>>
>>>> Refactoring of RegistryImpl Main should be clean and clearly 
>>>> separated.
>>> Hi Roger,
>>>
>>> Thank you for reviewing.
>>> Not sure if I understood you correctly, I created a new bug to track 
>>> refactoring of RegistryImpl, I will send out separate reviews for 
>>> AltSecurityManager in JDK-8172314, JDK-8030175. Please let me know 
>>> if you did not mean it.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8172347
>>> webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.00/, fix all 
>>> the below points.
>>>
>>> Thank you
>>> -Hamlin
>>>>
>>>> 365: static void RegistryImpl run():
>>>>
>>>> -  The signature of run should be run(int port) and documented as 
>>>> needing to be run in its
>>>>    own thread since it changes Thread context classloader and that 
>>>> it sets a securityManager.
>>>>    Leave it to main to parse and choose a port number.
>>>>
>>>> -  The comments should be functional as to the purpose of the code 
>>>> and not referencing a particular bug.
>>>>    (Regardless of prior example).
>>>>
>>>>  - The comment about getting the exact port is out of place because 
>>>> the port number cannot be
>>>>    retrieved from the returned RegistryImpl.  IF that's why this 
>>>> refactoring is needed, then
>>>>    perhaps there should be a getPort method that extracts it from 
>>>> the created UnicastServerRef.
>>>>
>>>> 423: static void main(String[] args):
>>>>
>>>>  - Parsing of args should be left in main(); avoiding the question 
>>>> about why NumberFormat is handled.
>>>>
>>>>  - Either main or run should set a security manager; but not both.
>>>>
>>>> Roger
>>>>
>>>>
>>>>
>>>>
>>>> On 1/4/2017 10:21 PM, Hamlin Li wrote:
>>>>> Hi Roger,
>>>>>
>>>>> Thank you for reviewing, please check comments inline.
>>>>>
>>>>>
>>>>> On 2017/1/5 4:18, Roger Riggs wrote:
>>>>>> Hi Hamlin,
>>>>>>
>>>>>> The original issue with timeout may be due to heavily loaded 
>>>>>> systems and short timeouts.
>>>>>> 15 sec is not enough on an overloaded system to wait for a 
>>>>>> process to start and then die.
>>>>>>
>>>>>> There is no indication in this issue about port-in-use; that 
>>>>>> would be a different issue.
>>>>> Agree, I put 2 fixes in one patch together as there is no port in 
>>>>> use issue reported, but by reviewing the code, potential port in 
>>>>> use issue could happen some time in the future.
>>>> Best to keep 1-1 to avoid complicating the discussion and 
>>>> increasing code complexity.
>>>>>>
>>>>>>
>>>>>> Common comments to both A and B.
>>>>>>
>>>>>> I'll need more time to look at B; it would be cleaner to use A if 
>>>>>> it can address the issue.
>>>>>> The alternative is to duplicate the code in run() in the 
>>>>>> TestLibrary and not modify the RegistryImpl.
>>>>> I prefer B, because
>>>>>   1. Although A looks cleaner but B is simulating more like 
>>>>> rmiregistry.
>>>>>   2. There are some other issue for example JDK-7146543, 
>>>>> JDK-8030950, JDK-8038772, fix based on version B works well, but 
>>>>> fix based on version A fails.
>>>>>   3. Impact of RegistryImpl modification is minimal. ( May we 
>>>>> could make Registry run(String args[]) private and access it in 
>>>>> test by reflection? )
>>>>>   4. Although it's simple to duplicate the code in run() in the 
>>>>> TestLibrary, but seems it's not a good design choice. (let's call 
>>>>> it version C.)
>>>>>   5. For JDK-8170728, the fix will need to modify 
>>>>> sun.rmi.registry.RegistryImpl anyway.
>>>>>
>>>>>
>>>>> Thank you for detailed review comments below.
>>>>> As we have several options, I will wait for your further comments 
>>>>> on choice of version A/B/C, then send out new webrev, hope I only 
>>>>> need to send out one version :-).
>>>>>
>>>>> Thank you
>>>>> -Hamlin
>>>>>>
>>>>>>
>>>>>> JavaVM:
>>>>>>  - Document the new methods.
>>>>>>
>>>>>> Line 232: Document the exception that may be thrown from exitValue.
>>>>>>
>>>>>>
>>>>>> RMID:
>>>>>> Line 204, 222: when adding new functions to the test library 
>>>>>> please add documentation for the methods.
>>>>>> There are now many variations of the methods that differ only by 
>>>>>> the number arguments.
>>>>>> It would be better if the name included some hint as to the 
>>>>>> additional functionality.
>>>>>>
>>>>>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>>>>>
>>>>>> REGISTRY:
>>>>>>   - Document the new methods.
>>>>>>
>>>>>>   - The name should be more indicative of its function and should 
>>>>>> NOT be all caps;  RMID is an acronym where the caps make sense.
>>>>>>
>>>>>>   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating 
>>>>>> code to wait for the subprocess.
>>>>>>
>>>>>>   - If the subprocesses are in an unknown state it would be 
>>>>>> useful to print diagnostic info from the subprocess before 
>>>>>> terminating.
>>>>>>     Line 106:
>>>>>>
>>>>>>  - Line 124:
>>>>>>  - I think I would have promoted the shutdown method to JavaVM 
>>>>>> instead of creating a new cleanup method
>>>>>>    to keep the code simpler.
>>>>>>
>>>>>>    ** The cleanup method never calls super.cleanup() so the 
>>>>>> process is never destroyed!.
>>>>>>
>>>>>> AltSecurityManager.java:
>>>>>>
>>>>>>  - Line 61: the empty constructor can be removed entirely.
>>>>>>
>>>>>>  - Line 80: change the message to say the exception did not occur.
>>>>>>     As written it implies it may have occurred but was not caught.
>>>>>>
>>>>>>  - Line 86: typo "a unexpected" -> "an unexpected"
>>>>>>
>>>>>> - Line 90: remove the printStackTrace; it is not useful and is a 
>>>>>> red flag in .jtr files
>>>>>>
>>>>>>  - Line 125: I don't see that cleanup is better than destroy; If 
>>>>>> there are doubts about destroy
>>>>>>    then destroy should be fixed not avoided.
>>>>>>
>>>>>> Roger
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>>>>>> Would you please review the below patches?
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>>>>>> webrev (version A): 
>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>>>>>> webrev (version B): 
>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>>>>>>
>>>>>>>
>>>>>>> There are 2 versions to be reviewed.
>>>>>>>
>>>>>>> In version A, just use RegistryRunner to replace rmiregistry.
>>>>>>> In version B, refactor sun.rmi.registry.RegistryImpl to improve 
>>>>>>> the testability of RMI code, and create/use RMIRegistryRunner to 
>>>>>>> simulate rmiregistry.
>>>>>>>
>>>>>>> Thank you
>>>>>>> -Hamlin
>>>>>>
>>>>>
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Mon Jan  9 15:58:18 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 9 Jan 2017 07:58:18 -0800
Subject: Review Request JDK-8170772: ResourceBundle improper caching
	causes tools/javadoc tests intermittently
In-Reply-To: <88089e10-bcb6-cec8-d33f-3324207be47c@gmail.com>
References: <E9A3FE4E-D5CD-41ED-BA14-7311C99180D8@oracle.com>
	<887b1af3-decf-5a9e-6577-4b2781e8183c@gmail.com>
	<0f17689a-84a6-7508-6802-6f440de93161@oracle.com>
	<0759b853-d076-f7ab-28bc-4623615f71c1@oracle.com>
	<8295D13D-74F9-4119-98FB-D43BD1C6012B@oracle.com>
	<88089e10-bcb6-cec8-d33f-3324207be47c@gmail.com>
Message-ID: <93192178-5124-0c02-dcec-99e91e0cfe24@oracle.com>

On 1/6/17 10:57 PM, Peter Levart wrote:
> Hi Mandy, Naoto,
>
> I think Mandy's original proposal has been pushed, but the
> simplification of CacheKey is still open:
>
> https://bugs.openjdk.java.net/browse/JDK-8171139
>
> as well as the re-examination of clearCahe methods:
>
> https://bugs.openjdk.java.net/browse/JDK-8171140
>
> Were you thinking of those two issues Naoto?

Yes. That was my intent.

Naoto

>
>
> Regards, Peter
>
> On 01/07/2017 05:41 AM, Mandy Chung wrote:
>> Thanks for looking through this, Naoto.
>>
>> This has been pushed and resolved in jdk-9+149.
>>
>> Mandy
>>
>>> On Jan 6, 2017, at 3:46 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>
>>> Hi Peter, Daniel, Mandy,
>>>
>>> Sorry for the late reply, and thanks for the patch. I went through the patch and I did not find any problem with it. Would you want to proceed with this?
>>>
>>> Naoto
>>>
>>> On 12/13/16 2:14 AM, Daniel Fuchs wrote:
>>>> Hi Peter,
>>>>
>>>> This is a bold proposal, I would be frightened to touch at
>>>> this code :-)
>>>>
>>>> Good observations about the simplifications induced by taking
>>>> the caller's module as part of the cache key (in particular
>>>> getting rid of RBClassLoader.INSTANCE).
>>>>
>>>> I have imported your patch (had to fight a bit because it
>>>> includes changes that had already been pushed) and sent it
>>>> through our internal testing system - and haven't seen any
>>>> new failures that seemed linked to resource bundles.
>>>>
>>>> A few observations concerning CacheKey - if I'm not mistaken
>>>> most of the key variables could be made final (in particular
>>>> callerRef and moduleRef) - and since they are required to be
>>>> non null - then getModule() and getCallerModule() could be
>>>> simplified. Not sure whether  making those final might require
>>>> to add a copy constructor to support clone() though?
>>>> It seems CacheKey::setName is never called - but it's probably
>>>> safer to keep it (maybe it's called by tests).
>>>>
>>>> I am not an expert of ResourceBundle - though I had to dive
>>>> into it a few times due it's use in logging. Hopefully others
>>>> will jump on this.
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>> On 12/12/16 15:10, Peter Levart wrote:
>>>>> Hi Mandy (once again for the list),
>>>>>
>>>>> On 12/09/2016 05:49 PM, Mandy Chung wrote:
>>>>>> Naoto,  > > Can you review this ResourceBundle caching fix?  The
>>>>>> caller module
>>>>>> may be different than the specified module to >
>>>>> ResourceBundle.getBundle(String, Module) method and it should also >
>>>>> part of the cache key. > >
>>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170772/webrev.00/ > >
>>>>> The new test shows the issue there and the first loading of the >
>>>>> resource bundle of a specific module (success or fail) will be put in >
>>>>> the cache and used by subsequent calls. > > Thanks Mandy
>>>>>
>>>>>
>>>>> I think that now callerModule is part of CacheKey, caching logic could
>>>>> be simplified. 1st the getBundleImpl method in line 1629:
>>>>>
>>>>>    private static ResourceBundle getBundleImpl(String baseName,
>>>>>                                                Locale locale,
>>>>>                                                Class<?> caller,
>>>>>                                                ClassLoader loader,
>>>>>                                                Control control) {
>>>>>        if (caller != null && caller.getModule().isNamed()) {
>>>>>            Module module = caller.getModule();
>>>>>            ClassLoader ml = getLoader(module);
>>>>>            // get resource bundles for a named module only
>>>>>            // if loader is the module's class loader
>>>>>            if (loader == ml || (ml == null && loader ==
>>>>> RBClassLoader.INSTANCE)) {
>>>>>                return getBundleImpl(module, module, loader, baseName,
>>>>> locale, control);
>>>>>            }
>>>>>        }
>>>>>        // find resource bundles from unnamed module
>>>>>        Module unnamedModule = loader != null
>>>>>            ? loader.getUnnamedModule()
>>>>>            : ClassLoader.getSystemClassLoader().getUnnamedModule();
>>>>>
>>>>>        if (caller == null) {
>>>>>            throw new InternalError("null caller");
>>>>>        }
>>>>>
>>>>>        Module callerModule = caller.getModule();
>>>>>        return getBundleImpl(callerModule, unnamedModule, loader,
>>>>> baseName, locale, control);
>>>>>    }
>>>>>
>>>>>
>>>>> ... could be cleaned up a bit without changing its semantics:
>>>>>
>>>>>    private static ResourceBundle getBundleImpl(String baseName,
>>>>>                                                Locale locale,
>>>>>                                                Class<?> caller,
>>>>>                                                ClassLoader loader,
>>>>>                                                Control control) {
>>>>>        if (caller == null) {
>>>>>            throw new InternalError("null caller");
>>>>>        }
>>>>>        Module callerModule = caller.getModule();
>>>>>
>>>>>        if (callerModule.isNamed()) {
>>>>>            ClassLoader ml = getLoader(callerModule);
>>>>>            // get resource bundles for a named module only
>>>>>            // if loader is the module's class loader
>>>>>            if (loader == ml || (ml == null && loader ==
>>>>> RBClassLoader.INSTANCE)) {
>>>>>                return getBundleImpl(callerModule, callerModule, loader,
>>>>> baseName, locale, control);
>>>>>            }
>>>>>        }
>>>>>
>>>>>        // find resource bundles from unnamed module
>>>>>        Module unnamedModule = loader != null
>>>>>            ? loader.getUnnamedModule()
>>>>>            : ClassLoader.getSystemClassLoader().getUnnamedModule();
>>>>>
>>>>>        return getBundleImpl(callerModule, unnamedModule, loader,
>>>>> baseName, locale, control);
>>>>>    }
>>>>>
>>>>>
>>>>> Next, I checked all callers of this method (there are 3 of them in
>>>>> lines: 1367, 1589, 1615) and all of them guard against passing a null
>>>>> 'loader' to this method:
>>>>>
>>>>>    @CallerSensitive
>>>>>    public static ResourceBundle getBundle(String baseName, Locale
>>>>> locale,
>>>>>                                           ClassLoader loader)
>>>>>    {
>>>>>        if (loader == null) {
>>>>>            throw new NullPointerException();
>>>>>        }
>>>>>        Class<?> caller = Reflection.getCallerClass();
>>>>>        return getBundleImpl(baseName, locale, caller, loader,
>>>>> getDefaultControl(caller, baseName));
>>>>>    }
>>>>>
>>>>> ...
>>>>>
>>>>>    @CallerSensitive
>>>>>    public static ResourceBundle getBundle(String baseName, Locale
>>>>> targetLocale,
>>>>>                                           ClassLoader loader, Control
>>>>> control) {
>>>>>        if (loader == null || control == null) {
>>>>>            throw new NullPointerException();
>>>>>        }
>>>>>        Class<?> caller = Reflection.getCallerClass();
>>>>>        checkNamedModule(caller);
>>>>>        return getBundleImpl(baseName, targetLocale, caller, loader,
>>>>> control);
>>>>>    }
>>>>>
>>>>> ...
>>>>>
>>>>>    private static ResourceBundle getBundleImpl(String baseName,
>>>>>                                                Locale locale,
>>>>>                                                Class<?> caller,
>>>>>                                                Control control) {
>>>>>        return getBundleImpl(baseName, locale, caller,
>>>>> getLoader(caller), control);
>>>>>    }
>>>>>
>>>>>    private static ClassLoader getLoader(Class<?> caller) {
>>>>>        ClassLoader cl = caller == null ? null : caller.getClassLoader();
>>>>>        if (cl == null) {
>>>>>            // When the caller's loader is the boot class loader, cl is
>>>>> null
>>>>>            // here. In that case, ClassLoader.getSystemClassLoader() may
>>>>>            // return the same class loader that the application is
>>>>>            // using. We therefore use a wrapper ClassLoader to create a
>>>>>            // separate scope for bundles loaded on behalf of the Java
>>>>>            // runtime so that these bundles cannot be returned from the
>>>>>            // cache to the application (5048280).
>>>>>            cl = RBClassLoader.INSTANCE;
>>>>>        }
>>>>>        return cl;
>>>>>    }
>>>>>
>>>>>
>>>>> Therefore the above method can be simplified further:
>>>>>
>>>>>    private static ResourceBundle getBundleImpl(String baseName,
>>>>>                                                Locale locale,
>>>>>                                                Class<?> caller,
>>>>>                                                ClassLoader loader,
>>>>>                                                Control control) {
>>>>>        if (caller == null) {
>>>>>            throw new InternalError("null caller");
>>>>>        }
>>>>>        if (loader == null) {
>>>>>            throw new InternalError("null loader");
>>>>>        }
>>>>>        Module callerModule = caller.getModule();
>>>>>
>>>>>        if (callerModule.isNamed()) {
>>>>>            ClassLoader ml = getLoader(callerModule);
>>>>>            // get resource bundles for a named module only
>>>>>            // if loader is the module's class loader
>>>>>            if (loader == ml || (ml == null && loader ==
>>>>> RBClassLoader.INSTANCE)) {
>>>>>                return getBundleImpl(callerModule, callerModule, loader,
>>>>> baseName, locale, control);
>>>>>            }
>>>>>        }
>>>>>
>>>>>        // find resource bundles from unnamed module
>>>>>        Module unnamedModule = loader.getUnnamedModule();
>>>>>        return getBundleImpl(callerModule, unnamedModule, loader,
>>>>> baseName, locale, control);
>>>>>    }
>>>>>
>>>>>
>>>>>
>>>>> ...here we can see that (callerModule, module, loader) triple passed to
>>>>> downstream getBundleImpl is either (callerModule, callerModule,
>>>>> callerModule's class loader) - with a RBClassLoader.INSTANCE substitute
>>>>> for bootstrap class loader, when the callerModule is a named module and
>>>>> requested loader is the callerModule's loader, or (callerModule,
>>>>> loader's unnamed module, loader) when loader is not callerModule's
>>>>> loader or callerModule is unnamed.
>>>>>
>>>>> other two callers of the downstream getBundleImpl are the
>>>>> JavaUtilResourceBundleAccess method:
>>>>>
>>>>>                public ResourceBundle getBundle(String baseName, Locale
>>>>> locale, Module module) {
>>>>>                    // use the given module as the caller to bypass the
>>>>> access check
>>>>>                    return getBundleImpl(module, module,
>>>>> getLoader(module),
>>>>>                                         baseName, locale,
>>>>> Control.INSTANCE);
>>>>>                }
>>>>>
>>>>> ...which is used in logging - the module passed here can be either named
>>>>> or unnamed;
>>>>>
>>>>> ... and a method invoked from new JDK 9 public getBundle() methods
>>>>> taking explicit Module argument:
>>>>>
>>>>>    private static ResourceBundle getBundleFromModule(Class<?> caller,
>>>>>                                                      Module module,
>>>>>                                                      String baseName,
>>>>>                                                      Locale locale,
>>>>>                                                      Control control) {
>>>>>        Objects.requireNonNull(module);
>>>>>        Module callerModule = caller.getModule();
>>>>>        if (callerModule != module) {
>>>>>            SecurityManager sm = System.getSecurityManager();
>>>>>            if (sm != null) {
>>>>>                sm.checkPermission(GET_CLASSLOADER_PERMISSION);
>>>>>            }
>>>>>        }
>>>>>        return getBundleImpl(callerModule, module, getLoader(module),
>>>>> baseName, locale, control);
>>>>>    }
>>>>>
>>>>> In all of these cases, the loader passed to downstream getBundleImpl is
>>>>> the module's (2nd argument 'module') class loader (or a special
>>>>> substitute for bootstrap loader).
>>>>>
>>>>> Considering all this, I think class loader is not needed any more as the
>>>>> CacheKey component. The distinction between scopes of system class
>>>>> loader (when the caller is not a bootstrap class) and the
>>>>> RBClassLoader.INSTANCE (when the caller is the bootstrap class) is also
>>>>> not needed any more since the callerModule is now part of CacheKey.
>>>>>
>>>>> I modified your patch (just ResourceBundle.java) to include all these
>>>>> simplifications and some cleanup:
>>>>>
>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.01/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This modification also contains a re-interpretation of clearCache()
>>>>> methods. Both existing clearCahe() methods together with the additional
>>>>> @since 9 method contain the following wording:
>>>>>
>>>>> "Removes all resource bundles from the cache that have been loaded by
>>>>> the caller's / given module..."
>>>>>
>>>>> What does it meant for a bundle to be loaded *by* some module? I think
>>>>> the right interpretation is that this is the caller module (the one that
>>>>> invokes ResourceBundle.getBundle() method). The module that calls
>>>>> ResourceBundle.getBundle() is usually also the module that is
>>>>> responsible for clearing the cache of entries that were cached by its
>>>>> loading requests, isn't it?
>>>>>
>>>>> So, what do you think?
>>>>>
>>>>> Regards, Peter
>>>>>
>

From mandy.chung at oracle.com  Mon Jan  9 17:02:35 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 9 Jan 2017 09:02:35 -0800
Subject: Review Request JDK-8170772: ResourceBundle improper caching
	causes tools/javadoc tests intermittently
In-Reply-To: <93192178-5124-0c02-dcec-99e91e0cfe24@oracle.com>
References: <E9A3FE4E-D5CD-41ED-BA14-7311C99180D8@oracle.com>
	<887b1af3-decf-5a9e-6577-4b2781e8183c@gmail.com>
	<0f17689a-84a6-7508-6802-6f440de93161@oracle.com>
	<0759b853-d076-f7ab-28bc-4623615f71c1@oracle.com>
	<8295D13D-74F9-4119-98FB-D43BD1C6012B@oracle.com>
	<88089e10-bcb6-cec8-d33f-3324207be47c@gmail.com>
	<93192178-5124-0c02-dcec-99e91e0cfe24@oracle.com>
Message-ID: <27A7FB68-8AC6-4EC5-A732-41284CB2F3FC@oracle.com>


> On Jan 9, 2017, at 7:58 AM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> On 1/6/17 10:57 PM, Peter Levart wrote:
>> Hi Mandy, Naoto,
>> 
>> I think Mandy's original proposal has been pushed, but the
>> simplification of CacheKey is still open:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8171139
>> 
>> as well as the re-examination of clearCahe methods:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8171140
>> 
>> Were you thinking of those two issues Naoto?
> 
> Yes. That was my intent.

OK.  JDK-8171139 and JDK-8171140 are currently assigned to you.  Do you expect Peter to take them?  In either case, please post a new thread for the code review for these issues.

Mandy



From naoto.sato at oracle.com  Mon Jan  9 17:21:03 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 9 Jan 2017 09:21:03 -0800
Subject: Review Request JDK-8170772: ResourceBundle improper caching
	causes tools/javadoc tests intermittently
In-Reply-To: <27A7FB68-8AC6-4EC5-A732-41284CB2F3FC@oracle.com>
References: <E9A3FE4E-D5CD-41ED-BA14-7311C99180D8@oracle.com>
	<887b1af3-decf-5a9e-6577-4b2781e8183c@gmail.com>
	<0f17689a-84a6-7508-6802-6f440de93161@oracle.com>
	<0759b853-d076-f7ab-28bc-4623615f71c1@oracle.com>
	<8295D13D-74F9-4119-98FB-D43BD1C6012B@oracle.com>
	<88089e10-bcb6-cec8-d33f-3324207be47c@gmail.com>
	<93192178-5124-0c02-dcec-99e91e0cfe24@oracle.com>
	<27A7FB68-8AC6-4EC5-A732-41284CB2F3FC@oracle.com>
Message-ID: <386e121c-577e-1f6c-75d7-0e38334680e4@oracle.com>

Either case is fine with me. I have the patch and wrote some additional 
test cases.

Naoto

On 1/9/17 9:02 AM, Mandy Chung wrote:
>
>> On Jan 9, 2017, at 7:58 AM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>
>> On 1/6/17 10:57 PM, Peter Levart wrote:
>>> Hi Mandy, Naoto,
>>>
>>> I think Mandy's original proposal has been pushed, but the
>>> simplification of CacheKey is still open:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8171139
>>>
>>> as well as the re-examination of clearCahe methods:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8171140
>>>
>>> Were you thinking of those two issues Naoto?
>>
>> Yes. That was my intent.
>
> OK.  JDK-8171139 and JDK-8171140 are currently assigned to you.  Do you expect Peter to take them?  In either case, please post a new thread for the code review for these issues.
>
> Mandy
>
>

From lance.andersen at oracle.com  Mon Jan  9 17:23:09 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 9 Jan 2017 12:23:09 -0500
Subject: [9] RFR: 8159058: SAXParseException when sending soap message
In-Reply-To: <81835be1-37dc-68d3-b033-2a1a468a79cd@oracle.com>
References: <81835be1-37dc-68d3-b033-2a1a468a79cd@oracle.com>
Message-ID: <6A55229D-FDE0-4D0C-BF93-289650DFADA3@oracle.com>

Hi Aleks,

The changes seem reasonable.  I am assuming that the JAXWS/SAAJ standalone tcks were run against the standalone RIs by the jaxws team?  The JCK tests are a variation of the standalone tests so might be good to sanity check if not already done.

Best
Lance
> On Jan 9, 2017, at 4:34 AM, Aleks Efimov <aleksej.efimov at oracle.com> wrote:
> 
> Hi,
> 
> Please, help to review the JDK9 fix for the issue [1] in processing of default namespace attribute with empty values (xmlns="") by SAAJ implementation:
> http://cr.openjdk.java.net/~aefimov/8159058/9/00
> 
> Same fix was already integrated into JAXWS-RI and SAAJ-RI standalone projects. These changes were backported from standalone projects with additional package names changes and regression test addition. Due to urgency of this issue I would like to integrate this change into JDK9 separately from jaxws-ri synchronization process.
> 
> The following test sets shows no related/new failures: JDK regression tests, JCK jaxws/b tests, standalone saaj-ri tck unit tests.
> 
> With Best Regards,
> Aleksej
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8159058
> 

 <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 huizhe.wang at oracle.com  Mon Jan  9 17:38:30 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 9 Jan 2017 09:38:30 -0800
Subject: RFR (JAXP) 8171243 : CatalogManager.catalogResolver throws
	FileSystemNotFoundException with jar
Message-ID: <3cfcba76-6436-92ec-5174-747318fa9ff5@oracle.com>

Hi,

The current Catalog API accepts file paths or URIs in a form of String 
to create Catalog or CatalogResolver in an effort to maintain 
consistency with the old Catalog API and other existing processors. 
However, that also introduced an ambiguity in the API, which is unwanted 
for a new API in Java SE 9.

Please review the changes.
In jaxp repo:
http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/

In jaxws repo:
http://cr.openjdk.java.net/~joehw/jdk9/8171243_jaxws/webrev/

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

Thanks,
Joe


From daniel.fuchs at oracle.com  Mon Jan  9 18:02:40 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 9 Jan 2017 18:02:40 +0000
Subject: RFR (JAXP) 8171243 : CatalogManager.catalogResolver throws
	FileSystemNotFoundException with jar
In-Reply-To: <3cfcba76-6436-92ec-5174-747318fa9ff5@oracle.com>
References: <3cfcba76-6436-92ec-5174-747318fa9ff5@oracle.com>
Message-ID: <e2d440d1-6a08-b4df-bc2c-507419f38eea@oracle.com>

Hi Joe,

BaseEntry.java:

  213      * @return The URI created from the specified uri
  214      * @throws IllegalArgumentException if the specified uri is null,
  215      * or a URL can not be created based on the specified base and uri
  216      */
  217     URL verifyURI(String arg, URL base, String uri) {
  218         CatalogMessages.reportNPEOnNull(arg, uri);

line 214 seems to contradict line 218...

What is the consequence of only allowing absolute URIs?
Is it something that might cause backward compatibility issues?

best regards,

-- daniel


On 09/01/17 17:38, huizhe wang wrote:
> Hi,
>
> The current Catalog API accepts file paths or URIs in a form of String
> to create Catalog or CatalogResolver in an effort to maintain
> consistency with the old Catalog API and other existing processors.
> However, that also introduced an ambiguity in the API, which is unwanted
> for a new API in Java SE 9.
>
> Please review the changes.
> In jaxp repo:
> http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/
>
> In jaxws repo:
> http://cr.openjdk.java.net/~joehw/jdk9/8171243_jaxws/webrev/
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8171243
>
> Thanks,
> Joe
>


From xueming.shen at oracle.com  Mon Jan  9 18:21:20 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 09 Jan 2017 10:21:20 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
Message-ID: <5873D4A0.204@oracle.com>

Hi,

Please review the following proposed changes for jar tool

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

(1) move the "packages" and "jarEntries" from "global" to "local", and 
only collect
the  info when needed (if there is a module-info and we indeed need 
these info
to update the module-info.class). The goal is to avoid/reduce any 
possible performance
regression/impact to those"non-module" jar file creation and update 
operations.
The proposed implementation now collects such info after "expand()" for 
"creation"
if there is "module-info.class". For "update" it is done during the 
"updating"

(2) consolidate all "validation" related implementation into 
Validator.java. The
"concealedPkgs" now is generated from the base 'module-info.class" from the
resulting temporary jar file directly, instead of the 
"module-info.class" binary during
the creation/update. Again, the reasoning is that the "validation" is 
only needed
for the mr module jar (for now), it is not needed for a "normal" module 
jar file.
A clear separation helps reducing the performance impact and improving the
maintainability.

(3) remove the "checkModuleInfos" logic/implementation, which 
incorrectly enforces
the restriction such as
     a) there must always be, at least, a root module-info, when there 
is an entry that
         has a name ended up with "module-info.class" in the jar file.
     b) module-info.class file can only be at root or a versioned 
folder. (why I can't jar
         a foo.jar that has a entry module-info.class at an arbitrary 
place?)

(4) consolidate and share the "updateModuleInfo()" for both creation and 
update.

(5) no longer always copy the "mainClass" and "version" attributes from 
the root
module-info.class into the corresponding versioned module-info.class 
"silently"
(in extendedInfoBytes()). Instead, the difference between the root 
module-info.class
and its versioned copy is checked, jar fails if there is inconsistence.

(6) clean up the Entry class and the expand() implementation. It appears 
the Entry
class might not be absolutely necessary, but I keep it as is for now.

(7) build the jar with -XDstringConcat=inline flag.

thanks,
Sherman

From huizhe.wang at oracle.com  Mon Jan  9 18:26:26 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 9 Jan 2017 10:26:26 -0800
Subject: RFR (JAXP) 8171243 : CatalogManager.catalogResolver throws
	FileSystemNotFoundException with jar
In-Reply-To: <e2d440d1-6a08-b4df-bc2c-507419f38eea@oracle.com>
References: <3cfcba76-6436-92ec-5174-747318fa9ff5@oracle.com>
	<e2d440d1-6a08-b4df-bc2c-507419f38eea@oracle.com>
Message-ID: <9cff6a4d-3115-555c-b827-762045001335@oracle.com>


On 1/9/2017 10:02 AM, Daniel Fuchs wrote:
> Hi Joe,
>
> BaseEntry.java:
>
>  213      * @return The URI created from the specified uri
>  214      * @throws IllegalArgumentException if the specified uri is 
> null,
>  215      * or a URL can not be created based on the specified base 
> and uri
>  216      */
>  217     URL verifyURI(String arg, URL base, String uri) {
>  218         CatalogMessages.reportNPEOnNull(arg, uri);

Good catch. I'm changing the docs to:
      * @throws NullPointerException if the specified uri is null
      * @throws IllegalArgumentException if a URL can not be created 
based on
      * the specified base and uri

NPE is required for the consistency throughout the API for handling null 
input.

>
> line 214 seems to contradict line 218...
>
> What is the consequence of only allowing absolute URIs?
> Is it something that might cause backward compatibility issues?

While the top interfaces requires that the URIs must be absolute, they 
can prevent relative URIs from happening in a catalog file, which is 
allowed by the Catalog Standard.

Best,
Joe

>
> best regards,
>
> -- daniel
>
>
> On 09/01/17 17:38, huizhe wang wrote:
>> Hi,
>>
>> The current Catalog API accepts file paths or URIs in a form of String
>> to create Catalog or CatalogResolver in an effort to maintain
>> consistency with the old Catalog API and other existing processors.
>> However, that also introduced an ambiguity in the API, which is unwanted
>> for a new API in Java SE 9.
>>
>> Please review the changes.
>> In jaxp repo:
>> http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/
>>
>> In jaxws repo:
>> http://cr.openjdk.java.net/~joehw/jdk9/8171243_jaxws/webrev/
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8171243
>>
>> Thanks,
>> Joe
>>
>


From martinrb at google.com  Mon Jan  9 18:43:44 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Jan 2017 10:43:44 -0800
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
	<d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
Message-ID: <CA+kOe09tSLRR_DRDMf7fzQGRpf9uG4RMm=srKGWEbU3FSTaTbA@mail.gmail.com>

Relatedly, I'm writing whitebox jtreg tests and would like to use
VarHandles to access internal data structures.
Because I have:

 * @modules java.base/java.util.concurrent:open

I can use reflection with setAccessible to obtain a usable Field, but if I
try to turn that into a VarHandle I get:

        Field f = ConcurrentLinkedQueue.class.getDeclaredField("head");
        f.setAccessible(true);
        VarHandle v = java.lang.invoke.MethodHandles.lookup()
            .unreflectVarHandle(f);

 java.lang.IllegalAccessException: member is private to package:
java.util.concurrent.ConcurrentLinkedQueue.head/java.util.concurrent.ConcurrentLinkedQueue$Node/getField,
from WhiteBox (unnamed module @7a187f14)

It seems wrong to have this sort of mismatch - setAccessible works, but the
strictly more powerful VarHandles remain unobtainable.

I happen to have a workaround, but I don't see a general solution for
whitebox testing.

From uschindler at apache.org  Mon Jan  9 18:49:44 2017
From: uschindler at apache.org (Uwe Schindler)
Date: Mon, 09 Jan 2017 18:49:44 +0000
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <CA+kOe09tSLRR_DRDMf7fzQGRpf9uG4RMm=srKGWEbU3FSTaTbA@mail.gmail.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
	<d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
	<CA+kOe09tSLRR_DRDMf7fzQGRpf9uG4RMm=srKGWEbU3FSTaTbA@mail.gmail.com>
Message-ID: <CE6B1E4C-565A-4EAC-98F8-EC18E6F09F79@apache.org>

Hi,

It's also inconsistent, because the same type of code works with MethodHandles. If you make something accessible (and succeed doing this), it uses some special internal lookup that has no restrictions for unreflect. 

Uwe

Am 9. Januar 2017 19:43:44 MEZ schrieb Martin Buchholz <martinrb at google.com>:
>Relatedly, I'm writing whitebox jtreg tests and would like to use
>VarHandles to access internal data structures.
>Because I have:
>
> * @modules java.base/java.util.concurrent:open
>
>I can use reflection with setAccessible to obtain a usable Field, but
>if I
>try to turn that into a VarHandle I get:
>
>        Field f = ConcurrentLinkedQueue.class.getDeclaredField("head");
>        f.setAccessible(true);
>        VarHandle v = java.lang.invoke.MethodHandles.lookup()
>            .unreflectVarHandle(f);
>
> java.lang.IllegalAccessException: member is private to package:
>java.util.concurrent.ConcurrentLinkedQueue.head/java.util.concurrent.ConcurrentLinkedQueue$Node/getField,
>from WhiteBox (unnamed module @7a187f14)
>
>It seems wrong to have this sort of mismatch - setAccessible works, but
>the
>strictly more powerful VarHandles remain unobtainable.
>
>I happen to have a workaround, but I don't see a general solution for
>whitebox testing.

From paul.sandoz at oracle.com  Mon Jan  9 19:09:08 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 9 Jan 2017 11:09:08 -0800
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
	<d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
Message-ID: <3D01F437-6CD5-4CE7-9816-9423A284D27D@oracle.com>


> On 9 Jan 2017, at 05:36, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 05/01/2017 19:01, Paul Sandoz wrote:
> 
>> Hi,
>> 
>> I encountered some circularity issues with security manager and VarHandles, specifically when attempting to use the new MethodHandles.privateLookupIn, so say ThreadLocalRandom has access to fields in Thread [1].
>> 
>> When running with a security manager ThreadLocalRandom clinit depends on various security stuff that eventually depends on ConcurrentSkipListMap which depends on ThreadLocalRandom, whose static state has not been fully initialzed.
>> 
>> The current security permission check in MethodHandles.privateLookupIn may be a too blunt and possibly should be refined along similar lines to Lookup.checkSecurityManager e.g. no check should be needed for classes within the same module (since this is a refined/controlled/principled form of setAccessible, plus no pounding on final fields). That would solve the problem in this case. But, the general point remains, and i have not thought too hard if there are other ways to solve this.
>> 
> This would mean inconsistency with setAccessible where you need this blunt permission when suppressing access. Also I think Lookup.checkSecurityManager will do different checks when you don't have a full power lookup so it would mean adjusting the privateLookupIn.

Some adjustment would definitely be required, the perhaps the simplest solution is not to perform a security check if within the same module?


> 
> I wonder if we could trigger more of this initialization in initPhase3 before the security manager is set. I'm sure TLR::current will do but that might be too much to do at startup.
> 

Yes, moving it within that phase may anyway tickle a circularity for other reasons, we have been bitten before for different reasons when the java.util.secureRandomSeed property is set to true.

Paul.

From huaming.li at oracle.com  Mon Jan  9 19:24:16 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Mon, 9 Jan 2017 11:24:16 -0800
Subject: RFR of JDK-8172347: Refactoring
	src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to
	improve testability of rmiregistry
In-Reply-To: <48bdbd18-f420-e526-2278-0506d02ee443@oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
	<0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
	<5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
	<6432c6de-af93-5224-f848-8e2e8f0f7c9f@oracle.com>
	<888af0b3-24ee-826a-7449-f3eece8ab9f8@Oracle.com>
	<2eecc91f-019a-024d-a48f-27930137cb09@oracle.com>
	<48bdbd18-f420-e526-2278-0506d02ee443@oracle.com>
Message-ID: <e2275242-d198-36da-868f-c0c07fb54922@oracle.com>

Hi Mark,

Thank you for reviewing, please check comments inline, and new webrev: 
http://cr.openjdk.java.net/~mli/8172347/webrev.02/.

Thank you
-Hamlin

On 2017/1/9 6:36, Mark Sheppard wrote:
> Hi Hamlin,
>
> If I read the changes correctly, there would appear to be a side 
> effect of your refactor extract method "run", such that the static 
> member variable
> registry is no longer set in the main method, and is set in the run 
> method ? Thus, invoking run multiple times (, whether that is intended 
> or not,) will
> see the registry static member variable overwritten, for each call. 
> While the current implementation that will occur once only within the 
> main method.
> So, what's the desired semantics for multiple "run" calls?
modified, assign "registry" it in main.
>
>  A "run" method is synonymous with Runnable interface, even though 
> this run method has a different signature, it's better
> to help us unwary avoid confusion!
> Also the run method instantiates and returns a RegistryImpl, thus 
> exhibiting factory method characteristics.
> As such, perhaps a refactor "rename" would be in order, such as 
> create, execute, or launch ?
renamed to launch.
>
> It would be helpful to provide a current summary, or a recap, as to 
> the motivation for the refactoring.
It's in the javadoc, I refined it again.
>
> Is this complimentary to the constructor RegistryImp(int port) or 
> LocateRegistry.createRegistry( ..)  ?
The new "launch" method is mainly used for tests to simulate rmiregistry 
which is an executable released by jdk.
>
>
> regards
> Mark
>
>
>
> On 09/01/2017 07:56, Hamlin Li wrote:
>> Hi Roger,
>>
>> Thank you for reviewing, please check new webrev: 
>> http://cr.openjdk.java.net/~mli/8172347/webrev.01/
>>
>> Thank you
>> -Hamlin
>>
>> On 2017/1/6 12:56, Roger Riggs wrote:
>>> Hi Hamlin,
>>>
>>> Yes, that looks better.
>>>
>>> On the comments, use the normal javadoc comment conventions for any 
>>> public API.
>>> @param @return, @throw, etc.
>>>
>>> I think comments should be direct about what the function does. It 
>>> does not need
>>> to explain why so much.  Or if so, later and in a separate 
>>> paragraph;  when reading
>>> the most important information should be first.
>>>
>>> Thanks, Roger
>>>
>>>
>>> On 1/6/2017 4:59 AM, Hamlin Li wrote:
>>>>
>>>> On 2017/1/6 6:15, Roger Riggs wrote:
>>>>> Hi Hamlin,
>>>>>
>>>>> There are too many issues being mixed together...
>>>>>
>>>>> Comments on B) RegistryImpl:
>>>>>
>>>>> Refactoring of RegistryImpl Main should be clean and clearly 
>>>>> separated.
>>>> Hi Roger,
>>>>
>>>> Thank you for reviewing.
>>>> Not sure if I understood you correctly, I created a new bug to 
>>>> track refactoring of RegistryImpl, I will send out separate reviews 
>>>> for AltSecurityManager in JDK-8172314, JDK-8030175. Please let me 
>>>> know if you did not mean it.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8172347
>>>> webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.00/, fix all 
>>>> the below points.
>>>>
>>>> Thank you
>>>> -Hamlin
>>>>>
>>>>> 365: static void RegistryImpl run():
>>>>>
>>>>> -  The signature of run should be run(int port) and documented as 
>>>>> needing to be run in its
>>>>>    own thread since it changes Thread context classloader and that 
>>>>> it sets a securityManager.
>>>>>    Leave it to main to parse and choose a port number.
>>>>>
>>>>> -  The comments should be functional as to the purpose of the code 
>>>>> and not referencing a particular bug.
>>>>>    (Regardless of prior example).
>>>>>
>>>>>  - The comment about getting the exact port is out of place 
>>>>> because the port number cannot be
>>>>>    retrieved from the returned RegistryImpl.  IF that's why this 
>>>>> refactoring is needed, then
>>>>>    perhaps there should be a getPort method that extracts it from 
>>>>> the created UnicastServerRef.
>>>>>
>>>>> 423: static void main(String[] args):
>>>>>
>>>>>  - Parsing of args should be left in main(); avoiding the question 
>>>>> about why NumberFormat is handled.
>>>>>
>>>>>  - Either main or run should set a security manager; but not both.
>>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 1/4/2017 10:21 PM, Hamlin Li wrote:
>>>>>> Hi Roger,
>>>>>>
>>>>>> Thank you for reviewing, please check comments inline.
>>>>>>
>>>>>>
>>>>>> On 2017/1/5 4:18, Roger Riggs wrote:
>>>>>>> Hi Hamlin,
>>>>>>>
>>>>>>> The original issue with timeout may be due to heavily loaded 
>>>>>>> systems and short timeouts.
>>>>>>> 15 sec is not enough on an overloaded system to wait for a 
>>>>>>> process to start and then die.
>>>>>>>
>>>>>>> There is no indication in this issue about port-in-use; that 
>>>>>>> would be a different issue.
>>>>>> Agree, I put 2 fixes in one patch together as there is no port in 
>>>>>> use issue reported, but by reviewing the code, potential port in 
>>>>>> use issue could happen some time in the future.
>>>>> Best to keep 1-1 to avoid complicating the discussion and 
>>>>> increasing code complexity.
>>>>>>>
>>>>>>>
>>>>>>> Common comments to both A and B.
>>>>>>>
>>>>>>> I'll need more time to look at B; it would be cleaner to use A 
>>>>>>> if it can address the issue.
>>>>>>> The alternative is to duplicate the code in run() in the 
>>>>>>> TestLibrary and not modify the RegistryImpl.
>>>>>> I prefer B, because
>>>>>>   1. Although A looks cleaner but B is simulating more like 
>>>>>> rmiregistry.
>>>>>>   2. There are some other issue for example JDK-7146543, 
>>>>>> JDK-8030950, JDK-8038772, fix based on version B works well, but 
>>>>>> fix based on version A fails.
>>>>>>   3. Impact of RegistryImpl modification is minimal. ( May we 
>>>>>> could make Registry run(String args[]) private and access it in 
>>>>>> test by reflection? )
>>>>>>   4. Although it's simple to duplicate the code in run() in the 
>>>>>> TestLibrary, but seems it's not a good design choice. (let's call 
>>>>>> it version C.)
>>>>>>   5. For JDK-8170728, the fix will need to modify 
>>>>>> sun.rmi.registry.RegistryImpl anyway.
>>>>>>
>>>>>>
>>>>>> Thank you for detailed review comments below.
>>>>>> As we have several options, I will wait for your further comments 
>>>>>> on choice of version A/B/C, then send out new webrev, hope I only 
>>>>>> need to send out one version :-).
>>>>>>
>>>>>> Thank you
>>>>>> -Hamlin
>>>>>>>
>>>>>>>
>>>>>>> JavaVM:
>>>>>>>  - Document the new methods.
>>>>>>>
>>>>>>> Line 232: Document the exception that may be thrown from exitValue.
>>>>>>>
>>>>>>>
>>>>>>> RMID:
>>>>>>> Line 204, 222: when adding new functions to the test library 
>>>>>>> please add documentation for the methods.
>>>>>>> There are now many variations of the methods that differ only by 
>>>>>>> the number arguments.
>>>>>>> It would be better if the name included some hint as to the 
>>>>>>> additional functionality.
>>>>>>>
>>>>>>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>>>>>>
>>>>>>> REGISTRY:
>>>>>>>   - Document the new methods.
>>>>>>>
>>>>>>>   - The name should be more indicative of its function and 
>>>>>>> should NOT be all caps;  RMID is an acronym where the caps make 
>>>>>>> sense.
>>>>>>>
>>>>>>>   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating 
>>>>>>> code to wait for the subprocess.
>>>>>>>
>>>>>>>   - If the subprocesses are in an unknown state it would be 
>>>>>>> useful to print diagnostic info from the subprocess before 
>>>>>>> terminating.
>>>>>>>     Line 106:
>>>>>>>
>>>>>>>  - Line 124:
>>>>>>>  - I think I would have promoted the shutdown method to JavaVM 
>>>>>>> instead of creating a new cleanup method
>>>>>>>    to keep the code simpler.
>>>>>>>
>>>>>>>    ** The cleanup method never calls super.cleanup() so the 
>>>>>>> process is never destroyed!.
>>>>>>>
>>>>>>> AltSecurityManager.java:
>>>>>>>
>>>>>>>  - Line 61: the empty constructor can be removed entirely.
>>>>>>>
>>>>>>>  - Line 80: change the message to say the exception did not occur.
>>>>>>>     As written it implies it may have occurred but was not caught.
>>>>>>>
>>>>>>>  - Line 86: typo "a unexpected" -> "an unexpected"
>>>>>>>
>>>>>>> - Line 90: remove the printStackTrace; it is not useful and is a 
>>>>>>> red flag in .jtr files
>>>>>>>
>>>>>>>  - Line 125: I don't see that cleanup is better than destroy; If 
>>>>>>> there are doubts about destroy
>>>>>>>    then destroy should be fixed not avoided.
>>>>>>>
>>>>>>> Roger
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>>>>>>> Would you please review the below patches?
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>>>>>>> webrev (version A): 
>>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>>>>>>> webrev (version B): 
>>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>>>>>>>
>>>>>>>>
>>>>>>>> There are 2 versions to be reviewed.
>>>>>>>>
>>>>>>>> In version A, just use RegistryRunner to replace rmiregistry.
>>>>>>>> In version B, refactor sun.rmi.registry.RegistryImpl to improve 
>>>>>>>> the testability of RMI code, and create/use RMIRegistryRunner 
>>>>>>>> to simulate rmiregistry.
>>>>>>>>
>>>>>>>> Thank you
>>>>>>>> -Hamlin
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From sean.mullan at oracle.com  Mon Jan  9 19:25:02 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 9 Jan 2017 14:25:02 -0500
Subject: RFR: 8055206: Update SecurityManager::checkPackageAccess to restrict
	non-exported JDK packages by default
Message-ID: <ad636b2b-64f4-1923-22d5-0abd914912c8@oracle.com>

Please review this JDK 9 change to make the 
SecurityManager::checkPackageAccess and checkPackageDefinition 
implementations restrict access to the same set of internal JDK packages 
as the module system.

This overall change will improve security by making these two mechanisms 
consistent and reduce the amount of work needed to maintain the 
package.access and package.definition security properties going forward.

JBS issue: https://bugs.openjdk.java.net/browse/JDK-8055206
JDK webrev: 
http://cr.openjdk.java.net/~mullan/webrevs/8055206/jdk/webrev.00/
JAXP webrev: 
http://cr.openjdk.java.net/~mullan/webrevs/8055206/jaxp/webrev.00/

The JBS bug has more details, but the fix consists of essentially 3 main 
parts:

1. Remove most packages from the package.{access,definition} security 
properties

2. Changes to the SecurityManager::checkPackage{Access,Definition} APIs 
to allow an implementation to restrict a default set of packages (in 
addition to those listed in the package.{access,definition} properties)

3. Changes to the default 
SecurityManager::checkPackage{Access,Definition} implementation to use 
Module APIs to compute the list of non-exported packages loaded by the 
platform class loader or its ancestors.

Several tests also had to be modified to be granted additional 
permission(s) to access the newly restricted packages under a 
SecurityManager. JAXP also needed a change to grant additional 
permissions to access internal packages that are exported to the modules 
that are dynamically created for use with XSLT.

Thanks,
Sean

From paul.sandoz at oracle.com  Mon Jan  9 19:29:21 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 9 Jan 2017 11:29:21 -0800
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <CA+kOe09tSLRR_DRDMf7fzQGRpf9uG4RMm=srKGWEbU3FSTaTbA@mail.gmail.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
	<d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
	<CA+kOe09tSLRR_DRDMf7fzQGRpf9uG4RMm=srKGWEbU3FSTaTbA@mail.gmail.com>
Message-ID: <58DC5C59-1F78-450F-A43A-B8578B77CF9E@oracle.com>

Hi Martin,

Have you tried using:

 MethodHandles.privateLookupIn(ConcurrentLinkedQueue.class, MethodHandles.lookup()).
    findVarHandle(?)

?

I agree there is some inconsistency here, and we wanted to discourage the use of setAccessible. One problem is setAccessible conflates accessibility with stomping on final fields. If we do allow setAccessible access to work for unreflecting i would still not want to allow VarHandles to stomp on final fields, so some inconsistency would remain.

My preference would be to encourage people to use MethodHandles.privateLookupIn.

Paul.


> On 9 Jan 2017, at 10:43, Martin Buchholz <martinrb at google.com> wrote:
> 
> Relatedly, I'm writing whitebox jtreg tests and would like to use VarHandles to access internal data structures.
> Because I have:
> 
>  * @modules java.base/java.util.concurrent:open
> 
> I can use reflection with setAccessible to obtain a usable Field, but if I try to turn that into a VarHandle I get:
> 
>         Field f = ConcurrentLinkedQueue.class.getDeclaredField("head");
>         f.setAccessible(true);
>         VarHandle v = java.lang.invoke.MethodHandles.lookup()
>             .unreflectVarHandle(f);
> 
>  java.lang.IllegalAccessException: member is private to package: java.util.concurrent.ConcurrentLinkedQueue.head/java.util.concurrent.ConcurrentLinkedQueue$Node/getField, from WhiteBox (unnamed module @7a187f14)
> 
> It seems wrong to have this sort of mismatch - setAccessible works, but the strictly more powerful VarHandles remain unobtainable.
> 
> I happen to have a workaround, but I don't see a general solution for whitebox testing.


From Roger.Riggs at Oracle.com  Mon Jan  9 21:04:27 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 9 Jan 2017 16:04:27 -0500
Subject: RFR of JDK-8172347: Refactoring
	src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to
	improve testability of rmiregistry
In-Reply-To: <48bdbd18-f420-e526-2278-0506d02ee443@oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
	<0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
	<5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
	<6432c6de-af93-5224-f848-8e2e8f0f7c9f@oracle.com>
	<888af0b3-24ee-826a-7449-f3eece8ab9f8@Oracle.com>
	<2eecc91f-019a-024d-a48f-27930137cb09@oracle.com>
	<48bdbd18-f420-e526-2278-0506d02ee443@oracle.com>
Message-ID: <7bf34238-0ea3-1bc8-7d72-84ceaedd225e@Oracle.com>

Hi Hamlin,

In addition to Mark's comments:

How about this for the method comment:

/**
   * Return a new RegistryImpl on the requested port and export it to 
serve registry requests.
   * A classloader is initialized from the system property 
"env.class.path" and
   * a security manager is set unless one is already set.
   * <p>
   * The returned Registry is fully functional within the current 
process and is usable for
   * internal and testing purposes.
   *
   * @param regPort port on which the rmiregistry accepts requests;
   *                            if 0, an implementation specific port is 
assigned
   * @return a RegistryImpl instance
   * @exception RemoteException If remote operation failed.
   * @since 9
   */
     public static RegistryImpl run(int regPort) throws RemoteException 
{...}

The method should throw RemoteException. Throws clauses should always be 
as specific as possible.

On 1/9/2017 9:36 AM, Mark Sheppard wrote:
> Hi Hamlin,
>
> If I read the changes correctly, there would appear to be a side 
> effect of your refactor extract method "run", such that the static 
> member variable
> registry is no longer set in the main method, and is set in the run 
> method ? Thus, invoking run multiple times (, whether that is intended 
> or not,) will
> see the registry static member variable overwritten, for each call. 
> While the current implementation that will occur once only within the 
> main method.
> So, what's the desired semantics for multiple "run" calls?
The static  registry field is never used and can/should be removed.
It can be handled with a local in the method.
>
>  A "run" method is synonymous with Runnable interface, even though 
> this run method has a different signature, it's better
> to help us unwary avoid confusion!
> Also the run method instantiates and returns a RegistryImpl, thus 
> exhibiting factory method characteristics.
> As such, perhaps a refactor "rename" would be in order, such as 
> create, execute, or launch ?
+1,  perhaps createRegistry(int port)


>
> It would be helpful to provide a current summary, or a recap, as to 
> the motivation for the refactoring.
That can be in the test or the bug report; the implementation code 
itself should describe the functionality
and its use.

$.02, Roger

>
> Is this complimentary to the constructor RegistryImp(int port) or 
> LocateRegistry.createRegistry( ..)  ?
>
>
> regards
> Mark
>
>
>
> On 09/01/2017 07:56, Hamlin Li wrote:
>> Hi Roger,
>>
>> Thank you for reviewing, please check new webrev: 
>> http://cr.openjdk.java.net/~mli/8172347/webrev.01/
>>
>> Thank you
>> -Hamlin
>>
>> On 2017/1/6 12:56, Roger Riggs wrote:
>>> Hi Hamlin,
>>>
>>> Yes, that looks better.
>>>
>>> On the comments, use the normal javadoc comment conventions for any 
>>> public API.
>>> @param @return, @throw, etc.
>>>
>>> I think comments should be direct about what the function does. It 
>>> does not need
>>> to explain why so much.  Or if so, later and in a separate 
>>> paragraph;  when reading
>>> the most important information should be first.
>>>
>>> Thanks, Roger
>>>
>>>
>>> On 1/6/2017 4:59 AM, Hamlin Li wrote:
>>>>
>>>> On 2017/1/6 6:15, Roger Riggs wrote:
>>>>> Hi Hamlin,
>>>>>
>>>>> There are too many issues being mixed together...
>>>>>
>>>>> Comments on B) RegistryImpl:
>>>>>
>>>>> Refactoring of RegistryImpl Main should be clean and clearly 
>>>>> separated.
>>>> Hi Roger,
>>>>
>>>> Thank you for reviewing.
>>>> Not sure if I understood you correctly, I created a new bug to 
>>>> track refactoring of RegistryImpl, I will send out separate reviews 
>>>> for AltSecurityManager in JDK-8172314, JDK-8030175. Please let me 
>>>> know if you did not mean it.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8172347
>>>> webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.00/, fix all 
>>>> the below points.
>>>>
>>>> Thank you
>>>> -Hamlin
>>>>>
>>>>> 365: static void RegistryImpl run():
>>>>>
>>>>> -  The signature of run should be run(int port) and documented as 
>>>>> needing to be run in its
>>>>>    own thread since it changes Thread context classloader and that 
>>>>> it sets a securityManager.
>>>>>    Leave it to main to parse and choose a port number.
>>>>>
>>>>> -  The comments should be functional as to the purpose of the code 
>>>>> and not referencing a particular bug.
>>>>>    (Regardless of prior example).
>>>>>
>>>>>  - The comment about getting the exact port is out of place 
>>>>> because the port number cannot be
>>>>>    retrieved from the returned RegistryImpl.  IF that's why this 
>>>>> refactoring is needed, then
>>>>>    perhaps there should be a getPort method that extracts it from 
>>>>> the created UnicastServerRef.
>>>>>
>>>>> 423: static void main(String[] args):
>>>>>
>>>>>  - Parsing of args should be left in main(); avoiding the question 
>>>>> about why NumberFormat is handled.
>>>>>
>>>>>  - Either main or run should set a security manager; but not both.
>>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 1/4/2017 10:21 PM, Hamlin Li wrote:
>>>>>> Hi Roger,
>>>>>>
>>>>>> Thank you for reviewing, please check comments inline.
>>>>>>
>>>>>>
>>>>>> On 2017/1/5 4:18, Roger Riggs wrote:
>>>>>>> Hi Hamlin,
>>>>>>>
>>>>>>> The original issue with timeout may be due to heavily loaded 
>>>>>>> systems and short timeouts.
>>>>>>> 15 sec is not enough on an overloaded system to wait for a 
>>>>>>> process to start and then die.
>>>>>>>
>>>>>>> There is no indication in this issue about port-in-use; that 
>>>>>>> would be a different issue.
>>>>>> Agree, I put 2 fixes in one patch together as there is no port in 
>>>>>> use issue reported, but by reviewing the code, potential port in 
>>>>>> use issue could happen some time in the future.
>>>>> Best to keep 1-1 to avoid complicating the discussion and 
>>>>> increasing code complexity.
>>>>>>>
>>>>>>>
>>>>>>> Common comments to both A and B.
>>>>>>>
>>>>>>> I'll need more time to look at B; it would be cleaner to use A 
>>>>>>> if it can address the issue.
>>>>>>> The alternative is to duplicate the code in run() in the 
>>>>>>> TestLibrary and not modify the RegistryImpl.
>>>>>> I prefer B, because
>>>>>>   1. Although A looks cleaner but B is simulating more like 
>>>>>> rmiregistry.
>>>>>>   2. There are some other issue for example JDK-7146543, 
>>>>>> JDK-8030950, JDK-8038772, fix based on version B works well, but 
>>>>>> fix based on version A fails.
>>>>>>   3. Impact of RegistryImpl modification is minimal. ( May we 
>>>>>> could make Registry run(String args[]) private and access it in 
>>>>>> test by reflection? )
>>>>>>   4. Although it's simple to duplicate the code in run() in the 
>>>>>> TestLibrary, but seems it's not a good design choice. (let's call 
>>>>>> it version C.)
>>>>>>   5. For JDK-8170728, the fix will need to modify 
>>>>>> sun.rmi.registry.RegistryImpl anyway.
>>>>>>
>>>>>>
>>>>>> Thank you for detailed review comments below.
>>>>>> As we have several options, I will wait for your further comments 
>>>>>> on choice of version A/B/C, then send out new webrev, hope I only 
>>>>>> need to send out one version :-).
>>>>>>
>>>>>> Thank you
>>>>>> -Hamlin
>>>>>>>
>>>>>>>
>>>>>>> JavaVM:
>>>>>>>  - Document the new methods.
>>>>>>>
>>>>>>> Line 232: Document the exception that may be thrown from exitValue.
>>>>>>>
>>>>>>>
>>>>>>> RMID:
>>>>>>> Line 204, 222: when adding new functions to the test library 
>>>>>>> please add documentation for the methods.
>>>>>>> There are now many variations of the methods that differ only by 
>>>>>>> the number arguments.
>>>>>>> It would be better if the name included some hint as to the 
>>>>>>> additional functionality.
>>>>>>>
>>>>>>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>>>>>>
>>>>>>> REGISTRY:
>>>>>>>   - Document the new methods.
>>>>>>>
>>>>>>>   - The name should be more indicative of its function and 
>>>>>>> should NOT be all caps;  RMID is an acronym where the caps make 
>>>>>>> sense.
>>>>>>>
>>>>>>>   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating 
>>>>>>> code to wait for the subprocess.
>>>>>>>
>>>>>>>   - If the subprocesses are in an unknown state it would be 
>>>>>>> useful to print diagnostic info from the subprocess before 
>>>>>>> terminating.
>>>>>>>     Line 106:
>>>>>>>
>>>>>>>  - Line 124:
>>>>>>>  - I think I would have promoted the shutdown method to JavaVM 
>>>>>>> instead of creating a new cleanup method
>>>>>>>    to keep the code simpler.
>>>>>>>
>>>>>>>    ** The cleanup method never calls super.cleanup() so the 
>>>>>>> process is never destroyed!.
>>>>>>>
>>>>>>> AltSecurityManager.java:
>>>>>>>
>>>>>>>  - Line 61: the empty constructor can be removed entirely.
>>>>>>>
>>>>>>>  - Line 80: change the message to say the exception did not occur.
>>>>>>>     As written it implies it may have occurred but was not caught.
>>>>>>>
>>>>>>>  - Line 86: typo "a unexpected" -> "an unexpected"
>>>>>>>
>>>>>>> - Line 90: remove the printStackTrace; it is not useful and is a 
>>>>>>> red flag in .jtr files
>>>>>>>
>>>>>>>  - Line 125: I don't see that cleanup is better than destroy; If 
>>>>>>> there are doubts about destroy
>>>>>>>    then destroy should be fixed not avoided.
>>>>>>>
>>>>>>> Roger
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>>>>>>> Would you please review the below patches?
>>>>>>>>
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>>>>>>> webrev (version A): 
>>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>>>>>>> webrev (version B): 
>>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>>>>>>>
>>>>>>>>
>>>>>>>> There are 2 versions to be reviewed.
>>>>>>>>
>>>>>>>> In version A, just use RegistryRunner to replace rmiregistry.
>>>>>>>> In version B, refactor sun.rmi.registry.RegistryImpl to improve 
>>>>>>>> the testability of RMI code, and create/use RMIRegistryRunner 
>>>>>>>> to simulate rmiregistry.
>>>>>>>>
>>>>>>>> Thank you
>>>>>>>> -Hamlin
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Mon Jan  9 21:20:23 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 9 Jan 2017 13:20:23 -0800
Subject: RFR(s): 8171958: Several tests from
	java/time/test/java/time/format requiring jdk.localedata for execution
In-Reply-To: <056de9df-4cb6-c17a-b8b1-6120d4b9389b@oracle.com>
References: <39bd0f19-5dbd-9790-2d5f-d3cae2a7cf08@oracle.com>
	<5dbbbb52-26fd-bd59-fdc8-ebb94585c7df@oracle.com>
	<3e978d60-2fed-4106-6d8f-fb64f32dff63@oracle.com>
	<056de9df-4cb6-c17a-b8b1-6120d4b9389b@oracle.com>
Message-ID: <61d8438f-8f9a-7ad3-3bc3-c0cf81711a27@oracle.com>

Hi Sergei,

java.base only supports Locale.US locale (and its parents 
Locale.ENGLISH/Locale.ROOT). I still see tests that use other locales, 
such as Locale.UK, Locale.FRENCH (eg. in 
TestDateTimeFormatterBuilder.java). Those test should also need to be 
separated.

Naoto

On 1/9/17 1:45 AM, Sergei Kovalev wrote:
> Hi All,
>
> Re-sending request because I'm still looking for reviewers.
>
> In addition for TEST.properties modification I'd like to put citation
> from Jon G. email.
>
>> FWIW, I note your TEST.properties file looks malformed.  It has 2
>> modules entries (line 4, line 7), which by the standard rules of Java
>> properties files, means that "last one wins".
>>
>> line source
>> # Threeten test uses TestNG
>> TestNG.dirs = .
>> othervm.dirs = tck/java/time/chrono test/java/time/chrono
>> test/java/time/format
>> modules = jdk.localedata
>> lib.dirs = ../../lib/testlibrary
>> lib.build = jdk.testlibrary.RandomFactory
>> modules = java.base/java.time:open java.base/java.time.chrono:open
>> java.base/java.time.zone:open
> This mean that first modules declaration could be safely removed as I did.
>
>
> 28.12.16 17:20, Sergei Kovalev wrote:
>>
>> Hi Rachna,
>>
>> Thank you for the comment. I've reviewed usage of module declaration
>> in TEST.properties file and find that it could be removed without any
>> impact. In both cases (with original and modified TEST.properties
>> file) I get same result.
>>
>> Test results: passed: 142; failed: 27
>>
>> The reason of this behavior is the lack of jtreg header in test
>> sources. In case test source has no "@test" tag jtreg ignores all
>> properties that exists in TEST.properties file.
>>
>> I recreated the review by adding TEST.properties modification:
>> http://cr.openjdk.java.net/~skovalev/8171958/webrev.01/
>>
>>
>> 27.12.16 13:55, Rachna Goel wrote:
>>>
>>> Hi Sergei,
>>>
>>> Though I am not a reviewer, But I have one comment on this fix.
>>>
>>> test/java/time/TEST.properties declares "modules = jdk.localedata" ,
>>> so that all tests for java.time can have access to "jdk.localedata"
>>> module.
>>>
>>> If we are restricting usage of jdk.localedata module for different
>>> tests, then TEST.properties need to be updated as well.
>>>
>>> Thanks,
>>> Rachna
>>>
>>>
>>>
>>> On 26/12/16 8:27 PM, Sergei Kovalev wrote:
>>>> Hello Team,
>>>>
>>>> Please review below fix for tests.
>>>>
>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8171958
>>>> Web review: http://cr.openjdk.java.net/~skovalev/8171958/webrev.00/
>>>>
>>>> Issue: some tests fails in case of module limitation by
>>>> '--limit-module java.base' command line option.
>>>> Root cause: The tests uses locale data that stored in separate
>>>> resource file "jdk.localedata".
>>>> Solution: Add declaration of required module. In same cases a test
>>>> file contains many test items, part of which could be executed with
>>>> java.base module only. In this cases we can separate the items and
>>>> extract that items which depend on locale data and run them
>>>> individually. Therefore this proposal contains additional test files
>>>> where added "WithLocale" suffix which demonstrate dependency on
>>>> resources. Alternative solution could be add a required module
>>>> declaration "jdk.localedata" to all files. However this will lead to
>>>> unnecessary test coverage reduction.
>>>>
>>>
>>
>> --
>> With best regards,
>> Sergei
>

From martinrb at google.com  Mon Jan  9 21:27:18 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Jan 2017 13:27:18 -0800
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <58DC5C59-1F78-450F-A43A-B8578B77CF9E@oracle.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
	<d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
	<CA+kOe09tSLRR_DRDMf7fzQGRpf9uG4RMm=srKGWEbU3FSTaTbA@mail.gmail.com>
	<58DC5C59-1F78-450F-A43A-B8578B77CF9E@oracle.com>
Message-ID: <CA+kOe08MkALjjxR8X+7EjanofCPw2PtxFh_7ZiwEJHtwN1=c0A@mail.gmail.com>

On Mon, Jan 9, 2017 at 11:29 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Martin,
>
> Have you tried using:
>
>  MethodHandles.privateLookupIn(ConcurrentLinkedQueue.class,
> MethodHandles.lookup()).
>     findVarHandle(?)
>
> ?
>

Thanks!  privateLookupIn was not in my toolbox.  I'm happy with:

    final VarHandle HEAD, TAIL, ITEM, NEXT;

    public WhiteBox() throws ReflectiveOperationException {
        Class<?> qClass = LinkedTransferQueue.class;
        Class<?> nodeClass = Class.forName(qClass.getName() + "$Node");
        MethodHandles.Lookup lookup
            = MethodHandles.privateLookupIn(qClass, MethodHandles.lookup());
        HEAD = lookup.findVarHandle(qClass, "head", nodeClass);
        TAIL = lookup.findVarHandle(qClass, "tail", nodeClass);
        NEXT = lookup.findVarHandle(nodeClass, "next", nodeClass);
        ITEM = lookup.findVarHandle(nodeClass, "item", Object.class);
    }

    Object head(LinkedTransferQueue q) { return HEAD.getVolatile(q); }
    Object tail(LinkedTransferQueue q) { return TAIL.getVolatile(q); }
    Object item(Object node)           { return ITEM.getVolatile(node); }
    Object next(Object node)           { return NEXT.getVolatile(node); }

although programming this way does not feel very Java-esque.  I miss being
able to use a Node type at compile time.

I agree there is some inconsistency here, and we wanted to discourage the
> use of setAccessible. One problem is setAccessible conflates accessibility
> with stomping on final fields. If we do allow setAccessible access to work
> for unreflecting i would still not want to allow VarHandles to stomp on
> final fields, so some inconsistency would remain.
>

I agree with your decision to not give unreflected VarHandles the same
unconstrained superpowers that the Field has.

My whitebox tests tend to use private access only for reading, but I can
imagine cases where it is useful to give testing code stronger access than
for regular VarHandles, maybe even to write final fields, for example for
fuzz testing or reliably creating an internal state that can only happen
with a race.  There's may be a case for providing such a big hammer, if
it's sufficiently hard to get at, but I can live without it.


> My preference would be to encourage people to use
> MethodHandles.privateLookupIn.
>

I'm a convert! It will take a while for privateLookupIn to become "common
knowledge".

From huaming.li at oracle.com  Mon Jan  9 21:49:09 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Mon, 9 Jan 2017 13:49:09 -0800
Subject: RFR of JDK-8172347: Refactoring
	src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to
	improve testability of rmiregistry
In-Reply-To: <7bf34238-0ea3-1bc8-7d72-84ceaedd225e@Oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
	<0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
	<5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
	<6432c6de-af93-5224-f848-8e2e8f0f7c9f@oracle.com>
	<888af0b3-24ee-826a-7449-f3eece8ab9f8@Oracle.com>
	<2eecc91f-019a-024d-a48f-27930137cb09@oracle.com>
	<48bdbd18-f420-e526-2278-0506d02ee443@oracle.com>
	<7bf34238-0ea3-1bc8-7d72-84ceaedd225e@Oracle.com>
Message-ID: <8a1b4651-8680-b615-9e16-dab6ab738b66@oracle.com>

Hi Roger,

Thank you for reviewing, please check the comments inline, and new 
webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.03/

Thank you
-Hamlin

On 2017/1/9 13:04, Roger Riggs wrote:
> Hi Hamlin,
>
> In addition to Mark's comments:
>
> How about this for the method comment:
>
> /**
>   * Return a new RegistryImpl on the requested port and export it to 
> serve registry requests.
>   * A classloader is initialized from the system property 
> "env.class.path" and
>   * a security manager is set unless one is already set.
>   * <p>
>   * The returned Registry is fully functional within the current 
> process and is usable for
>   * internal and testing purposes.
>   *
>   * @param regPort port on which the rmiregistry accepts requests;
>   *                            if 0, an implementation specific port 
> is assigned
>   * @return a RegistryImpl instance
>   * @exception RemoteException If remote operation failed.
>   * @since 9
>   */
Your java doc looks more clear, modified.
>     public static RegistryImpl run(int regPort) throws RemoteException 
> {...}
>
> The method should throw RemoteException. Throws clauses should always 
> be as specific as possible.
modified throws.
>
> On 1/9/2017 9:36 AM, Mark Sheppard wrote:
>> Hi Hamlin,
>>
>> If I read the changes correctly, there would appear to be a side 
>> effect of your refactor extract method "run", such that the static 
>> member variable
>> registry is no longer set in the main method, and is set in the run 
>> method ? Thus, invoking run multiple times (, whether that is 
>> intended or not,) will
>> see the registry static member variable overwritten, for each call. 
>> While the current implementation that will occur once only within the 
>> main method.
>> So, what's the desired semantics for multiple "run" calls?
> The static  registry field is never used and can/should be removed.
> It can be handled with a local in the method.
handled in a local in the method, and assign it to registry in man.
>>
>>  A "run" method is synonymous with Runnable interface, even though 
>> this run method has a different signature, it's better
>> to help us unwary avoid confusion!
>> Also the run method instantiates and returns a RegistryImpl, thus 
>> exhibiting factory method characteristics.
>> As such, perhaps a refactor "rename" would be in order, such as 
>> create, execute, or launch ?
> +1,  perhaps createRegistry(int port)
>
use launch, createRegistry makes me think of it as the same of 
LocateRegistry.createRegistry.
>
>>
>> It would be helpful to provide a current summary, or a recap, as to 
>> the motivation for the refactoring.
> That can be in the test or the bug report; the implementation code 
> itself should describe the functionality
> and its use.
will do it in test.
>
> $.02, Roger
>
>>
>> Is this complimentary to the constructor RegistryImp(int port) or 
>> LocateRegistry.createRegistry( ..)  ?
>>
>>
>> regards
>> Mark
>>
>>
>>
>> On 09/01/2017 07:56, Hamlin Li wrote:
>>> Hi Roger,
>>>
>>> Thank you for reviewing, please check new webrev: 
>>> http://cr.openjdk.java.net/~mli/8172347/webrev.01/
>>>
>>> Thank you
>>> -Hamlin
>>>
>>> On 2017/1/6 12:56, Roger Riggs wrote:
>>>> Hi Hamlin,
>>>>
>>>> Yes, that looks better.
>>>>
>>>> On the comments, use the normal javadoc comment conventions for any 
>>>> public API.
>>>> @param @return, @throw, etc.
>>>>
>>>> I think comments should be direct about what the function does. It 
>>>> does not need
>>>> to explain why so much.  Or if so, later and in a separate 
>>>> paragraph;  when reading
>>>> the most important information should be first.
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>> On 1/6/2017 4:59 AM, Hamlin Li wrote:
>>>>>
>>>>> On 2017/1/6 6:15, Roger Riggs wrote:
>>>>>> Hi Hamlin,
>>>>>>
>>>>>> There are too many issues being mixed together...
>>>>>>
>>>>>> Comments on B) RegistryImpl:
>>>>>>
>>>>>> Refactoring of RegistryImpl Main should be clean and clearly 
>>>>>> separated.
>>>>> Hi Roger,
>>>>>
>>>>> Thank you for reviewing.
>>>>> Not sure if I understood you correctly, I created a new bug to 
>>>>> track refactoring of RegistryImpl, I will send out separate 
>>>>> reviews for AltSecurityManager in JDK-8172314, JDK-8030175. Please 
>>>>> let me know if you did not mean it.
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8172347
>>>>> webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.00/, fix 
>>>>> all the below points.
>>>>>
>>>>> Thank you
>>>>> -Hamlin
>>>>>>
>>>>>> 365: static void RegistryImpl run():
>>>>>>
>>>>>> -  The signature of run should be run(int port) and documented as 
>>>>>> needing to be run in its
>>>>>>    own thread since it changes Thread context classloader and 
>>>>>> that it sets a securityManager.
>>>>>>    Leave it to main to parse and choose a port number.
>>>>>>
>>>>>> -  The comments should be functional as to the purpose of the 
>>>>>> code and not referencing a particular bug.
>>>>>>    (Regardless of prior example).
>>>>>>
>>>>>>  - The comment about getting the exact port is out of place 
>>>>>> because the port number cannot be
>>>>>>    retrieved from the returned RegistryImpl.  IF that's why this 
>>>>>> refactoring is needed, then
>>>>>>    perhaps there should be a getPort method that extracts it from 
>>>>>> the created UnicastServerRef.
>>>>>>
>>>>>> 423: static void main(String[] args):
>>>>>>
>>>>>>  - Parsing of args should be left in main(); avoiding the 
>>>>>> question about why NumberFormat is handled.
>>>>>>
>>>>>>  - Either main or run should set a security manager; but not both.
>>>>>>
>>>>>> Roger
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 1/4/2017 10:21 PM, Hamlin Li wrote:
>>>>>>> Hi Roger,
>>>>>>>
>>>>>>> Thank you for reviewing, please check comments inline.
>>>>>>>
>>>>>>>
>>>>>>> On 2017/1/5 4:18, Roger Riggs wrote:
>>>>>>>> Hi Hamlin,
>>>>>>>>
>>>>>>>> The original issue with timeout may be due to heavily loaded 
>>>>>>>> systems and short timeouts.
>>>>>>>> 15 sec is not enough on an overloaded system to wait for a 
>>>>>>>> process to start and then die.
>>>>>>>>
>>>>>>>> There is no indication in this issue about port-in-use; that 
>>>>>>>> would be a different issue.
>>>>>>> Agree, I put 2 fixes in one patch together as there is no port 
>>>>>>> in use issue reported, but by reviewing the code, potential port 
>>>>>>> in use issue could happen some time in the future.
>>>>>> Best to keep 1-1 to avoid complicating the discussion and 
>>>>>> increasing code complexity.
>>>>>>>>
>>>>>>>>
>>>>>>>> Common comments to both A and B.
>>>>>>>>
>>>>>>>> I'll need more time to look at B; it would be cleaner to use A 
>>>>>>>> if it can address the issue.
>>>>>>>> The alternative is to duplicate the code in run() in the 
>>>>>>>> TestLibrary and not modify the RegistryImpl.
>>>>>>> I prefer B, because
>>>>>>>   1. Although A looks cleaner but B is simulating more like 
>>>>>>> rmiregistry.
>>>>>>>   2. There are some other issue for example JDK-7146543, 
>>>>>>> JDK-8030950, JDK-8038772, fix based on version B works well, but 
>>>>>>> fix based on version A fails.
>>>>>>>   3. Impact of RegistryImpl modification is minimal. ( May we 
>>>>>>> could make Registry run(String args[]) private and access it in 
>>>>>>> test by reflection? )
>>>>>>>   4. Although it's simple to duplicate the code in run() in the 
>>>>>>> TestLibrary, but seems it's not a good design choice. (let's 
>>>>>>> call it version C.)
>>>>>>>   5. For JDK-8170728, the fix will need to modify 
>>>>>>> sun.rmi.registry.RegistryImpl anyway.
>>>>>>>
>>>>>>>
>>>>>>> Thank you for detailed review comments below.
>>>>>>> As we have several options, I will wait for your further 
>>>>>>> comments on choice of version A/B/C, then send out new webrev, 
>>>>>>> hope I only need to send out one version :-).
>>>>>>>
>>>>>>> Thank you
>>>>>>> -Hamlin
>>>>>>>>
>>>>>>>>
>>>>>>>> JavaVM:
>>>>>>>>  - Document the new methods.
>>>>>>>>
>>>>>>>> Line 232: Document the exception that may be thrown from 
>>>>>>>> exitValue.
>>>>>>>>
>>>>>>>>
>>>>>>>> RMID:
>>>>>>>> Line 204, 222: when adding new functions to the test library 
>>>>>>>> please add documentation for the methods.
>>>>>>>> There are now many variations of the methods that differ only 
>>>>>>>> by the number arguments.
>>>>>>>> It would be better if the name included some hint as to the 
>>>>>>>> additional functionality.
>>>>>>>>
>>>>>>>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>>>>>>>
>>>>>>>> REGISTRY:
>>>>>>>>   - Document the new methods.
>>>>>>>>
>>>>>>>>   - The name should be more indicative of its function and 
>>>>>>>> should NOT be all caps;  RMID is an acronym where the caps make 
>>>>>>>> sense.
>>>>>>>>
>>>>>>>>   - line 105: use JavaVM.waitFor(timeout) and avoid duplicating 
>>>>>>>> code to wait for the subprocess.
>>>>>>>>
>>>>>>>>   - If the subprocesses are in an unknown state it would be 
>>>>>>>> useful to print diagnostic info from the subprocess before 
>>>>>>>> terminating.
>>>>>>>>     Line 106:
>>>>>>>>
>>>>>>>>  - Line 124:
>>>>>>>>  - I think I would have promoted the shutdown method to JavaVM 
>>>>>>>> instead of creating a new cleanup method
>>>>>>>>    to keep the code simpler.
>>>>>>>>
>>>>>>>>    ** The cleanup method never calls super.cleanup() so the 
>>>>>>>> process is never destroyed!.
>>>>>>>>
>>>>>>>> AltSecurityManager.java:
>>>>>>>>
>>>>>>>>  - Line 61: the empty constructor can be removed entirely.
>>>>>>>>
>>>>>>>>  - Line 80: change the message to say the exception did not occur.
>>>>>>>>     As written it implies it may have occurred but was not caught.
>>>>>>>>
>>>>>>>>  - Line 86: typo "a unexpected" -> "an unexpected"
>>>>>>>>
>>>>>>>> - Line 90: remove the printStackTrace; it is not useful and is 
>>>>>>>> a red flag in .jtr files
>>>>>>>>
>>>>>>>>  - Line 125: I don't see that cleanup is better than destroy; 
>>>>>>>> If there are doubts about destroy
>>>>>>>>    then destroy should be fixed not avoided.
>>>>>>>>
>>>>>>>> Roger
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>>>>>>>> Would you please review the below patches?
>>>>>>>>>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>>>>>>>> webrev (version A): 
>>>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>>>>>>>> webrev (version B): 
>>>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There are 2 versions to be reviewed.
>>>>>>>>>
>>>>>>>>> In version A, just use RegistryRunner to replace rmiregistry.
>>>>>>>>> In version B, refactor sun.rmi.registry.RegistryImpl to 
>>>>>>>>> improve the testability of RMI code, and create/use 
>>>>>>>>> RMIRegistryRunner to simulate rmiregistry.
>>>>>>>>>
>>>>>>>>> Thank you
>>>>>>>>> -Hamlin
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From Roger.Riggs at Oracle.com  Mon Jan  9 21:55:39 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 9 Jan 2017 16:55:39 -0500
Subject: RFR of JDK-8172347: Refactoring
	src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to
	improve testability of rmiregistry
In-Reply-To: <8a1b4651-8680-b615-9e16-dab6ab738b66@oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
	<0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
	<5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
	<6432c6de-af93-5224-f848-8e2e8f0f7c9f@oracle.com>
	<888af0b3-24ee-826a-7449-f3eece8ab9f8@Oracle.com>
	<2eecc91f-019a-024d-a48f-27930137cb09@oracle.com>
	<48bdbd18-f420-e526-2278-0506d02ee443@oracle.com>
	<7bf34238-0ea3-1bc8-7d72-84ceaedd225e@Oracle.com>
	<8a1b4651-8680-b615-9e16-dab6ab738b66@oracle.com>
Message-ID: <2300b082-81c9-c0c6-5f32-0fc7699e4178@Oracle.com>

Hi Hamlin,

Its time to use 2017 for copyright dates.

The method name launch does not reflect is really happening.
Launch implies an active process or thread is being started.
But in this case there is no active element; it just creates and exports 
a remote object.
Otherwise, looks fine.

Thanks, Roger


On 1/9/2017 4:49 PM, Hamlin Li wrote:
> Hi Roger,
>
> Thank you for reviewing, please check the comments inline, and new 
> webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.03/
>
> Thank you
> -Hamlin
>
> On 2017/1/9 13:04, Roger Riggs wrote:
>> Hi Hamlin,
>>
>> In addition to Mark's comments:
>>
>> How about this for the method comment:
>>
>> /**
>>   * Return a new RegistryImpl on the requested port and export it to 
>> serve registry requests.
>>   * A classloader is initialized from the system property 
>> "env.class.path" and
>>   * a security manager is set unless one is already set.
>>   * <p>
>>   * The returned Registry is fully functional within the current 
>> process and is usable for
>>   * internal and testing purposes.
>>   *
>>   * @param regPort port on which the rmiregistry accepts requests;
>>   *                            if 0, an implementation specific port 
>> is assigned
>>   * @return a RegistryImpl instance
>>   * @exception RemoteException If remote operation failed.
>>   * @since 9
>>   */
> Your java doc looks more clear, modified.
>>     public static RegistryImpl run(int regPort) throws 
>> RemoteException {...}
>>
>> The method should throw RemoteException. Throws clauses should always 
>> be as specific as possible.
> modified throws.
>>
>> On 1/9/2017 9:36 AM, Mark Sheppard wrote:
>>> Hi Hamlin,
>>>
>>> If I read the changes correctly, there would appear to be a side 
>>> effect of your refactor extract method "run", such that the static 
>>> member variable
>>> registry is no longer set in the main method, and is set in the run 
>>> method ? Thus, invoking run multiple times (, whether that is 
>>> intended or not,) will
>>> see the registry static member variable overwritten, for each call. 
>>> While the current implementation that will occur once only within 
>>> the main method.
>>> So, what's the desired semantics for multiple "run" calls?
>> The static  registry field is never used and can/should be removed.
>> It can be handled with a local in the method.
> handled in a local in the method, and assign it to registry in man.
>>>
>>>  A "run" method is synonymous with Runnable interface, even though 
>>> this run method has a different signature, it's better
>>> to help us unwary avoid confusion!
>>> Also the run method instantiates and returns a RegistryImpl, thus 
>>> exhibiting factory method characteristics.
>>> As such, perhaps a refactor "rename" would be in order, such as 
>>> create, execute, or launch ?
>> +1,  perhaps createRegistry(int port)
>>
> use launch, createRegistry makes me think of it as the same of 
> LocateRegistry.createRegistry.
>>
>>>
>>> It would be helpful to provide a current summary, or a recap, as to 
>>> the motivation for the refactoring.
>> That can be in the test or the bug report; the implementation code 
>> itself should describe the functionality
>> and its use.
> will do it in test.
>>
>> $.02, Roger
>>
>>>
>>> Is this complimentary to the constructor RegistryImp(int port) or 
>>> LocateRegistry.createRegistry( ..)  ?
>>>
>>>
>>> regards
>>> Mark
>>>
>>>
>>>
>>> On 09/01/2017 07:56, Hamlin Li wrote:
>>>> Hi Roger,
>>>>
>>>> Thank you for reviewing, please check new webrev: 
>>>> http://cr.openjdk.java.net/~mli/8172347/webrev.01/
>>>>
>>>> Thank you
>>>> -Hamlin
>>>>
>>>> On 2017/1/6 12:56, Roger Riggs wrote:
>>>>> Hi Hamlin,
>>>>>
>>>>> Yes, that looks better.
>>>>>
>>>>> On the comments, use the normal javadoc comment conventions for 
>>>>> any public API.
>>>>> @param @return, @throw, etc.
>>>>>
>>>>> I think comments should be direct about what the function does. It 
>>>>> does not need
>>>>> to explain why so much.  Or if so, later and in a separate 
>>>>> paragraph;  when reading
>>>>> the most important information should be first.
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>>> On 1/6/2017 4:59 AM, Hamlin Li wrote:
>>>>>>
>>>>>> On 2017/1/6 6:15, Roger Riggs wrote:
>>>>>>> Hi Hamlin,
>>>>>>>
>>>>>>> There are too many issues being mixed together...
>>>>>>>
>>>>>>> Comments on B) RegistryImpl:
>>>>>>>
>>>>>>> Refactoring of RegistryImpl Main should be clean and clearly 
>>>>>>> separated.
>>>>>> Hi Roger,
>>>>>>
>>>>>> Thank you for reviewing.
>>>>>> Not sure if I understood you correctly, I created a new bug to 
>>>>>> track refactoring of RegistryImpl, I will send out separate 
>>>>>> reviews for AltSecurityManager in JDK-8172314, JDK-8030175. 
>>>>>> Please let me know if you did not mean it.
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8172347
>>>>>> webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.00/, fix 
>>>>>> all the below points.
>>>>>>
>>>>>> Thank you
>>>>>> -Hamlin
>>>>>>>
>>>>>>> 365: static void RegistryImpl run():
>>>>>>>
>>>>>>> -  The signature of run should be run(int port) and documented 
>>>>>>> as needing to be run in its
>>>>>>>    own thread since it changes Thread context classloader and 
>>>>>>> that it sets a securityManager.
>>>>>>>    Leave it to main to parse and choose a port number.
>>>>>>>
>>>>>>> -  The comments should be functional as to the purpose of the 
>>>>>>> code and not referencing a particular bug.
>>>>>>>    (Regardless of prior example).
>>>>>>>
>>>>>>>  - The comment about getting the exact port is out of place 
>>>>>>> because the port number cannot be
>>>>>>>    retrieved from the returned RegistryImpl.  IF that's why this 
>>>>>>> refactoring is needed, then
>>>>>>>    perhaps there should be a getPort method that extracts it 
>>>>>>> from the created UnicastServerRef.
>>>>>>>
>>>>>>> 423: static void main(String[] args):
>>>>>>>
>>>>>>>  - Parsing of args should be left in main(); avoiding the 
>>>>>>> question about why NumberFormat is handled.
>>>>>>>
>>>>>>>  - Either main or run should set a security manager; but not both.
>>>>>>>
>>>>>>> Roger
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 1/4/2017 10:21 PM, Hamlin Li wrote:
>>>>>>>> Hi Roger,
>>>>>>>>
>>>>>>>> Thank you for reviewing, please check comments inline.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2017/1/5 4:18, Roger Riggs wrote:
>>>>>>>>> Hi Hamlin,
>>>>>>>>>
>>>>>>>>> The original issue with timeout may be due to heavily loaded 
>>>>>>>>> systems and short timeouts.
>>>>>>>>> 15 sec is not enough on an overloaded system to wait for a 
>>>>>>>>> process to start and then die.
>>>>>>>>>
>>>>>>>>> There is no indication in this issue about port-in-use; that 
>>>>>>>>> would be a different issue.
>>>>>>>> Agree, I put 2 fixes in one patch together as there is no port 
>>>>>>>> in use issue reported, but by reviewing the code, potential 
>>>>>>>> port in use issue could happen some time in the future.
>>>>>>> Best to keep 1-1 to avoid complicating the discussion and 
>>>>>>> increasing code complexity.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Common comments to both A and B.
>>>>>>>>>
>>>>>>>>> I'll need more time to look at B; it would be cleaner to use A 
>>>>>>>>> if it can address the issue.
>>>>>>>>> The alternative is to duplicate the code in run() in the 
>>>>>>>>> TestLibrary and not modify the RegistryImpl.
>>>>>>>> I prefer B, because
>>>>>>>>   1. Although A looks cleaner but B is simulating more like 
>>>>>>>> rmiregistry.
>>>>>>>>   2. There are some other issue for example JDK-7146543, 
>>>>>>>> JDK-8030950, JDK-8038772, fix based on version B works well, 
>>>>>>>> but fix based on version A fails.
>>>>>>>>   3. Impact of RegistryImpl modification is minimal. ( May we 
>>>>>>>> could make Registry run(String args[]) private and access it in 
>>>>>>>> test by reflection? )
>>>>>>>>   4. Although it's simple to duplicate the code in run() in the 
>>>>>>>> TestLibrary, but seems it's not a good design choice. (let's 
>>>>>>>> call it version C.)
>>>>>>>>   5. For JDK-8170728, the fix will need to modify 
>>>>>>>> sun.rmi.registry.RegistryImpl anyway.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you for detailed review comments below.
>>>>>>>> As we have several options, I will wait for your further 
>>>>>>>> comments on choice of version A/B/C, then send out new webrev, 
>>>>>>>> hope I only need to send out one version :-).
>>>>>>>>
>>>>>>>> Thank you
>>>>>>>> -Hamlin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> JavaVM:
>>>>>>>>>  - Document the new methods.
>>>>>>>>>
>>>>>>>>> Line 232: Document the exception that may be thrown from 
>>>>>>>>> exitValue.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> RMID:
>>>>>>>>> Line 204, 222: when adding new functions to the test library 
>>>>>>>>> please add documentation for the methods.
>>>>>>>>> There are now many variations of the methods that differ only 
>>>>>>>>> by the number arguments.
>>>>>>>>> It would be better if the name included some hint as to the 
>>>>>>>>> additional functionality.
>>>>>>>>>
>>>>>>>>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>>>>>>>>
>>>>>>>>> REGISTRY:
>>>>>>>>>   - Document the new methods.
>>>>>>>>>
>>>>>>>>>   - The name should be more indicative of its function and 
>>>>>>>>> should NOT be all caps;  RMID is an acronym where the caps 
>>>>>>>>> make sense.
>>>>>>>>>
>>>>>>>>>   - line 105: use JavaVM.waitFor(timeout) and avoid 
>>>>>>>>> duplicating code to wait for the subprocess.
>>>>>>>>>
>>>>>>>>>   - If the subprocesses are in an unknown state it would be 
>>>>>>>>> useful to print diagnostic info from the subprocess before 
>>>>>>>>> terminating.
>>>>>>>>>     Line 106:
>>>>>>>>>
>>>>>>>>>  - Line 124:
>>>>>>>>>  - I think I would have promoted the shutdown method to JavaVM 
>>>>>>>>> instead of creating a new cleanup method
>>>>>>>>>    to keep the code simpler.
>>>>>>>>>
>>>>>>>>>    ** The cleanup method never calls super.cleanup() so the 
>>>>>>>>> process is never destroyed!.
>>>>>>>>>
>>>>>>>>> AltSecurityManager.java:
>>>>>>>>>
>>>>>>>>>  - Line 61: the empty constructor can be removed entirely.
>>>>>>>>>
>>>>>>>>>  - Line 80: change the message to say the exception did not 
>>>>>>>>> occur.
>>>>>>>>>     As written it implies it may have occurred but was not 
>>>>>>>>> caught.
>>>>>>>>>
>>>>>>>>>  - Line 86: typo "a unexpected" -> "an unexpected"
>>>>>>>>>
>>>>>>>>> - Line 90: remove the printStackTrace; it is not useful and is 
>>>>>>>>> a red flag in .jtr files
>>>>>>>>>
>>>>>>>>>  - Line 125: I don't see that cleanup is better than destroy; 
>>>>>>>>> If there are doubts about destroy
>>>>>>>>>    then destroy should be fixed not avoided.
>>>>>>>>>
>>>>>>>>> Roger
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>>>>>>>>> Would you please review the below patches?
>>>>>>>>>>
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>>>>>>>>> webrev (version A): 
>>>>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>>>>>>>>> webrev (version B): 
>>>>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> There are 2 versions to be reviewed.
>>>>>>>>>>
>>>>>>>>>> In version A, just use RegistryRunner to replace rmiregistry.
>>>>>>>>>> In version B, refactor sun.rmi.registry.RegistryImpl to 
>>>>>>>>>> improve the testability of RMI code, and create/use 
>>>>>>>>>> RMIRegistryRunner to simulate rmiregistry.
>>>>>>>>>>
>>>>>>>>>> Thank you
>>>>>>>>>> -Hamlin
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From paul.sandoz at oracle.com  Mon Jan  9 22:07:02 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 9 Jan 2017 14:07:02 -0800
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <CA+kOe08MkALjjxR8X+7EjanofCPw2PtxFh_7ZiwEJHtwN1=c0A@mail.gmail.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
	<d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
	<CA+kOe09tSLRR_DRDMf7fzQGRpf9uG4RMm=srKGWEbU3FSTaTbA@mail.gmail.com>
	<58DC5C59-1F78-450F-A43A-B8578B77CF9E@oracle.com>
	<CA+kOe08MkALjjxR8X+7EjanofCPw2PtxFh_7ZiwEJHtwN1=c0A@mail.gmail.com>
Message-ID: <0E07F1EF-F5D1-464D-8901-B4C86529DA2A@oracle.com>


> On 9 Jan 2017, at 13:27, Martin Buchholz <martinrb at google.com> wrote:
> 
> My whitebox tests tend to use private access only for reading, but I can imagine cases where it is useful to give testing code stronger access than for regular VarHandles, maybe even to write final fields, for example for fuzz testing or reliably creating an internal state that can only happen with a race.  There's may be a case for providing such a big hammer, if it's sufficiently hard to get at, but I can live without it.
> 

That big hammer could be jdk.internal.misc.Unsafe for certain tightly bound tests that really need it.


> My preference would be to encourage people to use MethodHandles.privateLookupIn.
> 
> I'm a convert!

Great!


> It will take a while for privateLookupIn to become "common knowledge".
> 

I shall endeavour to mention it at Devoxx US in March where John and I will present on java.lang.invoke.

Paul.

From Roger.Riggs at Oracle.com  Mon Jan  9 22:17:28 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 9 Jan 2017 17:17:28 -0500
Subject: RFR (JAXP) 8171243 : CatalogManager.catalogResolver throws
	FileSystemNotFoundException with jar
In-Reply-To: <3cfcba76-6436-92ec-5174-747318fa9ff5@oracle.com>
References: <3cfcba76-6436-92ec-5174-747318fa9ff5@oracle.com>
Message-ID: <25f1ea5e-a2cd-83c2-8f49-346fc9ff2350@Oracle.com>

Hi Joe,

a few comments:

CatalogManager:
  - line 58:  "will /return /as no mapping is found";
   Or is it describing the behavior of the CatalogResolver (which is 
throw a CatalogException)?
    (possible more than 1 place)

Check the copyrights -> 2017  (JarUtils.java)

in JAXWS repo:
  - Options.java:  line 786 - you could use URI[]::new instead of 
creating a placeholder URI[0].

Looks good,  Roger


On 1/9/2017 12:38 PM, huizhe wang wrote:
> Hi,
>
> The current Catalog API accepts file paths or URIs in a form of String 
> to create Catalog or CatalogResolver in an effort to maintain 
> consistency with the old Catalog API and other existing processors. 
> However, that also introduced an ambiguity in the API, which is 
> unwanted for a new API in Java SE 9.
>
> Please review the changes.
> In jaxp repo:
> http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/
>
> In jaxws repo:
> http://cr.openjdk.java.net/~joehw/jdk9/8171243_jaxws/webrev/
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8171243
>
> Thanks,
> Joe
>


From paul.sandoz at oracle.com  Mon Jan  9 22:21:48 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 9 Jan 2017 14:21:48 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <5873D4A0.204@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
Message-ID: <0C4D9E1D-24F7-4A31-A1B1-B4AB4B9CB9C4@oracle.com>

Hi,

A nice cleanup.

At this time of year: usual review comment to update the years in the license.


Main
?

 987                 jentries.stream().forEach( je -> addPackageIfNamed(packages, je));

If you wish you can remove the ?.stream()? and go straight to ?.forEach(?)? on the Set.


1870     private static boolean isModuleInfoEntry(String name) {
1871         // root or versioned module-info.class
1872         return name.endsWith(MODULE_INFO) &&
1873             (name.length() == MODULE_INFO.length() || name.startsWith(VERSIONS_DIR));

Is this sufficient? For the versioned case do we need to check it is VERSIONS_DIR/{n}/MODULE_INFO ?


Validator
?

  56     private final int vdlen = VERSIONS_DIR.length();

Can be static.


ConcealedPackage
?

Should the class be renamed?

Paul.



> On 9 Jan 2017, at 10:21, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi,
> 
> Please review the following proposed changes for jar tool
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8172432
> webrev: http://cr.openjdk.java.net/~sherman/8172432/webrev
>              http://cr.openjdk.java.net/~sherman/8172432/webrev_top/
> 
> (1) move the "packages" and "jarEntries" from "global" to "local", and only collect
> the  info when needed (if there is a module-info and we indeed need these info
> to update the module-info.class). The goal is to avoid/reduce any possible performance
> regression/impact to those"non-module" jar file creation and update operations.
> The proposed implementation now collects such info after "expand()" for "creation"
> if there is "module-info.class". For "update" it is done during the "updating"
> 
> (2) consolidate all "validation" related implementation into Validator.java. The
> "concealedPkgs" now is generated from the base 'module-info.class" from the
> resulting temporary jar file directly, instead of the "module-info.class" binary during
> the creation/update. Again, the reasoning is that the "validation" is only needed
> for the mr module jar (for now), it is not needed for a "normal" module jar file.
> A clear separation helps reducing the performance impact and improving the
> maintainability.
> 
> (3) remove the "checkModuleInfos" logic/implementation, which incorrectly enforces
> the restriction such as
>     a) there must always be, at least, a root module-info, when there is an entry that
>         has a name ended up with "module-info.class" in the jar file.
>     b) module-info.class file can only be at root or a versioned folder. (why I can't jar
>         a foo.jar that has a entry module-info.class at an arbitrary place?)
> 
> (4) consolidate and share the "updateModuleInfo()" for both creation and update.
> 
> (5) no longer always copy the "mainClass" and "version" attributes from the root
> module-info.class into the corresponding versioned module-info.class "silently"
> (in extendedInfoBytes()). Instead, the difference between the root module-info.class
> and its versioned copy is checked, jar fails if there is inconsistence.
> 
> (6) clean up the Entry class and the expand() implementation. It appears the Entry
> class might not be absolutely necessary, but I keep it as is for now.
> 
> (7) build the jar with -XDstringConcat=inline flag.
> 
> thanks,
> Sherman


From huaming.li at oracle.com  Mon Jan  9 22:31:22 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Mon, 9 Jan 2017 14:31:22 -0800
Subject: RFR of JDK-8172347: Refactoring
	src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to
	improve testability of rmiregistry
In-Reply-To: <2300b082-81c9-c0c6-5f32-0fc7699e4178@Oracle.com>
References: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com>
	<827c1058-4cc2-9639-3a39-0efebab8c038@Oracle.com>
	<0a470a7b-8f6d-e774-e4f1-c6ad43eefa06@oracle.com>
	<5d65e028-5f6c-557b-4a87-86658c6a426f@Oracle.com>
	<6432c6de-af93-5224-f848-8e2e8f0f7c9f@oracle.com>
	<888af0b3-24ee-826a-7449-f3eece8ab9f8@Oracle.com>
	<2eecc91f-019a-024d-a48f-27930137cb09@oracle.com>
	<48bdbd18-f420-e526-2278-0506d02ee443@oracle.com>
	<7bf34238-0ea3-1bc8-7d72-84ceaedd225e@Oracle.com>
	<8a1b4651-8680-b615-9e16-dab6ab738b66@oracle.com>
	<2300b082-81c9-c0c6-5f32-0fc7699e4178@Oracle.com>
Message-ID: <81bb8605-3263-46e5-dff2-15c5d9683444@oracle.com>


On 2017/1/9 13:55, Roger Riggs wrote:
> Hi Hamlin,
>
> Its time to use 2017 for copyright dates.
Hi Roger,
Yes, the new year! :-)
>
> The method name launch does not reflect is really happening.
> Launch implies an active process or thread is being started.
> But in this case there is no active element; it just creates and 
> exports a remote object.
> Otherwise, looks fine.
modified as createRegistry.
the code is pushed.

Thank you
-Hamlin
>
> Thanks, Roger
>
>
> On 1/9/2017 4:49 PM, Hamlin Li wrote:
>> Hi Roger,
>>
>> Thank you for reviewing, please check the comments inline, and new 
>> webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.03/
>>
>> Thank you
>> -Hamlin
>>
>> On 2017/1/9 13:04, Roger Riggs wrote:
>>> Hi Hamlin,
>>>
>>> In addition to Mark's comments:
>>>
>>> How about this for the method comment:
>>>
>>> /**
>>>   * Return a new RegistryImpl on the requested port and export it to 
>>> serve registry requests.
>>>   * A classloader is initialized from the system property 
>>> "env.class.path" and
>>>   * a security manager is set unless one is already set.
>>>   * <p>
>>>   * The returned Registry is fully functional within the current 
>>> process and is usable for
>>>   * internal and testing purposes.
>>>   *
>>>   * @param regPort port on which the rmiregistry accepts requests;
>>>   *                            if 0, an implementation specific port 
>>> is assigned
>>>   * @return a RegistryImpl instance
>>>   * @exception RemoteException If remote operation failed.
>>>   * @since 9
>>>   */
>> Your java doc looks more clear, modified.
>>>     public static RegistryImpl run(int regPort) throws 
>>> RemoteException {...}
>>>
>>> The method should throw RemoteException. Throws clauses should 
>>> always be as specific as possible.
>> modified throws.
>>>
>>> On 1/9/2017 9:36 AM, Mark Sheppard wrote:
>>>> Hi Hamlin,
>>>>
>>>> If I read the changes correctly, there would appear to be a side 
>>>> effect of your refactor extract method "run", such that the static 
>>>> member variable
>>>> registry is no longer set in the main method, and is set in the run 
>>>> method ? Thus, invoking run multiple times (, whether that is 
>>>> intended or not,) will
>>>> see the registry static member variable overwritten, for each call. 
>>>> While the current implementation that will occur once only within 
>>>> the main method.
>>>> So, what's the desired semantics for multiple "run" calls?
>>> The static  registry field is never used and can/should be removed.
>>> It can be handled with a local in the method.
>> handled in a local in the method, and assign it to registry in man.
>>>>
>>>>  A "run" method is synonymous with Runnable interface, even though 
>>>> this run method has a different signature, it's better
>>>> to help us unwary avoid confusion!
>>>> Also the run method instantiates and returns a RegistryImpl, thus 
>>>> exhibiting factory method characteristics.
>>>> As such, perhaps a refactor "rename" would be in order, such as 
>>>> create, execute, or launch ?
>>> +1,  perhaps createRegistry(int port)
>>>
>> use launch, createRegistry makes me think of it as the same of 
>> LocateRegistry.createRegistry.
>>>
>>>>
>>>> It would be helpful to provide a current summary, or a recap, as to 
>>>> the motivation for the refactoring.
>>> That can be in the test or the bug report; the implementation code 
>>> itself should describe the functionality
>>> and its use.
>> will do it in test.
>>>
>>> $.02, Roger
>>>
>>>>
>>>> Is this complimentary to the constructor RegistryImp(int port) or 
>>>> LocateRegistry.createRegistry( ..)  ?
>>>>
>>>>
>>>> regards
>>>> Mark
>>>>
>>>>
>>>>
>>>> On 09/01/2017 07:56, Hamlin Li wrote:
>>>>> Hi Roger,
>>>>>
>>>>> Thank you for reviewing, please check new webrev: 
>>>>> http://cr.openjdk.java.net/~mli/8172347/webrev.01/
>>>>>
>>>>> Thank you
>>>>> -Hamlin
>>>>>
>>>>> On 2017/1/6 12:56, Roger Riggs wrote:
>>>>>> Hi Hamlin,
>>>>>>
>>>>>> Yes, that looks better.
>>>>>>
>>>>>> On the comments, use the normal javadoc comment conventions for 
>>>>>> any public API.
>>>>>> @param @return, @throw, etc.
>>>>>>
>>>>>> I think comments should be direct about what the function does. 
>>>>>> It does not need
>>>>>> to explain why so much.  Or if so, later and in a separate 
>>>>>> paragraph;  when reading
>>>>>> the most important information should be first.
>>>>>>
>>>>>> Thanks, Roger
>>>>>>
>>>>>>
>>>>>> On 1/6/2017 4:59 AM, Hamlin Li wrote:
>>>>>>>
>>>>>>> On 2017/1/6 6:15, Roger Riggs wrote:
>>>>>>>> Hi Hamlin,
>>>>>>>>
>>>>>>>> There are too many issues being mixed together...
>>>>>>>>
>>>>>>>> Comments on B) RegistryImpl:
>>>>>>>>
>>>>>>>> Refactoring of RegistryImpl Main should be clean and clearly 
>>>>>>>> separated.
>>>>>>> Hi Roger,
>>>>>>>
>>>>>>> Thank you for reviewing.
>>>>>>> Not sure if I understood you correctly, I created a new bug to 
>>>>>>> track refactoring of RegistryImpl, I will send out separate 
>>>>>>> reviews for AltSecurityManager in JDK-8172314, JDK-8030175. 
>>>>>>> Please let me know if you did not mean it.
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8172347
>>>>>>> webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.00/, fix 
>>>>>>> all the below points.
>>>>>>>
>>>>>>> Thank you
>>>>>>> -Hamlin
>>>>>>>>
>>>>>>>> 365: static void RegistryImpl run():
>>>>>>>>
>>>>>>>> -  The signature of run should be run(int port) and documented 
>>>>>>>> as needing to be run in its
>>>>>>>>    own thread since it changes Thread context classloader and 
>>>>>>>> that it sets a securityManager.
>>>>>>>>    Leave it to main to parse and choose a port number.
>>>>>>>>
>>>>>>>> -  The comments should be functional as to the purpose of the 
>>>>>>>> code and not referencing a particular bug.
>>>>>>>>    (Regardless of prior example).
>>>>>>>>
>>>>>>>>  - The comment about getting the exact port is out of place 
>>>>>>>> because the port number cannot be
>>>>>>>>    retrieved from the returned RegistryImpl.  IF that's why 
>>>>>>>> this refactoring is needed, then
>>>>>>>>    perhaps there should be a getPort method that extracts it 
>>>>>>>> from the created UnicastServerRef.
>>>>>>>>
>>>>>>>> 423: static void main(String[] args):
>>>>>>>>
>>>>>>>>  - Parsing of args should be left in main(); avoiding the 
>>>>>>>> question about why NumberFormat is handled.
>>>>>>>>
>>>>>>>>  - Either main or run should set a security manager; but not both.
>>>>>>>>
>>>>>>>> Roger
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/4/2017 10:21 PM, Hamlin Li wrote:
>>>>>>>>> Hi Roger,
>>>>>>>>>
>>>>>>>>> Thank you for reviewing, please check comments inline.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2017/1/5 4:18, Roger Riggs wrote:
>>>>>>>>>> Hi Hamlin,
>>>>>>>>>>
>>>>>>>>>> The original issue with timeout may be due to heavily loaded 
>>>>>>>>>> systems and short timeouts.
>>>>>>>>>> 15 sec is not enough on an overloaded system to wait for a 
>>>>>>>>>> process to start and then die.
>>>>>>>>>>
>>>>>>>>>> There is no indication in this issue about port-in-use; that 
>>>>>>>>>> would be a different issue.
>>>>>>>>> Agree, I put 2 fixes in one patch together as there is no port 
>>>>>>>>> in use issue reported, but by reviewing the code, potential 
>>>>>>>>> port in use issue could happen some time in the future.
>>>>>>>> Best to keep 1-1 to avoid complicating the discussion and 
>>>>>>>> increasing code complexity.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Common comments to both A and B.
>>>>>>>>>>
>>>>>>>>>> I'll need more time to look at B; it would be cleaner to use 
>>>>>>>>>> A if it can address the issue.
>>>>>>>>>> The alternative is to duplicate the code in run() in the 
>>>>>>>>>> TestLibrary and not modify the RegistryImpl.
>>>>>>>>> I prefer B, because
>>>>>>>>>   1. Although A looks cleaner but B is simulating more like 
>>>>>>>>> rmiregistry.
>>>>>>>>>   2. There are some other issue for example JDK-7146543, 
>>>>>>>>> JDK-8030950, JDK-8038772, fix based on version B works well, 
>>>>>>>>> but fix based on version A fails.
>>>>>>>>>   3. Impact of RegistryImpl modification is minimal. ( May we 
>>>>>>>>> could make Registry run(String args[]) private and access it 
>>>>>>>>> in test by reflection? )
>>>>>>>>>   4. Although it's simple to duplicate the code in run() in 
>>>>>>>>> the TestLibrary, but seems it's not a good design choice. 
>>>>>>>>> (let's call it version C.)
>>>>>>>>>   5. For JDK-8170728, the fix will need to modify 
>>>>>>>>> sun.rmi.registry.RegistryImpl anyway.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thank you for detailed review comments below.
>>>>>>>>> As we have several options, I will wait for your further 
>>>>>>>>> comments on choice of version A/B/C, then send out new webrev, 
>>>>>>>>> hope I only need to send out one version :-).
>>>>>>>>>
>>>>>>>>> Thank you
>>>>>>>>> -Hamlin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> JavaVM:
>>>>>>>>>>  - Document the new methods.
>>>>>>>>>>
>>>>>>>>>> Line 232: Document the exception that may be thrown from 
>>>>>>>>>> exitValue.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> RMID:
>>>>>>>>>> Line 204, 222: when adding new functions to the test library 
>>>>>>>>>> please add documentation for the methods.
>>>>>>>>>> There are now many variations of the methods that differ only 
>>>>>>>>>> by the number arguments.
>>>>>>>>>> It would be better if the name included some hint as to the 
>>>>>>>>>> additional functionality.
>>>>>>>>>>
>>>>>>>>>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>>>>>>>>>
>>>>>>>>>> REGISTRY:
>>>>>>>>>>   - Document the new methods.
>>>>>>>>>>
>>>>>>>>>>   - The name should be more indicative of its function and 
>>>>>>>>>> should NOT be all caps;  RMID is an acronym where the caps 
>>>>>>>>>> make sense.
>>>>>>>>>>
>>>>>>>>>>   - line 105: use JavaVM.waitFor(timeout) and avoid 
>>>>>>>>>> duplicating code to wait for the subprocess.
>>>>>>>>>>
>>>>>>>>>>   - If the subprocesses are in an unknown state it would be 
>>>>>>>>>> useful to print diagnostic info from the subprocess before 
>>>>>>>>>> terminating.
>>>>>>>>>>     Line 106:
>>>>>>>>>>
>>>>>>>>>>  - Line 124:
>>>>>>>>>>  - I think I would have promoted the shutdown method to 
>>>>>>>>>> JavaVM instead of creating a new cleanup method
>>>>>>>>>>    to keep the code simpler.
>>>>>>>>>>
>>>>>>>>>>    ** The cleanup method never calls super.cleanup() so the 
>>>>>>>>>> process is never destroyed!.
>>>>>>>>>>
>>>>>>>>>> AltSecurityManager.java:
>>>>>>>>>>
>>>>>>>>>>  - Line 61: the empty constructor can be removed entirely.
>>>>>>>>>>
>>>>>>>>>>  - Line 80: change the message to say the exception did not 
>>>>>>>>>> occur.
>>>>>>>>>>     As written it implies it may have occurred but was not 
>>>>>>>>>> caught.
>>>>>>>>>>
>>>>>>>>>>  - Line 86: typo "a unexpected" -> "an unexpected"
>>>>>>>>>>
>>>>>>>>>> - Line 90: remove the printStackTrace; it is not useful and 
>>>>>>>>>> is a red flag in .jtr files
>>>>>>>>>>
>>>>>>>>>>  - Line 125: I don't see that cleanup is better than destroy; 
>>>>>>>>>> If there are doubts about destroy
>>>>>>>>>>    then destroy should be fixed not avoided.
>>>>>>>>>>
>>>>>>>>>> Roger
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>>>>>>>>>> Would you please review the below patches?
>>>>>>>>>>>
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>>>>>>>>>> webrev (version A): 
>>>>>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>>>>>>>>>> webrev (version B): 
>>>>>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> There are 2 versions to be reviewed.
>>>>>>>>>>>
>>>>>>>>>>> In version A, just use RegistryRunner to replace rmiregistry.
>>>>>>>>>>> In version B, refactor sun.rmi.registry.RegistryImpl to 
>>>>>>>>>>> improve the testability of RMI code, and create/use 
>>>>>>>>>>> RMIRegistryRunner to simulate rmiregistry.
>>>>>>>>>>>
>>>>>>>>>>> Thank you
>>>>>>>>>>> -Hamlin
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From martinrb at google.com  Mon Jan  9 22:45:45 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 9 Jan 2017 14:45:45 -0800
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <0E07F1EF-F5D1-464D-8901-B4C86529DA2A@oracle.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
	<d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
	<CA+kOe09tSLRR_DRDMf7fzQGRpf9uG4RMm=srKGWEbU3FSTaTbA@mail.gmail.com>
	<58DC5C59-1F78-450F-A43A-B8578B77CF9E@oracle.com>
	<CA+kOe08MkALjjxR8X+7EjanofCPw2PtxFh_7ZiwEJHtwN1=c0A@mail.gmail.com>
	<0E07F1EF-F5D1-464D-8901-B4C86529DA2A@oracle.com>
Message-ID: <CA+kOe0_LEQgjQXw5WvR=BKtDjL5N-P0gDXqGEvCYqNn1bRyvHA@mail.gmail.com>

I followed up on my own suggestion and wrote a race-simulating test without
the big hammer:

    /**
     * Checks that traversal operations collapse a random pattern of
     * dead nodes as could normally only occur with a race.
     */
    @Test(dataProvider = "traversalActions")
    public void traversalOperationsCollapseNodes(
        Consumer<LinkedTransferQueue> traversalAction) {
        LinkedTransferQueue q = new LinkedTransferQueue();
        int n = rnd.nextInt(6);
        for (int i = 0; i < n; i++) q.add(i);
        ArrayList nulledOut = new ArrayList();
        for (Object p = head(q); p != null; p = next(p))
            if (rnd.nextBoolean()) {
                nulledOut.add(item(p));
                ITEM.setVolatile(p, null);
            }
        traversalAction.accept(q);
        if (n == 0)
            assertEquals(nodeCount(q), 0);
        else {
            int c = nodeCount(q);
            assertEquals(q.size(), c - (q.contains(n - 1) ? 0 : 1));
            for (int i = 0; i < n; i++)
                assertTrue(nulledOut.contains(i) ^ q.contains(i));
        }
    }


On Mon, Jan 9, 2017 at 2:07 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> On 9 Jan 2017, at 13:27, Martin Buchholz <martinrb at google.com> wrote:
>
> My whitebox tests tend to use private access only for reading, but I can
> imagine cases where it is useful to give testing code stronger access than
> for regular VarHandles, maybe even to write final fields, for example for
> fuzz testing or reliably creating an internal state that can only happen
> with a race.  There's may be a case for providing such a big hammer, if
> it's sufficiently hard to get at, but I can live without it.
>
>
>
> That big hammer could be jdk.internal.misc.Unsafe for certain tightly
> bound tests that really need it.
>
>
> My preference would be to encourage people to use
>> MethodHandles.privateLookupIn.
>>
>
> I'm a convert!
>
>
> Great!
>
>
> It will take a while for privateLookupIn to become "common knowledge".
>
>
> I shall endeavour to mention it at Devoxx US in March where John and I
> will present on java.lang.invoke.
>
> Paul.
>

From mandy.chung at oracle.com  Mon Jan  9 23:46:55 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 9 Jan 2017 15:46:55 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <5873D4A0.204@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
Message-ID: <0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>


> On Jan 9, 2017, at 10:21 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi, 
> 
> Please review the following proposed changes for jar tool
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8172432 <https://bugs.openjdk.java.net/browse/JDK-8172432>
> webrev: http://cr.openjdk.java.net/~sherman/8172432/webrev <http://cr.openjdk.java.net/~sherman/8172432/webrev>
>              http://cr.openjdk.java.net/~sherman/8172432/webrev_top/ <http://cr.openjdk.java.net/~sherman/8172432/webrev_top/>
> 

This is a good cleanup.  This makes it easier to add any further validation such as JDK-8171830.

Main.java
 693                     warn("unexpected versioned entry: " + name);

Should this message be localized?  
1870     private static boolean isModuleInfoEntry(String name) {
1871         // root or versioned module-info.class
1872         return name.endsWith(MODULE_INFO) &&
1873             (name.length() == MODULE_INFO.length() || name.startsWith(VERSIONS_DIR));
This should return true if it starts with VERSIONS_DIR and the entry with ?/module-info.class"

Validator.java
 314             } catch (Exception x) {}

Would it be better to report the error if any exception thrown rather than silently swallowing it?

Otherwise looks good.

Mandy


From huizhe.wang at oracle.com  Tue Jan 10 00:54:17 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 9 Jan 2017 16:54:17 -0800
Subject: RFR (JAXP) 8171243 : CatalogManager.catalogResolver throws
	FileSystemNotFoundException with jar
In-Reply-To: <25f1ea5e-a2cd-83c2-8f49-346fc9ff2350@Oracle.com>
References: <3cfcba76-6436-92ec-5174-747318fa9ff5@oracle.com>
	<25f1ea5e-a2cd-83c2-8f49-346fc9ff2350@Oracle.com>
Message-ID: <0d5d12ca-5ad4-5d38-9484-4b6d7d82fae5@oracle.com>


On 1/9/2017 2:17 PM, Roger Riggs wrote:
> Hi Joe,
>
> a few comments:
>
> CatalogManager:
>  - line 58:  "will /return /as no mapping is found";
>   Or is it describing the behavior of the CatalogResolver (which is 
> throw a CatalogException)?
>    (possible more than 1 place)

Should have been empty Catalog object in this case. I'll re-submit the 
spec change.

>
> Check the copyrights -> 2017  (JarUtils.java)
>
> in JAXWS repo:
>  - Options.java:  line 786 - you could use URI[]::new instead of 
> creating a placeholder URI[0].

Ok, will change that of XmlUtil.java as well.

Thanks,
Joe

>
> Looks good,  Roger
>
>
> On 1/9/2017 12:38 PM, huizhe wang wrote:
>> Hi,
>>
>> The current Catalog API accepts file paths or URIs in a form of 
>> String to create Catalog or CatalogResolver in an effort to maintain 
>> consistency with the old Catalog API and other existing processors. 
>> However, that also introduced an ambiguity in the API, which is 
>> unwanted for a new API in Java SE 9.
>>
>> Please review the changes.
>> In jaxp repo:
>> http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/
>>
>> In jaxws repo:
>> http://cr.openjdk.java.net/~joehw/jdk9/8171243_jaxws/webrev/
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8171243
>>
>> Thanks,
>> Joe
>>
>


From asim2025 at yahoo.com  Tue Jan 10 01:07:23 2017
From: asim2025 at yahoo.com (Asim Aslam)
Date: Mon, 9 Jan 2017 20:07:23 -0500
Subject: core-libs-dev Digest, Vol 117, Issue 23
In-Reply-To: <mailman.3376.1484001951.12703.core-libs-dev@openjdk.java.net>
References: <mailman.3376.1484001951.12703.core-libs-dev@openjdk.java.net>
Message-ID: <765F5CF1-7E27-4775-8076-2B5B82936267@yahoo.com>



> On Jan 9, 2017, at 5:45 PM, core-libs-dev-request at openjdk.java.net wrote:
> 
> Send core-libs-dev mailing list submissions to
>    core-libs-dev at openjdk.java.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
> or, via email, send a message with subject or body 'help' to
>    core-libs-dev-request at openjdk.java.net
> 
> You can reach the person managing the list at
>    core-libs-dev-owner at openjdk.java.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of core-libs-dev digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: RFR (JAXP) 8171243 : CatalogManager.catalogResolver
>      throws    FileSystemNotFoundException with jar (Roger Riggs)
>   2. Re: RFR: JDK-8172432,jar cleanup/update for module and mrm
>      jar (Paul Sandoz)
>   3. Re: RFR of JDK-8172347: Refactoring
>      src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to
>      improve testability of rmiregistry (Hamlin Li)
>   4. Re: jdk.internal.reflect.ReflectionFactory and
>      SecurityManager (Martin Buchholz)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 9 Jan 2017 17:17:28 -0500
> From: Roger Riggs <Roger.Riggs at Oracle.com>
> To: core-libs-dev at openjdk.java.net
> Subject: Re: RFR (JAXP) 8171243 : CatalogManager.catalogResolver
>    throws    FileSystemNotFoundException with jar
> Message-ID: <25f1ea5e-a2cd-83c2-8f49-346fc9ff2350 at Oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Hi Joe,
> 
> a few comments:
> 
> CatalogManager:
>  - line 58:  "will /return /as no mapping is found";
>   Or is it describing the behavior of the CatalogResolver (which is 
> throw a CatalogException)?
>    (possible more than 1 place)
> 
> Check the copyrights -> 2017  (JarUtils.java)
> 
> in JAXWS repo:
>  - Options.java:  line 786 - you could use URI[]::new instead of 
> creating a placeholder URI[0].
> 
> Looks good,  Roger
> 
> 
>> On 1/9/2017 12:38 PM, huizhe wang wrote:
>> Hi,
>> 
>> The current Catalog API accepts file paths or URIs in a form of String 
>> to create Catalog or CatalogResolver in an effort to maintain 
>> consistency with the old Catalog API and other existing processors. 
>> However, that also introduced an ambiguity in the API, which is 
>> unwanted for a new API in Java SE 9.
>> 
>> Please review the changes.
>> In jaxp repo:
>> http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/
>> 
>> In jaxws repo:
>> http://cr.openjdk.java.net/~joehw/jdk9/8171243_jaxws/webrev/
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8171243
>> 
>> Thanks,
>> Joe
>> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 9 Jan 2017 14:21:48 -0800
> From: Paul Sandoz <paul.sandoz at oracle.com>
> To: Xueming Shen <xueming.shen at oracle.com>
> Cc: "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8172432,jar cleanup/update for module and mrm
>    jar
> Message-ID: <0C4D9E1D-24F7-4A31-A1B1-B4AB4B9CB9C4 at oracle.com>
> Content-Type: text/plain;    charset=windows-1252
> 
> Hi,
> 
> A nice cleanup.
> 
> At this time of year: usual review comment to update the years in the license.
> 
> 
> Main
> ?
> 
> 987                 jentries.stream().forEach( je -> addPackageIfNamed(packages, je));
> 
> If you wish you can remove the ?.stream()? and go straight to ?.forEach(?)? on the Set.
> 
> 
> 1870     private static boolean isModuleInfoEntry(String name) {
> 1871         // root or versioned module-info.class
> 1872         return name.endsWith(MODULE_INFO) &&
> 1873             (name.length() == MODULE_INFO.length() || name.startsWith(VERSIONS_DIR));
> 
> Is this sufficient? For the versioned case do we need to check it is VERSIONS_DIR/{n}/MODULE_INFO ?
> 
> 
> Validator
> ?
> 
>  56     private final int vdlen = VERSIONS_DIR.length();
> 
> Can be static.
> 
> 
> ConcealedPackage
> ?
> 
> Should the class be renamed?
> 
> Paul.
> 
> 
> 
>> On 9 Jan 2017, at 10:21, Xueming Shen <xueming.shen at oracle.com> wrote:
>> 
>> Hi,
>> 
>> Please review the following proposed changes for jar tool
>> 
>> issue: https://bugs.openjdk.java.net/browse/JDK-8172432
>> webrev: http://cr.openjdk.java.net/~sherman/8172432/webrev
>>             http://cr.openjdk.java.net/~sherman/8172432/webrev_top/
>> 
>> (1) move the "packages" and "jarEntries" from "global" to "local", and only collect
>> the  info when needed (if there is a module-info and we indeed need these info
>> to update the module-info.class). The goal is to avoid/reduce any possible performance
>> regression/impact to those"non-module" jar file creation and update operations.
>> The proposed implementation now collects such info after "expand()" for "creation"
>> if there is "module-info.class". For "update" it is done during the "updating"
>> 
>> (2) consolidate all "validation" related implementation into Validator.java. The
>> "concealedPkgs" now is generated from the base 'module-info.class" from the
>> resulting temporary jar file directly, instead of the "module-info.class" binary during
>> the creation/update. Again, the reasoning is that the "validation" is only needed
>> for the mr module jar (for now), it is not needed for a "normal" module jar file.
>> A clear separation helps reducing the performance impact and improving the
>> maintainability.
>> 
>> (3) remove the "checkModuleInfos" logic/implementation, which incorrectly enforces
>> the restriction such as
>>    a) there must always be, at least, a root module-info, when there is an entry that
>>        has a name ended up with "module-info.class" in the jar file.
>>    b) module-info.class file can only be at root or a versioned folder. (why I can't jar
>>        a foo.jar that has a entry module-info.class at an arbitrary place?)
>> 
>> (4) consolidate and share the "updateModuleInfo()" for both creation and update.
>> 
>> (5) no longer always copy the "mainClass" and "version" attributes from the root
>> module-info.class into the corresponding versioned module-info.class "silently"
>> (in extendedInfoBytes()). Instead, the difference between the root module-info.class
>> and its versioned copy is checked, jar fails if there is inconsistence.
>> 
>> (6) clean up the Entry class and the expand() implementation. It appears the Entry
>> class might not be absolutely necessary, but I keep it as is for now.
>> 
>> (7) build the jar with -XDstringConcat=inline flag.
>> 
>> thanks,
>> Sherman
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 9 Jan 2017 14:31:22 -0800
> From: Hamlin Li <huaming.li at oracle.com>
> To: Roger Riggs <Roger.Riggs at oracle.com>,    core-libs-dev
>    <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR of JDK-8172347: Refactoring
>    src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java to
>    improve testability of rmiregistry
> Message-ID: <81bb8605-3263-46e5-dff2-15c5d9683444 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> 
>> On 2017/1/9 13:55, Roger Riggs wrote:
>> Hi Hamlin,
>> 
>> Its time to use 2017 for copyright dates.
> Hi Roger,
> Yes, the new year! :-)
>> 
>> The method name launch does not reflect is really happening.
>> Launch implies an active process or thread is being started.
>> But in this case there is no active element; it just creates and 
>> exports a remote object.
>> Otherwise, looks fine.
> modified as createRegistry.
> the code is pushed.
> 
> Thank you
> -Hamlin
>> 
>> Thanks, Roger
>> 
>> 
>>> On 1/9/2017 4:49 PM, Hamlin Li wrote:
>>> Hi Roger,
>>> 
>>> Thank you for reviewing, please check the comments inline, and new 
>>> webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.03/
>>> 
>>> Thank you
>>> -Hamlin
>>> 
>>>> On 2017/1/9 13:04, Roger Riggs wrote:
>>>> Hi Hamlin,
>>>> 
>>>> In addition to Mark's comments:
>>>> 
>>>> How about this for the method comment:
>>>> 
>>>> /**
>>>>  * Return a new RegistryImpl on the requested port and export it to 
>>>> serve registry requests.
>>>>  * A classloader is initialized from the system property 
>>>> "env.class.path" and
>>>>  * a security manager is set unless one is already set.
>>>>  * <p>
>>>>  * The returned Registry is fully functional within the current 
>>>> process and is usable for
>>>>  * internal and testing purposes.
>>>>  *
>>>>  * @param regPort port on which the rmiregistry accepts requests;
>>>>  *                            if 0, an implementation specific port 
>>>> is assigned
>>>>  * @return a RegistryImpl instance
>>>>  * @exception RemoteException If remote operation failed.
>>>>  * @since 9
>>>>  */
>>> Your java doc looks more clear, modified.
>>>>    public static RegistryImpl run(int regPort) throws 
>>>> RemoteException {...}
>>>> 
>>>> The method should throw RemoteException. Throws clauses should 
>>>> always be as specific as possible.
>>> modified throws.
>>>> 
>>>>> On 1/9/2017 9:36 AM, Mark Sheppard wrote:
>>>>> Hi Hamlin,
>>>>> 
>>>>> If I read the changes correctly, there would appear to be a side 
>>>>> effect of your refactor extract method "run", such that the static 
>>>>> member variable
>>>>> registry is no longer set in the main method, and is set in the run 
>>>>> method ? Thus, invoking run multiple times (, whether that is 
>>>>> intended or not,) will
>>>>> see the registry static member variable overwritten, for each call. 
>>>>> While the current implementation that will occur once only within 
>>>>> the main method.
>>>>> So, what's the desired semantics for multiple "run" calls?
>>>> The static  registry field is never used and can/should be removed.
>>>> It can be handled with a local in the method.
>>> handled in a local in the method, and assign it to registry in man.
>>>>> 
>>>>> A "run" method is synonymous with Runnable interface, even though 
>>>>> this run method has a different signature, it's better
>>>>> to help us unwary avoid confusion!
>>>>> Also the run method instantiates and returns a RegistryImpl, thus 
>>>>> exhibiting factory method characteristics.
>>>>> As such, perhaps a refactor "rename" would be in order, such as 
>>>>> create, execute, or launch ?
>>>> +1,  perhaps createRegistry(int port)
>>>> 
>>> use launch, createRegistry makes me think of it as the same of 
>>> LocateRegistry.createRegistry.
>>>> 
>>>>> 
>>>>> It would be helpful to provide a current summary, or a recap, as to 
>>>>> the motivation for the refactoring.
>>>> That can be in the test or the bug report; the implementation code 
>>>> itself should describe the functionality
>>>> and its use.
>>> will do it in test.
>>>> 
>>>> $.02, Roger
>>>> 
>>>>> 
>>>>> Is this complimentary to the constructor RegistryImp(int port) or 
>>>>> LocateRegistry.createRegistry( ..)  ?
>>>>> 
>>>>> 
>>>>> regards
>>>>> Mark
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 09/01/2017 07:56, Hamlin Li wrote:
>>>>>> Hi Roger,
>>>>>> 
>>>>>> Thank you for reviewing, please check new webrev: 
>>>>>> http://cr.openjdk.java.net/~mli/8172347/webrev.01/
>>>>>> 
>>>>>> Thank you
>>>>>> -Hamlin
>>>>>> 
>>>>>>> On 2017/1/6 12:56, Roger Riggs wrote:
>>>>>>> Hi Hamlin,
>>>>>>> 
>>>>>>> Yes, that looks better.
>>>>>>> 
>>>>>>> On the comments, use the normal javadoc comment conventions for 
>>>>>>> any public API.
>>>>>>> @param @return, @throw, etc.
>>>>>>> 
>>>>>>> I think comments should be direct about what the function does. 
>>>>>>> It does not need
>>>>>>> to explain why so much.  Or if so, later and in a separate 
>>>>>>> paragraph;  when reading
>>>>>>> the most important information should be first.
>>>>>>> 
>>>>>>> Thanks, Roger
>>>>>>> 
>>>>>>> 
>>>>>>>> On 1/6/2017 4:59 AM, Hamlin Li wrote:
>>>>>>>> 
>>>>>>>>> On 2017/1/6 6:15, Roger Riggs wrote:
>>>>>>>>> Hi Hamlin,
>>>>>>>>> 
>>>>>>>>> There are too many issues being mixed together...
>>>>>>>>> 
>>>>>>>>> Comments on B) RegistryImpl:
>>>>>>>>> 
>>>>>>>>> Refactoring of RegistryImpl Main should be clean and clearly 
>>>>>>>>> separated.
>>>>>>>> Hi Roger,
>>>>>>>> 
>>>>>>>> Thank you for reviewing.
>>>>>>>> Not sure if I understood you correctly, I created a new bug to 
>>>>>>>> track refactoring of RegistryImpl, I will send out separate 
>>>>>>>> reviews for AltSecurityManager in JDK-8172314, JDK-8030175. 
>>>>>>>> Please let me know if you did not mean it.
>>>>>>>> 
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8172347
>>>>>>>> webrev: http://cr.openjdk.java.net/~mli/8172347/webrev.00/, fix 
>>>>>>>> all the below points.
>>>>>>>> 
>>>>>>>> Thank you
>>>>>>>> -Hamlin
>>>>>>>>> 
>>>>>>>>> 365: static void RegistryImpl run():
>>>>>>>>> 
>>>>>>>>> -  The signature of run should be run(int port) and documented 
>>>>>>>>> as needing to be run in its
>>>>>>>>>   own thread since it changes Thread context classloader and 
>>>>>>>>> that it sets a securityManager.
>>>>>>>>>   Leave it to main to parse and choose a port number.
>>>>>>>>> 
>>>>>>>>> -  The comments should be functional as to the purpose of the 
>>>>>>>>> code and not referencing a particular bug.
>>>>>>>>>   (Regardless of prior example).
>>>>>>>>> 
>>>>>>>>> - The comment about getting the exact port is out of place 
>>>>>>>>> because the port number cannot be
>>>>>>>>>   retrieved from the returned RegistryImpl.  IF that's why 
>>>>>>>>> this refactoring is needed, then
>>>>>>>>>   perhaps there should be a getPort method that extracts it 
>>>>>>>>> from the created UnicastServerRef.
>>>>>>>>> 
>>>>>>>>> 423: static void main(String[] args):
>>>>>>>>> 
>>>>>>>>> - Parsing of args should be left in main(); avoiding the 
>>>>>>>>> question about why NumberFormat is handled.
>>>>>>>>> 
>>>>>>>>> - Either main or run should set a security manager; but not both.
>>>>>>>>> 
>>>>>>>>> Roger
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 1/4/2017 10:21 PM, Hamlin Li wrote:
>>>>>>>>>> Hi Roger,
>>>>>>>>>> 
>>>>>>>>>> Thank you for reviewing, please check comments inline.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On 2017/1/5 4:18, Roger Riggs wrote:
>>>>>>>>>>> Hi Hamlin,
>>>>>>>>>>> 
>>>>>>>>>>> The original issue with timeout may be due to heavily loaded 
>>>>>>>>>>> systems and short timeouts.
>>>>>>>>>>> 15 sec is not enough on an overloaded system to wait for a 
>>>>>>>>>>> process to start and then die.
>>>>>>>>>>> 
>>>>>>>>>>> There is no indication in this issue about port-in-use; that 
>>>>>>>>>>> would be a different issue.
>>>>>>>>>> Agree, I put 2 fixes in one patch together as there is no port 
>>>>>>>>>> in use issue reported, but by reviewing the code, potential 
>>>>>>>>>> port in use issue could happen some time in the future.
>>>>>>>>> Best to keep 1-1 to avoid complicating the discussion and 
>>>>>>>>> increasing code complexity.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Common comments to both A and B.
>>>>>>>>>>> 
>>>>>>>>>>> I'll need more time to look at B; it would be cleaner to use 
>>>>>>>>>>> A if it can address the issue.
>>>>>>>>>>> The alternative is to duplicate the code in run() in the 
>>>>>>>>>>> TestLibrary and not modify the RegistryImpl.
>>>>>>>>>> I prefer B, because
>>>>>>>>>>  1. Although A looks cleaner but B is simulating more like 
>>>>>>>>>> rmiregistry.
>>>>>>>>>>  2. There are some other issue for example JDK-7146543, 
>>>>>>>>>> JDK-8030950, JDK-8038772, fix based on version B works well, 
>>>>>>>>>> but fix based on version A fails.
>>>>>>>>>>  3. Impact of RegistryImpl modification is minimal. ( May we 
>>>>>>>>>> could make Registry run(String args[]) private and access it 
>>>>>>>>>> in test by reflection? )
>>>>>>>>>>  4. Although it's simple to duplicate the code in run() in 
>>>>>>>>>> the TestLibrary, but seems it's not a good design choice. 
>>>>>>>>>> (let's call it version C.)
>>>>>>>>>>  5. For JDK-8170728, the fix will need to modify 
>>>>>>>>>> sun.rmi.registry.RegistryImpl anyway.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Thank you for detailed review comments below.
>>>>>>>>>> As we have several options, I will wait for your further 
>>>>>>>>>> comments on choice of version A/B/C, then send out new webrev, 
>>>>>>>>>> hope I only need to send out one version :-).
>>>>>>>>>> 
>>>>>>>>>> Thank you
>>>>>>>>>> -Hamlin
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> JavaVM:
>>>>>>>>>>> - Document the new methods.
>>>>>>>>>>> 
>>>>>>>>>>> Line 232: Document the exception that may be thrown from 
>>>>>>>>>>> exitValue.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> RMID:
>>>>>>>>>>> Line 204, 222: when adding new functions to the test library 
>>>>>>>>>>> please add documentation for the methods.
>>>>>>>>>>> There are now many variations of the methods that differ only 
>>>>>>>>>>> by the number arguments.
>>>>>>>>>>> It would be better if the name included some hint as to the 
>>>>>>>>>>> additional functionality.
>>>>>>>>>>> 
>>>>>>>>>>> typo:  "additionalOptions" -> "add*i*tionalOptions"
>>>>>>>>>>> 
>>>>>>>>>>> REGISTRY:
>>>>>>>>>>>  - Document the new methods.
>>>>>>>>>>> 
>>>>>>>>>>>  - The name should be more indicative of its function and 
>>>>>>>>>>> should NOT be all caps;  RMID is an acronym where the caps 
>>>>>>>>>>> make sense.
>>>>>>>>>>> 
>>>>>>>>>>>  - line 105: use JavaVM.waitFor(timeout) and avoid 
>>>>>>>>>>> duplicating code to wait for the subprocess.
>>>>>>>>>>> 
>>>>>>>>>>>  - If the subprocesses are in an unknown state it would be 
>>>>>>>>>>> useful to print diagnostic info from the subprocess before 
>>>>>>>>>>> terminating.
>>>>>>>>>>>    Line 106:
>>>>>>>>>>> 
>>>>>>>>>>> - Line 124:
>>>>>>>>>>> - I think I would have promoted the shutdown method to 
>>>>>>>>>>> JavaVM instead of creating a new cleanup method
>>>>>>>>>>>   to keep the code simpler.
>>>>>>>>>>> 
>>>>>>>>>>>   ** The cleanup method never calls super.cleanup() so the 
>>>>>>>>>>> process is never destroyed!.
>>>>>>>>>>> 
>>>>>>>>>>> AltSecurityManager.java:
>>>>>>>>>>> 
>>>>>>>>>>> - Line 61: the empty constructor can be removed entirely.
>>>>>>>>>>> 
>>>>>>>>>>> - Line 80: change the message to say the exception did not 
>>>>>>>>>>> occur.
>>>>>>>>>>>    As written it implies it may have occurred but was not 
>>>>>>>>>>> caught.
>>>>>>>>>>> 
>>>>>>>>>>> - Line 86: typo "a unexpected" -> "an unexpected"
>>>>>>>>>>> 
>>>>>>>>>>> - Line 90: remove the printStackTrace; it is not useful and 
>>>>>>>>>>> is a red flag in .jtr files
>>>>>>>>>>> 
>>>>>>>>>>> - Line 125: I don't see that cleanup is better than destroy; 
>>>>>>>>>>> If there are doubts about destroy
>>>>>>>>>>>   then destroy should be fixed not avoided.
>>>>>>>>>>> 
>>>>>>>>>>> Roger
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On 12/26/2016 3:51 AM, Hamlin Li wrote:
>>>>>>>>>>>> Would you please review the below patches?
>>>>>>>>>>>> 
>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8030175
>>>>>>>>>>>> webrev (version A): 
>>>>>>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.00/
>>>>>>>>>>>> webrev (version B): 
>>>>>>>>>>>> http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> There are 2 versions to be reviewed.
>>>>>>>>>>>> 
>>>>>>>>>>>> In version A, just use RegistryRunner to replace rmiregistry.
>>>>>>>>>>>> In version B, refactor sun.rmi.registry.RegistryImpl to 
>>>>>>>>>>>> improve the testability of RMI code, and create/use 
>>>>>>>>>>>> RMIRegistryRunner to simulate rmiregistry.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thank you
>>>>>>>>>>>> -Hamlin
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 9 Jan 2017 14:45:45 -0800
> From: Martin Buchholz <martinrb at google.com>
> To: Paul Sandoz <paul.sandoz at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>,
>    jtreg-use at openjdk.java.net
> Subject: Re: jdk.internal.reflect.ReflectionFactory and
>    SecurityManager
> Message-ID:
>    <CA+kOe0_LEQgjQXw5WvR=BKtDjL5N-P0gDXqGEvCYqNn1bRyvHA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> I followed up on my own suggestion and wrote a race-simulating test without
> the big hammer:
> 
>    /**
>     * Checks that traversal operations collapse a random pattern of
>     * dead nodes as could normally only occur with a race.
>     */
>    @Test(dataProvider = "traversalActions")
>    public void traversalOperationsCollapseNodes(
>        Consumer<LinkedTransferQueue> traversalAction) {
>        LinkedTransferQueue q = new LinkedTransferQueue();
>        int n = rnd.nextInt(6);
>        for (int i = 0; i < n; i++) q.add(i);
>        ArrayList nulledOut = new ArrayList();
>        for (Object p = head(q); p != null; p = next(p))
>            if (rnd.nextBoolean()) {
>                nulledOut.add(item(p));
>                ITEM.setVolatile(p, null);
>            }
>        traversalAction.accept(q);
>        if (n == 0)
>            assertEquals(nodeCount(q), 0);
>        else {
>            int c = nodeCount(q);
>            assertEquals(q.size(), c - (q.contains(n - 1) ? 0 : 1));
>            for (int i = 0; i < n; i++)
>                assertTrue(nulledOut.contains(i) ^ q.contains(i));
>        }
>    }
> 
> 
>> On Mon, Jan 9, 2017 at 2:07 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>> 
>> On 9 Jan 2017, at 13:27, Martin Buchholz <martinrb at google.com> wrote:
>> 
>> My whitebox tests tend to use private access only for reading, but I can
>> imagine cases where it is useful to give testing code stronger access than
>> for regular VarHandles, maybe even to write final fields, for example for
>> fuzz testing or reliably creating an internal state that can only happen
>> with a race.  There's may be a case for providing such a big hammer, if
>> it's sufficiently hard to get at, but I can live without it.
>> 
>> 
>> 
>> That big hammer could be jdk.internal.misc.Unsafe for certain tightly
>> bound tests that really need it.
>> 
>> 
>> My preference would be to encourage people to use
>>> MethodHandles.privateLookupIn.
>>> 
>> 
>> I'm a convert!
>> 
>> 
>> Great!
>> 
>> 
>> It will take a while for privateLookupIn to become "common knowledge".
>> 
>> 
>> I shall endeavour to mention it at Devoxx US in March where John and I
>> will present on java.lang.invoke.
>> 
>> Paul.
>> 
> 
> 
> End of core-libs-dev Digest, Vol 117, Issue 23
> **********************************************


From brian.burkhalter at oracle.com  Tue Jan 10 01:09:05 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 9 Jan 2017 17:09:05 -0800
Subject: JDK 9 RFR of 8153250: java.io.File does not handle Windows paths of
	the form "D:" (no path) correctly
Message-ID: <634C72D2-A396-4D67-A880-9A962E516855@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8153250
Patch:	http://cr.openjdk.java.net/~bpb/8153250/webrev.00/

On Windows only, when resolving a child path against a parent, do not interpose a file separator (slash) if the parent is a two-character string consisting of a drive letter followed by a colon. In this case the concatenation represents a directory-relative path [1]. The core regression tests pass with this patch applied as does the test added in this patch; the new test fails without the implementation change.

Thanks,

Brian

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

From xueming.shen at oracle.com  Tue Jan 10 01:23:55 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 09 Jan 2017 17:23:55 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <0C4D9E1D-24F7-4A31-A1B1-B4AB4B9CB9C4@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0C4D9E1D-24F7-4A31-A1B1-B4AB4B9CB9C4@oracle.com>
Message-ID: <587437AB.5060608@oracle.com>

Paul,

Thanks for the comments. The webrev has been updated accordingly.

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

On 1/9/17, 2:21 PM, Paul Sandoz wrote:
> At this time of year: usual review comment to update the years in the license.
>
>
> Main
> ?
>
>   987                 jentries.stream().forEach( je ->  addPackageIfNamed(packages, je));

updated.

> If you wish you can remove the ?.stream()? and go straight to ?.forEach(?)? on the Set.
>
>
> 1870     private static boolean isModuleInfoEntry(String name) {
> 1871         // root or versioned module-info.class
> 1872         return name.endsWith(MODULE_INFO)&&
> 1873             (name.length() == MODULE_INFO.length() || name.startsWith(VERSIONS_DIR));
>
> Is this sufficient? For the versioned case do we need to check it is VERSIONS_DIR/{n}/MODULE_INFO ?
>

updated to verify if the entry has a "n" in between.

> Validator
> ?
>
>    56     private final int vdlen = VERSIONS_DIR.length();
>
> Can be static.

done.

>
> ConcealedPackage
> ?
>
> Should the class be renamed?
>
>
renamed to Basic.java


From xueming.shen at oracle.com  Tue Jan 10 01:28:07 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 09 Jan 2017 17:28:07 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
Message-ID: <587438A7.8050806@oracle.com>

Thanks Mandy!

webrev has been updated accordingly.

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

On 1/9/17, 3:46 PM, Mandy Chung wrote:
>
> This is a good cleanup.  This makes it easier to add any further 
> validation such as JDK-8171830.
>
> Main.java
>  693                     warn("unexpected versioned entry: " + name);

added a jar.properties entry for this.

>
> Should this message be localized?
> 1870     private static boolean isModuleInfoEntry(String name) {
> 1871         // root or versioned module-info.class
> 1872         return name.endsWith(MODULE_INFO)&&
> 1873             (name.length() == MODULE_INFO.length() || name.startsWith(VERSIONS_DIR));
> This should return true if it starts with VERSIONS_DIR and the entry 
> with ?/module-info.class"
>

the method has been updated as Paul suggested, to only take the root 
module-info.class
and correct versioned   meta-inf/versions/n/module-info.class

> Validator.java
>  314             } catch (Exception x) {}

return "error" now, if there is an exception.
>
> Would it be better to report the error if any exception thrown rather 
> than silently swallowing it?
>
>


From mandy.chung at oracle.com  Tue Jan 10 01:39:07 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 9 Jan 2017 17:39:07 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <587438A7.8050806@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
	<587438A7.8050806@oracle.com>
Message-ID: <363A8057-9601-4E75-8C5C-CCD3CD2632DA@oracle.com>


> On Jan 9, 2017, at 5:28 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~sherman/8172432/webrev/
> 
> the method has been updated as Paul suggested, to only take the root module-info.class
> and correct versioned   meta-inf/versions/n/module-info.class

Does it miss ?/? between n and module-info.class?  It reads to me it would return true if the name is "META-INF/versions/9module-info.class??

Can you add a test case to catch this?

Mandy

From joe.darcy at oracle.com  Tue Jan 10 01:45:36 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 9 Jan 2017 17:45:36 -0800
Subject: JDK 9 RFR of JDK-8172475: Remove <tt></tt> usage from Class and
	ClassLoader
Message-ID: <8c65ce8f-c3a5-b27c-80d3-0727cf8a812c@oracle.com>

Hello,

The javadoc for java.lang.Class and java.lang.ClassLoader has some 
usages of the <tt></tt> HTML tag. This tag is not part of HTML 5 and has 
been replaced with <code></code>. In javadoc, direct use of <tt></tt> or 
<code></code> is rarely necessary since the {@code } tag can be used 
instead. In addition, ClassLoader has multiple extraneous usage of 
<tt></tt> inside the target of a {@link} tag; these usages should be 
removed.

Please review this webrev which addresses those issues:

     Webrev: http://cr.openjdk.java.net/~darcy/8172475.0/

Thanks,

-Joe


From brian.burkhalter at oracle.com  Tue Jan 10 01:59:16 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 9 Jan 2017 17:59:16 -0800
Subject: JDK 9 RFR of JDK-8172475: Remove <tt></tt> usage from Class and
	ClassLoader
In-Reply-To: <8c65ce8f-c3a5-b27c-80d3-0727cf8a812c@oracle.com>
References: <8c65ce8f-c3a5-b27c-80d3-0727cf8a812c@oracle.com>
Message-ID: <64C69D10-3EC2-4405-A7ED-C6152A4691FF@oracle.com>

Hi Joe,

I did not read every last line but a quick perusal does not reveal any straggling teletype tags.

Line 1018 of ClassLoader could use a space before the ?-1:?
1018      *         {@code b.position()} through {@code b.position() + b.limit() -1
The current copyright year needs to be 2017 (!).

So +1 from me but I hope someone else scans it also.

Brian

On Jan 9, 2017, at 5:45 PM, joe darcy <joe.darcy at oracle.com> wrote:

> The javadoc for java.lang.Class and java.lang.ClassLoader has some usages of the <tt></tt> HTML tag. This tag is not part of HTML 5 and has been replaced with <code></code>. In javadoc, direct use of <tt></tt> or <code></code> is rarely necessary since the {@code } tag can be used instead. In addition, ClassLoader has multiple extraneous usage of <tt></tt> inside the target of a {@link} tag; these usages should be removed.
> 
> Please review this webrev which addresses those issues:
> 
>    Webrev: http://cr.openjdk.java.net/~darcy/8172475.0/


From joe.darcy at oracle.com  Tue Jan 10 03:35:00 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 9 Jan 2017 19:35:00 -0800
Subject: JDK 9 RFR of JDK-8172475: Remove <tt></tt> usage from Class and
	ClassLoader
In-Reply-To: <64C69D10-3EC2-4405-A7ED-C6152A4691FF@oracle.com>
References: <8c65ce8f-c3a5-b27c-80d3-0727cf8a812c@oracle.com>
	<64C69D10-3EC2-4405-A7ED-C6152A4691FF@oracle.com>
Message-ID: <42413738-0e4b-ba09-244c-d71c6e0dbbd3@oracle.com>

Hi Brian,

For my rough methodology, I did a search and replace of "<tt>" with 
"{@code} and "</tt>" with "}" and then ran the docs build fixing issues 
with the {@link} with embedded {@code} until the docs build was 
successful again.

Thanks,

-Joe


On 1/9/2017 5:59 PM, Brian Burkhalter wrote:
> Hi Joe,
>
> I did not read every last line but a quick perusal does not reveal any 
> straggling teletype tags.
>
> Line 1018 of ClassLoader could use a space before the ?-1:?
> 1018      *         {@code b.position()} through {@code b.position() + b.limit() -1
> The current copyright year needs to be 2017 (!).
>
> So +1 from me but I hope someone else scans it also.
>
> Brian
>
> On Jan 9, 2017, at 5:45 PM, joe darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>> The javadoc for java.lang.Class and java.lang.ClassLoader has some 
>> usages of the <tt></tt> HTML tag. This tag is not part of HTML 5 and 
>> has been replaced with <code></code>. In javadoc, direct use of 
>> <tt></tt> or <code></code> is rarely necessary since the {@code } tag 
>> can be used instead. In addition, ClassLoader has multiple extraneous 
>> usage of <tt></tt> inside the target of a {@link} tag; these usages 
>> should be removed.
>>
>> Please review this webrev which addresses those issues:
>>
>>    Webrev:http://cr.openjdk.java.net/~darcy/8172475.0/ 
>> <http://cr.openjdk.java.net/%7Edarcy/8172475.0/>
>


From mandy.chung at oracle.com  Tue Jan 10 03:45:58 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 9 Jan 2017 19:45:58 -0800
Subject: JDK 9 RFR of JDK-8172475: Remove <tt></tt> usage from Class and
	ClassLoader
In-Reply-To: <8c65ce8f-c3a5-b27c-80d3-0727cf8a812c@oracle.com>
References: <8c65ce8f-c3a5-b27c-80d3-0727cf8a812c@oracle.com>
Message-ID: <921B29F0-FF06-451F-9148-67F40FA34CC8@oracle.com>


> On Jan 9, 2017, at 5:45 PM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> The javadoc for java.lang.Class and java.lang.ClassLoader has some usages of the <tt></tt> HTML tag. This tag is not part of HTML 5 and has been replaced with <code></code>. In javadoc, direct use of <tt></tt> or <code></code> is rarely necessary since the {@code } tag can be used instead. In addition, ClassLoader has multiple extraneous usage of <tt></tt> inside the target of a {@link} tag; these usages should be removed.
> 
> Please review this webrev which addresses those issues:
> 
>    Webrev: http://cr.openjdk.java.net/~darcy/8172475.0/

The javadoc change looks good.

Mandy


From xueming.shen at oracle.com  Tue Jan 10 08:25:32 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 10 Jan 2017 00:25:32 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <363A8057-9601-4E75-8C5C-CCD3CD2632DA@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
	<587438A7.8050806@oracle.com>
	<363A8057-9601-4E75-8C5C-CCD3CD2632DA@oracle.com>
Message-ID: <58749A7C.7080101@oracle.com>

On 1/9/17, 5:39 PM, Mandy Chung wrote:
>> On Jan 9, 2017, at 5:28 PM, Xueming Shen<xueming.shen at oracle.com>  wrote:
>>
>> http://cr.openjdk.java.net/~sherman/8172432/webrev/
>>
>> the method has been updated as Paul suggested, to only take the root module-info.class
>> and correct versioned   meta-inf/versions/n/module-info.class
> Does it miss ?/? between n and module-info.class?  It reads to me it would return true if the name is "META-INF/versions/9module-info.class??

good catch, the webrev has been updated to fix it #1882
http://cr.openjdk.java.net/~sherman/8172432/webrev

I did try to come up with the test case to catch various "incorrect" 
versioned
entries, but the Validator appears to be able to catch them, as the entries
such as

            "META-INF/versions/module-info.class",
           "META-INF/versions/9module-info.class",

basically are "illegal" versioned entries ....

The fix appears to work to not treat them as versioned module-info.class, as
expected.

I will try to see if I can come up with a better way to test this corner 
case.

-Sherman

From aleksej.efimov at oracle.com  Tue Jan 10 09:26:09 2017
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Tue, 10 Jan 2017 12:26:09 +0300
Subject: [9] RFR: 8159058: SAXParseException when sending soap message
In-Reply-To: <6A55229D-FDE0-4D0C-BF93-289650DFADA3@oracle.com>
References: <81835be1-37dc-68d3-b033-2a1a468a79cd@oracle.com>
	<6A55229D-FDE0-4D0C-BF93-289650DFADA3@oracle.com>
Message-ID: <9ed5c6a5-1dba-931c-8f8a-9613104a607e@oracle.com>

Hi Lance,

Thank you for the review.
Correct, standalone team did a testing of this fix on their side. I also 
executed all JAXWS/B related tests from JCK9 runtime/devtools suites - 
no related issues were detected.

Best Regards,
Aleksej

On 09/01/17 20:23, Lance Andersen wrote:
> Hi Aleks,
>
> The changes seem reasonable.  I am assuming that the JAXWS/SAAJ 
> standalone tcks were run against the standalone RIs by the jaxws team? 
>  The JCK tests are a variation of the standalone tests so might be 
> good to sanity check if not already done.
>
> Best
> Lance
>> On Jan 9, 2017, at 4:34 AM, Aleks Efimov <aleksej.efimov at oracle.com 
>> <mailto:aleksej.efimov at oracle.com>> wrote:
>>
>> Hi,
>>
>> Please, help to review the JDK9 fix for the issue [1] in processing 
>> of default namespace attribute with empty values (xmlns="") by SAAJ 
>> implementation:
>> http://cr.openjdk.java.net/~aefimov/8159058/9/00 
>> <http://cr.openjdk.java.net/%7Eaefimov/8159058/9/00>
>>
>> Same fix was already integrated into JAXWS-RI and SAAJ-RI standalone 
>> projects. These changes were backported from standalone projects with 
>> additional package names changes and regression test addition. Due to 
>> urgency of this issue I would like to integrate this change into JDK9 
>> separately from jaxws-ri synchronization process.
>>
>> The following test sets shows no related/new failures: JDK regression 
>> tests, JCK jaxws/b tests, standalone saaj-ri tck unit tests.
>>
>> With Best Regards,
>> Aleksej
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8159058
>>
>
> <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 sergei.kovalev at oracle.com  Tue Jan 10 10:26:43 2017
From: sergei.kovalev at oracle.com (Sergei Kovalev)
Date: Tue, 10 Jan 2017 13:26:43 +0300
Subject: RFR(s): 8171958: Several tests from
	java/time/test/java/time/format requiring jdk.localedata for execution
In-Reply-To: <61d8438f-8f9a-7ad3-3bc3-c0cf81711a27@oracle.com>
References: <39bd0f19-5dbd-9790-2d5f-d3cae2a7cf08@oracle.com>
	<5dbbbb52-26fd-bd59-fdc8-ebb94585c7df@oracle.com>
	<3e978d60-2fed-4106-6d8f-fb64f32dff63@oracle.com>
	<056de9df-4cb6-c17a-b8b1-6120d4b9389b@oracle.com>
	<61d8438f-8f9a-7ad3-3bc3-c0cf81711a27@oracle.com>
Message-ID: <5614888e-bce8-7330-1e85-9eb9b36c2e32@oracle.com>

Hi Naoto,

Thank you for review. I looked throw sources mode carefully and found 
some inconsistency you mentioned. I cleaned out all possible 
dependencies on jdk.localedata. Probably previously the cases passed 
because they doing only number formatting. However I agree that it 
meaningful to collect all localedata dependencies in single place.

Could you please take a look at the updated version?

http://cr.openjdk.java.net/~skovalev/8171958/webrev.02/


10.01.17 00:20, Naoto Sato wrote:
> Hi Sergei,
>
> java.base only supports Locale.US locale (and its parents 
> Locale.ENGLISH/Locale.ROOT). I still see tests that use other locales, 
> such as Locale.UK, Locale.FRENCH (eg. in 
> TestDateTimeFormatterBuilder.java). Those test should also need to be 
> separated.
>
> Naoto
>
> On 1/9/17 1:45 AM, Sergei Kovalev wrote:
>> Hi All,
>>
>> Re-sending request because I'm still looking for reviewers.
>>
>> In addition for TEST.properties modification I'd like to put citation
>> from Jon G. email.
>>
>>> FWIW, I note your TEST.properties file looks malformed.  It has 2
>>> modules entries (line 4, line 7), which by the standard rules of Java
>>> properties files, means that "last one wins".
>>>
>>> line source
>>> # Threeten test uses TestNG
>>> TestNG.dirs = .
>>> othervm.dirs = tck/java/time/chrono test/java/time/chrono
>>> test/java/time/format
>>> modules = jdk.localedata
>>> lib.dirs = ../../lib/testlibrary
>>> lib.build = jdk.testlibrary.RandomFactory
>>> modules = java.base/java.time:open java.base/java.time.chrono:open
>>> java.base/java.time.zone:open
>> This mean that first modules declaration could be safely removed as I 
>> did.
>>
>>
>> 28.12.16 17:20, Sergei Kovalev wrote:
>>>
>>> Hi Rachna,
>>>
>>> Thank you for the comment. I've reviewed usage of module declaration
>>> in TEST.properties file and find that it could be removed without any
>>> impact. In both cases (with original and modified TEST.properties
>>> file) I get same result.
>>>
>>> Test results: passed: 142; failed: 27
>>>
>>> The reason of this behavior is the lack of jtreg header in test
>>> sources. In case test source has no "@test" tag jtreg ignores all
>>> properties that exists in TEST.properties file.
>>>
>>> I recreated the review by adding TEST.properties modification:
>>> http://cr.openjdk.java.net/~skovalev/8171958/webrev.01/
>>>
>>>
>>> 27.12.16 13:55, Rachna Goel wrote:
>>>>
>>>> Hi Sergei,
>>>>
>>>> Though I am not a reviewer, But I have one comment on this fix.
>>>>
>>>> test/java/time/TEST.properties declares "modules = jdk.localedata" ,
>>>> so that all tests for java.time can have access to "jdk.localedata"
>>>> module.
>>>>
>>>> If we are restricting usage of jdk.localedata module for different
>>>> tests, then TEST.properties need to be updated as well.
>>>>
>>>> Thanks,
>>>> Rachna
>>>>
>>>>
>>>>
>>>> On 26/12/16 8:27 PM, Sergei Kovalev wrote:
>>>>> Hello Team,
>>>>>
>>>>> Please review below fix for tests.
>>>>>
>>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8171958
>>>>> Web review: http://cr.openjdk.java.net/~skovalev/8171958/webrev.00/
>>>>>
>>>>> Issue: some tests fails in case of module limitation by
>>>>> '--limit-module java.base' command line option.
>>>>> Root cause: The tests uses locale data that stored in separate
>>>>> resource file "jdk.localedata".
>>>>> Solution: Add declaration of required module. In same cases a test
>>>>> file contains many test items, part of which could be executed with
>>>>> java.base module only. In this cases we can separate the items and
>>>>> extract that items which depend on locale data and run them
>>>>> individually. Therefore this proposal contains additional test files
>>>>> where added "WithLocale" suffix which demonstrate dependency on
>>>>> resources. Alternative solution could be add a required module
>>>>> declaration "jdk.localedata" to all files. However this will lead to
>>>>> unnecessary test coverage reduction.
>>>>>
>>>>
>>>
>>> -- 
>>> With best regards,
>>> Sergei
>>

-- 
With best regards,
Sergei


From claes.redestad at oracle.com  Tue Jan 10 11:50:58 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 10 Jan 2017 12:50:58 +0100
Subject: RFR: 8166365: Small immutable collections should provide optimized
	implementations when possible
Message-ID: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>

Hi,

please review this change to improve startup/warmup characteristics
and performance of the immutable collection factories:

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

While filed as an RFE, and a more thorough examination of the hierarchy
of the ImmutableCollection classes has been discussed[1], this more
limited patch resolves some immediate issues related to module system
bootstrap and is therefore motivated to push to 9.

Thanks!

/Claes

[1] we should likely not inherit Iterator classes that check for
co-modification etc,

From tom.schindl at bestsolution.at  Tue Jan 10 12:20:47 2017
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Tue, 10 Jan 2017 13:20:47 +0100
Subject: RFR (JAXP) 8146271: File system contention in debug print via
	XPathFactory.newInstance
In-Reply-To: <ab453abb-f103-d569-76e8-53674dc643f8@oracle.com>
References: <2d1445dc-b748-4442-20b0-26ca887a2f82@oracle.com>
	<585093BD.1020904@oracle.com>
	<803efb79-2b7b-b892-351a-a7268c85f3c9@oracle.com>
	<1D9B1E48-ECAE-4293-A774-BB9E52C42EC2@bestsolution.at>
	<ab453abb-f103-d569-76e8-53674dc643f8@oracle.com>
Message-ID: <3eac02cd-8ad5-64ab-9dac-e44ebdaf18d1@bestsolution.at>

Hi Aleks,

Sorry for not responding but what I tried to say is that with your code
you are still creating a instance of Supplier which could be avoided by
changing the code to use a BiFunction

Take
"src/java.xml/share/classes/com/sun/org/apache/xalan/internal/utils/ObjectFactory.java"
as a example.

You changed the code to:
---
private static void debugPrintln(Supplier<String> msgGen) {
  if (DEBUG) {
     System.err.println("JAXP: " + msgGen.get());
  }
}

...

debugPrintln(()->"created new instance of " + providerClass +
                    " using ClassLoader: " + cl);
---

If you'd use a BiFunction you would not need to capture "providerClass"
and "cl" hence only one single instance is created.

---
private static void debugPrintln(Object o1, Object o2,
BiFunction<Object,Object,String> msgGen) {
  if (DEBUG) {
     System.err.println("JAXP: " + msgGen.apply(o1,o2));
  }
}

...

debugPrintln(providerClass, cl,
   (o1,o2) ->
     "created new instance of " + o1 + " using ClassLoader: " + o2
);
---

Whether this makes sense depends on how frequently this code is run.

Tom

On 15.12.16 21:45, Aleks Efimov wrote:
> Hi Tom,
> 
> The main purpose of this fix is to postpone debug message string parts
> calculation/concatenation till when the actual output is needed, i.e. we
> don't want to call which(clazz) until the debug output is needed
> (debug=true) in XPathFactoryFinder ). I'm not sure that
> function/bifunction can give us such possibility due to different ways
> of messages construction in dPrint and debugPrintln usages.
> 
> 
> Best,
> Aleksej
> 
> On 15/12/16 20:22, Tom Schindl wrote:
>> Wouldn't it be better to use a function/bifunction instead of a supplier because the supplier is a capturing?
>>
>> Tom
>>
>> Von meinem iPhone gesendet
>>
>>> Am 14.12.2016 um 19:04 schrieb Aleks Efimov <aleksej.efimov at oracle.com>:
>>>
>>> Hi Joe,
>>>
>>> Thank you for the suggestions. What about modifying the 'debugPrintln' and 'dPrint' functions to accept 'j.u.function.Supplier<String>' instead of 'String'? Such approach will give us a possibility to do the output string calculation only when debugging is switched on. Such approach can be illustrated by this webrev:
>>> http://cr.openjdk.java.net/~aefimov/8146271/9/01
>>>
>>> Best Regards,
>>> Aleksej
>>>
>>>
>>>> On 14/12/16 03:35, Joe Wang wrote:
>>>> Hi Aleksej,
>>>>
>>>> You may want to improve the debugPrintln or its usage to remove the String concatenations or method calls such as f.getClass().getName() that are unnecessary when debug == false. Where we are here, could you expand the patch to cover other jaxp packages (e.g. javax.xml.parsers) where similar problems exist.
>>>>
>>>> Best,
>>>> Joe
>>>>
>>>>> On 12/13/16, 3:02 PM, Aleks Efimov wrote:
>>>>> Hello,
>>>>>
>>>>> Please, help to review the changes that addresses the file system contention caused by debug code in XPathFactoryFinder and XPathFactoryFinder classes [1]. Proposed fix wraps the debug output code in "if(debug)" block:
>>>>> http://cr.openjdk.java.net/~aefimov/8146271/9/00/
>>>>>
>>>>> Best Regards,
>>>>> Aleksej
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8146271
>>>>>
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From Alan.Bateman at oracle.com  Tue Jan 10 13:00:47 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Jan 2017 13:00:47 +0000
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <3D01F437-6CD5-4CE7-9816-9423A284D27D@oracle.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
	<d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
	<3D01F437-6CD5-4CE7-9816-9423A284D27D@oracle.com>
Message-ID: <bc4e511a-5eb2-f130-4334-b779dfa9fb48@oracle.com>



On 09/01/2017 19:09, Paul Sandoz wrote:
>> On 9 Jan 2017, at 05:36, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>> On 05/01/2017 19:01, Paul Sandoz wrote:
>>
>>> Hi,
>>>
>>> I encountered some circularity issues with security manager and VarHandles, specifically when attempting to use the new MethodHandles.privateLookupIn, so say ThreadLocalRandom has access to fields in Thread [1].
>>>
>>> When running with a security manager ThreadLocalRandom clinit depends on various security stuff that eventually depends on ConcurrentSkipListMap which depends on ThreadLocalRandom, whose static state has not been fully initialzed.
>>>
>>> The current security permission check in MethodHandles.privateLookupIn may be a too blunt and possibly should be refined along similar lines to Lookup.checkSecurityManager e.g. no check should be needed for classes within the same module (since this is a refined/controlled/principled form of setAccessible, plus no pounding on final fields). That would solve the problem in this case. But, the general point remains, and i have not thought too hard if there are other ways to solve this.
>>>
>> This would mean inconsistency with setAccessible where you need this blunt permission when suppressing access. Also I think Lookup.checkSecurityManager will do different checks when you don't have a full power lookup so it would mean adjusting the privateLookupIn.
> Some adjustment would definitely be required, the perhaps the simplest solution is not to perform a security check if within the same module?
>
It might be okay when the lookup is a full-power lookup to class in 
java.base and it's called to get a full-power look to some other class 
in java.base. However, generalizing this would probably need security 
eyes. Consider two libraries on the class path (same unnamed module) for 
example. Also the inconsistency with setAccessible where it always 
checks the permission when running with a security manager.

-Alan

From paul.sandoz at oracle.com  Tue Jan 10 16:32:25 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Jan 2017 08:32:25 -0800
Subject: RFR: 8166365: Small immutable collections should provide
	optimized implementations when possible
In-Reply-To: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
References: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
Message-ID: <0F40F15F-CCCF-4BA8-8477-5249E9FAC6B9@oracle.com>

Hi,

ImmutableCollections
?

Did you forget or intentionally omit overriding the hashCode for List2 and ListN?


 481         @Override
 482         public int hashCode() {
 483             int h = 0;
 484             for (E e : elements) {
 485                 if (e != null) {
 486                     h += e.hashCode();
 487                 }
 488             }
 489             return h;
 490         }

No need for the null check of e. If you override hashCode should you override equals as well?


 617         @Override
 618         public int hashCode() {
 619             return k0.hashCode() ^ v0.hashCode();
 620         }

That does not conform to the specification of Map.hashCode:

/**
 * Returns the hash code value for this map.  The hash code of a map is
 * defined to be the sum of the hash codes of each entry in the map's
 * {@code entrySet()} view.  This ensures that {@code m1.equals(m2)}

(Your tests might be lucky with the summing of hash codes with distinct ranges of bits set?)


 669         @Override
 670         public boolean containsValue(Object o) {
 671             for (int i = 1; i < table.length; i += 2) {
 672                 Object v = table[i];
 673                 if (v != null && o.equals(v)) {
 674                     return true;
 675                 }
 676             }
 677             return false;
 678         }

No need for the null check for v, can pass table[i] directly to o.equals

Paul.

> On 10 Jan 2017, at 03:50, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> please review this change to improve startup/warmup characteristics
> and performance of the immutable collection factories:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166365
> Webrev: http://cr.openjdk.java.net/~redestad/8166365/webrev.01/
> 
> While filed as an RFE, and a more thorough examination of the hierarchy
> of the ImmutableCollection classes has been discussed[1], this more
> limited patch resolves some immediate issues related to module system
> bootstrap and is therefore motivated to push to 9.
> 
> Thanks!
> 
> /Claes
> 
> [1] we should likely not inherit Iterator classes that check for
> co-modification etc,


From felix.yang at oracle.com  Tue Jan 10 16:36:07 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Tue, 10 Jan 2017 08:36:07 -0800
Subject: RFR 8075884, new tests to check runtime usage with Multi-Release
	jars
In-Reply-To: <757BE8AF-9D33-4AFA-8433-CBF085521BF7@oracle.com>
References: <b797746d-ba2e-f156-220c-b09b1b911c3a@oracle.com>
	<757BE8AF-9D33-4AFA-8433-CBF085521BF7@oracle.com>
Message-ID: <7E40D62F-7681-474A-AFCC-C5C44B2FED3E@oracle.com>

Hi Paul,
     thanks for the comments. Please review the updated patch. About JJS testing, I?m not really aware of Nashorn codes but just help to implement the designed one. Andrey may comment more. In my opinion, it looks to be a reasonable use case from functional aspect.

Webrev: http://cr.openjdk.java.net/~xiaofeya/8075884/webrev.01/ <http://cr.openjdk.java.net/~xiaofeya/8075884/webrev.01/>

Thanks,
Felix

> On 6 Jan 2017, at 11:26 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi Felix,
> 
> Generally looks good.
> 
> RuntimeTest
> ?
> 
>  78     @BeforeTest
>  79     protected void setUpTest() throws Throwable {
> 
> Can you use @BeforeClass? since i believe the jar files only need to be created once for all tests.
> 
> (And i presume it just overwrites any existing files that were previously generated.)
> 
> 
> 172         if (mainVersionActual != mainVersionExpected) {
> 173             throw new AssertionError(
> 174                     "Test failed: Expected Main class version: "
> 175                             + mainVersionExpected + " Actual version: "
> 176                             + mainVersionActual);
> 177         }
> 
> You can use Assert.equals.
> 
> 
> 191     @Test(dataProvider = "jarFiles")
> 192     void testJjs(String jar, int mainVer, int helperVer, int resVer)
> 193             throws Throwable {
> 
> What is the rational for testing with jjs? i.e. what does it test beyond the other tests?
> 
> Paul.
> 
> 
>> On 5 Jan 2017, at 22:20, Felix Yang <felix.yang at oracle.com> wrote:
>> 
>> Hi there,
>> 
>>   please review the following new tests to check runtime usage with Multi-Release jars.
>> 
>> Bug:
>> 
>>   https://bugs.openjdk.java.net/browse/JDK-8075884
>> 
>> Webrev:
>> 
>>   http://cr.openjdk.java.net/~xiaofeya/8075884/webrev.00/
>> 
>> Thanks,
>> 
>> Felix
>> 
> 


From paul.sandoz at oracle.com  Tue Jan 10 16:49:27 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Jan 2017 08:49:27 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <58749A7C.7080101@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
	<587438A7.8050806@oracle.com>
	<363A8057-9601-4E75-8C5C-CCD3CD2632DA@oracle.com>
	<58749A7C.7080101@oracle.com>
Message-ID: <38CFD329-3907-4F6F-BF4E-38F5AE3C5A72@oracle.com>


> On 10 Jan 2017, at 00:25, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> On 1/9/17, 5:39 PM, Mandy Chung wrote:
>> 
>>> On Jan 9, 2017, at 5:28 PM, Xueming Shen <xueming.shen at oracle.com> <mailto:xueming.shen at oracle.com> wrote:
>>> 
>>> http://cr.openjdk.java.net/~sherman/8172432/webrev/ <http://cr.openjdk.java.net/~sherman/8172432/webrev/>
>>> 
>>> the method has been updated as Paul suggested, to only take the root module-info.class
>>> and correct versioned   meta-inf/versions/n/module-info.class
>> Does it miss ?/? between n and module-info.class?  It reads to me it would return true if the name is "META-INF/versions/9module-info.class??
> 
> good catch, the webrev has been updated to fix it #1882
> http://cr.openjdk.java.net/~sherman/8172432/webrev <http://cr.openjdk.java.net/~sherman/8172432/webrev>
> 

Looks good,
Paul.


> I did try to come up with the test case to catch various "incorrect" versioned
> entries, but the Validator appears to be able to catch them, as the entries
> such as
> 
>            "META-INF/versions/module-info.class",
>           "META-INF/versions/9module-info.class",
> 
> basically are "illegal" versioned entries ....
> 
> The fix appears to work to not treat them as versioned module-info.class, as
> expected.
> 
> I will try to see if I can come up with a better way to test this corner case.
> 
> -Sherman


From mandy.chung at oracle.com  Tue Jan 10 16:54:50 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Jan 2017 08:54:50 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <58749A7C.7080101@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
	<587438A7.8050806@oracle.com>
	<363A8057-9601-4E75-8C5C-CCD3CD2632DA@oracle.com>
	<58749A7C.7080101@oracle.com>
Message-ID: <303BB2D3-9385-417C-9730-0BDCBD99E7FA@oracle.com>


> On Jan 10, 2017, at 12:25 AM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> On 1/9/17, 5:39 PM, Mandy Chung wrote:
>> 
>>> On Jan 9, 2017, at 5:28 PM, Xueming Shen <xueming.shen at oracle.com> <mailto:xueming.shen at oracle.com> wrote:
>>> 
>>> http://cr.openjdk.java.net/~sherman/8172432/webrev/ <http://cr.openjdk.java.net/~sherman/8172432/webrev/>
>>> 
>>> the method has been updated as Paul suggested, to only take the root module-info.class
>>> and correct versioned   meta-inf/versions/n/module-info.class
>> Does it miss ?/? between n and module-info.class?  It reads to me it would return true if the name is "META-INF/versions/9module-info.class??
> 
> good catch, the webrev has been updated to fix it #1882
> http://cr.openjdk.java.net/~sherman/8172432/webrev <http://cr.openjdk.java.net/~sherman/8172432/webrev>
> 

Looks good.

> I did try to come up with the test case to catch various "incorrect" versioned
> entries, but the Validator appears to be able to catch them, as the entries
> such as
> 
>            "META-INF/versions/module-info.class",
>           "META-INF/versions/9module-info.class",
> 
> basically are "illegal" versioned entries ....
> 
> The fix appears to work to not treat them as versioned module-info.class, as
> expected.
> 
> I will try to see if I can come up with a better way to test this corner case.

OK.  We can file a follow-up issue to add a test case, when you find a good way doing it.

Mandy


From chris.hegarty at oracle.com  Tue Jan 10 16:56:20 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 10 Jan 2017 16:56:20 +0000
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <58749A7C.7080101@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
	<587438A7.8050806@oracle.com>
	<363A8057-9601-4E75-8C5C-CCD3CD2632DA@oracle.com>
	<58749A7C.7080101@oracle.com>
Message-ID: <2F93DA49-CE82-4AD3-96E2-F8D177FD9E06@oracle.com>


> On 10 Jan 2017, at 08:25, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> On 1/9/17, 5:39 PM, Mandy Chung wrote:
>>> On Jan 9, 2017, at 5:28 PM, Xueming Shen <xueming.shen at oracle.com>
>>>  wrote:
>>> 
>>> 
>>> http://cr.openjdk.java.net/~sherman/8172432/webrev/
>>> 
>>> 
>>> the method has been updated as Paul suggested, to only take the root module-info.class
>>> and correct versioned   meta-inf/versions/n/module-info.class
>>> 
>> Does it miss ?/? between n and module-info.class?  It reads to me it would return true if the name is "META-INF/versions/9module-info.class??
> 
> good catch, the webrev has been updated to fix it #1882
> http://cr.openjdk.java.net/~sherman/8172432/webrev

Thank you Sherman. I think this is a really nice change.

If I?m not mistaken, this change also resolves
  https://bugs.openjdk.java.net/browse/JDK-8165640, right ?

-Chris.

From claes.redestad at oracle.com  Tue Jan 10 17:00:18 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 10 Jan 2017 18:00:18 +0100
Subject: RFR: 8166365: Small immutable collections should provide
	optimized implementations when possible
In-Reply-To: <0F40F15F-CCCF-4BA8-8477-5249E9FAC6B9@oracle.com>
References: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
	<0F40F15F-CCCF-4BA8-8477-5249E9FAC6B9@oracle.com>
Message-ID: <3cd85019-effe-a962-3489-4fb4a79d1bce@oracle.com>

Hi Paul,

On 2017-01-10 17:32, Paul Sandoz wrote:
> Hi,
>
> ImmutableCollections
> ?
>
> Did you forget or intentionally omit overriding the hashCode for List2 and ListN?

Intentionally omitted: since List2 and ListN have O(1) get performance,
the Iterator provided by AbstractList seems good enough for now.

>
>
>  481         @Override
>  482         public int hashCode() {
>  483             int h = 0;
>  484             for (E e : elements) {
>  485                 if (e != null) {
>  486                     h += e.hashCode();
>  487                 }
>  488             }
>  489             return h;
>  490         }
>
> No need for the null check of e.

Actually null checks are needed: SetN elements is a sparse array with
null at indexes where there is no actual entry.

Or are you suggesting we do the following?

for (E e : elements) {
     h += Objects.hashCode(e);
}

> If you override hashCode should you override equals as well?

I need to look into this one and get back to you, might be
unintentionally left out.

>
>
>  617         @Override
>  618         public int hashCode() {
>  619             return k0.hashCode() ^ v0.hashCode();
>  620         }
>
> That does not conform to the specification of Map.hashCode:
>
> /**
>  * Returns the hash code value for this map.  The hash code of a map is
>  * defined to be the sum of the hash codes of each entry in the map's
>  * {@code entrySet()} view.  This ensures that {@code m1.equals(m2)}
>
> (Your tests might be lucky with the summing of hash codes with distinct ranges of bits set?)

I think you're mistaken: k0 and v0 constitute the sole entry of Map1,
and k0.hashCode() ^ v0.hashCode() is the hash code for said entry;
compare HashMap.Node.hashCode().

>
>
>  669         @Override
>  670         public boolean containsValue(Object o) {
>  671             for (int i = 1; i < table.length; i += 2) {
>  672                 Object v = table[i];
>  673                 if (v != null && o.equals(v)) {
>  674                     return true;
>  675                 }
>  676             }
>  677             return false;
>  678         }
>
> No need for the null check for v, can pass table[i] directly to o.equals

Again, table is sparse and contain null entries when there's no map
entry at that index in the table.  In this case o.equals(null) would
likely return the right thing (false) for all objects, but seems a bit
odd to me.

Thanks!

/Claes

>
> Paul.
>
>> On 10 Jan 2017, at 03:50, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Hi,
>>
>> please review this change to improve startup/warmup characteristics
>> and performance of the immutable collection factories:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166365
>> Webrev: http://cr.openjdk.java.net/~redestad/8166365/webrev.01/
>>
>> While filed as an RFE, and a more thorough examination of the hierarchy
>> of the ImmutableCollection classes has been discussed[1], this more
>> limited patch resolves some immediate issues related to module system
>> bootstrap and is therefore motivated to push to 9.
>>
>> Thanks!
>>
>> /Claes
>>
>> [1] we should likely not inherit Iterator classes that check for
>> co-modification etc,
>

From paul.sandoz at oracle.com  Tue Jan 10 17:37:34 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Jan 2017 09:37:34 -0800
Subject: RFR: 8166365: Small immutable collections should provide
	optimized implementations when possible
In-Reply-To: <3cd85019-effe-a962-3489-4fb4a79d1bce@oracle.com>
References: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
	<0F40F15F-CCCF-4BA8-8477-5249E9FAC6B9@oracle.com>
	<3cd85019-effe-a962-3489-4fb4a79d1bce@oracle.com>
Message-ID: <88579538-1872-405B-A830-4600CBE06772@oracle.com>

Hi,

Cleary i should be more careful reviewing while eating my breakfast.


> On 10 Jan 2017, at 09:00, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi Paul,
> 
> On 2017-01-10 17:32, Paul Sandoz wrote:
>> Hi,
>> 
>> ImmutableCollections
>> ?
>> 
>> Did you forget or intentionally omit overriding the hashCode for List2 and ListN?
> 
> Intentionally omitted: since List2 and ListN have O(1) get performance,
> the Iterator provided by AbstractList seems good enough for now.
> 

Ok. Given the collections are small i wondered if the iterator allocation was significant.


>> 
>> 
>> 481         @Override
>> 482         public int hashCode() {
>> 483             int h = 0;
>> 484             for (E e : elements) {
>> 485                 if (e != null) {
>> 486                     h += e.hashCode();
>> 487                 }
>> 488             }
>> 489             return h;
>> 490         }
>> 
>> No need for the null check of e.
> 
> Actually null checks are needed: SetN elements is a sparse array with
> null at indexes where there is no actual entry.
> 

Doh!


> Or are you suggesting we do the following?
> 

No, i forgot the table can contain null values.


> for (E e : elements) {
>    h += Objects.hashCode(e);
> }
> 
>> If you override hashCode should you override equals as well?
> 
> I need to look into this one and get back to you, might be
> unintentionally left out.
> 

Ok.


>> 
>> 
>> 617         @Override
>> 618         public int hashCode() {
>> 619             return k0.hashCode() ^ v0.hashCode();
>> 620         }
>> 
>> That does not conform to the specification of Map.hashCode:
>> 
>> /**
>> * Returns the hash code value for this map.  The hash code of a map is
>> * defined to be the sum of the hash codes of each entry in the map's
>> * {@code entrySet()} view.  This ensures that {@code m1.equals(m2)}
>> 
>> (Your tests might be lucky with the summing of hash codes with distinct ranges of bits set?)
> 
> I think you're mistaken: k0 and v0 constitute the sole entry of Map1,
> and k0.hashCode() ^ v0.hashCode() is the hash code for said entry;
> compare HashMap.Node.hashCode().
> 

Another Doh! I got crosseyed thinking this for a map holding two entries.

Paul.

>> 
>> 
>> 669         @Override
>> 670         public boolean containsValue(Object o) {
>> 671             for (int i = 1; i < table.length; i += 2) {
>> 672                 Object v = table[i];
>> 673                 if (v != null && o.equals(v)) {
>> 674                     return true;
>> 675                 }
>> 676             }
>> 677             return false;
>> 678         }
>> 
>> No need for the null check for v, can pass table[i] directly to o.equals
> 
> Again, table is sparse and contain null entries when there's no map
> entry at that index in the table.  In this case o.equals(null) would
> likely return the right thing (false) for all objects, but seems a bit
> odd to me.
> 
> Thanks!
> 
> /Claes
> 
>> 
>> Paul.
>> 
>>> On 10 Jan 2017, at 03:50, Claes Redestad <claes.redestad at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> please review this change to improve startup/warmup characteristics
>>> and performance of the immutable collection factories:
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166365
>>> Webrev: http://cr.openjdk.java.net/~redestad/8166365/webrev.01/
>>> 
>>> While filed as an RFE, and a more thorough examination of the hierarchy
>>> of the ImmutableCollection classes has been discussed[1], this more
>>> limited patch resolves some immediate issues related to module system
>>> bootstrap and is therefore motivated to push to 9.
>>> 
>>> Thanks!
>>> 
>>> /Claes
>>> 
>>> [1] we should likely not inherit Iterator classes that check for
>>> co-modification etc,
>> 


From paul.sandoz at oracle.com  Tue Jan 10 18:11:43 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Jan 2017 10:11:43 -0800
Subject: RFR 8075884,
	new tests to check runtime usage with Multi-Release jars
In-Reply-To: <7E40D62F-7681-474A-AFCC-C5C44B2FED3E@oracle.com>
References: <b797746d-ba2e-f156-220c-b09b1b911c3a@oracle.com>
	<757BE8AF-9D33-4AFA-8433-CBF085521BF7@oracle.com>
	<7E40D62F-7681-474A-AFCC-C5C44B2FED3E@oracle.com>
Message-ID: <022D0B6B-8D6F-4C66-A62B-47E6938DDE59@oracle.com>


> On 10 Jan 2017, at 08:36, Felix Yang <felix.yang at oracle.com> wrote:
> 
> Hi Paul,
>      thanks for the comments. Please review the updated patch. About JJS testing, I?m not really aware of Nashorn codes but just help to implement the designed one. Andrey may comment more. In my opinion, it looks to be a reasonable use case from functional aspect.
> 

Ok.


> Webrev: http://cr.openjdk.java.net/~xiaofeya/8075884/webrev.01/ <http://cr.openjdk.java.net/~xiaofeya/8075884/webrev.01/>
> 

Looks good,
Paul.

From Roger.Riggs at Oracle.com  Tue Jan 10 18:16:27 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 10 Jan 2017 13:16:27 -0500
Subject: JDK 9 RFR of 8153250: java.io.File does not handle Windows paths
	of the form "D:" (no path) correctly
In-Reply-To: <634C72D2-A396-4D67-A880-9A962E516855@oracle.com>
References: <634C72D2-A396-4D67-A880-9A962E516855@oracle.com>
Message-ID: <dbbac256-afa4-ddae-a32b-a68e78235157@Oracle.com>

Hi Brian,

Looks good.

Roger


On 1/9/2017 8:09 PM, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8153250
> Patch:	http://cr.openjdk.java.net/~bpb/8153250/webrev.00/
>
> On Windows only, when resolving a child path against a parent, do not interpose a file separator (slash) if the parent is a two-character string consisting of a drive letter followed by a colon. In this case the concatenation represents a directory-relative path [1]. The core regression tests pass with this patch applied as does the test added in this patch; the new test fails without the implementation change.
>
> Thanks,
>
> Brian
>
> [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx


From naoto.sato at oracle.com  Tue Jan 10 18:22:29 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 10 Jan 2017 10:22:29 -0800
Subject: RFR(s): 8171958: Several tests from
	java/time/test/java/time/format requiring jdk.localedata for execution
In-Reply-To: <5614888e-bce8-7330-1e85-9eb9b36c2e32@oracle.com>
References: <39bd0f19-5dbd-9790-2d5f-d3cae2a7cf08@oracle.com>
	<5dbbbb52-26fd-bd59-fdc8-ebb94585c7df@oracle.com>
	<3e978d60-2fed-4106-6d8f-fb64f32dff63@oracle.com>
	<056de9df-4cb6-c17a-b8b1-6120d4b9389b@oracle.com>
	<61d8438f-8f9a-7ad3-3bc3-c0cf81711a27@oracle.com>
	<5614888e-bce8-7330-1e85-9eb9b36c2e32@oracle.com>
Message-ID: <8c39f401-62a1-c38f-84a9-abad6de624ce@oracle.com>

Looks good to me.

Naoto

On 1/10/17 2:26 AM, Sergei Kovalev wrote:
> Hi Naoto,
>
> Thank you for review. I looked throw sources mode carefully and found
> some inconsistency you mentioned. I cleaned out all possible
> dependencies on jdk.localedata. Probably previously the cases passed
> because they doing only number formatting. However I agree that it
> meaningful to collect all localedata dependencies in single place.
>
> Could you please take a look at the updated version?
>
> http://cr.openjdk.java.net/~skovalev/8171958/webrev.02/
>
>
> 10.01.17 00:20, Naoto Sato wrote:
>> Hi Sergei,
>>
>> java.base only supports Locale.US locale (and its parents
>> Locale.ENGLISH/Locale.ROOT). I still see tests that use other locales,
>> such as Locale.UK, Locale.FRENCH (eg. in
>> TestDateTimeFormatterBuilder.java). Those test should also need to be
>> separated.
>>
>> Naoto
>>
>> On 1/9/17 1:45 AM, Sergei Kovalev wrote:
>>> Hi All,
>>>
>>> Re-sending request because I'm still looking for reviewers.
>>>
>>> In addition for TEST.properties modification I'd like to put citation
>>> from Jon G. email.
>>>
>>>> FWIW, I note your TEST.properties file looks malformed.  It has 2
>>>> modules entries (line 4, line 7), which by the standard rules of Java
>>>> properties files, means that "last one wins".
>>>>
>>>> line source
>>>> # Threeten test uses TestNG
>>>> TestNG.dirs = .
>>>> othervm.dirs = tck/java/time/chrono test/java/time/chrono
>>>> test/java/time/format
>>>> modules = jdk.localedata
>>>> lib.dirs = ../../lib/testlibrary
>>>> lib.build = jdk.testlibrary.RandomFactory
>>>> modules = java.base/java.time:open java.base/java.time.chrono:open
>>>> java.base/java.time.zone:open
>>> This mean that first modules declaration could be safely removed as I
>>> did.
>>>
>>>
>>> 28.12.16 17:20, Sergei Kovalev wrote:
>>>>
>>>> Hi Rachna,
>>>>
>>>> Thank you for the comment. I've reviewed usage of module declaration
>>>> in TEST.properties file and find that it could be removed without any
>>>> impact. In both cases (with original and modified TEST.properties
>>>> file) I get same result.
>>>>
>>>> Test results: passed: 142; failed: 27
>>>>
>>>> The reason of this behavior is the lack of jtreg header in test
>>>> sources. In case test source has no "@test" tag jtreg ignores all
>>>> properties that exists in TEST.properties file.
>>>>
>>>> I recreated the review by adding TEST.properties modification:
>>>> http://cr.openjdk.java.net/~skovalev/8171958/webrev.01/
>>>>
>>>>
>>>> 27.12.16 13:55, Rachna Goel wrote:
>>>>>
>>>>> Hi Sergei,
>>>>>
>>>>> Though I am not a reviewer, But I have one comment on this fix.
>>>>>
>>>>> test/java/time/TEST.properties declares "modules = jdk.localedata" ,
>>>>> so that all tests for java.time can have access to "jdk.localedata"
>>>>> module.
>>>>>
>>>>> If we are restricting usage of jdk.localedata module for different
>>>>> tests, then TEST.properties need to be updated as well.
>>>>>
>>>>> Thanks,
>>>>> Rachna
>>>>>
>>>>>
>>>>>
>>>>> On 26/12/16 8:27 PM, Sergei Kovalev wrote:
>>>>>> Hello Team,
>>>>>>
>>>>>> Please review below fix for tests.
>>>>>>
>>>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8171958
>>>>>> Web review: http://cr.openjdk.java.net/~skovalev/8171958/webrev.00/
>>>>>>
>>>>>> Issue: some tests fails in case of module limitation by
>>>>>> '--limit-module java.base' command line option.
>>>>>> Root cause: The tests uses locale data that stored in separate
>>>>>> resource file "jdk.localedata".
>>>>>> Solution: Add declaration of required module. In same cases a test
>>>>>> file contains many test items, part of which could be executed with
>>>>>> java.base module only. In this cases we can separate the items and
>>>>>> extract that items which depend on locale data and run them
>>>>>> individually. Therefore this proposal contains additional test files
>>>>>> where added "WithLocale" suffix which demonstrate dependency on
>>>>>> resources. Alternative solution could be add a required module
>>>>>> declaration "jdk.localedata" to all files. However this will lead to
>>>>>> unnecessary test coverage reduction.
>>>>>>
>>>>>
>>>>
>>>> --
>>>> With best regards,
>>>> Sergei
>>>
>

From huizhe.wang at oracle.com  Tue Jan 10 18:58:48 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 10 Jan 2017 10:58:48 -0800
Subject: RFR (JAXP) 8171243 : CatalogManager.catalogResolver throws
	FileSystemNotFoundException with jar
In-Reply-To: <25f1ea5e-a2cd-83c2-8f49-346fc9ff2350@Oracle.com>
References: <3cfcba76-6436-92ec-5174-747318fa9ff5@oracle.com>
	<25f1ea5e-a2cd-83c2-8f49-346fc9ff2350@Oracle.com>
Message-ID: <a7710860-2e81-fa86-c7a3-75a9e3f01147@oracle.com>


On 1/9/2017 2:17 PM, Roger Riggs wrote:
> Hi Joe,
>
> a few comments:
>
> CatalogManager:
>  - line 58:  "will /return /as no mapping is found";
>   Or is it describing the behavior of the CatalogResolver (which is 
> throw a CatalogException)?
>    (possible more than 1 place)

While waiting for spec approval, I've updated the webrev and added 3 
tests in CatalogFileInputTest [1]: line 118 - 138.

[1] 
http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/test/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java.html
>
> Check the copyrights -> 2017  (JarUtils.java)

Updated all classes / tests.
>
> in JAXWS repo:
>  - Options.java:  line 786 - you could use URI[]::new instead of 
> creating a placeholder URI[0].

Updated both classes.

webrevs:
http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/
http://cr.openjdk.java.net/~joehw/jdk9/8171243_jaxws/webrev/

Thanks,
Joe

>
> Looks good,  Roger
>
>
> On 1/9/2017 12:38 PM, huizhe wang wrote:
>> Hi,
>>
>> The current Catalog API accepts file paths or URIs in a form of 
>> String to create Catalog or CatalogResolver in an effort to maintain 
>> consistency with the old Catalog API and other existing processors. 
>> However, that also introduced an ambiguity in the API, which is 
>> unwanted for a new API in Java SE 9.
>>
>> Please review the changes.
>> In jaxp repo:
>> http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/
>>
>> In jaxws repo:
>> http://cr.openjdk.java.net/~joehw/jdk9/8171243_jaxws/webrev/
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8171243
>>
>> Thanks,
>> Joe
>>
>


From naoto.sato at oracle.com  Wed Jan 11 00:10:04 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 10 Jan 2017 16:10:04 -0800
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and ClassLoader
	may not be needed
Message-ID: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>

Hello,

Please review the changes to the subject issue:

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

The changes are located at:

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

The changeset is the same as the one in the mail thread [1] contributed by Peter Levart, plus additional clearCache() test cases.

Naoto

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html>


From xueming.shen at oracle.com  Wed Jan 11 01:03:58 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 10 Jan 2017 17:03:58 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
Message-ID: <5875847E.50307@oracle.com>

On 1/9/17, 3:46 PM, Mandy Chung wrote:
>
>> On Jan 9, 2017, at 10:21 AM, Xueming Shen <xueming.shen at oracle.com 
>> <mailto:xueming.shen at oracle.com>> wrote:
>>
>> Hi,
>>
>> Please review the following proposed changes for jar tool
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8172432
>> webrev: http://cr.openjdk.java.net/~sherman/8172432/webrev
>> http://cr.openjdk.java.net/~sherman/8172432/webrev_top/
>>
>
> This is a good cleanup.  This makes it easier to add any further 
> validation such as JDK-8171830.
>
>
Hi Mandy,

I spent some time today for JDK-8171830.

http://cr.openjdk.java.net/~sherman/8172432/webrev2/src/jdk.jartool/share/classes/sun/tools/jar/Main.java.sdiff.html
--> Line#1851 checkModuleInfo()

http://cr.openjdk.java.net/~sherman/8172432/webrev2/test/tools/jar/modularJar/Basic.java.sdiff.html
--> Line#739

Only after I checked out the output bytes I realized that the current 
implementation
for "checkServices", in which it creates a ModuleDescriptor from bytes as

ModuleDescriptor md = 
ModuleDescriptor.read(ByteBuffer.wrap(moduleInfoBytes));

actually triggers the sanity check inside ModuleInfo.doRead(), which 
does validate if all
exported/open packages are contained in the "packages" attribute.

java.lang.module.InvalidModuleDescriptorException: Package jdk.test.bar missing from ModulePackages attribute
	at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1078)
	at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:318)
	at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:141)
	at java.base/java.lang.module.ModuleDescriptor.read(ModuleDescriptor.java:2377)
	at jdk.jartool/sun.tools.jar.Main.checkModuleInfo(Main.java:1843)
	at jdk.jartool/sun.tools.jar.Main.run(Main.java:289)
	at jdk.jartool/sun.tools.jar.Main.main(Main.java:1651)


Just wanted to confirm with you that we actually don't need to do 
anything for 8171830,
other than throwing in a test case (or wrap the 
InvalidModuleDescriptorException into
a "jar" exception?

Thanks,
Sherman



From paul.sandoz at oracle.com  Wed Jan 11 01:55:01 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 10 Jan 2017 17:55:01 -0800
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <bc4e511a-5eb2-f130-4334-b779dfa9fb48@oracle.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
	<d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
	<3D01F437-6CD5-4CE7-9816-9423A284D27D@oracle.com>
	<bc4e511a-5eb2-f130-4334-b779dfa9fb48@oracle.com>
Message-ID: <66C0AE9A-7182-4FD2-B60E-AECC49805CC4@oracle.com>

I am concerned it?s getting too late to twiddle with the security setting so i took the plunge and wrapped the privateLookupIn calls in doPrivileged blocks. It?s ugly but avoids the circularity (JPRT core/hotspot testing has not failed).

http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/

I??ll resend this out for closer review by Martin and Doug.

Paul.


> On 10 Jan 2017, at 05:00, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 09/01/2017 19:09, Paul Sandoz wrote:
>>> On 9 Jan 2017, at 05:36, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> 
>>> On 05/01/2017 19:01, Paul Sandoz wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I encountered some circularity issues with security manager and VarHandles, specifically when attempting to use the new MethodHandles.privateLookupIn, so say ThreadLocalRandom has access to fields in Thread [1].
>>>> 
>>>> When running with a security manager ThreadLocalRandom clinit depends on various security stuff that eventually depends on ConcurrentSkipListMap which depends on ThreadLocalRandom, whose static state has not been fully initialzed.
>>>> 
>>>> The current security permission check in MethodHandles.privateLookupIn may be a too blunt and possibly should be refined along similar lines to Lookup.checkSecurityManager e.g. no check should be needed for classes within the same module (since this is a refined/controlled/principled form of setAccessible, plus no pounding on final fields). That would solve the problem in this case. But, the general point remains, and i have not thought too hard if there are other ways to solve this.
>>>> 
>>> This would mean inconsistency with setAccessible where you need this blunt permission when suppressing access. Also I think Lookup.checkSecurityManager will do different checks when you don't have a full power lookup so it would mean adjusting the privateLookupIn.
>> Some adjustment would definitely be required, the perhaps the simplest solution is not to perform a security check if within the same module?
>> 
> It might be okay when the lookup is a full-power lookup to class in java.base and it's called to get a full-power look to some other class in java.base. However, generalizing this would probably need security eyes. Consider two libraries on the class path (same unnamed module) for example. Also the inconsistency with setAccessible where it always checks the permission when running with a security manager.
> 
> -Alan


From stuart.marks at oracle.com  Wed Jan 11 03:10:26 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 10 Jan 2017 19:10:26 -0800
Subject: RFR: 8166365: Small immutable collections should provide
	optimized implementations when possible
In-Reply-To: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
References: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
Message-ID: <c7ca271e-8640-0822-bfaa-362098215a91@oracle.com>

On 1/10/17 3:50 AM, Claes Redestad wrote:
> please review this change to improve startup/warmup characteristics
> and performance of the immutable collection factories:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166365
> Webrev: http://cr.openjdk.java.net/~redestad/8166365/webrev.01/
>
> While filed as an RFE, and a more thorough examination of the hierarchy
> of the ImmutableCollection classes has been discussed[1], this more
> limited patch resolves some immediate issues related to module system
> bootstrap and is therefore motivated to push to 9.
>
> Thanks!
>
> /Claes
>
> [1] we should likely not inherit Iterator classes that check for
> co-modification etc,

Hi Claes,

Thanks for taking this on.

Interesting that some -- and only some -- of the existing empty and singleton 
collections in Collections.java hadn't overridden hashCode(). Thanks for filling 
these in.

The following comments all apply to ImmutableCollections.java.

-------

Regarding Paul's questions about whether you should override equals() and 
various additional hashCode() methods:

The general rule from "Effective Java" is that equals() and hashCode() both be 
overridden. However, this is mainly directed at classes that are chidren of 
Object and that are providing semantics that differ from Object's equals() and 
hashCode() methods. The more precise rule is that the semantics of equals() and 
hashCode() must match.

It's oddly asymmetric to override hashCode() but not equals(), but that's OK, as 
these implementations all inherit equals() from their superclasses, which 
provide the right semantics. In addition, equals() is a bit complicated and is 
kind of expensive, and it should be relatively infrequent.

The point of hashCode() is to avoid unnecessary calls to equals(), so overriding 
hashCode() to make it go fast is more important than overriding equals(). In 
that light it's a bit odd that hashCode() is overridden in most places here, but

List2.hashCode()
ListN.hashCode()
MapN.hashCode()

aren't overridden.

I'd like to see them added at some point, but if your benchmarks don't justify 
them, maybe they're not necessary right now. If not, we should make a note to 
add them later.

-------

All of List{0,1,2,N}.contains(null) will currently return false. With this 
change, List{0,1,2}.contains(null) will change to throw NPE, but 
ListN.contains(null) will continue to return false.

I actually like the change of throwing NPE on contains(null). Note that all the 
Set and Map implementations here throw NPE when null is passed to 
contains/containsKey/containsValue, so returning false instead of throwing NPE 
from the List.contains() methods might have been an oversight on my part. But 
all the List implementations should be made consistent.

Thus, ListN.contains() should be overridden to provide consistent NPE behavior. 
It could simply be

     return super.contains(Objects.requireNonNull(o));

or maybe just write out the loop in order to avoid Iterator allocation.

Also note that (as Peter Levart mentioned some time ago, in the initial review 
of these implementations) that although it isn't guaranteed by specification, 
the convention in the collections implementations is to compare an argument o to 
a contained element e by calling o.equals(e). Thus List1.contains(o) should 
change to

     return o.equals(e0); // implicit nullcheck of o

and the call to Objects.requireNonNull(o) can be dropped.

-------

  287         @Override
  288         public boolean containsAll(Collection<?> o) {
  289             return o.isEmpty(); // implicit nullcheck
  290         }


  324         @Override
  325         public boolean contains(Object o) {
  326             return o.equals(e0); // implicit nullcheck of o
  327         }

  373         @Override
  374         public boolean contains(Object o) {
  375             return o.equals(e0) || o.equals(e1); // implicit nullcheck of o
  376         }

While it does add a bit of clutter, I like the idea of commenting every location 
where an implicit nullcheck is done, as is done here, and in several other 
places you had removed the Objects.requireNonNull() call. Note that some 
implicit nullchecks in the List code aren't commented; comments should be added 
there. Please also add a comment at this code in Set2:

  355             if (e0.equals(Objects.requireNonNull(e1))) {

something like "// implicit nullcheck of e0".

Also please add comments for SetN.probe() and MapN.probe() to indicate that 
callers are relying on them to do implicit nullchecks of their args.

-------

In Set2, SetN, Map1, and MapN, the addition of @Stable also dropped the 
"private" access modifier. Other implementations still have corresponding fields 
as private. Was this intentional? I think they should all remain private.

-------

  664         @Override
  665         public boolean containsKey(Object o) {
  666             return probe(o) >= 0; // probe implicity nullchecks o
  667         }

Typo "implicity".

-------

  669         @Override
  670         public boolean containsValue(Object o) {
  671             for (int i = 1; i < table.length; i += 2) {
  672                 Object v = table[i];
  673                 if (v != null && o.equals(v)) {
  674                     return true;
  675                 }
  676             }
  677             return false;
  678         }

At 673, // implicit nullcheck of o

-------

Thanks!!

s'marks

From mandy.chung at oracle.com  Wed Jan 11 05:14:19 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Jan 2017 21:14:19 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <5875847E.50307@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
	<5875847E.50307@oracle.com>
Message-ID: <3193532E-4248-4192-9914-AE6D4062B5DA@oracle.com>


> On Jan 10, 2017, at 5:03 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> Hi Mandy,
> 
> I spent some time today for JDK-8171830. 
> 
> http://cr.openjdk.java.net/~sherman/8172432/webrev2/src/jdk.jartool/share/classes/sun/tools/jar/Main.java.sdiff.html <http://cr.openjdk.java.net/~sherman/8172432/webrev2/src/jdk.jartool/share/classes/sun/tools/jar/Main.java.sdiff.html>
> --> Line#1851 checkModuleInfo()
> 
> http://cr.openjdk.java.net/~sherman/8172432/webrev2/test/tools/jar/modularJar/Basic.java.sdiff.html <http://cr.openjdk.java.net/~sherman/8172432/webrev2/test/tools/jar/modularJar/Basic.java.sdiff.html>
> --> Line#739
> 
> Only after I checked out the output bytes I realized that the current implementation
> for "checkServices", in which it creates a ModuleDescriptor from bytes as
> 
> ModuleDescriptor md = ModuleDescriptor.read(ByteBuffer.wrap(moduleInfoBytes));
> 
> actually triggers the sanity check inside ModuleInfo.doRead(), which does validate if all
> exported/open packages are contained in the "packages" attribute.
> 

This is good.  jar tool calls ModuleDescriptor.read after ModulePackages attribute is added/updated and this will leverage the ModuleDescriptor validation.
> java.lang.module.InvalidModuleDescriptorException: Package jdk.test.bar missing from ModulePackages attribute
> 	at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1078)
> 	at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:318)
> 	at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:141)
> 	at java.base/java.lang.module.ModuleDescriptor.read(ModuleDescriptor.java:2377)
> 	at jdk.jartool/sun.tools.jar.Main.checkModuleInfo(Main.java:1843)
> 	at jdk.jartool/sun.tools.jar.Main.run(Main.java:289)
> 	at jdk.jartool/sun.tools.jar.Main.main(Main.java:1651)
> 
> Just wanted to confirm with you that we actually don't need to do anything for 8171830,
> other than throwing in a test case (or wrap the InvalidModuleDescriptorException into
> a "jar" exception?
> 

I agree that you can depend on the validation done by ModuleDescriptor::read as long as the jar tool reports the error message gracefully (probably catch InvalidModuleDescriptorException and output the error).  It?d be good to add a comment to describe that exports/opens package will be validated.

thanks
Mandy


From xueming.shen at oracle.com  Wed Jan 11 06:00:12 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 10 Jan 2017 22:00:12 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <3193532E-4248-4192-9914-AE6D4062B5DA@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
	<5875847E.50307@oracle.com>
	<3193532E-4248-4192-9914-AE6D4062B5DA@oracle.com>
Message-ID: <5875C9EC.6030506@oracle.com>

On 1/10/17, 9:14 PM, Mandy Chung wrote:
>
>
> I agree that you can depend on the validation done by 
> ModuleDescriptor::read as long as the jar tool reports the error 
> message gracefully (probably catch InvalidModuleDescriptorException 
> and output the error). It?d be good to add a comment to describe that 
> exports/opens package will be validated.
>
>

webrev has been updated to catch IMDE and fails the jar as other fatal 
error handing.

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

compared to last webrev, the changes are

(1) Main.java line#1839 checkModuleInfo(), renamed from checkServices(), 
in which the impl
catches the InvalidModuleDescriptorException for the open/exported pkg 
check.

(2) Validator.java line#343 checkModuleDescriptor(), same as (1) above, 
the IMDE is
caught and handled, when the ModuleDescriptor object being checked is 
the first
versioned md (lowest) and there is NO root module-info.class, in which 
case, this
md is the base module-info.class

(3) couple test cases has been added in 
test/tools/jar/modularJar/Basic.java to test
above scenarios.

-----------------------------------
  If I?m not mistaken, this change also resolves 
https://bugs.openjdk.java.net/browse/JDK-8165640, right ?
------------------------------------

To Chris, yes, 8165640 is being addressed as well here.

Thank,
Sherman

From peter.levart at gmail.com  Wed Jan 11 11:14:41 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 11 Jan 2017 12:14:41 +0100
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <66C0AE9A-7182-4FD2-B60E-AECC49805CC4@oracle.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
	<d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
	<3D01F437-6CD5-4CE7-9816-9423A284D27D@oracle.com>
	<bc4e511a-5eb2-f130-4334-b779dfa9fb48@oracle.com>
	<66C0AE9A-7182-4FD2-B60E-AECC49805CC4@oracle.com>
Message-ID: <5454aae7-f55b-bec3-f00e-8d76a4a289ad@gmail.com>

Hi Paul,

On 01/11/2017 02:55 AM, Paul Sandoz wrote:
> I am concerned it?s getting too late to twiddle with the security setting so i took the plunge and wrapped the privateLookupIn calls in doPrivileged blocks. It?s ugly but avoids the circularity (JPRT core/hotspot testing has not failed).
>
> http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/
>
> I??ll resend this out for closer review by Martin and Doug.

You could simplify the static initializer in TLR.ThreadGroupCreator a bit:

     static {
         try {
             // Teleport the lookup to access fields in Thread and 
ThreadGroup
             MethodHandles.Lookup[] l = 
java.security.AccessController.doPrivileged(
                 new 
java.security.PrivilegedExceptionAction<MethodHandles.Lookup[]>() {
                     public MethodHandles.Lookup[] run() {
                         MethodHandles.Lookup lookup = 
MethodHandles.lookup();
                         return new MethodHandles.Lookup[] {
MethodHandles.privateLookupIn(Thread.class, lookup),
MethodHandles.privateLookupIn(ThreadGroup.class, lookup)
                         };
                     }
                 });
             THREAD_GROUP =
                 l[0].findVarHandle(Thread.class, "group", 
ThreadGroup.class);
             THREAD_GROUP_PARENT =
                 l[1].findVarHandle(ThreadGroup.class, "parent", 
ThreadGroup.class);
         } catch (Exception e) {
             throw new Error(e);
         }
     }


Regards, Peter

> Paul.
>
>
>> On 10 Jan 2017, at 05:00, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>>
>>
>> On 09/01/2017 19:09, Paul Sandoz wrote:
>>>> On 9 Jan 2017, at 05:36, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>>
>>>> On 05/01/2017 19:01, Paul Sandoz wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I encountered some circularity issues with security manager and VarHandles, specifically when attempting to use the new MethodHandles.privateLookupIn, so say ThreadLocalRandom has access to fields in Thread [1].
>>>>>
>>>>> When running with a security manager ThreadLocalRandom clinit depends on various security stuff that eventually depends on ConcurrentSkipListMap which depends on ThreadLocalRandom, whose static state has not been fully initialzed.
>>>>>
>>>>> The current security permission check in MethodHandles.privateLookupIn may be a too blunt and possibly should be refined along similar lines to Lookup.checkSecurityManager e.g. no check should be needed for classes within the same module (since this is a refined/controlled/principled form of setAccessible, plus no pounding on final fields). That would solve the problem in this case. But, the general point remains, and i have not thought too hard if there are other ways to solve this.
>>>>>
>>>> This would mean inconsistency with setAccessible where you need this blunt permission when suppressing access. Also I think Lookup.checkSecurityManager will do different checks when you don't have a full power lookup so it would mean adjusting the privateLookupIn.
>>> Some adjustment would definitely be required, the perhaps the simplest solution is not to perform a security check if within the same module?
>>>
>> It might be okay when the lookup is a full-power lookup to class in java.base and it's called to get a full-power look to some other class in java.base. However, generalizing this would probably need security eyes. Consider two libraries on the class path (same unnamed module) for example. Also the inconsistency with setAccessible where it always checks the permission when running with a security manager.
>>
>> -Alan


From claes.redestad at oracle.com  Wed Jan 11 13:43:28 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 11 Jan 2017 14:43:28 +0100
Subject: RFR: 8166365: Small immutable collections should provide
	optimized implementations when possible
In-Reply-To: <c7ca271e-8640-0822-bfaa-362098215a91@oracle.com>
References: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
	<c7ca271e-8640-0822-bfaa-362098215a91@oracle.com>
Message-ID: <8f960792-51e1-f829-762b-02fc2781abc6@oracle.com>

Hi Stuart,

On 01/11/2017 04:10 AM, Stuart Marks wrote:
> On 1/10/17 3:50 AM, Claes Redestad wrote:
>> please review this change to improve startup/warmup characteristics
>> and performance of the immutable collection factories:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166365
>> Webrev: http://cr.openjdk.java.net/~redestad/8166365/webrev.01/
>>
>> While filed as an RFE, and a more thorough examination of the hierarchy
>> of the ImmutableCollection classes has been discussed[1], this more
>> limited patch resolves some immediate issues related to module system
>> bootstrap and is therefore motivated to push to 9.
>>
>> Thanks!
>>
>> /Claes
>>
>> [1] we should likely not inherit Iterator classes that check for
>> co-modification etc,
>
> Hi Claes,
>
> Thanks for taking this on.
>
> Interesting that some -- and only some -- of the existing empty and 
> singleton collections in Collections.java hadn't overridden 
> hashCode(). Thanks for filling these in.
>
> The following comments all apply to ImmutableCollections.java.
>
> -------
>
> Regarding Paul's questions about whether you should override equals() 
> and various additional hashCode() methods:
>
> The general rule from "Effective Java" is that equals() and hashCode() 
> both be overridden. However, this is mainly directed at classes that 
> are chidren of Object and that are providing semantics that differ 
> from Object's equals() and hashCode() methods. The more precise rule 
> is that the semantics of equals() and hashCode() must match.
>
> It's oddly asymmetric to override hashCode() but not equals(), but 
> that's OK, as these implementations all inherit equals() from their 
> superclasses, which provide the right semantics. In addition, equals() 
> is a bit complicated and is kind of expensive, and it should be 
> relatively infrequent.
>
> The point of hashCode() is to avoid unnecessary calls to equals(), so 
> overriding hashCode() to make it go fast is more important than 
> overriding equals(). In that light it's a bit odd that hashCode() is 
> overridden in most places here, but
>
> List2.hashCode()
> ListN.hashCode()
> MapN.hashCode()
>
> aren't overridden.
>
> I'd like to see them added at some point, but if your benchmarks don't 
> justify them, maybe they're not necessary right now. If not, we should 
> make a note to add them later.

As they are all rather simple and straightforward I've added them for 
consistency.

>
> -------
>
> All of List{0,1,2,N}.contains(null) will currently return false. With 
> this change, List{0,1,2}.contains(null) will change to throw NPE, but 
> ListN.contains(null) will continue to return false.
>
> I actually like the change of throwing NPE on contains(null). Note 
> that all the Set and Map implementations here throw NPE when null is 
> passed to contains/containsKey/containsValue, so returning false 
> instead of throwing NPE from the List.contains() methods might have 
> been an oversight on my part. But all the List implementations should 
> be made consistent.
>
> Thus, ListN.contains() should be overridden to provide consistent NPE 
> behavior. It could simply be
>
>     return super.contains(Objects.requireNonNull(o));
>
> or maybe just write out the loop in order to avoid Iterator allocation.

Done.

>
> Also note that (as Peter Levart mentioned some time ago, in the 
> initial review of these implementations) that although it isn't 
> guaranteed by specification, the convention in the collections 
> implementations is to compare an argument o to a contained element e 
> by calling o.equals(e). Thus List1.contains(o) should change to
>
>     return o.equals(e0); // implicit nullcheck of o
>
> and the call to Objects.requireNonNull(o) can be dropped.

Done.

>
> -------
>
>  287         @Override
>  288         public boolean containsAll(Collection<?> o) {
>  289             return o.isEmpty(); // implicit nullcheck
>  290         }
>
>
>  324         @Override
>  325         public boolean contains(Object o) {
>  326             return o.equals(e0); // implicit nullcheck of o
>  327         }
>
>  373         @Override
>  374         public boolean contains(Object o) {
>  375             return o.equals(e0) || o.equals(e1); // implicit 
> nullcheck of o
>  376         }
>
> While it does add a bit of clutter, I like the idea of commenting 
> every location where an implicit nullcheck is done, as is done here, 
> and in several other places you had removed the 
> Objects.requireNonNull() call. Note that some implicit nullchecks in 
> the List code aren't commented; comments should be added there. Please 
> also add a comment at this code in Set2:
>
>  355             if (e0.equals(Objects.requireNonNull(e1))) {
>
> something like "// implicit nullcheck of e0".
>
> Also please add comments for SetN.probe() and MapN.probe() to indicate 
> that callers are relying on them to do implicit nullchecks of their args.

Done.

>
> -------
>
> In Set2, SetN, Map1, and MapN, the addition of @Stable also dropped 
> the "private" access modifier. Other implementations still have 
> corresponding fields as private. Was this intentional? I think they 
> should all remain private.

This was intentional: for those implementations where I dropped private 
there are inner
classes which access the fields directly.  This leads to synthetic 
accessors, which shows up
as JIT compilation overhead during module bootstrap profiling.

This is what made me look at this in the first place, and a large part 
of the reason why I
believe that it's motivated to fast-track this enhancement as a means to 
improve JDK 9
startup metrics.  If you have a strong preference against them being 
made package-private
there's a similar gain to be had by passing them as arguments to 
concrete inner classes,
e.g., for Set2:

         static class Itr<E> implements Iterator<E> {
             private final E e0;
             private final E e1;
             private int idx = 0;
             Itr(E e0, E e1) {
                 this.e0 = e0;
                 this.e1 = e1;
             }
             @Override
             public boolean hasNext() {
                 return idx < 2;
             }

             @Override
             public E next() {
                 if (idx == 0) {
                     idx = 1;
                     return e0;
                 } else if (idx == 1) {
                     idx = 2;
                     return e1;
                 } else {
                     throw new NoSuchElementException();
                 }
             }
         }

         @Override
         public Iterator<E> iterator() {
             return new Itr<E>(e0, e1);
         }

>
> -------
>
>  664         @Override
>  665         public boolean containsKey(Object o) {
>  666             return probe(o) >= 0; // probe implicity nullchecks o
>  667         }
>
> Typo "implicity".

Fixed.

>
> -------
>
>  669         @Override
>  670         public boolean containsValue(Object o) {
>  671             for (int i = 1; i < table.length; i += 2) {
>  672                 Object v = table[i];
>  673                 if (v != null && o.equals(v)) {
>  674                     return true;
>  675                 }
>  676             }
>  677             return false;
>  678         }
>
> At 673, // implicit nullcheck of o

All done:

http://cr.openjdk.java.net/~redestad/8166365/webrev.02/

Thanks for the thorough review!

/Claes

>
> -------
>
> Thanks!!
>
> s'marks


From david.buck at oracle.com  Wed Jan 11 13:56:58 2017
From: david.buck at oracle.com (David Buck)
Date: Wed, 11 Jan 2017 22:56:58 +0900
Subject: [8u-dev] Request for Approval: 8159058: SAXParseException when
	sending soap message
In-Reply-To: <e425b454-aede-cae3-f5ac-342c6ac6b8db@oracle.com>
References: <e425b454-aede-cae3-f5ac-342c6ac6b8db@oracle.com>
Message-ID: <587639AA.7090906@oracle.com>

approved for push to 8u-dev (contingent on successful code review)

I have added the core libraries alias for what will hopefully be a 
trivial code review process.

Cheers,
-Buck



On 2017/01/11 22:01, Aleks Efimov wrote:
> Hello,
>
> Please, approve a backport of JDK-8159058 to JDK8u-dev. This is almost
> straight-forward backport except one difference:
> com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriter.java is not
> part of JDK8 JAXWS version and therefore this changes wasn't
> backported/not needed.
> Regression test and other source changes were applied cleanly after
> reshuffling.
> Testing shows no related failures: JDK regression tests (with backported
> one), JCK runtime jaxws/b related test.
>
> With Best Regards,
> Aleksej
>
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8159058
>
> JDK8 webrev:
> http://cr.openjdk.java.net/~aefimov/8159058/8/00/
>
> JDK9 changesets:
> http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/a98174edd246
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/766677da17b5
>
> JDK9 review thread:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045785.html
>
>
>
>

From chris.hegarty at oracle.com  Wed Jan 11 15:03:59 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 11 Jan 2017 15:03:59 +0000
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <5454aae7-f55b-bec3-f00e-8d76a4a289ad@gmail.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
	<d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
	<3D01F437-6CD5-4CE7-9816-9423A284D27D@oracle.com>
	<bc4e511a-5eb2-f130-4334-b779dfa9fb48@oracle.com>
	<66C0AE9A-7182-4FD2-B60E-AECC49805CC4@oracle.com>
	<5454aae7-f55b-bec3-f00e-8d76a4a289ad@gmail.com>
Message-ID: <A6413C43-D70E-415D-8941-A97D7B3679B1@oracle.com>


On 01/11/2017 02:55 AM, Paul Sandoz wrote:
> I am concerned it?s getting too late to twiddle with the security setting so i took the plunge and wrapped the privateLookupIn calls in doPrivileged blocks. It?s ugly but avoids the circularity (JPRT core/hotspot testing has not failed).
> 
> http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/


This looks good.

Trivially, the comment,  "Initialized lazily on demand?,  applies to the
lazy instantiation of the static nested class rather than the fields
themselves. I wonder if it would be better at the nested class level,
rather than at the fields.

-Chris.

From sean.coffey at oracle.com  Wed Jan 11 15:22:30 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 11 Jan 2017 15:22:30 +0000
Subject: [8u-dev] Request for Approval: 8159058: SAXParseException when
	sending soap message
In-Reply-To: <587639AA.7090906@oracle.com>
References: <e425b454-aede-cae3-f5ac-342c6ac6b8db@oracle.com>
	<587639AA.7090906@oracle.com>
Message-ID: <58764DB6.9030509@oracle.com>

Backported changes look fine.

Regards,
Sean.

On 11/01/17 13:56, David Buck wrote:
> approved for push to 8u-dev (contingent on successful code review)
>
> I have added the core libraries alias for what will hopefully be a 
> trivial code review process.
>
> Cheers,
> -Buck
>
>
>
> On 2017/01/11 22:01, Aleks Efimov wrote:
>> Hello,
>>
>> Please, approve a backport of JDK-8159058 to JDK8u-dev. This is almost
>> straight-forward backport except one difference:
>> com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriter.java is not
>> part of JDK8 JAXWS version and therefore this changes wasn't
>> backported/not needed.
>> Regression test and other source changes were applied cleanly after
>> reshuffling.
>> Testing shows no related failures: JDK regression tests (with backported
>> one), JCK runtime jaxws/b related test.
>>
>> With Best Regards,
>> Aleksej
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8159058
>>
>> JDK8 webrev:
>> http://cr.openjdk.java.net/~aefimov/8159058/8/00/
>>
>> JDK9 changesets:
>> http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/a98174edd246
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/766677da17b5
>>
>> JDK9 review thread:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045785.html 
>>
>>
>>
>>
>>


From szegedia at gmail.com  Wed Jan 11 16:01:09 2017
From: szegedia at gmail.com (Attila Szegedi)
Date: Wed, 11 Jan 2017 17:01:09 +0100
Subject: RFR: 8166365: Small immutable collections should provide
	optimized implementations when possible
In-Reply-To: <8f960792-51e1-f829-762b-02fc2781abc6@oracle.com>
References: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
	<c7ca271e-8640-0822-bfaa-362098215a91@oracle.com>
	<8f960792-51e1-f829-762b-02fc2781abc6@oracle.com>
Message-ID: <1AF7279C-A9AE-474B-A8EB-33C95D53BD7F@gmail.com>

Collections.java:

4987         @Override
4988         public int hashCode() {
4989             return (k == null ? 0 : k.hashCode()) ^
4990                    (v == null ? 0 : v.hashCode());

Why not use Objects.hashCode here too, that is return Objects.hashCode(k) ^ Objects.hashCode(v) ?

Attila.

> On 11 Jan 2017, at 14:43, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
>> ...
> 
> All done:
> 
> http://cr.openjdk.java.net/~redestad/8166365/webrev.02/
> 
> Thanks for the thorough review!
> 
> /Claes


From claes.redestad at oracle.com  Wed Jan 11 16:12:54 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 11 Jan 2017 17:12:54 +0100
Subject: RFR: 8166365: Small immutable collections should provide
	optimized implementations when possible
In-Reply-To: <1AF7279C-A9AE-474B-A8EB-33C95D53BD7F@gmail.com>
References: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
	<c7ca271e-8640-0822-bfaa-362098215a91@oracle.com>
	<8f960792-51e1-f829-762b-02fc2781abc6@oracle.com>
	<1AF7279C-A9AE-474B-A8EB-33C95D53BD7F@gmail.com>
Message-ID: <8a10722d-8c8e-9db3-083f-2557acf2836c@oracle.com>

Hi Attila,

On 01/11/2017 05:01 PM, Attila Szegedi wrote:
> Collections.java:
>
> 4987         @Override
> 4988         public int hashCode() {
> 4989             return (k == null ? 0 : k.hashCode()) ^
> 4990                    (v == null ? 0 : v.hashCode());
>
> Why not use Objects.hashCode here too, that is return Objects.hashCode(k) ^ Objects.hashCode(v) ?

why not, indeed. Updated in-place.

Thanks!

/Claes

>
> Attila.
>
>> On 11 Jan 2017, at 14:43, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>>> ...
>> All done:
>>
>> http://cr.openjdk.java.net/~redestad/8166365/webrev.02/
>>
>> Thanks for the thorough review!
>>
>> /Claes


From paul.sandoz at oracle.com  Wed Jan 11 16:42:53 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Jan 2017 08:42:53 -0800
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <5454aae7-f55b-bec3-f00e-8d76a4a289ad@gmail.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
	<d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
	<3D01F437-6CD5-4CE7-9816-9423A284D27D@oracle.com>
	<bc4e511a-5eb2-f130-4334-b779dfa9fb48@oracle.com>
	<66C0AE9A-7182-4FD2-B60E-AECC49805CC4@oracle.com>
	<5454aae7-f55b-bec3-f00e-8d76a4a289ad@gmail.com>
Message-ID: <F6036E2D-CD3D-4158-9939-703B76038509@oracle.com>

Hi Peter,

You beat me to it!

My plan was to define a private method, accepting the lookup and teleporting class, and encapsulating the doPrivileged block. Then i could call that method for all usages in TLR. It does mean three doPrivileged executions, but that is probably ok.

Thanks,
Paul.

> On 11 Jan 2017, at 03:14, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi Paul,
> 
> On 01/11/2017 02:55 AM, Paul Sandoz wrote:
>> I am concerned it?s getting too late to twiddle with the security setting so i took the plunge and wrapped the privateLookupIn calls in doPrivileged blocks. It?s ugly but avoids the circularity (JPRT core/hotspot testing has not failed).
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/>
>> 
>> I??ll resend this out for closer review by Martin and Doug.
> 
> You could simplify the static initializer in TLR.ThreadGroupCreator a bit:
> 
>     static {
>         try {
>             // Teleport the lookup to access fields in Thread and ThreadGroup
>             MethodHandles.Lookup[] l = java.security.AccessController.doPrivileged(
>                 new java.security.PrivilegedExceptionAction<MethodHandles.Lookup[]>() {
>                     public MethodHandles.Lookup[] run() {
>                         MethodHandles.Lookup lookup = MethodHandles.lookup();
>                         return new MethodHandles.Lookup[] {
>                             MethodHandles.privateLookupIn(Thread.class, lookup),
>                             MethodHandles.privateLookupIn(ThreadGroup.class, lookup)
>                         };
>                     }
>                 });
>             THREAD_GROUP =
>                 l[0].findVarHandle(Thread.class, "group", ThreadGroup.class);
>             THREAD_GROUP_PARENT =
>                 l[1].findVarHandle(ThreadGroup.class, "parent", ThreadGroup.class);
>         } catch (Exception e) {
>             throw new Error(e);
>         }
>     }
> 
> 
> Regards, Peter
> 
>> Paul.
>> 
>> 
>>> On 10 Jan 2017, at 05:00, Alan Bateman <Alan.Bateman at oracle.com> <mailto:Alan.Bateman at oracle.com> wrote:
>>> 
>>> 
>>> 
>>> On 09/01/2017 19:09, Paul Sandoz wrote:
>>>>> On 9 Jan 2017, at 05:36, Alan Bateman <Alan.Bateman at oracle.com> <mailto:Alan.Bateman at oracle.com> wrote:
>>>>> 
>>>>> On 05/01/2017 19:01, Paul Sandoz wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I encountered some circularity issues with security manager and VarHandles, specifically when attempting to use the new MethodHandles.privateLookupIn, so say ThreadLocalRandom has access to fields in Thread [1].
>>>>>> 
>>>>>> When running with a security manager ThreadLocalRandom clinit depends on various security stuff that eventually depends on ConcurrentSkipListMap which depends on ThreadLocalRandom, whose static state has not been fully initialzed.
>>>>>> 
>>>>>> The current security permission check in MethodHandles.privateLookupIn may be a too blunt and possibly should be refined along similar lines to Lookup.checkSecurityManager e.g. no check should be needed for classes within the same module (since this is a refined/controlled/principled form of setAccessible, plus no pounding on final fields). That would solve the problem in this case. But, the general point remains, and i have not thought too hard if there are other ways to solve this.
>>>>>> 
>>>>> This would mean inconsistency with setAccessible where you need this blunt permission when suppressing access. Also I think Lookup.checkSecurityManager will do different checks when you don't have a full power lookup so it would mean adjusting the privateLookupIn.
>>>> Some adjustment would definitely be required, the perhaps the simplest solution is not to perform a security check if within the same module?
>>>> 
>>> It might be okay when the lookup is a full-power lookup to class in java.base and it's called to get a full-power look to some other class in java.base. However, generalizing this would probably need security eyes. Consider two libraries on the class path (same unnamed module) for example. Also the inconsistency with setAccessible where it always checks the permission when running with a security manager.
>>> 
>>> -Alan
> 


From paul.sandoz at oracle.com  Wed Jan 11 16:43:06 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Jan 2017 08:43:06 -0800
Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager
In-Reply-To: <A6413C43-D70E-415D-8941-A97D7B3679B1@oracle.com>
References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com>
	<2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com>
	<0e2b9fdc-8b7d-73c9-907d-ffe987b5b8fd@gmail.com>
	<a380b9e2-7ac8-ad0a-2589-83ea40c42160@oracle.com>
	<EA94713D-F669-4BC3-A872-42372FF38FB2@oracle.com>
	<d78b60b9-2a8d-aea4-4aac-916c91791586@oracle.com>
	<3D01F437-6CD5-4CE7-9816-9423A284D27D@oracle.com>
	<bc4e511a-5eb2-f130-4334-b779dfa9fb48@oracle.com>
	<66C0AE9A-7182-4FD2-B60E-AECC49805CC4@oracle.com>
	<5454aae7-f55b-bec3-f00e-8d76a4a289ad@gmail.com>
	<A6413C43-D70E-415D-8941-A97D7B3679B1@oracle.com>
Message-ID: <799E65B1-7DC1-4606-A786-E759C2B9CBE3@oracle.com>


> On 11 Jan 2017, at 07:03, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> 
> On 01/11/2017 02:55 AM, Paul Sandoz wrote:
>> I am concerned it?s getting too late to twiddle with the security setting so i took the plunge and wrapped the privateLookupIn calls in doPrivileged blocks. It?s ugly but avoids the circularity (JPRT core/hotspot testing has not failed).
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/
> 
> 
> This looks good.
> 
> Trivially, the comment,  "Initialized lazily on demand?,  applies to the
> lazy instantiation of the static nested class rather than the fields
> themselves. I wonder if it would be better at the nested class level,
> rather than at the fields.
> 

Yes, i will do that.

Thanks,
Paul.

From lance.andersen at oracle.com  Wed Jan 11 17:03:46 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 11 Jan 2017 12:03:46 -0500
Subject: [8u-dev] Request for Approval: 8159058: SAXParseException when
	sending soap message
In-Reply-To: <587639AA.7090906@oracle.com>
References: <e425b454-aede-cae3-f5ac-342c6ac6b8db@oracle.com>
	<587639AA.7090906@oracle.com>
Message-ID: <36D47A48-6507-4F2F-8AF0-090979B5F1BF@oracle.com>

The change looks good.  

Best
Lance
> On Jan 11, 2017, at 8:56 AM, David Buck <david.buck at oracle.com> wrote:
> 
> approved for push to 8u-dev (contingent on successful code review)
> 
> I have added the core libraries alias for what will hopefully be a trivial code review process.
> 
> Cheers,
> -Buck
> 
> 
> 
> On 2017/01/11 22:01, Aleks Efimov wrote:
>> Hello,
>> 
>> Please, approve a backport of JDK-8159058 to JDK8u-dev. This is almost
>> straight-forward backport except one difference:
>> com/sun/xml/internal/messaging/saaj/util/stax/SaajStaxWriter.java is not
>> part of JDK8 JAXWS version and therefore this changes wasn't
>> backported/not needed.
>> Regression test and other source changes were applied cleanly after
>> reshuffling.
>> Testing shows no related failures: JDK regression tests (with backported
>> one), JCK runtime jaxws/b related test.
>> 
>> With Best Regards,
>> Aleksej
>> 
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8159058
>> 
>> JDK8 webrev:
>> http://cr.openjdk.java.net/~aefimov/8159058/8/00/
>> 
>> JDK9 changesets:
>> http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/a98174edd246
>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/766677da17b5
>> 
>> JDK9 review thread:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045785.html
>> 
>> 
>> 
>> 

 <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 daniel.latremoliere at gmail.com  Wed Jan 11 17:26:16 2017
From: daniel.latremoliere at gmail.com (=?UTF-8?B?RGFuaWVsIExhdHLDqW1vbGnDqHJl?=)
Date: Wed, 11 Jan 2017 18:26:16 +0100
Subject: Useful factory for defensive copying (short-circuit with new
	immutable collections)
Message-ID: <757048c1-2bc4-ef4f-c650-b710ae76f53b@gmail.com>

In a library, when you receive externally an object at construction of 
one of your class and mandate it to be immutable, you need to make a 
defensive copy. Given new immutable collections, it would be useful to 
have a factory for defensive copy, doing nothing if object to be copied 
is already an immutable collection (List, Set, Map), e.g. with a Map:

public static <K,V> Map<K,V> ofEntries(Map<K,V> map) {
   // short-circuit if already an immutable Map
   if (map.getClass().getDeclaringClass() == java.util.ImmutableCollections.class) {
    return map;
   }
   // if mutable, then make an immutable copy
   Map.Entry[] entries = new Map.Entry[map.size()];
   int i = 0;
   for(Map.Entry<K,V> entry : map.entrySet()) {
     entries[i] = Map.entry(entry.getKey(), entry.getValue());
     i += 1;
  }
  return Map.ofEntries(entries);
}


--
Thanks,
Daniel.


From martinrb at google.com  Wed Jan 11 18:05:50 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 11 Jan 2017 10:05:50 -0800
Subject: RFR: 8166365: Small immutable collections should provide
	optimized implementations when possible
In-Reply-To: <8f960792-51e1-f829-762b-02fc2781abc6@oracle.com>
References: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
	<c7ca271e-8640-0822-bfaa-362098215a91@oracle.com>
	<8f960792-51e1-f829-762b-02fc2781abc6@oracle.com>
Message-ID: <CA+kOe08Ou380ZU+MJcBG5Qxom4t95zWmeZ9x3gfeKx_E5b9Unw@mail.gmail.com>

On Wed, Jan 11, 2017 at 5:43 AM, Claes Redestad <claes.redestad at oracle.com>
wrote:

>
>> -------
>>
>> In Set2, SetN, Map1, and MapN, the addition of @Stable also dropped the
>> "private" access modifier. Other implementations still have corresponding
>> fields as private. Was this intentional? I think they should all remain
>> private.
>>
>
> This was intentional: for those implementations where I dropped private
> there are inner
> classes which access the fields directly.  This leads to synthetic
> accessors, which shows up
> as JIT compilation overhead during module bootstrap profiling.
>

In java.util.concurrent, our policy is to avoid creating synthetic
accessors, so we also promote private to package private when accessed by
nested classes, and this seems to be the best engineering compromise...
(until we get nestmates?)


> This is what made me look at this in the first place, and a large part of
> the reason why I
> believe that it's motivated to fast-track this enhancement as a means to
> improve JDK 9
> startup metrics.  If you have a strong preference against them being made
> package-private
> there's a similar gain to be had by passing them as arguments to concrete
> inner classes,
> e.g., for Set2:
>
>         static class Itr<E> implements Iterator<E> {
>             private final E e0;
>             private final E e1;
>             private int idx = 0;
>             Itr(E e0, E e1) {
>                 this.e0 = e0;
>                 this.e1 = e1;
>             }
>             @Override
>             public boolean hasNext() {
>                 return idx < 2;
>             }
>
>             @Override
>             public E next() {
>                 if (idx == 0) {
>                     idx = 1;
>                     return e0;
>                 } else if (idx == 1) {
>                     idx = 2;
>                     return e1;
>                 } else {
>                     throw new NoSuchElementException();
>                 }
>             }
>         }
>
>         @Override
>         public Iterator<E> iterator() {
>             return new Itr<E>(e0, e1);
>         }
>

From Roger.Riggs at Oracle.com  Wed Jan 11 18:38:01 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 11 Jan 2017 13:38:01 -0500
Subject: RFR (JAXP) 8171243 : CatalogManager.catalogResolver throws
	FileSystemNotFoundException with jar
In-Reply-To: <a7710860-2e81-fa86-c7a3-75a9e3f01147@oracle.com>
References: <3cfcba76-6436-92ec-5174-747318fa9ff5@oracle.com>
	<25f1ea5e-a2cd-83c2-8f49-346fc9ff2350@Oracle.com>
	<a7710860-2e81-fa86-c7a3-75a9e3f01147@oracle.com>
Message-ID: <688d45d8-7c4b-88dd-72d6-14e15afd90ff@Oracle.com>

Hi Joe,

Thanks for the clarifications.

Looks good

Roger


On 1/10/2017 1:58 PM, huizhe wang wrote:
>
> On 1/9/2017 2:17 PM, Roger Riggs wrote:
>> Hi Joe,
>>
>> a few comments:
>>
>> CatalogManager:
>>  - line 58:  "will /return /as no mapping is found";
>>   Or is it describing the behavior of the CatalogResolver (which is 
>> throw a CatalogException)?
>>    (possible more than 1 place)
>
> While waiting for spec approval, I've updated the webrev and added 3 
> tests in CatalogFileInputTest [1]: line 118 - 138.
>
> [1] 
> http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/test/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java.html
>>
>> Check the copyrights -> 2017  (JarUtils.java)
>
> Updated all classes / tests.
>>
>> in JAXWS repo:
>>  - Options.java:  line 786 - you could use URI[]::new instead of 
>> creating a placeholder URI[0].
>
> Updated both classes.
>
> webrevs:
> http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/
> http://cr.openjdk.java.net/~joehw/jdk9/8171243_jaxws/webrev/
>
> Thanks,
> Joe
>
>>
>> Looks good,  Roger
>>
>>
>> On 1/9/2017 12:38 PM, huizhe wang wrote:
>>> Hi,
>>>
>>> The current Catalog API accepts file paths or URIs in a form of 
>>> String to create Catalog or CatalogResolver in an effort to maintain 
>>> consistency with the old Catalog API and other existing processors. 
>>> However, that also introduced an ambiguity in the API, which is 
>>> unwanted for a new API in Java SE 9.
>>>
>>> Please review the changes.
>>> In jaxp repo:
>>> http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/
>>>
>>> In jaxws repo:
>>> http://cr.openjdk.java.net/~joehw/jdk9/8171243_jaxws/webrev/
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8171243
>>>
>>> Thanks,
>>> Joe
>>>
>>
>


From paul.sandoz at oracle.com  Wed Jan 11 20:21:49 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Jan 2017 12:21:49 -0800
Subject: RFR 8160710: Enable Thread to grant VarHandle field access to
	ThreadLocalRandom/Striped64
Message-ID: <9F11819C-A5CF-4F74-B463-EB3CB6731393@oracle.com>

Hi,

Please review:

  http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/

This patch updates ThreadLocalRandom, Striped64 and LockSupport to use VarHandles instead of Unsafe to access fields in Thread, via the MethodsHandles.privateLookupIn method.

Since there are three usages of MethodsHandles.privateLookupIn in ThreadLocalRandom i consolidated the doPrivileged block in a private static helper method, being paranoid i placed some checks to avoid this method being potentially abused to circumvent the security check, perhaps that is overkill?

I ran this patch though our test infra a few times and have not observed any transient failures.

Thanks,
Paul.

From huizhe.wang at oracle.com  Wed Jan 11 20:22:47 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 11 Jan 2017 12:22:47 -0800
Subject: RFR (JAXP) 8171243 : CatalogManager.catalogResolver throws
	FileSystemNotFoundException with jar
In-Reply-To: <688d45d8-7c4b-88dd-72d6-14e15afd90ff@Oracle.com>
References: <3cfcba76-6436-92ec-5174-747318fa9ff5@oracle.com>
	<25f1ea5e-a2cd-83c2-8f49-346fc9ff2350@Oracle.com>
	<a7710860-2e81-fa86-c7a3-75a9e3f01147@oracle.com>
	<688d45d8-7c4b-88dd-72d6-14e15afd90ff@Oracle.com>
Message-ID: <0dbb02b1-2444-2e8c-c5b9-b62347ed4b5e@oracle.com>

Thanks Roger!

-Joe

On 1/11/2017 10:38 AM, Roger Riggs wrote:
> Hi Joe,
>
> Thanks for the clarifications.
>
> Looks good
>
> Roger
>
>
> On 1/10/2017 1:58 PM, huizhe wang wrote:
>>
>> On 1/9/2017 2:17 PM, Roger Riggs wrote:
>>> Hi Joe,
>>>
>>> a few comments:
>>>
>>> CatalogManager:
>>>  - line 58:  "will /return /as no mapping is found";
>>>   Or is it describing the behavior of the CatalogResolver (which is 
>>> throw a CatalogException)?
>>>    (possible more than 1 place)
>>
>> While waiting for spec approval, I've updated the webrev and added 3 
>> tests in CatalogFileInputTest [1]: line 118 - 138.
>>
>> [1] 
>> http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/test/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java.html
>>>
>>> Check the copyrights -> 2017  (JarUtils.java)
>>
>> Updated all classes / tests.
>>>
>>> in JAXWS repo:
>>>  - Options.java:  line 786 - you could use URI[]::new instead of 
>>> creating a placeholder URI[0].
>>
>> Updated both classes.
>>
>> webrevs:
>> http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/
>> http://cr.openjdk.java.net/~joehw/jdk9/8171243_jaxws/webrev/
>>
>> Thanks,
>> Joe
>>
>>>
>>> Looks good,  Roger
>>>
>>>
>>> On 1/9/2017 12:38 PM, huizhe wang wrote:
>>>> Hi,
>>>>
>>>> The current Catalog API accepts file paths or URIs in a form of 
>>>> String to create Catalog or CatalogResolver in an effort to 
>>>> maintain consistency with the old Catalog API and other existing 
>>>> processors. However, that also introduced an ambiguity in the API, 
>>>> which is unwanted for a new API in Java SE 9.
>>>>
>>>> Please review the changes.
>>>> In jaxp repo:
>>>> http://cr.openjdk.java.net/~joehw/jdk9/8171243/webrev/
>>>>
>>>> In jaxws repo:
>>>> http://cr.openjdk.java.net/~joehw/jdk9/8171243_jaxws/webrev/
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8171243
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>
>>
>


From martinrb at google.com  Wed Jan 11 22:00:12 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 11 Jan 2017 14:00:12 -0800
Subject: RFR 8160710: Enable Thread to grant VarHandle field access to
	ThreadLocalRandom/Striped64
In-Reply-To: <9F11819C-A5CF-4F74-B463-EB3CB6731393@oracle.com>
References: <9F11819C-A5CF-4F74-B463-EB3CB6731393@oracle.com>
Message-ID: <CA+kOe0_UMinGyWD5WV_HneS9htz+0GaFJ=wLrLjRhSGW9JkL0w@mail.gmail.com>

Thanks, Paul.

Looks good.  Nits:

---

Our inline assignment style is non-standard, but we like it and it saves a
byte of bytecode occasionally, making things a tiny bit easier for the JIT.

---

The threadgroup creation code that uses cheating has always seemed fishy to
me.  The straightforward

    /**
     * Returns a new group with the system ThreadGroup (the
     * topmost, parent-less group) as parent.
     */
    static final ThreadGroup createThreadGroup(String name) {
        if (name == null)
            throw new NullPointerException();
        ThreadGroup group = Thread.currentThread().getThreadGroup();
        for (ThreadGroup p; (p = group.getParent()) != null; )
            group = p;
        return new ThreadGroup(group, name);
    }

passes all tests.  That could be wrapped in a doPrivileged, or we could add
something more principled to ThreadGroup itself.  I don't know what the
motivations are for the threadgroup code.

---

 431             // Teleport the lookup to access fields in Thread

Teleport?!  Maybe "Obtain a private lookup object" but that should be
obvious from the name "privateLookupIn"


On Wed, Jan 11, 2017 at 12:21 PM, Paul Sandoz <paul.sandoz at oracle.com>
wrote:

> Hi,
>
> Please review:
>
>   http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/
>
> This patch updates ThreadLocalRandom, Striped64 and LockSupport to use
> VarHandles instead of Unsafe to access fields in Thread, via the
> MethodsHandles.privateLookupIn method.
>
> Since there are three usages of MethodsHandles.privateLookupIn in
> ThreadLocalRandom i consolidated the doPrivileged block in a private static
> helper method, being paranoid i placed some checks to avoid this method
> being potentially abused to circumvent the security check, perhaps that is
> overkill?
>
> I ran this patch though our test infra a few times and have not observed
> any transient failures.
>
> Thanks,
> Paul.
>

From wasserman.louis at gmail.com  Wed Jan 11 22:30:45 2017
From: wasserman.louis at gmail.com (Louis Wasserman)
Date: Wed, 11 Jan 2017 22:30:45 +0000
Subject: RFR: 8166365: Small immutable collections should provide
	optimized implementations when possible
In-Reply-To: <CA+kOe08Ou380ZU+MJcBG5Qxom4t95zWmeZ9x3gfeKx_E5b9Unw@mail.gmail.com>
References: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
	<c7ca271e-8640-0822-bfaa-362098215a91@oracle.com>
	<8f960792-51e1-f829-762b-02fc2781abc6@oracle.com>
	<CA+kOe08Ou380ZU+MJcBG5Qxom4t95zWmeZ9x3gfeKx_E5b9Unw@mail.gmail.com>
Message-ID: <CA+tXMXORYNbp-t7UcAu1_7AVXG=WvGq5xjuKH_54RzW9N55Yvg@mail.gmail.com>

I haven't followed this much, but an observation: in Guava, we avoided
creating lots of specialized implementations for small collections, because
the JVM, at least at the time, had a sweet spot for bimorphic dispatch:
method calls where the real implementation would be one of two options, and
that the cost blew up after you hit three, and we considered hitting that
sweet spot more worthwhile than the slightly smaller overhead for
collections that were already small.

As a result, many of our immutable collection implementations converged on
having two implementations: one single-element implementation, and one
implementation for everything else (0, 2, 3... but not 1), and then we had
a singleton static constant object for the 0-element case.

I don't know if that calculus has changed, but it seemed worth mentioning.

On Wed, Jan 11, 2017 at 10:06 AM Martin Buchholz <martinrb at google.com>
wrote:

> On Wed, Jan 11, 2017 at 5:43 AM, Claes Redestad <claes.redestad at oracle.com
> >
> wrote:
>
> >
> >> -------
> >>
> >> In Set2, SetN, Map1, and MapN, the addition of @Stable also dropped the
> >> "private" access modifier. Other implementations still have
> corresponding
> >> fields as private. Was this intentional? I think they should all remain
> >> private.
> >>
> >
> > This was intentional: for those implementations where I dropped private
> > there are inner
> > classes which access the fields directly.  This leads to synthetic
> > accessors, which shows up
> > as JIT compilation overhead during module bootstrap profiling.
> >
>
> In java.util.concurrent, our policy is to avoid creating synthetic
> accessors, so we also promote private to package private when accessed by
> nested classes, and this seems to be the best engineering compromise...
> (until we get nestmates?)
>
>
> > This is what made me look at this in the first place, and a large part of
> > the reason why I
> > believe that it's motivated to fast-track this enhancement as a means to
> > improve JDK 9
> > startup metrics.  If you have a strong preference against them being made
> > package-private
> > there's a similar gain to be had by passing them as arguments to concrete
> > inner classes,
> > e.g., for Set2:
> >
> >         static class Itr<E> implements Iterator<E> {
> >             private final E e0;
> >             private final E e1;
> >             private int idx = 0;
> >             Itr(E e0, E e1) {
> >                 this.e0 = e0;
> >                 this.e1 = e1;
> >             }
> >             @Override
> >             public boolean hasNext() {
> >                 return idx < 2;
> >             }
> >
> >             @Override
> >             public E next() {
> >                 if (idx == 0) {
> >                     idx = 1;
> >                     return e0;
> >                 } else if (idx == 1) {
> >                     idx = 2;
> >                     return e1;
> >                 } else {
> >                     throw new NoSuchElementException();
> >                 }
> >             }
> >         }
> >
> >         @Override
> >         public Iterator<E> iterator() {
> >             return new Itr<E>(e0, e1);
> >         }
> >
>

From stuart.marks at oracle.com  Wed Jan 11 22:38:43 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 11 Jan 2017 14:38:43 -0800
Subject: RFR: 8166365: Small immutable collections should provide
	optimized implementations when possible
In-Reply-To: <8f960792-51e1-f829-762b-02fc2781abc6@oracle.com>
References: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
	<c7ca271e-8640-0822-bfaa-362098215a91@oracle.com>
	<8f960792-51e1-f829-762b-02fc2781abc6@oracle.com>
Message-ID: <955e7d38-7495-429f-c890-3423c1c55df8@oracle.com>



On 1/11/17 5:43 AM, Claes Redestad wrote:
>> List2.hashCode()
>> ListN.hashCode()
>> MapN.hashCode()
>>
>> aren't overridden.
>>
>> I'd like to see them added at some point, but if your benchmarks don't justify
>> them, maybe they're not necessary right now. If not, we should make a note to
>> add them later.
>
> As they are all rather simple and straightforward I've added them for consistency.

OK, thanks for adding these.

>> In Set2, SetN, Map1, and MapN, the addition of @Stable also dropped the
>> "private" access modifier. Other implementations still have corresponding
>> fields as private. Was this intentional? I think they should all remain private.
>
> This was intentional: for those implementations where I dropped private there
> are inner
> classes which access the fields directly.  This leads to synthetic accessors,
> which shows up
> as JIT compilation overhead during module bootstrap profiling.
>
> This is what made me look at this in the first place, and a large part of the
> reason why I
> believe that it's motivated to fast-track this enhancement as a means to improve
> JDK 9
> startup metrics.  If you have a strong preference against them being made

[snipped example of using static classes]

Oh, right! I was aware of the issue of the accessor methods, but somehow I 
forgot about it when reviewing the code.

For the implementations that have inner classes (Set2, SetN, and MapN) I think 
it's fine for the fields to have package access instead of being private. It 
doesn't seem worth it to do the refactoring of the inner classes to static 
classes, just to make the fields private. (In fact, I seem to recall that an 
earlier version of the code did use static classes, and I had refactored it to 
use inner classes, reducing the clutter considerably.)

But note, it looks like Map1 dropped "private" even though it doesn't have any 
inner classes. So maybe just restore "private" for Map1's fields.

> All done:
>
> http://cr.openjdk.java.net/~redestad/8166365/webrev.02/

Looks great! If all you do is restore private fields in Map1, no need for 
another webrev.

Thanks,

s'marks


From paul.sandoz at oracle.com  Wed Jan 11 23:13:49 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Jan 2017 15:13:49 -0800
Subject: RFR 8160710: Enable Thread to grant VarHandle field access to
	ThreadLocalRandom/Striped64
In-Reply-To: <CA+kOe0_UMinGyWD5WV_HneS9htz+0GaFJ=wLrLjRhSGW9JkL0w@mail.gmail.com>
References: <9F11819C-A5CF-4F74-B463-EB3CB6731393@oracle.com>
	<CA+kOe0_UMinGyWD5WV_HneS9htz+0GaFJ=wLrLjRhSGW9JkL0w@mail.gmail.com>
Message-ID: <CC0BFC96-0DE2-47A6-BD18-A09DCE06A469@oracle.com>


> On 11 Jan 2017, at 14:00, Martin Buchholz <martinrb at google.com> wrote:
> 
> Thanks, Paul.
> 
> Looks good.  Nits:
> 
> ---
> 
> Our inline assignment style is non-standard, but we like it and it saves a byte of bytecode occasionally, making things a tiny bit easier for the JIT.
> 

Are you referring to cases like:

 964         int r = (int) SECONDARY.get(t);
 965         if (r != 0) {

?

I moved it out to make it clearer on the cast, but i can inline it as you prefer.


> ---
> 
> The threadgroup creation code that uses cheating has always seemed fishy to me.  The straightforward
> 
>     /**
>      * Returns a new group with the system ThreadGroup (the
>      * topmost, parent-less group) as parent.
>      */
>     static final ThreadGroup createThreadGroup(String name) {
>         if (name == null)
>             throw new NullPointerException();
>         ThreadGroup group = Thread.currentThread().getThreadGroup();
>         for (ThreadGroup p; (p = group.getParent()) != null; )
>             group = p;
>         return new ThreadGroup(group, name);
>     }
> 
> passes all tests.  That could be wrapped in a doPrivileged, or we could add something more principled to ThreadGroup itself.  I don't know what the motivations are for the threadgroup code.
> 

Good point, me neither, nor the association with TLR (perhaps because there are over methods used by InnocuousForkJoinWorkerThread, see below). The Unsafe usage rolled in with:

  https://bugs.openjdk.java.net/browse/JDK-8157523
  http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fd4819ec5afd


In ForkJoinWorkerThread:

static final class InnocuousForkJoinWorkerThread extends ForkJoinWorkerThread {
    /** The ThreadGroup for all InnocuousForkJoinWorkerThreads */
    private static final ThreadGroup innocuousThreadGroup =
        ThreadLocalRandom.createThreadGroup("InnocuousForkJoinWorkerThreadGroup?);


In ForkJoinPool:

private ForkJoinPool(byte forCommonPoolOnly) {
...
    ForkJoinWorkerThreadFactory fac = null;
...
    if (fac == null) {
        if (System.getSecurityManager() == null)
            fac = defaultForkJoinWorkerThreadFactory;
        else // use security-managed default
            fac = new InnocuousForkJoinWorkerThreadFactory();
    }
?


private static final class InnocuousForkJoinWorkerThreadFactory
    implements ForkJoinWorkerThreadFactory {
...
    public final ForkJoinWorkerThread newThread(ForkJoinPool pool) {
        return AccessController.doPrivileged(new PrivilegedAction<>() {
            public ForkJoinWorkerThread run() {
                return new ForkJoinWorkerThread.
                    InnocuousForkJoinWorkerThread(pool);
            }}, INNOCUOUS_ACC);
    }
}


So everything is wrapped in a doPrivileged block.

My guess as at some point in development it was important to efficiently bypass the security check of ThreadGroup.getParent, and Thread.getGroup came along for the ride.

AFAICT I don?t think we need it, and it would be nice to remove the VarHandle code and move createThreadGroup to be a static method of InnocuousForkJoinWorkerThread. How about:


static final class InnocuousForkJoinWorkerThread extends ForkJoinWorkerThread {
    /** The ThreadGroup for all InnocuousForkJoinWorkerThreads */
    private static final ThreadGroup innocuousThreadGroup =
            createThreadGroup();
?
    private static ThreadGroup createThreadGroup() {
        ThreadGroup currentGroup = Thread.currentThread().getThreadGroup();
        ThreadGroup topGroup = java.security.AccessController.doPrivileged(
                new java.security.PrivilegedAction<ThreadGroup>() {
                    public ThreadGroup run() {
                        ThreadGroup group = currentGroup;
                        for (ThreadGroup p; (p = group.getParent()) != null; )
                            group = p;
                        return group;
                    }});
        return new ThreadGroup(topGroup, "InnocuousForkJoinWorkerThreadGroup");
    }
}

That also passes the tests we have for the Innocuous case.


> ---
> 
>  431             // Teleport the lookup to access fields in Thread
> 
> Teleport?!  Maybe "Obtain a private lookup object" but that should be obvious from the name ?privateLookupIn?
> 

Yes, i removed the comments.

Thanks,
Paul.


> 
> On Wed, Jan 11, 2017 at 12:21 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Hi,
> 
> Please review:
> 
>   http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/
> 
> This patch updates ThreadLocalRandom, Striped64 and LockSupport to use VarHandles instead of Unsafe to access fields in Thread, via the MethodsHandles.privateLookupIn method.
> 
> Since there are three usages of MethodsHandles.privateLookupIn in ThreadLocalRandom i consolidated the doPrivileged block in a private static helper method, being paranoid i placed some checks to avoid this method being potentially abused to circumvent the security check, perhaps that is overkill?
> 
> I ran this patch though our test infra a few times and have not observed any transient failures.
> 
> Thanks,
> Paul.
> 


From martinrb at google.com  Wed Jan 11 23:39:52 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 11 Jan 2017 15:39:52 -0800
Subject: RFR 8160710: Enable Thread to grant VarHandle field access to
	ThreadLocalRandom/Striped64
In-Reply-To: <CC0BFC96-0DE2-47A6-BD18-A09DCE06A469@oracle.com>
References: <9F11819C-A5CF-4F74-B463-EB3CB6731393@oracle.com>
	<CA+kOe0_UMinGyWD5WV_HneS9htz+0GaFJ=wLrLjRhSGW9JkL0w@mail.gmail.com>
	<CC0BFC96-0DE2-47A6-BD18-A09DCE06A469@oracle.com>
Message-ID: <CA+kOe095Nebj=TOVgnBJ2xnspUpMStVDN=f0O3sXRgwbqMxGmQ@mail.gmail.com>

Doug, please try to remember the details of the thread group code.


On Wed, Jan 11, 2017 at 3:13 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> > On 11 Jan 2017, at 14:00, Martin Buchholz <martinrb at google.com> wrote:
>
> > Our inline assignment style is non-standard, but we like it and it saves
> a byte of bytecode occasionally, making things a tiny bit easier for the
> JIT.
> >
>
> Are you referring to cases like:
>
>  964         int r = (int) SECONDARY.get(t);
>  965         if (r != 0) {
>
> ?
>
> I moved it out to make it clearer on the cast, but i can inline it as you
> prefer.
>
>
Yes. jsr166 style is to inline, even though we don't recommend it for
regular java code.


> ---
> >
> > The threadgroup creation code that uses cheating has always seemed fishy
> to me.  The straightforward
> >
> >     /**
> >      * Returns a new group with the system ThreadGroup (the
> >      * topmost, parent-less group) as parent.
> >      */
> >     static final ThreadGroup createThreadGroup(String name) {
> >         if (name == null)
> >             throw new NullPointerException();
> >         ThreadGroup group = Thread.currentThread().getThreadGroup();
> >         for (ThreadGroup p; (p = group.getParent()) != null; )
> >             group = p;
> >         return new ThreadGroup(group, name);
> >     }
> >
> > passes all tests.  That could be wrapped in a doPrivileged, or we could
> add something more principled to ThreadGroup itself.  I don't know what the
> motivations are for the threadgroup code.
> >
>
> Good point, me neither, nor the association with TLR (perhaps because
> there are over methods used by InnocuousForkJoinWorkerThread, see below).
> The Unsafe usage rolled in with:
>
>   https://bugs.openjdk.java.net/browse/JDK-8157523
>   http://hg.openjdk.java.net/jdk9/dev/jdk/rev/fd4819ec5afd
>
>
> In ForkJoinWorkerThread:
>
> static final class InnocuousForkJoinWorkerThread extends
> ForkJoinWorkerThread {
>     /** The ThreadGroup for all InnocuousForkJoinWorkerThreads */
>     private static final ThreadGroup innocuousThreadGroup =
>         ThreadLocalRandom.createThreadGroup("
> InnocuousForkJoinWorkerThreadGroup?);
>
>
> In ForkJoinPool:
>
> private ForkJoinPool(byte forCommonPoolOnly) {
> ...
>     ForkJoinWorkerThreadFactory fac = null;
> ...
>     if (fac == null) {
>         if (System.getSecurityManager() == null)
>             fac = defaultForkJoinWorkerThreadFactory;
>         else // use security-managed default
>             fac = new InnocuousForkJoinWorkerThreadFactory();
>     }
> ?
>
>
> private static final class InnocuousForkJoinWorkerThreadFactory
>     implements ForkJoinWorkerThreadFactory {
> ...
>     public final ForkJoinWorkerThread newThread(ForkJoinPool pool) {
>         return AccessController.doPrivileged(new PrivilegedAction<>() {
>             public ForkJoinWorkerThread run() {
>                 return new ForkJoinWorkerThread.
>                     InnocuousForkJoinWorkerThread(pool);
>             }}, INNOCUOUS_ACC);
>     }
> }
>
>
> So everything is wrapped in a doPrivileged block.
>
> My guess as at some point in development it was important to efficiently
> bypass the security check of ThreadGroup.getParent, and Thread.getGroup
> came along for the ride.
>
> AFAICT I don?t think we need it, and it would be nice to remove the
> VarHandle code and move createThreadGroup to be a static method of
> InnocuousForkJoinWorkerThread. How about:
>
>
> static final class InnocuousForkJoinWorkerThread extends
> ForkJoinWorkerThread {
>     /** The ThreadGroup for all InnocuousForkJoinWorkerThreads */
>     private static final ThreadGroup innocuousThreadGroup =
>             createThreadGroup();
> ?
>     private static ThreadGroup createThreadGroup() {
>         ThreadGroup currentGroup = Thread.currentThread().
> getThreadGroup();
>         ThreadGroup topGroup = java.security.
> AccessController.doPrivileged(
>                 new java.security.PrivilegedAction<ThreadGroup>() {
>                     public ThreadGroup run() {
>                         ThreadGroup group = currentGroup;
>                         for (ThreadGroup p; (p = group.getParent()) !=
> null; )
>                             group = p;
>                         return group;
>                     }});
>         return new ThreadGroup(topGroup, "InnocuousForkJoinWorkerThreadG
> roup");
>     }
> }
>
> That also passes the tests we have for the Innocuous case.
>
>
That seems good to me.


>
> > ---
> >
> >  431             // Teleport the lookup to access fields in Thread
> >
> > Teleport?!  Maybe "Obtain a private lookup object" but that should be
> obvious from the name ?privateLookupIn?
> >
>
> Yes, i removed the comments.
>
> Thanks,
> Paul.
>
>
> >
> > On Wed, Jan 11, 2017 at 12:21 PM, Paul Sandoz <paul.sandoz at oracle.com>
> wrote:
> > Hi,
> >
> > Please review:
> >
> >   http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/
> >
> > This patch updates ThreadLocalRandom, Striped64 and LockSupport to use
> VarHandles instead of Unsafe to access fields in Thread, via the
> MethodsHandles.privateLookupIn method.
> >
> > Since there are three usages of MethodsHandles.privateLookupIn in
> ThreadLocalRandom i consolidated the doPrivileged block in a private static
> helper method, being paranoid i placed some checks to avoid this method
> being potentially abused to circumvent the security check, perhaps that is
> overkill?
> >
> > I ran this patch though our test infra a few times and have not observed
> any transient failures.
> >
> > Thanks,
> > Paul.
> >
>
>

From dl at cs.oswego.edu  Thu Jan 12 00:12:06 2017
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 11 Jan 2017 19:12:06 -0500
Subject: RFR 8160710: Enable Thread to grant VarHandle field access to
	ThreadLocalRandom/Striped64
In-Reply-To: <CA+kOe095Nebj=TOVgnBJ2xnspUpMStVDN=f0O3sXRgwbqMxGmQ@mail.gmail.com>
References: <9F11819C-A5CF-4F74-B463-EB3CB6731393@oracle.com>
	<CA+kOe0_UMinGyWD5WV_HneS9htz+0GaFJ=wLrLjRhSGW9JkL0w@mail.gmail.com>
	<CC0BFC96-0DE2-47A6-BD18-A09DCE06A469@oracle.com>
	<CA+kOe095Nebj=TOVgnBJ2xnspUpMStVDN=f0O3sXRgwbqMxGmQ@mail.gmail.com>
Message-ID: <9faa74d3-5bb5-3dad-67d0-19071ad117bd@cs.oswego.edu>

On 01/11/2017 06:39 PM, Martin Buchholz wrote:
> Doug, please try to remember the details of the thread group code.
>

>     >
>     > The threadgroup creation code that uses cheating has always seemed fishy to me.  The straightforward
>     >
>     >     /**
>     >      * Returns a new group with the system ThreadGroup (the
>     >      * topmost, parent-less group) as parent.
>     >      */
>     >     static final ThreadGroup createThreadGroup(String name) {
>     >         if (name == null)
>     >             throw new NullPointerException();
>     >         ThreadGroup group = Thread.currentThread().getThreadGroup();
>     >         for (ThreadGroup p; (p = group.getParent()) != null; )
>     >             group = p;
>     >         return new ThreadGroup(group, name);
>     >     }
>     >
>     > passes all tests.  That could be wrapped in a doPrivileged, or we could add something more principled to ThreadGroup itself.  I don't know what the motivations are for the threadgroup code.
>     >
>

There was a some point a problem with using doPrivileged in the
context of FJP.commonPool initialization, so we went with the
suggestion of using unsafe.

And at a different point, we decided to place
all non-VarHandle-amenable code into TLR so that it could be
replaced all at once when bootstrap problems were addressed.

And at a different point (which we hope is Now :-) we can
replace the unnecessary prior workarounds.

-Doug




From paul.sandoz at oracle.com  Thu Jan 12 00:48:49 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 11 Jan 2017 16:48:49 -0800
Subject: RFR 8160710: Enable Thread to grant VarHandle field access to
	ThreadLocalRandom/Striped64
In-Reply-To: <9faa74d3-5bb5-3dad-67d0-19071ad117bd@cs.oswego.edu>
References: <9F11819C-A5CF-4F74-B463-EB3CB6731393@oracle.com>
	<CA+kOe0_UMinGyWD5WV_HneS9htz+0GaFJ=wLrLjRhSGW9JkL0w@mail.gmail.com>
	<CC0BFC96-0DE2-47A6-BD18-A09DCE06A469@oracle.com>
	<CA+kOe095Nebj=TOVgnBJ2xnspUpMStVDN=f0O3sXRgwbqMxGmQ@mail.gmail.com>
	<9faa74d3-5bb5-3dad-67d0-19071ad117bd@cs.oswego.edu>
Message-ID: <BDAD7469-1078-4AA6-B53A-A4045577E4F0@oracle.com>

Thanks.

Here is an update:

  http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/

With changes to inline expressions, remove thread group stuff from TLR, and do the following in InnocuousForkJoinWorkerThread:

 185     static final class InnocuousForkJoinWorkerThread extends ForkJoinWorkerThread {
 186         /** The ThreadGroup for all InnocuousForkJoinWorkerThreads */
 187         private static final ThreadGroup innocuousThreadGroup =
 188                 java.security.AccessController.doPrivileged(
 189                     new java.security.PrivilegedAction<>() {
 190                         public ThreadGroup run() {
 191                             ThreadGroup group = Thread.currentThread().getThreadGroup();
 192                             for (ThreadGroup p; (p = group.getParent()) != null; )
 193                                 group = p;
 194                             return new ThreadGroup(group, "InnocuousForkJoinWorkerThreadGroup");
 195                         }});

Note: the ThreadGroup constructor also performs a security permission check

Paul.

> On 11 Jan 2017, at 16:12, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> On 01/11/2017 06:39 PM, Martin Buchholz wrote:
>> Doug, please try to remember the details of the thread group code.
>> 
> 
>>    >
>>    > The threadgroup creation code that uses cheating has always seemed fishy to me.  The straightforward
>>    >
>>    >     /**
>>    >      * Returns a new group with the system ThreadGroup (the
>>    >      * topmost, parent-less group) as parent.
>>    >      */
>>    >     static final ThreadGroup createThreadGroup(String name) {
>>    >         if (name == null)
>>    >             throw new NullPointerException();
>>    >         ThreadGroup group = Thread.currentThread().getThreadGroup();
>>    >         for (ThreadGroup p; (p = group.getParent()) != null; )
>>    >             group = p;
>>    >         return new ThreadGroup(group, name);
>>    >     }
>>    >
>>    > passes all tests.  That could be wrapped in a doPrivileged, or we could add something more principled to ThreadGroup itself.  I don't know what the motivations are for the threadgroup code.
>>    >
>> 
> 
> There was a some point a problem with using doPrivileged in the
> context of FJP.commonPool initialization, so we went with the
> suggestion of using unsafe.
> 
> And at a different point, we decided to place
> all non-VarHandle-amenable code into TLR so that it could be
> replaced all at once when bootstrap problems were addressed.
> 
> And at a different point (which we hope is Now :-) we can
> replace the unnecessary prior workarounds.
> 
> -Doug
> 
> 
> 


From naoto.sato at oracle.com  Thu Jan 12 01:45:25 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 11 Jan 2017 17:45:25 -0800
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
Message-ID: <01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>

Decided to include the fix to 8171140 [1] as well, as they are closely 
related. Here is the updated webrev.

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

Additional changes to the version 00 are to mainly remove 
clearCache(Module) method, as clearCache() is chiefly used in 
combination with ResourceBundle.Control, which is not supported in named 
modules. Still named modules can issue clearCache() with no argument 
which will result in the same effect. Also, other clearCache() overloads 
have clearer method descriptions.

CCC for 8171140 will be filed accordingly.

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

On 1/10/17 4:10 PM, Naoto Sato wrote:
> Hello,
>
> Please review the changes to the subject issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8171139
>
> The changes are located at:
>
> http://cr.openjdk.java.net/~naoto/8171139/webrev.00/
>
> The changeset is the same as the one in the mail thread [1] contributed by Peter Levart, plus additional clearCache() test cases.
>
> Naoto
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html>
>

From amy.lu at oracle.com  Thu Jan 12 02:10:53 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 12 Jan 2017 10:10:53 +0800
Subject: JDK 9 RFR of JDK-8146668: Replace custom check/range functionality
	with check index/range methods in java.util.Objects
Message-ID: <de138c68-e8e5-ba3b-6e2b-603b8fc49329@oracle.com>

8135248 and 8155794 introduced utility methods for checking indexes and 
ranges. Existing code with custom checkIndex/checkRange can be updated 
to use these methods. Please review the patch for this purpose:

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

The type of exception thrown are preserved. Custom checkIndex/checkRange 
functions that throw IOOBE are now using ?check? utility methods 
provided by java.lang.Objects (which also throws IOOBE), functions that 
throw other exceptions use jdk.internal.util.Preconditions to preserve 
exception types, with the help of new BiFunction vars.

I'd like to get this in JDK 9 if it's not too late, otherwise, JDK 10.

Thanks,
Amy

From amy.lu at oracle.com  Thu Jan 12 02:14:09 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 12 Jan 2017 10:14:09 +0800
Subject: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java
	fail intermittently on windows-x64
In-Reply-To: <6cac2594-9f40-bb1a-a8c0-7bccf8c57370@oracle.com>
References: <20533121-1ea0-e372-7504-ae946ce522b5@oracle.com>
	<2e1b9908-dfa8-bfae-2c21-acb62efb85af@oracle.com>
	<8C39D6AB-BEBE-4EF9-8F49-5E5B71733B74@oracle.com>
	<d1bc6c96-451f-2ee9-42d8-f44295f5127f@oracle.com>
	<AD7A9770-4A56-4E4D-8DAE-5B5311A45873@oracle.com>
	<6cac2594-9f40-bb1a-a8c0-7bccf8c57370@oracle.com>
Message-ID: <38ae71f3-d838-36e6-7085-5ce222f5f529@oracle.com>

On 12/23/16 8:54 AM, Amy Lu wrote:
> On 12/20/16 8:04 PM, Wang Weijun wrote:
>>> For the failing case, the first time it calls checkNames, the "ans" 
>>> (the 3rd arg) is "current working dir" (/path/scratch/1).
>> Is it possible to use ./tmp as "ans"?
>>
>> --Max
>>
> Yes, good idea.
>
> Please review the updated webrev to make the data one level deeper:
> http://cr.openjdk.java.net/~amlu/8156595/webrev.02/
Please review the updated webrev.

Thanks,
Amy
>
>
> Thanks,
> Amy


From martinrb at google.com  Thu Jan 12 02:22:30 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 11 Jan 2017 18:22:30 -0800
Subject: RFR 8160710: Enable Thread to grant VarHandle field access to
	ThreadLocalRandom/Striped64
In-Reply-To: <BDAD7469-1078-4AA6-B53A-A4045577E4F0@oracle.com>
References: <9F11819C-A5CF-4F74-B463-EB3CB6731393@oracle.com>
	<CA+kOe0_UMinGyWD5WV_HneS9htz+0GaFJ=wLrLjRhSGW9JkL0w@mail.gmail.com>
	<CC0BFC96-0DE2-47A6-BD18-A09DCE06A469@oracle.com>
	<CA+kOe095Nebj=TOVgnBJ2xnspUpMStVDN=f0O3sXRgwbqMxGmQ@mail.gmail.com>
	<9faa74d3-5bb5-3dad-67d0-19071ad117bd@cs.oswego.edu>
	<BDAD7469-1078-4AA6-B53A-A4045577E4F0@oracle.com>
Message-ID: <CA+kOe08sq0A0LoXdUU3t=PFkYX7U_Awep03u3FrQjL=-ZH+8fw@mail.gmail.com>

Looks good!

On Wed, Jan 11, 2017 at 4:48 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Thanks.
>
> Here is an update:
>
>   http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/
>
> With changes to inline expressions, remove thread group stuff from TLR,
> and do the following in InnocuousForkJoinWorkerThread:
>
>  185     static final class InnocuousForkJoinWorkerThread extends
> ForkJoinWorkerThread {
>  186         /** The ThreadGroup for all InnocuousForkJoinWorkerThreads */
>  187         private static final ThreadGroup innocuousThreadGroup =
>  188                 java.security.AccessController.doPrivileged(
>  189                     new java.security.PrivilegedAction<>() {
>  190                         public ThreadGroup run() {
>  191                             ThreadGroup group =
> Thread.currentThread().getThreadGroup();
>  192                             for (ThreadGroup p; (p =
> group.getParent()) != null; )
>  193                                 group = p;
>  194                             return new ThreadGroup(group, "
> InnocuousForkJoinWorkerThreadGroup");
>  195                         }});
>
> Note: the ThreadGroup constructor also performs a security permission check
>
> Paul.
>
> > On 11 Jan 2017, at 16:12, Doug Lea <dl at cs.oswego.edu> wrote:
> >
> > On 01/11/2017 06:39 PM, Martin Buchholz wrote:
> >> Doug, please try to remember the details of the thread group code.
> >>
> >
> >>    >
> >>    > The threadgroup creation code that uses cheating has always seemed
> fishy to me.  The straightforward
> >>    >
> >>    >     /**
> >>    >      * Returns a new group with the system ThreadGroup (the
> >>    >      * topmost, parent-less group) as parent.
> >>    >      */
> >>    >     static final ThreadGroup createThreadGroup(String name) {
> >>    >         if (name == null)
> >>    >             throw new NullPointerException();
> >>    >         ThreadGroup group = Thread.currentThread().
> getThreadGroup();
> >>    >         for (ThreadGroup p; (p = group.getParent()) != null; )
> >>    >             group = p;
> >>    >         return new ThreadGroup(group, name);
> >>    >     }
> >>    >
> >>    > passes all tests.  That could be wrapped in a doPrivileged, or we
> could add something more principled to ThreadGroup itself.  I don't know
> what the motivations are for the threadgroup code.
> >>    >
> >>
> >
> > There was a some point a problem with using doPrivileged in the
> > context of FJP.commonPool initialization, so we went with the
> > suggestion of using unsafe.
> >
> > And at a different point, we decided to place
> > all non-VarHandle-amenable code into TLR so that it could be
> > replaced all at once when bootstrap problems were addressed.
> >
> > And at a different point (which we hope is Now :-) we can
> > replace the unnecessary prior workarounds.
> >
> > -Doug
> >
> >
> >
>
>

From mandy.chung at oracle.com  Thu Jan 12 02:35:15 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 Jan 2017 18:35:15 -0800
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
Message-ID: <3612B6E7-8BFD-4B15-8F81-91CE6DD5CAE5@oracle.com>


> On 1/10/17 4:10 PM, Naoto Sato wrote:
>> Hello,
>> 
>> Please review the changes to the subject issue:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8171139
>> 
>> The changes are located at:
>> 
>> http://cr.openjdk.java.net/~naoto/8171139/webrev.00/
>> 

 622         CacheKey setName(String baseName) {
   Is the setName method used anywhere? I would expect the basename 
   of a CacheKey should be immutable.  Should this be removed?

 698                 Module module = getModule();
 699                 clone.moduleRef =
 700                     module == null

Nit: line 699 can be merged with line 698

 636         Module getModule() {
 637             return moduleRef == null ? null : moduleRef.get();
 638         }
 639 
 640         Module getCallerModule() {
 641             return callerRef == null ? null : callerRef.get();
 642         }

How do we get to moduleRef and callerRef be null?

1487         return getBundleImpl(baseName, locale, caller, caller.getClassLoader(), control);

This assumes caller class is non-null. Perhaps line 1506-1508 should be moved to 1486.

1516         // there's no code in unnamed module of bootstrap class loader so loader
1517         // must be non-null (non-bootstrap) if the caller is from unnamed module
1518         if (loader == null) {
1519             throw new InternalError("null loader");
1520         }
1522         // find resource bundles from unnamed module of given class loader
1523         Module unnamedModule = loader.getUnnamedModule();

Java agent can add to the bootclasspath e.g. via java.lang.instrument.Instrumentation and load classes in unnamed module.  It may call RB::getBundle that will end up here with loader == null.

The above should be:
    Module unnamedModule = loader != null
        			? loader.getUnnamedModule()
        			: BootLoader.getUnnamedModule();

I?ll reply the fix for JDK-8171140 separately.

Mandy


From mandy.chung at oracle.com  Thu Jan 12 02:55:59 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 Jan 2017 18:55:59 -0800
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
Message-ID: <52E49414-B0E3-44B4-92D4-06F0E8A6FCD5@oracle.com>


> On Jan 11, 2017, at 5:45 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Decided to include the fix to 8171140 [1] as well, as they are closely related. Here is the updated webrev.
> 
> http://cr.openjdk.java.net/~naoto/8171139.8171140/webrev.01/
> 
> Additional changes to the version 00 are to mainly remove clearCache(Module) method, as clearCache() is chiefly used in combination with ResourceBundle.Control, which is not supported in named modules. Still named modules can issue clearCache() with no argument which will result in the same effect. Also, other clearCache() overloads have clearer method descriptions.


I think removing the clearCache(Module) method and have the clearCache() method removing the resource bundles loaded by the caller?s module is reasonable.  For unnamed module loaded by the application class loader as the caller, the no-arg clearCache will remove the resource bundles loaded from the classpath.  Comparing to JDK 8, it does not remove resource bundles from the JDK modules that used to be in tools.jar.  IMO this behavioral difference is a good one.

2179     @CallerSensitive
2180     public static final void clearCache(ClassLoader loader) {
2181         Objects.requireNonNull(loader);
2182         Class<?> caller = Reflection.getCallerClass();
2183         clearCacheImpl(null, loader);
2184     }

The clearCache(ClassLoader) method no longer needs to be caller-sensitive.  @CS should be removed, line 2179 and 2182 should be removed.

With this change, I think clearCacheImpl is not as useful.  I suggest to do the removal in the clearCache method body.

It?s okay to push the changesets for two issues together.  It?d be useful to generate a webrev against JDK-8171139 to contain the change in clearCache for JDK-8171140.

thanks
Mandy   


From huaming.li at oracle.com  Thu Jan 12 03:14:19 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 11 Jan 2017 19:14:19 -0800
Subject: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java
	fail intermittently on windows-x64
In-Reply-To: <38ae71f3-d838-36e6-7085-5ce222f5f529@oracle.com>
References: <20533121-1ea0-e372-7504-ae946ce522b5@oracle.com>
	<2e1b9908-dfa8-bfae-2c21-acb62efb85af@oracle.com>
	<8C39D6AB-BEBE-4EF9-8F49-5E5B71733B74@oracle.com>
	<d1bc6c96-451f-2ee9-42d8-f44295f5127f@oracle.com>
	<AD7A9770-4A56-4E4D-8DAE-5B5311A45873@oracle.com>
	<6cac2594-9f40-bb1a-a8c0-7bccf8c57370@oracle.com>
	<38ae71f3-d838-36e6-7085-5ce222f5f529@oracle.com>
Message-ID: <1715bacc-55c7-5506-d83c-6e599d162128@oracle.com>

Need to update the year in copyright, it's new year 2017, I guess lot of 
us do not notice it.

Thank you
-Hamlin

On 2017/1/11 18:14, Amy Lu wrote:
> On 12/23/16 8:54 AM, Amy Lu wrote:
>> On 12/20/16 8:04 PM, Wang Weijun wrote:
>>>> For the failing case, the first time it calls checkNames, the "ans" 
>>>> (the 3rd arg) is "current working dir" (/path/scratch/1).
>>> Is it possible to use ./tmp as "ans"?
>>>
>>> --Max
>>>
>> Yes, good idea.
>>
>> Please review the updated webrev to make the data one level deeper:
>> http://cr.openjdk.java.net/~amlu/8156595/webrev.02/
> Please review the updated webrev.
>
> Thanks,
> Amy
>>
>>
>> Thanks,
>> Amy
>


From huaming.li at oracle.com  Thu Jan 12 04:33:04 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 11 Jan 2017 20:33:04 -0800
Subject: RFR of JDK-8030950: TEST_BUG:
	java/rmi/registry/classPathCodebase/ClassPathCodebase.java failing
	intermittently
Message-ID: <1a6a0607-0b4c-d2bc-1439-cf0b3a2e8e6c@oracle.com>

Would you please review the below patch?

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

Thank you
-Hamlin

From amy.lu at oracle.com  Thu Jan 12 07:07:33 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 12 Jan 2017 15:07:33 +0800
Subject: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java
	fail intermittently on windows-x64
In-Reply-To: <1715bacc-55c7-5506-d83c-6e599d162128@oracle.com>
References: <20533121-1ea0-e372-7504-ae946ce522b5@oracle.com>
	<2e1b9908-dfa8-bfae-2c21-acb62efb85af@oracle.com>
	<8C39D6AB-BEBE-4EF9-8F49-5E5B71733B74@oracle.com>
	<d1bc6c96-451f-2ee9-42d8-f44295f5127f@oracle.com>
	<AD7A9770-4A56-4E4D-8DAE-5B5311A45873@oracle.com>
	<6cac2594-9f40-bb1a-a8c0-7bccf8c57370@oracle.com>
	<38ae71f3-d838-36e6-7085-5ce222f5f529@oracle.com>
	<1715bacc-55c7-5506-d83c-6e599d162128@oracle.com>
Message-ID: <e135539c-4895-b6f1-4be6-24ac8eac414c@oracle.com>

On 1/12/17 11:14 AM, Hamlin Li wrote:
> Need to update the year in copyright, it's new year 2017, I guess lot 
> of us do not notice it.
Thank you. Fixed :-)

Thanks,
Amy
>
> Thank you
> -Hamlin
>
> On 2017/1/11 18:14, Amy Lu wrote:
>> On 12/23/16 8:54 AM, Amy Lu wrote:
>>> On 12/20/16 8:04 PM, Wang Weijun wrote:
>>>>> For the failing case, the first time it calls checkNames, the 
>>>>> "ans" (the 3rd arg) is "current working dir" (/path/scratch/1).
>>>> Is it possible to use ./tmp as "ans"?
>>>>
>>>> --Max
>>>>
>>> Yes, good idea.
>>>
>>> Please review the updated webrev to make the data one level deeper:
>>> http://cr.openjdk.java.net/~amlu/8156595/webrev.02/
>> Please review the updated webrev.
>>
>> Thanks,
>> Amy
>>>
>>>
>>> Thanks,
>>> Amy
>>
>


From claes.redestad at oracle.com  Thu Jan 12 12:42:45 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 12 Jan 2017 13:42:45 +0100
Subject: RFR: 8166365: Small immutable collections should provide
	optimized implementations when possible
In-Reply-To: <955e7d38-7495-429f-c890-3423c1c55df8@oracle.com>
References: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
	<c7ca271e-8640-0822-bfaa-362098215a91@oracle.com>
	<8f960792-51e1-f829-762b-02fc2781abc6@oracle.com>
	<955e7d38-7495-429f-c890-3423c1c55df8@oracle.com>
Message-ID: <893e1e96-53b6-37e1-2124-a65b78a65f27@oracle.com>



On 2017-01-11 23:38, Stuart Marks wrote:
>> All done:
>>
>> http://cr.openjdk.java.net/~redestad/8166365/webrev.02/
>
> Looks great! If all you do is restore private fields in Map1, no need
> for another webrev.

Done, and pushed.

Thanks!

/Claes

From daniel.fuchs at oracle.com  Thu Jan 12 13:57:04 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 12 Jan 2017 13:57:04 +0000
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
Message-ID: <5296eb83-349c-9a56-139e-64fdc88ef08e@oracle.com>

Hi Naoto,

If I'm not mistaken, CacheKey is not subclassed anywhere, so it could
be final. I'm wondering whether it would be a better idea to implement
CacheKey.clone() with a private (copy?) constructor. It would make
it possible to make most fields final: I believe it would be beneficial
to have all fields in CacheKey either final or volatile - since AFAICT
CacheKey can be created by one thread and then read by another.
And if most fields could be final then all the better :-)

best regards,

-- daniel

On 12/01/17 01:45, Naoto Sato wrote:
> Decided to include the fix to 8171140 [1] as well, as they are closely
> related. Here is the updated webrev.
>
> http://cr.openjdk.java.net/~naoto/8171139.8171140/webrev.01/
>
> Additional changes to the version 00 are to mainly remove
> clearCache(Module) method, as clearCache() is chiefly used in
> combination with ResourceBundle.Control, which is not supported in named
> modules. Still named modules can issue clearCache() with no argument
> which will result in the same effect. Also, other clearCache() overloads
> have clearer method descriptions.
>
> CCC for 8171140 will be filed accordingly.
>
> Naoto
> --
> [1]: https://bugs.openjdk.java.net/browse/JDK-8171140
>
> On 1/10/17 4:10 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes to the subject issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8171139
>>
>> The changes are located at:
>>
>> http://cr.openjdk.java.net/~naoto/8171139/webrev.00/
>>
>> The changeset is the same as the one in the mail thread [1]
>> contributed by Peter Levart, plus additional clearCache() test cases.
>>
>> Naoto
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html
>> <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html>
>>
>>


From claes.redestad at oracle.com  Thu Jan 12 14:48:24 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 12 Jan 2017 15:48:24 +0100
Subject: RFR: 8037325: Class.getConstructor() performance regression
Message-ID: <e502d8bb-d1a1-faef-c7c3-a88490ae3edf@oracle.com>

Hi,

please review this fix to various performance regressions observed
as the security model has evolved over the years.

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

- For cases where a SecurityManager is not installed, this improves
performance by avoiding calls to Reflection.getCallerClass, which
can be very expensive when not inlined. Regrettably this adds some
boilerplate.

- For cases where a SecurityManager is installed, this improves
performance slightly by avoiding repeated calls to 
System.getSecurityManager (which does volatile read).

- Use of Class.getPackageName when appropriate reduce the
number of allocations done.

- Places where doPrivileged calls were used to bypass access checking 
when calling methods on Class can safely be replaced by calling
corresponding private methods directly if care is taken to copy the
end result as appropriate.

- Finally, by using the recently used 
ReflectionFactory.getExecutableSharedParameterTypes we also get rid of
some unnecessary copying.

Thanks!

/Claes

From claes.redestad at oracle.com  Thu Jan 12 15:42:11 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 12 Jan 2017 16:42:11 +0100
Subject: RFR: 8172720: Collections.SingletonList::hashCode not spec-compliant
Message-ID: <e685a151-4cea-aea8-8abb-a430a7bd374c@oracle.com>

Hi,

there was an issue with my patch for JDK-8037325 where the
hashCode implemented for Collections.SingletonList was not
compliant with specification, which breaks certain tests.

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

Trivial fix:

diff -r 59e5101730c8 src/java.base/share/classes/java/util/Collections.java
--- a/src/java.base/share/classes/java/util/Collections.java	Thu Jan 12 
13:38:27 2017 +0100
+++ b/src/java.base/share/classes/java/util/Collections.java	Thu Jan 12 
16:39:44 2017 +0100
@@ -4859,7 +4859,7 @@
          }
          @Override
          public int hashCode() {
-            return Objects.hashCode(element);
+            return 31 + Objects.hashCode(element);
          }
      }


From chris.hegarty at oracle.com  Thu Jan 12 16:03:30 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 12 Jan 2017 16:03:30 +0000
Subject: RFR: 8172720: Collections.SingletonList::hashCode not
	spec-compliant
In-Reply-To: <e685a151-4cea-aea8-8abb-a430a7bd374c@oracle.com>
References: <e685a151-4cea-aea8-8abb-a430a7bd374c@oracle.com>
Message-ID: <57BE91BD-9428-4C78-8348-859FF37730CA@oracle.com>


> On 12 Jan 2017, at 15:42, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> there was an issue with my patch for JDK-8037325 where the
> hashCode implemented for Collections.SingletonList was not
> compliant with specification, which breaks certain tests.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8172720
> 
> Trivial fix:
> 
> diff -r 59e5101730c8 src/java.base/share/classes/java/util/Collections.java
> --- a/src/java.base/share/classes/java/util/Collections.java	Thu Jan 12 13:38:27 2017 +0100
> +++ b/src/java.base/share/classes/java/util/Collections.java	Thu Jan 12 16:39:44 2017 +0100
> @@ -4859,7 +4859,7 @@
>         }
>         @Override
>         public int hashCode() {
> -            return Objects.hashCode(element);
> +            return 31 + Objects.hashCode(element);
>         }
>     }
> 

Looks fine.

-Chris.

From claes.redestad at oracle.com  Thu Jan 12 16:07:06 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 12 Jan 2017 17:07:06 +0100
Subject: RFR: 8172720: Collections.SingletonList::hashCode not
	spec-compliant
In-Reply-To: <57BE91BD-9428-4C78-8348-859FF37730CA@oracle.com>
References: <e685a151-4cea-aea8-8abb-a430a7bd374c@oracle.com>
	<57BE91BD-9428-4C78-8348-859FF37730CA@oracle.com>
Message-ID: <72da75a3-068c-8ab5-5f8b-df16844c4eb6@oracle.com>

Thanks Chris!

/Claes

On 2017-01-12 17:03, Chris Hegarty wrote:
>
>> On 12 Jan 2017, at 15:42, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Hi,
>>
>> there was an issue with my patch for JDK-8037325 where the
>> hashCode implemented for Collections.SingletonList was not
>> compliant with specification, which breaks certain tests.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172720
>>
>> Trivial fix:
>>
>> diff -r 59e5101730c8 src/java.base/share/classes/java/util/Collections.java
>> --- a/src/java.base/share/classes/java/util/Collections.java	Thu Jan 12 13:38:27 2017 +0100
>> +++ b/src/java.base/share/classes/java/util/Collections.java	Thu Jan 12 16:39:44 2017 +0100
>> @@ -4859,7 +4859,7 @@
>>         }
>>         @Override
>>         public int hashCode() {
>> -            return Objects.hashCode(element);
>> +            return 31 + Objects.hashCode(element);
>>         }
>>     }
>>
>
> Looks fine.
>
> -Chris.
>

From paul.sandoz at oracle.com  Thu Jan 12 16:18:32 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Jan 2017 08:18:32 -0800
Subject: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java
	fail intermittently on windows-x64
In-Reply-To: <e135539c-4895-b6f1-4be6-24ac8eac414c@oracle.com>
References: <20533121-1ea0-e372-7504-ae946ce522b5@oracle.com>
	<2e1b9908-dfa8-bfae-2c21-acb62efb85af@oracle.com>
	<8C39D6AB-BEBE-4EF9-8F49-5E5B71733B74@oracle.com>
	<d1bc6c96-451f-2ee9-42d8-f44295f5127f@oracle.com>
	<AD7A9770-4A56-4E4D-8DAE-5B5311A45873@oracle.com>
	<6cac2594-9f40-bb1a-a8c0-7bccf8c57370@oracle.com>
	<38ae71f3-d838-36e6-7085-5ce222f5f529@oracle.com>
	<1715bacc-55c7-5506-d83c-6e599d162128@oracle.com>
	<e135539c-4895-b6f1-4be6-24ac8eac414c@oracle.com>
Message-ID: <7D54829B-EDB8-4894-A5FA-494418B2E132@oracle.com>


> On 11 Jan 2017, at 23:07, Amy Lu <amy.lu at oracle.com> wrote:
> 
> On 1/12/17 11:14 AM, Hamlin Li wrote:
>> Need to update the year in copyright, it's new year 2017, I guess lot of us do not notice it.
> Thank you. Fixed :-)
> 

Looks ok (although i must admit to not fully understanding all the idiosyncrasies of windows).

Paul.

From paul.sandoz at oracle.com  Thu Jan 12 16:52:24 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Jan 2017 08:52:24 -0800
Subject: JDK 9 RFR of JDK-8146668: Replace custom check/range
	functionality with check index/range methods in java.util.Objects
In-Reply-To: <de138c68-e8e5-ba3b-6e2b-603b8fc49329@oracle.com>
References: <de138c68-e8e5-ba3b-6e2b-603b8fc49329@oracle.com>
Message-ID: <44FFB565-3075-49C5-9069-08189E13BE7B@oracle.com>

HI Amy,

Overall this looks very good, well done.


At this point we are down to two things:

1) should we preserve exception messages?

2) due diligence on the performance.


On 1) my preference is that uniform (and informative) messages are better for IndexOutOfBounds and subtypes, and defining that in addition to the checks in one place is very valuable. In some sense that does change some behavioural compatibility and i think because of that pushing in 10 (when the repos) open with a CCC would be more preferable.

On 2) this is a valuable exercise to perform (either using an existing test and/or writing JMH benchmarks). I don?t expect any major problems. Care was taken to ensure the uncommon exception processing path will optimize away for the common case. The BiFunction parameter passed as the last argument is always a constant, so should fold away from the hot path.

Paul.


> On 11 Jan 2017, at 18:10, Amy Lu <amy.lu at oracle.com> wrote:
> 
> 8135248 and 8155794 introduced utility methods for checking indexes and ranges. Existing code with custom checkIndex/checkRange can be updated to use these methods. Please review the patch for this purpose:
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8146668
> webrev: http://cr.openjdk.java.net/~amlu/8146668/webrev.01
> 
> The type of exception thrown are preserved. Custom checkIndex/checkRange functions that throw IOOBE are now using ?check? utility methods provided by java.lang.Objects (which also throws IOOBE), functions that throw other exceptions use jdk.internal.util.Preconditions to preserve exception types, with the help of new BiFunction vars.
> 
> I'd like to get this in JDK 9 if it's not too late, otherwise, JDK 10.
> 
> Thanks,
> Amy


From Roger.Riggs at Oracle.com  Thu Jan 12 17:05:48 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 12 Jan 2017 12:05:48 -0500
Subject: RFR of JDK-8030950: TEST_BUG:
	java/rmi/registry/classPathCodebase/ClassPathCodebase.java failing
	intermittently
In-Reply-To: <1a6a0607-0b4c-d2bc-1439-cf0b3a2e8e6c@oracle.com>
References: <1a6a0607-0b4c-d2bc-1439-cf0b3a2e8e6c@oracle.com>
Message-ID: <c7e8469c-a39b-0432-836b-0cb7e815d75d@Oracle.com>

Hi Hamlin,

ClassPathCodebase:
  - line 51: The comment says seconds but it is really milliseconds.

security.policy:
  - line 21: "this its" -> "its"

  - line 26:  Is the relative path in the File permission correct;
    Is there a ${test.xxx} path to refer to that file.


registry.security.policy:  Add a comment saying how this policy is used 
(to distinguish it from the other security policy).

Otherwise looks fine,

Roger


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


From huaming.li at oracle.com  Thu Jan 12 18:13:19 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Thu, 12 Jan 2017 10:13:19 -0800
Subject: RFR of JDK-8030950: TEST_BUG:
	java/rmi/registry/classPathCodebase/ClassPathCodebase.java failing
	intermittently
In-Reply-To: <c7e8469c-a39b-0432-836b-0cb7e815d75d@Oracle.com>
References: <1a6a0607-0b4c-d2bc-1439-cf0b3a2e8e6c@oracle.com>
	<c7e8469c-a39b-0432-836b-0cb7e815d75d@Oracle.com>
Message-ID: <ed404e43-3f53-e483-96f5-6b8ce73116b5@oracle.com>

Hi Roger,

Thank you for reviewing. Please check comments inline.


On 2017/1/12 9:05, Roger Riggs wrote:
> Hi Hamlin,
>
> ClassPathCodebase:
>  - line 51: The comment says seconds but it is really milliseconds.
Yes, the comment little bit confusing, modified as "dozens of seconds", 
as it will wait for N*10000 milliseconds.
>
> security.policy:
>  - line 21: "this its" -> "its"
fixed.
>
>  - line 26:  Is the relative path in the File permission correct;
>    Is there a ${test.xxx} path to refer to that file.
yes, JavaVM.getCodeCoverageOptions will need the access to the relative 
path.
>
>
> registry.security.policy:  Add a comment saying how this policy is 
> used (to distinguish it from the other security policy).
added.
>
> Otherwise looks fine,
code is pushed.

Thank you
-Hamlin
>
> Roger
>
>
> On 1/11/2017 11:33 PM, Hamlin Li wrote:
>> Would you please review the below patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8030950
>> webrev: http://cr.openjdk.java.net/~mli/8030950/webrev.00/
>>
>> Thank you
>> -Hamlin
>


From martinrb at google.com  Thu Jan 12 18:52:00 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 12 Jan 2017 10:52:00 -0800
Subject: JDK 9 RFR of JDK-8146668: Replace custom check/range
	functionality with check index/range methods in java.util.Objects
In-Reply-To: <44FFB565-3075-49C5-9069-08189E13BE7B@oracle.com>
References: <de138c68-e8e5-ba3b-6e2b-603b8fc49329@oracle.com>
	<44FFB565-3075-49C5-9069-08189E13BE7B@oracle.com>
Message-ID: <CA+kOe0-mmbcSbmPqAjrGcRuceu23y9hsSOUWicG7fmbs8-R2LQ@mail.gmail.com>

We recently modernized all the *MicroBenchmark.java in java/util EXCEPT
for RangeCheckMicroBenchmark.
RangeCheckMicroBenchmark is old and crufty, but may still give us useful
numbers.
The range checking code in ArrayList was carefully written many years ago
to make the hotspot of that time happy; I'm always afraid that hotspot may
not have improved enough, but we have to trust it far more these days with
java.lang.invoke magic, which seems to work well.

From john_platts at hotmail.com  Thu Jan 12 19:11:47 2017
From: john_platts at hotmail.com (John Platts)
Date: Thu, 12 Jan 2017 19:11:47 +0000
Subject: Backport of JEP 254 (Compact Strings) to OpenJDK 8
Message-ID: <DM3PR15MB0912C742A9A0D40AC31C4BAC9D790@DM3PR15MB0912.namprd15.prod.outlook.com>

I am interested in OpenJDK 8 builds with JEP 254 (Compact Strings) support backported from OpenJDK 9. I like the compact strings work that is being done in JDK 9, but I am interested in a OpenJDK 8 build with backported JEP 254 support since I am working with Java applications that might not work in OpenJDK 9 yet and since I would like take advantage of the feature in a backported OpenJDK 8 build instead of having to wait for the JDK 9 release.

From shade at redhat.com  Thu Jan 12 19:15:29 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 12 Jan 2017 20:15:29 +0100
Subject: Backport of JEP 254 (Compact Strings) to OpenJDK 8
In-Reply-To: <DM3PR15MB0912C742A9A0D40AC31C4BAC9D790@DM3PR15MB0912.namprd15.prod.outlook.com>
References: <DM3PR15MB0912C742A9A0D40AC31C4BAC9D790@DM3PR15MB0912.namprd15.prod.outlook.com>
Message-ID: <35b8f044-14a7-06a0-8ebe-23fac3363dba@redhat.com>

On 01/12/2017 08:11 PM, John Platts wrote:
> I am interested in OpenJDK 8 builds with JEP 254 (Compact Strings) support
> backported from OpenJDK 9. I like the compact strings work that is being done
> in JDK 9, but I am interested in a OpenJDK 8 build with backported JEP 254
> support since I am working with Java applications that might not work in
> OpenJDK 9 yet and since I would like take advantage of the feature in a
> backported OpenJDK 8 build instead of having to wait for the JDK 9 release.

This was discussed a number of times both internally and externally, and the
maintainers' consensus was that the feature is too intrusive VM- and JDK- wise.
Backporting it would be very painful, and probably destabilizing for JDK 8.

Think about the work one does enabling applications to run on JDK 9 as the price
to get Compact Strings :)

Thanks,
-Aleksey


From naoto.sato at oracle.com  Thu Jan 12 19:16:44 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 12 Jan 2017 11:16:44 -0800
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
Message-ID: <4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>

Thank you, Mandy and Daniel for your comments. I incorporated your 
suggestions and updated the fix as follows:

http://cr.openjdk.java.net/~naoto/8171139/webrev.02/
http://cr.openjdk.java.net/~naoto/8171140/webrev.00/

Please review.

Naoto


On 1/11/17 5:45 PM, Naoto Sato wrote:
> Decided to include the fix to 8171140 [1] as well, as they are closely
> related. Here is the updated webrev.
>
> http://cr.openjdk.java.net/~naoto/8171139.8171140/webrev.01/
>
> Additional changes to the version 00 are to mainly remove
> clearCache(Module) method, as clearCache() is chiefly used in
> combination with ResourceBundle.Control, which is not supported in named
> modules. Still named modules can issue clearCache() with no argument
> which will result in the same effect. Also, other clearCache() overloads
> have clearer method descriptions.
>
> CCC for 8171140 will be filed accordingly.
>
> Naoto
> --
> [1]: https://bugs.openjdk.java.net/browse/JDK-8171140
>
> On 1/10/17 4:10 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes to the subject issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8171139
>>
>> The changes are located at:
>>
>> http://cr.openjdk.java.net/~naoto/8171139/webrev.00/
>>
>> The changeset is the same as the one in the mail thread [1]
>> contributed by Peter Levart, plus additional clearCache() test cases.
>>
>> Naoto
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html
>> <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html>
>>
>>

From stuart.marks at oracle.com  Thu Jan 12 19:28:48 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 12 Jan 2017 11:28:48 -0800
Subject: RFR: 8172720: Collections.SingletonList::hashCode not
	spec-compliant
In-Reply-To: <72da75a3-068c-8ab5-5f8b-df16844c4eb6@oracle.com>
References: <e685a151-4cea-aea8-8abb-a430a7bd374c@oracle.com>
	<57BE91BD-9428-4C78-8348-859FF37730CA@oracle.com>
	<72da75a3-068c-8ab5-5f8b-df16844c4eb6@oracle.com>
Message-ID: <d10f0769-6a11-eadf-3cdb-17b92cfd8b5f@oracle.com>

Whoops, we all missed this one. Thanks for the quick fix.

On 1/12/17 8:07 AM, Claes Redestad wrote:
> Thanks Chris!
>
> /Claes
>
> On 2017-01-12 17:03, Chris Hegarty wrote:
>>
>>> On 12 Jan 2017, at 15:42, Claes Redestad <claes.redestad at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> there was an issue with my patch for JDK-8037325 where the
>>> hashCode implemented for Collections.SingletonList was not
>>> compliant with specification, which breaks certain tests.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172720
>>>
>>> Trivial fix:
>>>
>>> diff -r 59e5101730c8 src/java.base/share/classes/java/util/Collections.java
>>> --- a/src/java.base/share/classes/java/util/Collections.java    Thu Jan 12
>>> 13:38:27 2017 +0100
>>> +++ b/src/java.base/share/classes/java/util/Collections.java    Thu Jan 12
>>> 16:39:44 2017 +0100
>>> @@ -4859,7 +4859,7 @@
>>>         }
>>>         @Override
>>>         public int hashCode() {
>>> -            return Objects.hashCode(element);
>>> +            return 31 + Objects.hashCode(element);
>>>         }
>>>     }
>>>
>>
>> Looks fine.
>>
>> -Chris.
>>

From martinrb at google.com  Thu Jan 12 19:34:30 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 12 Jan 2017 11:34:30 -0800
Subject: RFR: 8172720: Collections.SingletonList::hashCode not
	spec-compliant
In-Reply-To: <d10f0769-6a11-eadf-3cdb-17b92cfd8b5f@oracle.com>
References: <e685a151-4cea-aea8-8abb-a430a7bd374c@oracle.com>
	<57BE91BD-9428-4C78-8348-859FF37730CA@oracle.com>
	<72da75a3-068c-8ab5-5f8b-df16844c4eb6@oracle.com>
	<d10f0769-6a11-eadf-3cdb-17b92cfd8b5f@oracle.com>
Message-ID: <CA+kOe0_dHZBW6imF7yT3ZWgfeM8SSUPvQSsQPyo8iQhY83oS1w@mail.gmail.com>

Grumpy here would like to point out that in his preferred never-ever broken
world, this would have quietly been fixed with only Claes and his friendly
neighborhood release engineer (who might be a bot) noticiing.

On Thu, Jan 12, 2017 at 11:28 AM, Stuart Marks <stuart.marks at oracle.com>
wrote:

> Whoops, we all missed this one. Thanks for the quick fix.
>
> On 1/12/17 8:07 AM, Claes Redestad wrote:
>
>> Thanks Chris!
>>
>> /Claes
>>
>> On 2017-01-12 17:03, Chris Hegarty wrote:
>>
>>>
>>> On 12 Jan 2017, at 15:42, Claes Redestad <claes.redestad at oracle.com>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> there was an issue with my patch for JDK-8037325 where the
>>>> hashCode implemented for Collections.SingletonList was not
>>>> compliant with specification, which breaks certain tests.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172720
>>>>
>>>> Trivial fix:
>>>>
>>>> diff -r 59e5101730c8 src/java.base/share/classes/ja
>>>> va/util/Collections.java
>>>> --- a/src/java.base/share/classes/java/util/Collections.java    Thu
>>>> Jan 12
>>>> 13:38:27 2017 +0100
>>>> +++ b/src/java.base/share/classes/java/util/Collections.java    Thu
>>>> Jan 12
>>>> 16:39:44 2017 +0100
>>>> @@ -4859,7 +4859,7 @@
>>>>         }
>>>>         @Override
>>>>         public int hashCode() {
>>>> -            return Objects.hashCode(element);
>>>> +            return 31 + Objects.hashCode(element);
>>>>         }
>>>>     }
>>>>
>>>>
>>> Looks fine.
>>>
>>> -Chris.
>>>
>>>

From stuart.marks at oracle.com  Thu Jan 12 19:44:58 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 12 Jan 2017 11:44:58 -0800
Subject: RFR: 8166365: Small immutable collections should provide
	optimized implementations when possible
In-Reply-To: <CA+tXMXORYNbp-t7UcAu1_7AVXG=WvGq5xjuKH_54RzW9N55Yvg@mail.gmail.com>
References: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
	<c7ca271e-8640-0822-bfaa-362098215a91@oracle.com>
	<8f960792-51e1-f829-762b-02fc2781abc6@oracle.com>
	<CA+kOe08Ou380ZU+MJcBG5Qxom4t95zWmeZ9x3gfeKx_E5b9Unw@mail.gmail.com>
	<CA+tXMXORYNbp-t7UcAu1_7AVXG=WvGq5xjuKH_54RzW9N55Yvg@mail.gmail.com>
Message-ID: <d9458a0b-bae4-1059-5356-e8dbb764371a@oracle.com>



On 1/11/17 2:30 PM, Louis Wasserman wrote:
> I haven't followed this much, but an observation: in Guava, we avoided
> creating lots of specialized implementations for small collections, because
> the JVM, at least at the time, had a sweet spot for bimorphic dispatch:
> method calls where the real implementation would be one of two options, and
> that the cost blew up after you hit three, and we considered hitting that
> sweet spot more worthwhile than the slightly smaller overhead for
> collections that were already small.
>
> As a result, many of our immutable collection implementations converged on
> having two implementations: one single-element implementation, and one
> implementation for everything else (0, 2, 3... but not 1), and then we had
> a singleton static constant object for the 0-element case.
>
> I don't know if that calculus has changed, but it seemed worth mentioning.

It seems worth keeping an eye on this. I'll let the Hotspot performance guys say 
whether megamorphic calls become an issue. At this point it seems like we're 
working on more fundamental optimizations, such as the stuff that Claes just pushed.

There is also some excess array copying that needs to be cleaned up, and the 
spliterators still need to be optimized....

If we were to try to reduce the implementations down to two, I'd say that we'd 
want a field-based implementation and an array-based implementation. Having a 
field-based implementation avoids a dependent load and a separate object header 
for the array. But the space savings of 0-field and 1-field classes over a 
2-field class aren't so large, so maybe these could be consolidated if warranted.

Fortunately :-) the APIs are designed so that we have complete freedom to 
rearrange the implementations compatibly in the future, as we get more 
information, or as the various space/performance tradeoffs change.

s'marks

From naoto.sato at oracle.com  Thu Jan 12 21:20:11 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 12 Jan 2017 13:20:11 -0800
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
	<4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
Message-ID: <af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>

Realized moduleRef & callerRef would never be null with this new 
version. Thus modified the patch as:

http://cr.openjdk.java.net/~naoto/8171139/webrev.03/

Naoto

On 1/12/17 11:16 AM, Naoto Sato wrote:
> Thank you, Mandy and Daniel for your comments. I incorporated your
> suggestions and updated the fix as follows:
>
> http://cr.openjdk.java.net/~naoto/8171139/webrev.02/
> http://cr.openjdk.java.net/~naoto/8171140/webrev.00/
>
> Please review.
>
> Naoto
>
>
> On 1/11/17 5:45 PM, Naoto Sato wrote:
>> Decided to include the fix to 8171140 [1] as well, as they are closely
>> related. Here is the updated webrev.
>>
>> http://cr.openjdk.java.net/~naoto/8171139.8171140/webrev.01/
>>
>> Additional changes to the version 00 are to mainly remove
>> clearCache(Module) method, as clearCache() is chiefly used in
>> combination with ResourceBundle.Control, which is not supported in named
>> modules. Still named modules can issue clearCache() with no argument
>> which will result in the same effect. Also, other clearCache() overloads
>> have clearer method descriptions.
>>
>> CCC for 8171140 will be filed accordingly.
>>
>> Naoto
>> --
>> [1]: https://bugs.openjdk.java.net/browse/JDK-8171140
>>
>> On 1/10/17 4:10 PM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the changes to the subject issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8171139
>>>
>>> The changes are located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8171139/webrev.00/
>>>
>>> The changeset is the same as the one in the mail thread [1]
>>> contributed by Peter Levart, plus additional clearCache() test cases.
>>>
>>> Naoto
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html
>>>
>>> <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html>
>>>
>>>
>>>

From mandy.chung at oracle.com  Thu Jan 12 21:46:47 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 12 Jan 2017 13:46:47 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <5875C9EC.6030506@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
	<5875847E.50307@oracle.com>
	<3193532E-4248-4192-9914-AE6D4062B5DA@oracle.com>
	<5875C9EC.6030506@oracle.com>
Message-ID: <4533EC6E-CD7E-44D0-A645-776B5AD027A0@oracle.com>


> On Jan 10, 2017, at 10:00 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> 
> webrev has been updated to catch IMDE and fails the jar as other fatal error handing.
> 
> http://cr.openjdk.java.net/~sherman/8172432/webrev <http://cr.openjdk.java.net/~sherman/8172432/webrev>
> 

This version includes new fixes for JDK-8171830 and JDK-8165640.  Thanks for doing that.  The fix for JDK-8171830 looks fine.

For JDK-8165640, it looks like checkModuleInfo can be refactored / moved to Validator so that the validation code is consistent and shared for checking in both places (MMR validation and module-info.class).

Since it?s a separate issue, you should consider just to pushing the changeset for JDK-8172432 and JDK-8171830.   Resolve  JDK-8165640 in a separate patch that will make the review easier too.

Mandy


From forax at univ-mlv.fr  Thu Jan 12 21:48:01 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 12 Jan 2017 22:48:01 +0100 (CET)
Subject: RFR: 8166365: Small immutable collections should provide
	optimized implementations when possible
In-Reply-To: <d9458a0b-bae4-1059-5356-e8dbb764371a@oracle.com>
References: <8fda1446-42de-b1e7-5a31-b3afc769054c@oracle.com>
	<c7ca271e-8640-0822-bfaa-362098215a91@oracle.com>
	<8f960792-51e1-f829-762b-02fc2781abc6@oracle.com>
	<CA+kOe08Ou380ZU+MJcBG5Qxom4t95zWmeZ9x3gfeKx_E5b9Unw@mail.gmail.com>
	<CA+tXMXORYNbp-t7UcAu1_7AVXG=WvGq5xjuKH_54RzW9N55Yvg@mail.gmail.com>
	<d9458a0b-bae4-1059-5356-e8dbb764371a@oracle.com>
Message-ID: <1078132667.1815583.1484257681349.JavaMail.zimbra@u-pem.fr>

Note that the bimorphic rule is per callsite,
it's fine to have several implementations if for a specific method call there are only two possibles implementations.

cheers,
R?mi

----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> ?: "Louis Wasserman" <wasserman.louis at gmail.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Jeudi 12 Janvier 2017 20:44:58
> Objet: Re: RFR: 8166365: Small immutable collections should provide	optimized implementations when possible

> On 1/11/17 2:30 PM, Louis Wasserman wrote:
>> I haven't followed this much, but an observation: in Guava, we avoided
>> creating lots of specialized implementations for small collections, because
>> the JVM, at least at the time, had a sweet spot for bimorphic dispatch:
>> method calls where the real implementation would be one of two options, and
>> that the cost blew up after you hit three, and we considered hitting that
>> sweet spot more worthwhile than the slightly smaller overhead for
>> collections that were already small.
>>
>> As a result, many of our immutable collection implementations converged on
>> having two implementations: one single-element implementation, and one
>> implementation for everything else (0, 2, 3... but not 1), and then we had
>> a singleton static constant object for the 0-element case.
>>
>> I don't know if that calculus has changed, but it seemed worth mentioning.
> 
> It seems worth keeping an eye on this. I'll let the Hotspot performance guys say
> whether megamorphic calls become an issue. At this point it seems like we're
> working on more fundamental optimizations, such as the stuff that Claes just
> pushed.
> 
> There is also some excess array copying that needs to be cleaned up, and the
> spliterators still need to be optimized....
> 
> If we were to try to reduce the implementations down to two, I'd say that we'd
> want a field-based implementation and an array-based implementation. Having a
> field-based implementation avoids a dependent load and a separate object header
> for the array. But the space savings of 0-field and 1-field classes over a
> 2-field class aren't so large, so maybe these could be consolidated if
> warranted.
> 
> Fortunately :-) the APIs are designed so that we have complete freedom to
> rearrange the implementations compatibly in the future, as we get more
> information, or as the various space/performance tradeoffs change.
> 
> s'marks

From stuart.marks at oracle.com  Thu Jan 12 22:53:27 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 12 Jan 2017 14:53:27 -0800
Subject: RFR(xs): 8172221: Directorate of Time has been superseded
Message-ID: <9461a7e9-6598-20b3-2587-f33017693440@oracle.com>

Hi all,

Please review this small patch to Date.java to remove the reference to the 
USNO's Directorate of Time, and to make minor adjustments to the text and the links.

Thanks.

s'marks




# HG changeset patch
# User smarks
# Date 1484261274 28800
#      Thu Jan 12 14:47:54 2017 -0800
# Node ID 8443f4c21532c01621066a7a78ccea702e213c9b
# Parent  81b1a6a91b9116faa8144b79d7d1e484e83f3540
8172221: Directorate of Time has been superseded
Reviewed-by: XXX

diff -r 81b1a6a91b91 -r 8443f4c21532 src/java.base/share/classes/java/util/Date.java
--- a/src/java.base/share/classes/java/util/Date.java	Wed Jan 04 00:08:40 2017 +0000
+++ b/src/java.base/share/classes/java/util/Date.java	Thu Jan 12 14:47:54 2017 -0800
@@ -82,17 +82,19 @@
   * well; for example, the time scale used by the satellite-based
   * global positioning system (GPS) is synchronized to UTC but is
   * <i>not</i> adjusted for leap seconds. An interesting source of
- * further information is the U.S. Naval Observatory, particularly
- * the Directorate of Time at:
+ * further information is the United States Naval Observatory (USNO):
   * <blockquote><pre>
- *     <a href="http://www.usno.navy.mil">http://www.usno.navy.mil</a>
+ *     <a href="http://www.usno.navy.mil/USNO">http://www.usno.navy.mil/USNO</a>
   * </pre></blockquote>
   * <p>
- * and their definitions of "Systems of Time" at:
+ * and the material regarding "Systems of Time" at:
   * <blockquote><pre>
   *     <a 
href="http://www.usno.navy.mil/USNO/time/master-clock/systems-of-time">http://www.usno.navy.mil/USNO/time/master-clock/systems-of-time</a>
   * </pre></blockquote>
   * <p>
+ * which has descriptions of various different time systems including
+ * UT, UT1, and UTC.
+ * <p>
   * In all methods of class {@code Date} that accept or return
   * year, month, date, hours, minutes, and seconds values, the
   * following representations are used:

From xueming.shen at oracle.com  Thu Jan 12 23:10:06 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 12 Jan 2017 15:10:06 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <4533EC6E-CD7E-44D0-A645-776B5AD027A0@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
	<5875847E.50307@oracle.com>
	<3193532E-4248-4192-9914-AE6D4062B5DA@oracle.com>
	<5875C9EC.6030506@oracle.com>
	<4533EC6E-CD7E-44D0-A645-776B5AD027A0@oracle.com>
Message-ID: <58780CCE.60801@oracle.com>

On 01/12/2017 01:46 PM, Mandy Chung wrote:
>
>> On Jan 10, 2017, at 10:00 PM, Xueming Shen <xueming.shen at oracle.com <mailto:xueming.shen at oracle.com>> wrote:
>>
>>
>> webrev has been updated to catch IMDE and fails the jar as other fatal error handing.
>>
>> http://cr.openjdk.java.net/~sherman/8172432/webrev
>>
>
> This version includes new fixes for JDK-8171830 and JDK-8165640.  Thanks for doing that.  The fix for JDK-8171830 looks fine.
>
> For JDK-8165640, it looks like checkModuleInfo can be refactored / moved to Validator so that the validation code is consistent and shared for checking in both places (MMR validation and module-info.class).


>
> Since it?s a separate issue, you should consider just to pushing the changeset for JDK-8172432 and JDK-8171830.   Resolve  JDK-8165640 in a separate patch that will make the review easier too.

OK. as suggested, I have pulled out the latest changes related JDK-8165640,

which includes the extra "service provider impl" check in the Validate.java, when
there is no root module-info.class. and 2 extra test case in modularJar.Basic.java.
(that webrev has been renamed to
http://cr.openjdk.java.net/~sherman/8172432/webrev.02)

Since now there is no leverage for checkModuleInfo() (check service provider impl) in MMR
validation, I leave it in Main.java asis.

The latest webrev is at

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

(you can compare it to the webrev you reviewed without JDK-8171830 at
http://cr.openjdk.java.net/~sherman/8172432/webrev.01)

I will address JDK-8165640 in a separate issue.

Thanks,
Sherman


From mandy.chung at oracle.com  Thu Jan 12 23:44:43 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 12 Jan 2017 15:44:43 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <58780CCE.60801@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
	<5875847E.50307@oracle.com>
	<3193532E-4248-4192-9914-AE6D4062B5DA@oracle.com>
	<5875C9EC.6030506@oracle.com>
	<4533EC6E-CD7E-44D0-A645-776B5AD027A0@oracle.com>
	<58780CCE.60801@oracle.com>
Message-ID: <7F3FC820-A0BC-453E-A8F1-0EF65DAB8F48@oracle.com>

http://cr.openjdk.java.net/~sherman/8172432/webrev.01 <http://cr.openjdk.java.net/~sherman/8172432/webrev.01>

Validator.java
    159 if (entryName.endsWith(MODULE_INFO)) {

Does this have the same issue as the isModuleInfoEntry method addresses (i.e. META-INF/versioned/n/module-info.class)?

I?m okay if you want to address this together with JDK-8165640.   This patch is a good improvement to the existing code anyway and good to push it.

Mandy


> On Jan 12, 2017, at 3:10 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> On 01/12/2017 01:46 PM, Mandy Chung wrote:
>> 
>> 
>>> On Jan 10, 2017, at 10:00 PM, Xueming Shen <xueming.shen at oracle.com <mailto:xueming.shen at oracle.com>> wrote:
>>> 
>>> 
>>> webrev has been updated to catch IMDE and fails the jar as other fatal error handing.
>>> 
>>> http://cr.openjdk.java.net/~sherman/8172432/webrev <http://cr.openjdk.java.net/%7Esherman/8172432/webrev>
>>> 
>> 
>> This version includes new fixes for JDK-8171830 and JDK-8165640.  Thanks for doing that.  The fix for JDK-8171830 looks fine.
>> 
>> For JDK-8165640, it looks like checkModuleInfo can be refactored / moved to Validator so that the validation code is consistent and shared for checking in both places (MMR validation and module-info.class).
> 
> 
>> 
>> Since it?s a separate issue, you should consider just to pushing the changeset for JDK-8172432 and JDK-8171830.   Resolve  JDK-8165640 in a separate patch that will make the review easier too.
> 
> OK. as suggested, I have pulled out the latest changes related JDK-8165640,
> 
> which includes the extra "service provider impl" check in the Validate.java, when
> there is no root module-info.class. and 2 extra test case in modularJar.Basic.java.
> (that webrev has been renamed to
> http://cr.openjdk.java.net/~sherman/8172432/webrev.02 <http://cr.openjdk.java.net/~sherman/8172432/webrev.02>)
> 
> Since now there is no leverage for checkModuleInfo() (check service provider impl) in MMR
> validation, I leave it in Main.java asis.
> 
> The latest webrev is at
> 
> http://cr.openjdk.java.net/~sherman/8172432/webrev/ <http://cr.openjdk.java.net/~sherman/8172432/webrev/>
> 
> (you can compare it to the webrev you reviewed without JDK-8171830 at
> http://cr.openjdk.java.net/~sherman/8172432/webrev.01 <http://cr.openjdk.java.net/~sherman/8172432/webrev.01>)
> 
> I will address JDK-8165640 in a separate issue.
> 
> Thanks,
> Sherman
> 


From xueming.shen at oracle.com  Fri Jan 13 00:08:56 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 12 Jan 2017 16:08:56 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <7F3FC820-A0BC-453E-A8F1-0EF65DAB8F48@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
	<5875847E.50307@oracle.com>
	<3193532E-4248-4192-9914-AE6D4062B5DA@oracle.com>
	<5875C9EC.6030506@oracle.com>
	<4533EC6E-CD7E-44D0-A645-776B5AD027A0@oracle.com>
	<58780CCE.60801@oracle.com>
	<7F3FC820-A0BC-453E-A8F1-0EF65DAB8F48@oracle.com>
Message-ID: <58781A98.7090505@oracle.com>

On 01/12/2017 03:44 PM, Mandy Chung wrote:
> http://cr.openjdk.java.net/~sherman/8172432/webrev.01 <http://cr.openjdk.java.net/%7Esherman/8172432/webrev.01>
>
> Validator.java
>     159 if (entryName.endsWith(MODULE_INFO)) {
>
> Does this have the same issue as the isModuleInfoEntry method addresses (i.e. META-INF/versioned/n/module-info.class)?

let's use the Main.isModuleInfoEntry for consistency.

  159         // validate the versioned module-info
  160         if (isModuleInfoEntry(entryName)) {
  161             if (entryName.length() != MODULE_INFO.length())
  162                 checkModuleDescriptor(je);
  163             return;
  164         }

webrev has been updated accordingly.

-sherman


>
> I?m okay if you want to address this together with JDK-8165640.   This patch is a good improvement to the existing code anyway and good to push it.
>
> Mandy
>
>
>> On Jan 12, 2017, at 3:10 PM, Xueming Shen <xueming.shen at oracle.com <mailto:xueming.shen at oracle.com>> wrote:
>>
>> On 01/12/2017 01:46 PM, Mandy Chung wrote:
>>>
>>>> On Jan 10, 2017, at 10:00 PM, Xueming Shen <xueming.shen at oracle.com <mailto:xueming.shen at oracle.com>> wrote:
>>>>
>>>>
>>>> webrev has been updated to catch IMDE and fails the jar as other fatal error handing.
>>>>
>>>> http://cr.openjdk.java.net/~sherman/8172432/webrev
>>>>
>>>
>>> This version includes new fixes for JDK-8171830 and JDK-8165640.  Thanks for doing that.  The fix for JDK-8171830 looks fine.
>>>
>>> For JDK-8165640, it looks like checkModuleInfo can be refactored / moved to Validator so that the validation code is consistent and shared for checking in both places (MMR validation and module-info.class).
>>
>>
>>>
>>> Since it?s a separate issue, you should consider just to pushing the changeset for JDK-8172432 and JDK-8171830.   Resolve  JDK-8165640 in a separate patch that will make the review easier too.
>>
>> OK. as suggested, I have pulled out the latest changes related JDK-8165640,
>>
>> which includes the extra "service provider impl" check in the Validate.java, when
>> there is no root module-info.class. and 2 extra test case in modularJar.Basic.java.
>> (that webrev has been renamed to
>> http://cr.openjdk.java.net/~sherman/8172432/webrev.02)
>>
>> Since now there is no leverage for checkModuleInfo() (check service provider impl) in MMR
>> validation, I leave it in Main.java asis.
>>
>> The latest webrev is at
>>
>> http://cr.openjdk.java.net/~sherman/8172432/webrev/
>>
>> (you can compare it to the webrev you reviewed without JDK-8171830 at
>> http://cr.openjdk.java.net/~sherman/8172432/webrev.01)
>>
>> I will address JDK-8165640 in a separate issue.
>>
>> Thanks,
>> Sherman
>>
>


From mandy.chung at oracle.com  Fri Jan 13 00:42:47 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 12 Jan 2017 16:42:47 -0800
Subject: RFR: JDK-8172432,jar cleanup/update for module and mrm jar
In-Reply-To: <58781A98.7090505@oracle.com>
References: <586C107D.1060004@oracle.com>
	<202BE885-1E00-4595-8FD9-6E75A44F415D@oracle.com>
	<22E5EC41-8237-45A8-AA39-7E683D7B3C0E@oracle.com>
	<BB2F2B3B-80A7-4C18-9DD2-A713CECE72B8@oracle.com>
	<C6C2393B-FFEA-4CBA-9C14-B4226F699A59@oracle.com>
	<586C5C46.9080404@oracle.com>
	<459476C9-3EF0-4232-A18B-BA760F1BF067@oracle.com>
	<E7C1092B-9B28-4238-90D1-3ACC59CC2227@oracle.com>
	<e7d29225-cebc-42f2-735b-7320f89902dc@oracle.com>
	<06d1ae3d-76e1-ab21-d4b3-891e635d4e3d@oracle.com>
	<43F915A2-A6F6-4399-AD9B-721FD421F259@oracle.com>
	<586DBCF4.6040306@oracle.com>
	<8FB0FBBE-532E-4634-BBAD-606AC429E48F@oracle.com>
	<5873D4A0.204@oracle.com>
	<0902C861-3BC1-48FB-AAA7-A98F79759FC8@oracle.com>
	<5875847E.50307@oracle.com>
	<3193532E-4248-4192-9914-AE6D4062B5DA@oracle.com>
	<5875C9EC.6030506@oracle.com>
	<4533EC6E-CD7E-44D0-A645-776B5AD027A0@oracle.com>
	<58780CCE.60801@oracle.com>
	<7F3FC820-A0BC-453E-A8F1-0EF65DAB8F48@oracle.com>
	<58781A98.7090505@oracle.com>
Message-ID: <57EB7065-9B8D-40CB-8146-897666BD428A@oracle.com>


> On Jan 12, 2017, at 4:08 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> On 01/12/2017 03:44 PM, Mandy Chung wrote:
>> 
>> http://cr.openjdk.java.net/~sherman/8172432/webrev.01 <http://cr.openjdk.java.net/%7Esherman/8172432/webrev.01>
>> 
>> Validator.java
>>     159 if (entryName.endsWith(MODULE_INFO)) {
>> 
>> Does this have the same issue as the isModuleInfoEntry method addresses (i.e. META-INF/versioned/n/module-info.class)?
> 
> let's use the Main.isModuleInfoEntry for consistency.
>  159         // validate the versioned module-info
>  160         if (isModuleInfoEntry(entryName)) {
>  161             if (entryName.length() != MODULE_INFO.length())
>  162                 checkModuleDescriptor(je);
>  163             return;
>  164         }
> 
> webrev has been updated accordingly.

+1

Mandy


From xueming.shen at oracle.com  Fri Jan 13 05:02:45 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 12 Jan 2017 21:02:45 -0800
Subject: RFR JDK-8172761,Test change in tools/jar/InputFilesTest.java for
	JDK-8172432 is missing
Message-ID: <58785F75.9000906@oracle.com>

Hi Mandy,

Please review the change to push the missing test case change back.

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

Thanks!
Sherman

From mandy.chung at oracle.com  Fri Jan 13 06:32:33 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 12 Jan 2017 22:32:33 -0800
Subject: RFR JDK-8172761,
	Test change in tools/jar/InputFilesTest.java for JDK-8172432 is
	missing
In-Reply-To: <58785F75.9000906@oracle.com>
References: <58785F75.9000906@oracle.com>
Message-ID: <514908E5-8CD3-45BE-8EF9-1F11B7C858BB@oracle.com>

+1

Mandy

> On Jan 12, 2017, at 9:02 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi Mandy,
> 
> Please review the change to push the missing test case change back.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8172761
> webrev: http://cr.openjdk.java.net/~sherman/8172761
> 
> Thanks!
> Sherman


From huaming.li at oracle.com  Fri Jan 13 07:32:33 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Thu, 12 Jan 2017 23:32:33 -0800
Subject: RFR of JDK-7146543: TEST_BUG: java/rmi/registry/readTest/readTest.sh
	failing intermittently with port in use
Message-ID: <778a62e8-6949-cdeb-53c6-33ad762ec409@oracle.com>

Would you please review the below patch?

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

The patch rewrite the test in java, fixes the bug.

Thank you
-Hamlin

From mandy.chung at oracle.com  Fri Jan 13 07:38:46 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 12 Jan 2017 23:38:46 -0800
Subject: RFR: 8055206: Update SecurityManager::checkPackageAccess to
	restrict non-exported JDK packages by default
In-Reply-To: <ad636b2b-64f4-1923-22d5-0abd914912c8@oracle.com>
References: <ad636b2b-64f4-1923-22d5-0abd914912c8@oracle.com>
Message-ID: <F83F4FB7-AB97-47EE-969B-B96838A02010@oracle.com>


> On Jan 9, 2017, at 11:25 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Please review this JDK 9 change to make the SecurityManager::checkPackageAccess and checkPackageDefinition implementations restrict access to the same set of internal JDK packages as the module system.
> 
> This overall change will improve security by making these two mechanisms consistent and reduce the amount of work needed to maintain the package.access and package.definition security properties going forward.
> 
> JBS issue: https://bugs.openjdk.java.net/browse/JDK-8055206
> JDK webrev: http://cr.openjdk.java.net/~mullan/webrevs/8055206/jdk/webrev.00/
> JAXP webrev: http://cr.openjdk.java.net/~mullan/webrevs/8055206/jaxp/webrev.00/
> 

This looks quite good.  It?s good that the restricted package list for the system modules is no longer modifiable.  This change may impact existing applications that are running with security manager and uses a JDK internal API from the runtime that was not in the package.access list.  It may require  the application to grant additional ?accessClassInPackage.<pkg>? permissions in addition to using `?-add-exports` to break into encapsulation.

Similar to the feedback I suggest for JDK-8168075.  We can move this initialization to the holder class and trigger the initialization in the SecurityManager constructor.

> :
> Several tests also had to be modified to be granted additional permission(s) to access the newly restricted packages under a SecurityManager. JAXP also needed a change to grant additional permissions to access internal packages that are exported to the modules that are dynamically created for use with XSLT.

We will have to see if any dynamic generated bytecode in the field will need access to internal API like XSLT case.  It seems something not right for a module that has access to an internal package in another module via qualified exports is required to have ?accessClassInPackage.<pkg>? runtime permission.  I believe the ?accessClassInPackage.<pkg>? permission is checked when a deprivileged module loads an internal class in a module defined by the boot loader even if the package of that internal class is exported to it to access.  I do think we should follow up and look into the potential solutions to respect the qualified exports.  In addition, we should file an issue to look into any possibility to respect `?-add-exports` if specified (perhaps automatically add an entry in the default policy?).  I?m okay to follow up these with separate JBS issues.

Otherwise looks good.
Mandy

From lance.andersen at oracle.com  Fri Jan 13 12:31:58 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 13 Jan 2017 07:31:58 -0500
Subject: RFR(xs): 8172221: Directorate of Time has been superseded
In-Reply-To: <9461a7e9-6598-20b3-2587-f33017693440@oracle.com>
References: <9461a7e9-6598-20b3-2587-f33017693440@oracle.com>
Message-ID: <FB9F78F2-4822-49CC-B942-90F897804075@oracle.com>

Hi Stuart,

Looks fine and validated the URLs are working :-)

Best
Lance
> On Jan 12, 2017, at 5:53 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi all,
> 
> Please review this small patch to Date.java to remove the reference to the USNO's Directorate of Time, and to make minor adjustments to the text and the links.
> 
> Thanks.
> 
> s'marks
> 
> 
> 
> 
> # HG changeset patch
> # User smarks
> # Date 1484261274 28800
> #      Thu Jan 12 14:47:54 2017 -0800
> # Node ID 8443f4c21532c01621066a7a78ccea702e213c9b
> # Parent  81b1a6a91b9116faa8144b79d7d1e484e83f3540
> 8172221: Directorate of Time has been superseded
> Reviewed-by: XXX
> 
> diff -r 81b1a6a91b91 -r 8443f4c21532 src/java.base/share/classes/java/util/Date.java
> --- a/src/java.base/share/classes/java/util/Date.java	Wed Jan 04 00:08:40 2017 +0000
> +++ b/src/java.base/share/classes/java/util/Date.java	Thu Jan 12 14:47:54 2017 -0800
> @@ -82,17 +82,19 @@
>  * well; for example, the time scale used by the satellite-based
>  * global positioning system (GPS) is synchronized to UTC but is
>  * <i>not</i> adjusted for leap seconds. An interesting source of
> - * further information is the U.S. Naval Observatory, particularly
> - * the Directorate of Time at:
> + * further information is the United States Naval Observatory (USNO):
>  * <blockquote><pre>
> - *     <a href="http://www.usno.navy.mil">http://www.usno.navy.mil</a>
> + *     <a href="http://www.usno.navy.mil/USNO">http://www.usno.navy.mil/USNO</a>
>  * </pre></blockquote>
>  * <p>
> - * and their definitions of "Systems of Time" at:
> + * and the material regarding "Systems of Time" at:
>  * <blockquote><pre>
>  *     <a href="http://www.usno.navy.mil/USNO/time/master-clock/systems-of-time">http://www.usno.navy.mil/USNO/time/master-clock/systems-of-time</a>
>  * </pre></blockquote>
>  * <p>
> + * which has descriptions of various different time systems including
> + * UT, UT1, and UTC.
> + * <p>
>  * In all methods of class {@code Date} that accept or return
>  * year, month, date, hours, minutes, and seconds values, the
>  * following representations are used:

 <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 christoph.dreis at freenet.de  Fri Jan 13 12:29:37 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Fri, 13 Jan 2017 13:29:37 +0100
Subject: RFR: 8037325: Class.getConstructor() performance regression
Message-ID: <000001d26d98$b50e8550$1f2b8ff0$@freenet.de>

Hey,

your extraction of methodName() made me aware of another small thing. What about rewriting argumentTypesToString() to avoid creating the StringJoiner if not needed?

    private static String argumentTypesToString(Class<?>[] argTypes) {
        if (argTypes != null) {
            StringJoiner sj = new StringJoiner(", ", "(", ")");
            for (int i = 0; i < argTypes.length; i++) {
                Class<?> c = argTypes[i];
                sj.add((c == null) ? "null" : c.getName());
            }
            return sj.toString();
        }
        return "()";
    }

Should have a very minor impact though. Apart from that looks good to me.

Cheers,
Christoph

-----Original Message-----
From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Claes Redestad
Sent: Thursday, January 12, 2017 3:48 PM
To: core-libs-dev Libs <core-libs-dev at openjdk.java.net>; Security Dev OpenJDK <security-dev at openjdk.java.net>
Subject: RFR: 8037325: Class.getConstructor() performance regression

Hi,

please review this fix to various performance regressions observed
as the security model has evolved over the years.

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

- For cases where a SecurityManager is not installed, this improves
performance by avoiding calls to Reflection.getCallerClass, which
can be very expensive when not inlined. Regrettably this adds some
boilerplate.

- For cases where a SecurityManager is installed, this improves
performance slightly by avoiding repeated calls to 
System.getSecurityManager (which does volatile read).

- Use of Class.getPackageName when appropriate reduce the
number of allocations done.

- Places where doPrivileged calls were used to bypass access checking 
when calling methods on Class can safely be replaced by calling
corresponding private methods directly if care is taken to copy the
end result as appropriate.

- Finally, by using the recently used 
ReflectionFactory.getExecutableSharedParameterTypes we also get rid of
some unnecessary copying.

Thanks!

/Claes


From claes.redestad at oracle.com  Fri Jan 13 12:58:02 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 13 Jan 2017 13:58:02 +0100
Subject: RFR: 8037325: Class.getConstructor() performance regression
In-Reply-To: <000001d26d98$b50e8550$1f2b8ff0$@freenet.de>
References: <000001d26d98$b50e8550$1f2b8ff0$@freenet.de>
Message-ID: <09f64edb-94ab-7f8d-b39b-8a55909354b6@oracle.com>

Hi Christoph,

thanks for looking at this!

Extracting methodName was part cleanup, part meant to
outline some rarely executed error handling code, which
can help a JIT focus on the critical path.

I'd prefer not to micro-optimize argumentTypesToString
(and would likely look at other things than StringJoiner if it
was performance sensitive).

Thanks!

/Claes

On 01/13/2017 01:29 PM, Christoph Dreis wrote:
> Hey,
>
> your extraction of methodName() made me aware of another small thing. What about rewriting argumentTypesToString() to avoid creating the StringJoiner if not needed?
>
>      private static String argumentTypesToString(Class<?>[] argTypes) {
>          if (argTypes != null) {
>              StringJoiner sj = new StringJoiner(", ", "(", ")");
>              for (int i = 0; i < argTypes.length; i++) {
>                  Class<?> c = argTypes[i];
>                  sj.add((c == null) ? "null" : c.getName());
>              }
>              return sj.toString();
>          }
>          return "()";
>      }
>
> Should have a very minor impact though. Apart from that looks good to me.
>
> Cheers,
> Christoph
>
> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Claes Redestad
> Sent: Thursday, January 12, 2017 3:48 PM
> To: core-libs-dev Libs <core-libs-dev at openjdk.java.net>; Security Dev OpenJDK <security-dev at openjdk.java.net>
> Subject: RFR: 8037325: Class.getConstructor() performance regression
>
> Hi,
>
> please review this fix to various performance regressions observed
> as the security model has evolved over the years.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8037325
> Webrev: http://cr.openjdk.java.net/~redestad/8037325/webrev.01
>
> - For cases where a SecurityManager is not installed, this improves
> performance by avoiding calls to Reflection.getCallerClass, which
> can be very expensive when not inlined. Regrettably this adds some
> boilerplate.
>
> - For cases where a SecurityManager is installed, this improves
> performance slightly by avoiding repeated calls to
> System.getSecurityManager (which does volatile read).
>
> - Use of Class.getPackageName when appropriate reduce the
> number of allocations done.
>
> - Places where doPrivileged calls were used to bypass access checking
> when calling methods on Class can safely be replaced by calling
> corresponding private methods directly if care is taken to copy the
> end result as appropriate.
>
> - Finally, by using the recently used
> ReflectionFactory.getExecutableSharedParameterTypes we also get rid of
> some unnecessary copying.
>
> Thanks!
>
> /Claes
>


From gunnar at hibernate.org  Fri Jan 13 17:14:13 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 13 Jan 2017 18:14:13 +0100
Subject: Guaranteed order of annotations?
Message-ID: <CADGJaX8xu+6XbjxU8G7no31KA17WW9P6hjgh-vvC0Ezg7qgTMg@mail.gmail.com>

Hi,

Is there any order guaranteed in which an element's annotations are
returned by AnnotatedElement#getDeclaredAnnotations()? Specifically,
is this the order in which the annotations are given in the source
code?

Section 9.7.5. of the JLS ("Multiple Annotations of the Same Type")
makes a statement of the source order being considered by the array of
the implicit container annotation created for a repeatable annotation
("[...] all the base annotations in the left-to-right order in which
they appeared in the context").

But I couldn't find any authoritative description on the ordering
behaviour of getDeclaredAnnotations(). Should we assume that we cannot
rely on the order in the source?

Thanks for any pointers,

--Gunnar

From daniel.fuchs at oracle.com  Fri Jan 13 17:34:02 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 13 Jan 2017 17:34:02 +0000
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
	<4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
	<af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
Message-ID: <5ccd20fd-9baf-9860-433d-106b1e7f3a42@oracle.com>

On 12/01/17 21:20, Naoto Sato wrote:
> Realized moduleRef & callerRef would never be null with this new
> version. Thus modified the patch as:
>
> http://cr.openjdk.java.net/~naoto/8171139/webrev.03/

Hi Naoto,

619             this(src.getName(), src.getLocale(), src.getModule(), 
src.getCallerModule());

this is going to throw NPE if either module is null.

I wonder if there is a risk that the modules might get
garbage collected between the time at which 'src' was obtained
and the time at which src.get[Caller]Module() is called.
If there's such a risk then maybe Reference::reachabilityFence
could be used at strategic places to prevent this?

Also the copy constructor will recompute the hash - (through the
this(...) constructor) and I wonder whether that's intended.

best regards,

-- daniel

>
> Naoto
>
> On 1/12/17 11:16 AM, Naoto Sato wrote:
>> Thank you, Mandy and Daniel for your comments. I incorporated your
>> suggestions and updated the fix as follows:
>>
>> http://cr.openjdk.java.net/~naoto/8171139/webrev.02/
>> http://cr.openjdk.java.net/~naoto/8171140/webrev.00/
>>
>> Please review.
>>
>> Naoto
>>
>>
>> On 1/11/17 5:45 PM, Naoto Sato wrote:
>>> Decided to include the fix to 8171140 [1] as well, as they are closely
>>> related. Here is the updated webrev.
>>>
>>> http://cr.openjdk.java.net/~naoto/8171139.8171140/webrev.01/
>>>
>>> Additional changes to the version 00 are to mainly remove
>>> clearCache(Module) method, as clearCache() is chiefly used in
>>> combination with ResourceBundle.Control, which is not supported in named
>>> modules. Still named modules can issue clearCache() with no argument
>>> which will result in the same effect. Also, other clearCache() overloads
>>> have clearer method descriptions.
>>>
>>> CCC for 8171140 will be filed accordingly.
>>>
>>> Naoto
>>> --
>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8171140
>>>
>>> On 1/10/17 4:10 PM, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the changes to the subject issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8171139
>>>>
>>>> The changes are located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8171139/webrev.00/
>>>>
>>>> The changeset is the same as the one in the mail thread [1]
>>>> contributed by Peter Levart, plus additional clearCache() test cases.
>>>>
>>>> Naoto
>>>>
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html
>>>>
>>>>
>>>> <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-January/045790.html>
>>>>
>>>>
>>>>
>>>>


From joel.borggren.franck at gmail.com  Fri Jan 13 17:54:19 2017
From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=)
Date: Fri, 13 Jan 2017 17:54:19 +0000
Subject: Guaranteed order of annotations?
In-Reply-To: <CADGJaX8xu+6XbjxU8G7no31KA17WW9P6hjgh-vvC0Ezg7qgTMg@mail.gmail.com>
References: <CADGJaX8xu+6XbjxU8G7no31KA17WW9P6hjgh-vvC0Ezg7qgTMg@mail.gmail.com>
Message-ID: <CAFG0kMaznHhQM_n7J9F2zRaJ+WNBScw0=o5erUhmqyjyV__KvQ@mail.gmail.com>

Iirc there are no guatantees but we try as best as we can to maintain
source code order. It has been a couple of years now but I think there are
a few corner cases with repeating annotations.

Cheers
/Joel

On Fri, 13 Jan 2017 at 18:14, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
>
>
> Is there any order guaranteed in which an element's annotations are
>
> returned by AnnotatedElement#getDeclaredAnnotations()? Specifically,
>
> is this the order in which the annotations are given in the source
>
> code?
>
>
>
> Section 9.7.5. of the JLS ("Multiple Annotations of the Same Type")
>
> makes a statement of the source order being considered by the array of
>
> the implicit container annotation created for a repeatable annotation
>
> ("[...] all the base annotations in the left-to-right order in which
>
> they appeared in the context").
>
>
>
> But I couldn't find any authoritative description on the ordering
>
> behaviour of getDeclaredAnnotations(). Should we assume that we cannot
>
> rely on the order in the source?
>
>
>
> Thanks for any pointers,
>
>
>
> --Gunnar
>
>

From felix.yang at oracle.com  Fri Jan 13 17:57:25 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Fri, 13 Jan 2017 09:57:25 -0800
Subject: RFR 8172765,
	closed/javax/sound/sampled/Clip/AppletAudioClip/SoundBug.java failed in
	headless system
Message-ID: <A8643A70-5903-4816-9D7C-E734C5DC56FB@oracle.com>

Hi team,
    please review the patch to mark following test as headful. It has been failing in Mach 5 for several runs

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

Thanks,
Felix

Patch:

diff -r 2ca43b220611 javax/sound/sampled/Clip/AppletAudioClip/SoundBug.java
--- a/javax/sound/sampled/Clip/AppletAudioClip/SoundBug.java	Fri Jan 13 01:36:12 2017 +0000
+++ b/javax/sound/sampled/Clip/AppletAudioClip/SoundBug.java	Fri Jan 13 09:34:46 2017 -0800
@@ -11,7 +11,7 @@
  * @test
  * @bug 4181910
  * @summary AudioClip incompatibility
- * @key closed-binary
+ * @key closed-binary headful
  */
 public class SoundBug extends Frame {



From felix.yang at oracle.com  Fri Jan 13 18:11:13 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Fri, 13 Jan 2017 10:11:13 -0800
Subject: RFR 8172765,
	closed/javax/sound/sampled/Clip/AppletAudioClip/SoundBug.java failed in
	headless system
In-Reply-To: <A8643A70-5903-4816-9D7C-E734C5DC56FB@oracle.com>
References: <A8643A70-5903-4816-9D7C-E734C5DC56FB@oracle.com>
Message-ID: <1FCD1830-2A5D-4D78-A737-7B5BD018F65C@oracle.com>

oops! Incidentally sent to wrong alias. Sorry, please ignore it.

Thanks,
Felix
> On 13 Jan 2017, at 9:57 AM, Felix Yang <felix.yang at oracle.com> wrote:
> 
> Hi team,
>    please review the patch to mark following test as headful. It has been failing in Mach 5 for several runs
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8172765
> 
> Thanks,
> Felix
> 
> Patch:
> 
> diff -r 2ca43b220611 javax/sound/sampled/Clip/AppletAudioClip/SoundBug.java
> --- a/javax/sound/sampled/Clip/AppletAudioClip/SoundBug.java	Fri Jan 13 01:36:12 2017 +0000
> +++ b/javax/sound/sampled/Clip/AppletAudioClip/SoundBug.java	Fri Jan 13 09:34:46 2017 -0800
> @@ -11,7 +11,7 @@
>  * @test
>  * @bug 4181910
>  * @summary AudioClip incompatibility
> - * @key closed-binary
> + * @key closed-binary headful
>  */
> public class SoundBug extends Frame {
> 
> 


From ygaevsky at azulsystems.com  Fri Jan 13 20:15:20 2017
From: ygaevsky at azulsystems.com (Yuri Gaevsky)
Date: Fri, 13 Jan 2017 20:15:20 +0000
Subject: Guaranteed order of annotations?
In-Reply-To: <CADGJaX8xu+6XbjxU8G7no31KA17WW9P6hjgh-vvC0Ezg7qgTMg@mail.gmail.com>
References: <CADGJaX8xu+6XbjxU8G7no31KA17WW9P6hjgh-vvC0Ezg7qgTMg@mail.gmail.com>
Message-ID: <ABC6F6B1F6CA734A9B233369A3750F1531093392@MBX021-W3-CA-4.exch021.domain.local>

Hi Gunnar,

Please take a look at JDK-8010679 'Clarify "present" and annotation ordering in Core Reflection for Annotations' [*].

Best regards,
-Yuri

[*] https://bugs.openjdk.java.net/browse/JDK-8010679


-----Original Message-----
From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Gunnar Morling
Sent: Friday, January 13, 2017 08:14 PM
To: core-libs-dev at openjdk.java.net
Subject: Guaranteed order of annotations?

Hi,

Is there any order guaranteed in which an element's annotations are
returned by AnnotatedElement#getDeclaredAnnotations()? Specifically,
is this the order in which the annotations are given in the source
code?

Section 9.7.5. of the JLS ("Multiple Annotations of the Same Type")
makes a statement of the source order being considered by the array of
the implicit container annotation created for a repeatable annotation
("[...] all the base annotations in the left-to-right order in which
they appeared in the context").

But I couldn't find any authoritative description on the ordering
behaviour of getDeclaredAnnotations(). Should we assume that we cannot
rely on the order in the source?

Thanks for any pointers,

--Gunnar

From Roger.Riggs at Oracle.com  Fri Jan 13 20:23:45 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 13 Jan 2017 15:23:45 -0500
Subject: RFR of JDK-7146543: TEST_BUG:
	java/rmi/registry/readTest/readTest.sh failing intermittently with port
	in use
In-Reply-To: <778a62e8-6949-cdeb-53c6-33ad762ec409@oracle.com>
References: <778a62e8-6949-cdeb-53c6-33ad762ec409@oracle.com>
Message-ID: <2b2b0ce5-c1d7-b4a4-acc3-8ebf476991d0@Oracle.com>

Hi Hamlin,

Looks good, thanks for converting that shell test to java.

Roger




On 1/13/2017 2:32 AM, Hamlin Li wrote:
> Would you please review the below patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-7146543
> webrev: http://cr.openjdk.java.net/~mli/7146543/webrev.00/
>
> The patch rewrite the test in java, fixes the bug.
>
> Thank you
> -Hamlin


From gunnar at hibernate.org  Fri Jan 13 21:16:47 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 13 Jan 2017 22:16:47 +0100
Subject: Guaranteed order of annotations?
In-Reply-To: <ABC6F6B1F6CA734A9B233369A3750F1531093392@MBX021-W3-CA-4.exch021.domain.local>
References: <CADGJaX8xu+6XbjxU8G7no31KA17WW9P6hjgh-vvC0Ezg7qgTMg@mail.gmail.com>
	<ABC6F6B1F6CA734A9B233369A3750F1531093392@MBX021-W3-CA-4.exch021.domain.local>
Message-ID: <CADGJaX8HfFX7Q2YK-_tpcf6xdMTzrrasAtVbBgGSss8e_uWz3A@mail.gmail.com>

Hi Yuri,

Thanks for the pointer.

But do you see any clear description of an order mandated for
getDeclaredAnnotations()? The only references to an order I can find
there are for repeatable annotations (where source code order is
maintained when retrieving them via the container annotation type).
But I cannot find any guaranteed order when obtaining all declared
annotations from an element.

The reason why I'm asking is Bean Validation, where we've seen
requests of people that wish to validate the constraints of an element
in a fixed order, aborting after the first failed constraint:

    @NotNull
    @Email
    String email;

Here one may want to first validate @NotNull and don't proceed with
validating @Email if the field is null.

Relying on source order would be a very natural way to express the
order of constraints. Without a guaranteed ordering of annotations
we'd have to add some other means of ordering, e.g. an attribute with
the index (@NotNull(order=0) @Email(order=1)) which is more verbose of
course.

--Gunnar





2017-01-13 21:15 GMT+01:00 Yuri Gaevsky <ygaevsky at azulsystems.com>:
> Hi Gunnar,
>
> Please take a look at JDK-8010679 'Clarify "present" and annotation ordering in Core Reflection for Annotations' [*].
>
> Best regards,
> -Yuri
>
> [*] https://bugs.openjdk.java.net/browse/JDK-8010679
>
>
> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Gunnar Morling
> Sent: Friday, January 13, 2017 08:14 PM
> To: core-libs-dev at openjdk.java.net
> Subject: Guaranteed order of annotations?
>
> Hi,
>
> Is there any order guaranteed in which an element's annotations are
> returned by AnnotatedElement#getDeclaredAnnotations()? Specifically,
> is this the order in which the annotations are given in the source
> code?
>
> Section 9.7.5. of the JLS ("Multiple Annotations of the Same Type")
> makes a statement of the source order being considered by the array of
> the implicit container annotation created for a repeatable annotation
> ("[...] all the base annotations in the left-to-right order in which
> they appeared in the context").
>
> But I couldn't find any authoritative description on the ordering
> behaviour of getDeclaredAnnotations(). Should we assume that we cannot
> rely on the order in the source?
>
> Thanks for any pointers,
>
> --Gunnar

From mandy.chung at oracle.com  Fri Jan 13 21:25:06 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 13 Jan 2017 13:25:06 -0800
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
	<4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
	<af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
Message-ID: <30D742E8-4C2C-4A0A-8147-154C4775C5C0@oracle.com>


> On Jan 12, 2017, at 1:20 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Realized moduleRef & callerRef would never be null with this new version. Thus modified the patch as:
> 
> http://cr.openjdk.java.net/~naoto/8171139/webrev.03/

CacheKey
   Nit: line 576 can be moved after 581 to group the volatile fields together

 619             this(src.getName(), src.getLocale(), src.getModule(), src.getCallerModule());

Daniel asks whether there is any possibility that the target module or caller module would be GC?ed.

CacheKey is copied in two places, one in findBundle and the other is putBundleInCache which is actually passed with a newly cloned CacheKey.  IIUC, the cacheKey passed to findBundle ia always a new instance (as it subsequently sets to different locale during the lookup).  Its caller module is the caller on the stack and the target module is also a strong reference either caller?s module, unnamed module from a given class loader, or a given module.

Naoto will have to double check.

Otherwise look fine.
Mandy

From naoto.sato at oracle.com  Sat Jan 14 00:05:45 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 13 Jan 2017 16:05:45 -0800
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <30D742E8-4C2C-4A0A-8147-154C4775C5C0@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
	<4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
	<af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
	<30D742E8-4C2C-4A0A-8147-154C4775C5C0@oracle.com>
Message-ID: <49e94b11-4491-6c33-2afe-76c23066f5af@oracle.com>

Thank you again, Daniel & Mandy.

On 1/13/17 1:25 PM, Mandy Chung wrote:
>
>> On Jan 12, 2017, at 1:20 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>
>> Realized moduleRef & callerRef would never be null with this new version. Thus modified the patch as:
>>
>> http://cr.openjdk.java.net/~naoto/8171139/webrev.03/
>
> CacheKey
>    Nit: line 576 can be moved after 581 to group the volatile fields together

As in the comment line 574, the first 4 fields are the actual keys for 
lookup, so I'd keep them that way.

>
>  619             this(src.getName(), src.getLocale(), src.getModule(), src.getCallerModule());
>
> Daniel asks whether there is any possibility that the target module or caller module would be GC?ed.
>
> CacheKey is copied in two places, one in findBundle and the other is putBundleInCache which is actually passed with a newly cloned CacheKey.  IIUC, the cacheKey passed to findBundle ia always a new instance (as it subsequently sets to different locale during the lookup).  Its caller module is the caller on the stack and the target module is also a strong reference either caller?s module, unnamed module from a given class loader, or a given module.
>
> Naoto will have to double check.

I think this is correct. The current way of using CacheKey is safe from 
its modules to be GC'ed. However in general, it'd be good prepare them 
to be GC'ed. I modified the impl to hold them in local variables 
preventing them to be GC'ed before instantiating new References. (Also I 
modified not to call the other constructor in the copy constructor, 
reinstating some piece what Peter's diff originally had). So here is the 
updated webrev:

http://cr.openjdk.java.net/~naoto/8171139/webrev.04/

Naoto

From mandy.chung at oracle.com  Sat Jan 14 00:25:15 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 13 Jan 2017 16:25:15 -0800
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <49e94b11-4491-6c33-2afe-76c23066f5af@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
	<4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
	<af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
	<30D742E8-4C2C-4A0A-8147-154C4775C5C0@oracle.com>
	<49e94b11-4491-6c33-2afe-76c23066f5af@oracle.com>
Message-ID: <F72E509E-51E2-456C-A2D1-BA5A7D9F2091@oracle.com>


> On Jan 13, 2017, at 4:05 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>> 
>> Daniel asks whether there is any possibility that the target module or caller module would be GC?ed.
>> 
>> CacheKey is copied in two places, one in findBundle and the other is putBundleInCache which is actually passed with a newly cloned CacheKey.  IIUC, the cacheKey passed to findBundle ia always a new instance (as it subsequently sets to different locale during the lookup).  Its caller module is the caller on the stack and the target module is also a strong reference either caller?s module, unnamed module from a given class loader, or a given module.
>> 
>> Naoto will have to double check.
> 
> I think this is correct. The current way of using CacheKey is safe from its modules to be GC'ed. However in general, it'd be good prepare them to be GC'ed. I modified the impl to hold them in local variables preventing them to be GC'ed before instantiating new References. (Also I modified not to call the other constructor in the copy constructor, reinstating some piece what Peter's diff originally had). So here is the updated webrev:
> 
> http://cr.openjdk.java.net/~naoto/8171139/webrev.04/

So callerRef and moduleRef may be null. getLoader(null) may be called which will throw NPE.

Mandy


From naoto.sato at oracle.com  Sat Jan 14 00:54:49 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 13 Jan 2017 16:54:49 -0800
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <F72E509E-51E2-456C-A2D1-BA5A7D9F2091@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
	<4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
	<af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
	<30D742E8-4C2C-4A0A-8147-154C4775C5C0@oracle.com>
	<49e94b11-4491-6c33-2afe-76c23066f5af@oracle.com>
	<F72E509E-51E2-456C-A2D1-BA5A7D9F2091@oracle.com>
Message-ID: <a97b7396-c1c1-910c-583a-cac3cf5b71f5@oracle.com>

Modified as:

diff -r a6d3c80ea436 
src/java.base/share/classes/java/util/ResourceBundle.java
--- a/src/java.base/share/classes/java/util/ResourceBundle.java
+++ b/src/java.base/share/classes/java/util/ResourceBundle.java
@@ -2192,7 +2192,7 @@
      private static void clearCacheImpl(Module callerModule, 
ClassLoader loader) {
          cacheList.keySet().removeIf(
              key -> key.getCallerModule() == callerModule &&
-                   getLoader(key.getModule()) == loader
+                   key.getModule() != null && 
getLoader(key.getModule()) == loader
          );
      }

This is the only occurence where CacheKey's modules are passed to 
getLoader(Module). Entire webrev is here:

http://cr.openjdk.java.net/~naoto/8171139/webrev.05/

Naoto

On 01/13/2017 04:25 PM, Mandy Chung wrote:
>
>> On Jan 13, 2017, at 4:05 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>
>>> Daniel asks whether there is any possibility that the target module or caller module would be GC?ed.
>>>
>>> CacheKey is copied in two places, one in findBundle and the other is putBundleInCache which is actually passed with a newly cloned CacheKey.  IIUC, the cacheKey passed to findBundle ia always a new instance (as it subsequently sets to different locale during the lookup).  Its caller module is the caller on the stack and the target module is also a strong reference either caller?s module, unnamed module from a given class loader, or a given module.
>>>
>>> Naoto will have to double check.
>>
>> I think this is correct. The current way of using CacheKey is safe from its modules to be GC'ed. However in general, it'd be good prepare them to be GC'ed. I modified the impl to hold them in local variables preventing them to be GC'ed before instantiating new References. (Also I modified not to call the other constructor in the copy constructor, reinstating some piece what Peter's diff originally had). So here is the updated webrev:
>>
>> http://cr.openjdk.java.net/~naoto/8171139/webrev.04/
>
> So callerRef and moduleRef may be null. getLoader(null) may be called which will throw NPE.
>
> Mandy
>


From mandy.chung at oracle.com  Sat Jan 14 01:32:33 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 13 Jan 2017 17:32:33 -0800
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <a97b7396-c1c1-910c-583a-cac3cf5b71f5@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
	<4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
	<af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
	<30D742E8-4C2C-4A0A-8147-154C4775C5C0@oracle.com>
	<49e94b11-4491-6c33-2afe-76c23066f5af@oracle.com>
	<F72E509E-51E2-456C-A2D1-BA5A7D9F2091@oracle.com>
	<a97b7396-c1c1-910c-583a-cac3cf5b71f5@oracle.com>
Message-ID: <5A2732B6-1182-4819-866D-6E22995A254B@oracle.com>

What I wanted to say is that you are creating a new CacheKey which is used to load a resource bundle and if found, it will be put in the cacheList.

It seems wrong to continue the request for loading a bundle but its caller module and target module is GC?ed and put a NONEXISTENT_BUNDLE in the cache. I consider it as an error state if we ever get there.

Mandy

> On Jan 13, 2017, at 4:54 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Modified as:
> 
> diff -r a6d3c80ea436 src/java.base/share/classes/java/util/ResourceBundle.java
> --- a/src/java.base/share/classes/java/util/ResourceBundle.java
> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java
> @@ -2192,7 +2192,7 @@
>     private static void clearCacheImpl(Module callerModule, ClassLoader loader) {
>         cacheList.keySet().removeIf(
>             key -> key.getCallerModule() == callerModule &&
> -                   getLoader(key.getModule()) == loader
> +                   key.getModule() != null && getLoader(key.getModule()) == loader
>         );
>     }
> 
> This is the only occurence where CacheKey's modules are passed to getLoader(Module). Entire webrev is here:
> 
> http://cr.openjdk.java.net/~naoto/8171139/webrev.05/
> 
> Naoto
> 
> On 01/13/2017 04:25 PM, Mandy Chung wrote:
>> 
>>> On Jan 13, 2017, at 4:05 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>> 
>>>> Daniel asks whether there is any possibility that the target module or caller module would be GC?ed.
>>>> 
>>>> CacheKey is copied in two places, one in findBundle and the other is putBundleInCache which is actually passed with a newly cloned CacheKey.  IIUC, the cacheKey passed to findBundle ia always a new instance (as it subsequently sets to different locale during the lookup).  Its caller module is the caller on the stack and the target module is also a strong reference either caller?s module, unnamed module from a given class loader, or a given module.
>>>> 
>>>> Naoto will have to double check.
>>> 
>>> I think this is correct. The current way of using CacheKey is safe from its modules to be GC'ed. However in general, it'd be good prepare them to be GC'ed. I modified the impl to hold them in local variables preventing them to be GC'ed before instantiating new References. (Also I modified not to call the other constructor in the copy constructor, reinstating some piece what Peter's diff originally had). So here is the updated webrev:
>>> 
>>> http://cr.openjdk.java.net/~naoto/8171139/webrev.04/
>> 
>> So callerRef and moduleRef may be null. getLoader(null) may be called which will throw NPE.
>> 
>> Mandy
>> 
> 


From me at yawk.at  Sun Jan 15 21:37:59 2017
From: me at yawk.at (Jonas Konrad)
Date: Sun, 15 Jan 2017 22:37:59 +0100
Subject: Fixing Object.hashCode documentation
Message-ID: <447fbc83-78fd-313c-caeb-daf4a0617ff0@yawk.at>

Hi,

https://bugs.openjdk.java.net/browse/JDK-6321873 has been idle since 
2005. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/458adf31ad5b changed 
the wording somewhat (though I still don't think it's explicit enough in 
that OpenJDK does *not* use the address). Could you further improve the 
wording, or if you believe it is sufficient, close the jira bug?

Thank you,
- Jonas Konrad

From amy.lu at oracle.com  Mon Jan 16 09:41:15 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Mon, 16 Jan 2017 17:41:15 +0800
Subject: JDK 9 RFR of JDK-8146668: Replace custom check/range
	functionality with check index/range methods in java.util.Objects
In-Reply-To: <44FFB565-3075-49C5-9069-08189E13BE7B@oracle.com>
References: <de138c68-e8e5-ba3b-6e2b-603b8fc49329@oracle.com>
	<44FFB565-3075-49C5-9069-08189E13BE7B@oracle.com>
Message-ID: <eeea98c6-0d3a-6830-dea3-d32d436aa8fc@oracle.com>

Thank you Paul and Martin for your review.

On 1/13/17 12:52 AM, Paul Sandoz wrote:
> HI Amy,
>
> Overall this looks very good, well done.
>
>
> At this point we are down to two things:
>
> 1) should we preserve exception messages?
>
> 2) due diligence on the performance.
>
>
> On 1) my preference is that uniform (and informative) messages are better for IndexOutOfBounds and subtypes, and defining that in addition to the checks in one place is very valuable. In some sense that does change some behavioural compatibility and i think because of that pushing in 10 (when the repos) open with a CCC would be more preferable.
Got it. Will wait for 10.
>
> On 2) this is a valuable exercise to perform (either using an existing test and/or writing JMH benchmarks). I don?t expect any major problems. Care was taken to ensure the uncommon exception processing path will optimize away for the common case. The BiFunction parameter passed as the last argument is always a constant, so should fold away from the hot path.

Tested with java/util/ArrayList/RangeCheckMicroBenchmark.java and 
java/nio/Buffer/SwapMicroBenchmark.java, no performance regression observed.

java/util/ArrayList/RangeCheckMicroBenchmark.java

without 8146668
--------------------
  get                             26          1
  set                             40.6        1.5707
  get/set                         85.7        3.3002
  add/remove at end               337.5       12.9197
  subList get                     25          0.9747
  subList set                     59.9        2.3
  subList get/set                 92.2        3.5414
  subList add/remove at end       429.8       16.45

with 8146668
--------------------
  get                             26          1
  set                             39.1        1.5188
  get/set                         86.8        3.3363
  add/remove at end               335.5       12.8549
  subList get                     24.8        0.9715
  subList set                     59.2        2.2728
  subList get/set                 92.2        3.5473
  subList add/remove at end       427.7       16.3789

java/nio/Buffer/SwapMicroBenchmark.java

without 8146668
--------------------
  swap char LITTLE_ENDIAN         11          1
  swap short LITTLE_ENDIAN        10.2        0.9895
  swap int LITTLE_ENDIAN          5           0.4961
  swap long LITTLE_ENDIAN         3           0.3345

with 8146668
--------------------
  swap char LITTLE_ENDIAN         10.1        1
  swap short LITTLE_ENDIAN        10.1        0.9995
  swap int LITTLE_ENDIAN          5           0.5005
  swap long LITTLE_ENDIAN         3           0.3327

Thanks,
Amy
>
> Paul.
>
>
>> On 11 Jan 2017, at 18:10, Amy Lu <amy.lu at oracle.com> wrote:
>>
>> 8135248 and 8155794 introduced utility methods for checking indexes and ranges. Existing code with custom checkIndex/checkRange can be updated to use these methods. Please review the patch for this purpose:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8146668
>> webrev: http://cr.openjdk.java.net/~amlu/8146668/webrev.01
>>
>> The type of exception thrown are preserved. Custom checkIndex/checkRange functions that throw IOOBE are now using ?check? utility methods provided by java.lang.Objects (which also throws IOOBE), functions that throw other exceptions use jdk.internal.util.Preconditions to preserve exception types, with the help of new BiFunction vars.
>>
>> I'd like to get this in JDK 9 if it's not too late, otherwise, JDK 10.
>>
>> Thanks,
>> Amy


From daniel.fuchs at oracle.com  Mon Jan 16 11:25:27 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 16 Jan 2017 11:25:27 +0000
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <a97b7396-c1c1-910c-583a-cac3cf5b71f5@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
	<4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
	<af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
	<30D742E8-4C2C-4A0A-8147-154C4775C5C0@oracle.com>
	<49e94b11-4491-6c33-2afe-76c23066f5af@oracle.com>
	<F72E509E-51E2-456C-A2D1-BA5A7D9F2091@oracle.com>
	<a97b7396-c1c1-910c-583a-cac3cf5b71f5@oracle.com>
Message-ID: <49cc18e1-18c1-adf2-14a9-f5f1d067f4fc@oracle.com>

Hi Naoto,

On 14/01/17 00:54, Naoto Sato wrote:
> diff -r a6d3c80ea436
> src/java.base/share/classes/java/util/ResourceBundle.java
> --- a/src/java.base/share/classes/java/util/ResourceBundle.java
> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java
> @@ -2192,7 +2192,7 @@
>      private static void clearCacheImpl(Module callerModule, ClassLoader
> loader) {
>          cacheList.keySet().removeIf(
>              key -> key.getCallerModule() == callerModule &&
> -                   getLoader(key.getModule()) == loader
> +                   key.getModule() != null &&
> getLoader(key.getModule()) == loader
>          );
>      }
>
> This is the only occurence where CacheKey's modules are passed to
> getLoader(Module). Entire webrev is here:
>
> http://cr.openjdk.java.net/~naoto/8171139/webrev.05/

I think you need to introduce a new static method here, because
there's no guarantee that a module won't be GC'ed between
two calls to key.getModule() - the first call could return
non null and the second could return null:

private static boolean isMatching(CacheKey key, Module callerModule, 
ClassLoader loader) {
     final Module module = key.getModule();
     return key.getCallerModule() == callerModule &&
            module != null && getLoader(module) == loader;
}

and then use that in the lambda.

A related question is whether a CacheKey whose module is null
is stale? If so maybe clearCacheImpl could also be changed to
removed stale keys as well as matching keys?

private static boolean isMatching(CacheKey key, Module callerModule, 
ClassLoader loader) {
     final Module km = key.getModule();
     final Module kcm = key.getCallerModule();
     return kcm == null || km == null || kcm == callerModule &&
            getLoader(km) == loader;
}


best regards,

-- daniel

From christoph.langer at sap.com  Mon Jan 16 14:48:42 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 16 Jan 2017 14:48:42 +0000
Subject: RFR: 8169631: [JAXP] XALAN: transformation of XML via
	namespace-unaware SAX input yields a different result than
	namespace-unaware DOM input
In-Reply-To: <583C7FFD.4000601@oracle.com>
References: <313759790392479fa80a10542ab664ec@dewdfe13de07.global.corp.sap>
	<582A7170.7030100@oracle.com>
	<4be5158237814eeb9352fe8fe344e47c@dewdfe13de07.global.corp.sap>
	<582E8944.7090906@oracle.com>
	<a7f7c322bfb441e89e61ccd80627fff9@DEWDFE13DE03.global.corp.sap>
	<582F90D6.1040308@oracle.com> <5834985F.4060503@oracle.com>
	<4ff8d067fd88496ba536c65610ee54cb@DEWDFE13DE03.global.corp.sap>
	<583C7FFD.4000601@oracle.com>
Message-ID: <ddfa743c14a34dbca97f60f16d6e85e6@derote13de46.global.corp.sap>

Hi Joe,

I finally got back to this one and pushed the change with some minor whitespace diffs.

Thanks
Christoph

> -----Original Message-----
> From: Joe Wang [mailto:huizhe.wang at oracle.com]
> Sent: Montag, 28. November 2016 20:06
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via
> namespace-unaware SAX input yields a different result than namespace-
> unaware DOM input
> 
> Hi Christoph,
> 
> The changes look good. I also run the other tests (smoke test and etc.),
> and they all passed.
> 
> Best,
> Joe
> 
> On 11/25/16, 4:25 AM, Langer, Christoph wrote:
> > Hi Joe,
> >
> > when trying to finish this up, I had a closer look again.
> >
> > I found out that it's necessary to look at attributes as well and handle the case
> where namespace prefixes are used.
> >
> > Here is a new version of the changeset that passes all jaxp jtreg tests:
> > http://cr.openjdk.java.net/~clanger/webrevs/8169631.1/
> >
> > Now I would also throw out prefixes in localName if we don't have
> namespace support - for both, elements and attributes (in
> SAX2DTM2.startElement()).
> >
> > I also removed some qname handling in DOM2SAX as it is not needed with
> my changes to SAX2DTM2 anymore.
> >
> > The test case was adopted.
> >
> > Thanks&  best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: Joe Wang [mailto:huizhe.wang at oracle.com]
> >> Sent: Dienstag, 22. November 2016 20:11
> >> To: Langer, Christoph<christoph.langer at sap.com>
> >> Cc: core-libs-dev at openjdk.java.net
> >> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via
> >> namespace-unaware SAX input yields a different result than namespace-
> >> unaware DOM input
> >>
> >> Hi Christoph,
> >>
> >> Once you're able to run all tests, feel free to push the changeset.
> >> Frank has fixed the Smoke test.
> >>
> >> Thanks,
> >> Joe
> >>
> >> On 11/18/16, 3:37 PM, Joe Wang wrote:
> >>> Hi Christoph,
> >>>
> >>> Thanks for explaining the customer's dilemma with regard to their
> >>> legacy process.
> >>>
> >>> The testcase I sent you was extracted from an internal SQE smoke test.
> >>> I agree with your analysis, the 'golden' file which has been in there
> >>> for over 10 years turns out to be wrong and needs to be updated.
> >>>
> >>> To fix this issue, we need to get that test fixed, and the check-in of
> >>> your patch and that of the test need needs to happen simultaneously.
> >>> Would you mind wanting for me to go through an internal process to get
> >>> a patch ready, then we can check in almost at the same time?
> >>>
> >>> Best,
> >>> Joe
> >>>
> >>> On 11/18/16, 2:51 PM, Langer, Christoph wrote:
> >>>> Hi Joe,
> >>>>
> >>>> thanks for the feedback.
> >>>>
> >>>> I've now understood the testcase that you've sent over and the reason
> >>>> that it is reporting failure after my fix is that the output of its
> >>>> transform operation is rather correct now. And before it was wrong. :)
> >>>> The test is comparing the actual result to a "golden" result file in
> >>>> the end and both of these were not looking healthy so far. The reason
> >>>> is that your test is using a namespace unaware SAX Parser as input.
> >>>> With the current JDK XALAN, you could already modify your smoketest
> >>>> to use a namespace aware parser.
> >>>>
> >>>> E.g. replace lines
> >>>>
> >>>> 82        // Use the JAXP way to get an XMLReader
> >>>> 83        XMLReader reader =
> >>>> SAXParserFactory.newInstance().newSAXParser().getXMLReader();
> >>>>
> >>>> with
> >>>>
> >>>> 82        // Use the JAXP way to get an XMLReader
> >>>> 83        SAXParserFactory spf = SAXParserFactory.newInstance();
> >>>> 84        spf.setNamespaceAware(true);
> >>>> 85        XMLReader reader = spf.newSAXParser().getXMLReader();
> >>>>
> >>>> ...and you would already get correct results that also DOM input or
> >>>> Stream Input would yield.
> >>>>
> >>>> So, are there other concerns/issues with this fix? Do you want me to
> >>>> include a transformation operation like the one that your SmokeTest
> >>>> does to TransformerTest which would illustrate the problem with
> >>>> namespace unaware SAX input data?
> >>>>
> >>>> Best regards
> >>>> Christoph
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Joe Wang [mailto:huizhe.wang at oracle.com]
> >>>>> Sent: Freitag, 18. November 2016 05:53
> >>>>> To: Langer, Christoph<christoph.langer at sap.com>
> >>>>> Cc: core-libs-dev at openjdk.java.net
> >>>>> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via
> >>>>> namespace-unaware SAX input yields a different result than namespace-
> >>>>> unaware DOM input
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 11/14/16, 11:43 PM, Langer, Christoph wrote:
> >>>>>> Hi Joe,
> >>>>>>
> >>>>>> thanks for looking.
> >>>>>>
> >>>>>> Can you let me know which smoke test is failing? I didn't see
> >>>>>> issues so far - I
> >>>>> was merely running the jtreg unittests for transformer.
> >>>>>
> >>>>> I sent the test to your mailbox.
> >>>>>> I stepped back from replacing Vector with ArrayList for
> >>>>>> m_prefixMappings
> >>>>> because the code is using methods indexOf() with a start index and
> >>>>> setSize() for
> >>>>> which ArrayList has no direct matchings. One could, for sure, add
> >>>>> some other
> >>>>> coding, e.g. use ArrayList's subList() method for the index based
> >>>>> search - but I
> >>>>> wouldn't want to run the risk of adding a regression here just
> >>>>> because I
> >>>>> modified the code and did not well test it. But if you insist, I
> >>>>> could have another
> >>>>> look.
> >>>>>
> >>>>> Ok, that's fine. subList would do, but setSize may need a bit more
> >>>>> work.
> >>>>>
> >>>>> Best,
> >>>>> Joe
> >>>>>> Best regards
> >>>>>> Christoph
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Joe Wang [mailto:huizhe.wang at oracle.com]
> >>>>>>> Sent: Dienstag, 15. November 2016 03:23
> >>>>>>> To: Langer, Christoph<christoph.langer at sap.com>
> >>>>>>> Cc: core-libs-dev at openjdk.java.net
> >>>>>>> Subject: Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via
> >>>>>>> namespace-unaware SAX input yields a different result than
> namespace-
> >>>>>>> unaware DOM input
> >>>>>>>
> >>>>>>> Hi Christoph,
> >>>>>>>
> >>>>>>> Not all tests have finished yet, but there's at least one failure
> >>>>>>> in the
> >>>>>>> smoke test. I'll get to the details when I have time.
> >>>>>>>
> >>>>>>> Any reason why m_prefixMappings can not be replaced with
> ArrayList?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Joe
> >>>>>>>
> >>>>>>> On 11/14/16, 6:10 AM, Langer, Christoph wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> please review this fix for bug 8169631.
> >>>>>>>>
> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169631
> >>>>>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169631.0/
> >>>>>>>>
> >>>>>>>> When XALAN is handling namespace unaware input, it behaves
> >>>>>>>> differently
> >>>>>>> while using SAX input compared to DOM input.
> >>>>>>>> With both input source types, the class
> >>>>>>> com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2
> converts
> >> SAX
> >>>>>>> input into a DTM representation for processing by the XALAN
> >>>>>>> transformer.
> >>>>> Its
> >>>>>>> method startElement takes URI, localname and qName as attribute.
> >>>>>>> In case
> >>>>> of
> >>>>>>> missing feature namespaces, startElement and localname can be
> empty.
> >>>>>>> However, the function uses the localname value for the call to
> >>>>>>> m_expandedNameTable.getExpandedTypeID() and further processing.
> In
> >>>>>>> the
> >>>>>>> case where only qName has data, this leads to issues.
> >>>>>>>> When using DOM input, the class
> >>>>>>> com.sun.org.apache.xalan.internal.xsltc.trax.DOM2SAX converts the
> >> DOM
> >>>>> input
> >>>>>>> into SAX input. In the case of empty localname, it fills localname
> >>>>>>> with qname
> >>>>>>> data. See method getLocalName() [1], called by parse() [2].
> >>>>>>>> When directly using SAX input, the SAX parser calls the
> >>>>>>>> startElement()
> >>>>>>> function on XALAN's handler with empty uri and localname - which
> >>>>>>> seems
> >>>>>>> correct, as per the spec.
> >>>>>>>> Both paths end up in SAX2DTM2's startElement(). So I suggest to
> >>>>>>>> change
> >>>>> this
> >>>>>>> method to handle the case when uri and localname are empty and
> >>>>>>> then set
> >>>>>>> qname as localname. Maybe one should even change DOM2SAX's
> >>>>>>> getLocalName handling to not fill localname with qname in case it
> >>>>>>> is empty
> >>>>>>> after SAX2DTM was changed..
> >>>>>>>> Generally, JavaDoc for SAXSource says that "Attempting to
> >>>>>>>> transform an
> >>>>> input
> >>>>>>> source that is not generated with a namespace-aware parser may
> >>>>>>> result in
> >>>>>>> errors." But why not fix some of these :)
> >>>>>>>> Furthermore I did some cleanups in the code.
> >>>>>>>>
> >>>>>>>> Thanks and best regards
> >>>>>>>> Christoph
> >>>>>>>>
> >>>>>>>> [1]
> >>
> http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar
> >>>>>
> >>
> e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l139
> >>>>>>>> [2]
> >>
> http://hg.openjdk.java.net/jdk9/dev/jaxp/file/71558b38bad7/src/java.xml/shar
> >>>>>
> >>
> e/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java#l279
> >>>>>>>> [3]
> >>
> https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource
> >>>>>>> .html

From mandy.chung at oracle.com  Mon Jan 16 21:39:57 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 16 Jan 2017 13:39:57 -0800
Subject: RFR: 8037325: Class.getConstructor() performance regression
In-Reply-To: <e502d8bb-d1a1-faef-c7c3-a88490ae3edf@oracle.com>
References: <e502d8bb-d1a1-faef-c7c3-a88490ae3edf@oracle.com>
Message-ID: <D4E33DDA-39EE-4158-9781-0E1FD524C2AA@oracle.com>


> On Jan 12, 2017, at 6:48 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> please review this fix to various performance regressions observed
> as the security model has evolved over the years.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8037325
> Webrev: http://cr.openjdk.java.net/~redestad/8037325/webrev.01
> 

Looks good.

Nit: methodName method returns the string representation of the method signature and so more than the method name.  Maybe it should call ?methodToString??  The argumentTypesToString method is only used to print the method signature.  You could merge these two methods if you like.

ReflectUtil.java
 262     public static boolean isNonPublicProxyClass(Class<?> cls) {
 263         String pkg;
 264         return Proxy.isProxyClass(cls) &&
 265                 ((pkg = cls.getPackageName()) == null || !pkg.startsWith(PROXY_PACKAGE));
 266     }

Nit: just a personal preference: move Proxy.isProxyClass(cls) check in a separate if-statement and the declaration pkg can be moved with the assignment.

Mandy


From claes.redestad at oracle.com  Mon Jan 16 21:59:50 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 16 Jan 2017 22:59:50 +0100
Subject: RFR: 8037325: Class.getConstructor() performance regression
In-Reply-To: <D4E33DDA-39EE-4158-9781-0E1FD524C2AA@oracle.com>
References: <e502d8bb-d1a1-faef-c7c3-a88490ae3edf@oracle.com>
	<D4E33DDA-39EE-4158-9781-0E1FD524C2AA@oracle.com>
Message-ID: <20e15902-ccac-01b3-21c6-879c58e29521@oracle.com>



On 2017-01-16 22:39, Mandy Chung wrote:
>
>> On Jan 12, 2017, at 6:48 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Hi,
>>
>> please review this fix to various performance regressions observed
>> as the security model has evolved over the years.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8037325
>> Webrev: http://cr.openjdk.java.net/~redestad/8037325/webrev.01
>>
>
> Looks good.

Thanks!

>
> Nit: methodName method returns the string representation of the method signature and so more than the method name.  Maybe it should call ?methodToString??  The argumentTypesToString method is only used to print the method signature.  You could merge these two methods if you like.
>
> ReflectUtil.java
>  262     public static boolean isNonPublicProxyClass(Class<?> cls) {
>  263         String pkg;
>  264         return Proxy.isProxyClass(cls) &&
>  265                 ((pkg = cls.getPackageName()) == null || !pkg.startsWith(PROXY_PACKAGE));
>  266     }
>
> Nit: just a personal preference: move Proxy.isProxyClass(cls) check in a separate if-statement and the declaration pkg can be moved with the assignment.

http://cr.openjdk.java.net/~redestad/8037325/webrev.02/

Like that?

/Claes
>
> Mandy
>

From mandy.chung at oracle.com  Mon Jan 16 22:27:27 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 16 Jan 2017 14:27:27 -0800
Subject: RFR: 8037325: Class.getConstructor() performance regression
In-Reply-To: <20e15902-ccac-01b3-21c6-879c58e29521@oracle.com>
References: <e502d8bb-d1a1-faef-c7c3-a88490ae3edf@oracle.com>
	<D4E33DDA-39EE-4158-9781-0E1FD524C2AA@oracle.com>
	<20e15902-ccac-01b3-21c6-879c58e29521@oracle.com>
Message-ID: <A75052F0-F3C6-4CCC-8D39-67DF1FAC1BD4@oracle.com>


> On Jan 16, 2017, at 1:59 PM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~redestad/8037325/webrev.02/

+1

Mandy

From daniel.fuchs at oracle.com  Tue Jan 17 11:45:12 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 17 Jan 2017 11:45:12 +0000
Subject: RFR: 8172886: Add a test that shows how the LogManager can be
	implemented by a module
Message-ID: <ef078150-769b-a74f-c8b3-9255d9f1f03e@oracle.com>

Hi,

Please find below a patch that adds a test that verifies that
LogManager, Handlers, and config classes can be implemented
from within a module (provided they are exported to java.logging).

JBS: https://bugs.openjdk.java.net/browse/JDK-8172886
webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8172886/webrev.00/


best regards,

-- daniel

From peter.levart at gmail.com  Tue Jan 17 11:53:58 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 17 Jan 2017 12:53:58 +0100
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <a97b7396-c1c1-910c-583a-cac3cf5b71f5@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
	<4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
	<af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
	<30D742E8-4C2C-4A0A-8147-154C4775C5C0@oracle.com>
	<49e94b11-4491-6c33-2afe-76c23066f5af@oracle.com>
	<F72E509E-51E2-456C-A2D1-BA5A7D9F2091@oracle.com>
	<a97b7396-c1c1-910c-583a-cac3cf5b71f5@oracle.com>
Message-ID: <2085c1ef-8699-8604-11ae-4fef3b1d1778@gmail.com>

Hi Naoto,

Sorry for joining late for review. Thanks for taking this on. I think it 
is shaping well...

On 01/14/2017 01:54 AM, Naoto Sato wrote:
>
>
> http://cr.openjdk.java.net/~naoto/8171139/webrev.05/
>

Tho things...

1. As said, the "cloning" of CacheKey has no purpose in the following 
section of code (lines 1685...1709):

             CacheKey constKey = new CacheKey(cacheKey);
             trace("findBundle: %d %s %s formats: %s%n", index, 
candidateLocales, cacheKey, formats);
             try {
                 if (module.isNamed()) {
                     bundle = loadBundle(cacheKey, formats, control, 
module, callerModule);
                 } else {
                     bundle = loadBundle(cacheKey, formats, control, 
expiredBundle);
                 }
                 if (bundle != null) {
                     if (bundle.parent == null) {
                         bundle.setParent(parent);
                     }
                     bundle.locale = targetLocale;
                     bundle = putBundleInCache(cacheKey, bundle, control);
                     return bundle;
                 }

                 // Put NONEXISTENT_BUNDLE in the cache as a mark that 
there's no bundle
                 // instance for the locale.
                 putBundleInCache(cacheKey, NONEXISTENT_BUNDLE, control);
             } finally {
                 if (constKey.getCause() instanceof InterruptedException) {
                     Thread.currentThread().interrupt();
                 }
             }

The 'constKey' is copied of the 'cacheKey' and is not used anywhere 
except in finally block where it is asked for .getCause() which will 
always be null since copying of CacheKey never copies the cause...

2. We can make sure that CacheKey copy constructor always copies a 
CacheKey that has non-cleared moduleRef and callerRef. The original 
cacheKey is created in getBundleImpl() from nun-null module and 
callerModule.  getBundleImpl() then calls down to findModule() with this 
cacheKey. If we keep a reference to module and callerModule in 
getBundleImpl() alive until the end of this method, we guarantee that 
moduleRef and callerRef will not be cleared while using such cacheKey to 
construct copies of it.

Here's those two changes applied to your webrev.05 and also a race in 
clearCacheImpl() fixed (as reported by Daniel Fuchs):

http://cr.openjdk.java.net/~plevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.06/

What do you think?

Regards, Peter


From daniel.fuchs at oracle.com  Tue Jan 17 12:24:43 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 17 Jan 2017 12:24:43 +0000
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <2085c1ef-8699-8604-11ae-4fef3b1d1778@gmail.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
	<4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
	<af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
	<30D742E8-4C2C-4A0A-8147-154C4775C5C0@oracle.com>
	<49e94b11-4491-6c33-2afe-76c23066f5af@oracle.com>
	<F72E509E-51E2-456C-A2D1-BA5A7D9F2091@oracle.com>
	<a97b7396-c1c1-910c-583a-cac3cf5b71f5@oracle.com>
	<2085c1ef-8699-8604-11ae-4fef3b1d1778@gmail.com>
Message-ID: <b41af12c-4ee2-8c19-f50e-63ca40aa8139@oracle.com>

+1

With Peter's proposed changes if I'm not mistaken then all methods
that operate on the CacheKey (findBundle, findBundleInCache, 
putBundleInCache, loadBundle, loadBundleFromProvider) are all
called from a point originating from within the block now protected
by the reachability fences, so there should be no opportunity for the
referents of our KeyElementReference to become null while the
CacheKey is used.

Thanks Peter!

-- daniel

On 17/01/17 11:53, Peter Levart wrote:
> Hi Naoto,
>
> Sorry for joining late for review. Thanks for taking this on. I think it
> is shaping well...
>
> On 01/14/2017 01:54 AM, Naoto Sato wrote:
>>
>>
>> http://cr.openjdk.java.net/~naoto/8171139/webrev.05/
>>
>
> Tho things...
>
> 1. As said, the "cloning" of CacheKey has no purpose in the following
> section of code (lines 1685...1709):
>
>             CacheKey constKey = new CacheKey(cacheKey);
>             trace("findBundle: %d %s %s formats: %s%n", index,
> candidateLocales, cacheKey, formats);
>             try {
>                 if (module.isNamed()) {
>                     bundle = loadBundle(cacheKey, formats, control,
> module, callerModule);
>                 } else {
>                     bundle = loadBundle(cacheKey, formats, control,
> expiredBundle);
>                 }
>                 if (bundle != null) {
>                     if (bundle.parent == null) {
>                         bundle.setParent(parent);
>                     }
>                     bundle.locale = targetLocale;
>                     bundle = putBundleInCache(cacheKey, bundle, control);
>                     return bundle;
>                 }
>
>                 // Put NONEXISTENT_BUNDLE in the cache as a mark that
> there's no bundle
>                 // instance for the locale.
>                 putBundleInCache(cacheKey, NONEXISTENT_BUNDLE, control);
>             } finally {
>                 if (constKey.getCause() instanceof InterruptedException) {
>                     Thread.currentThread().interrupt();
>                 }
>             }
>
> The 'constKey' is copied of the 'cacheKey' and is not used anywhere
> except in finally block where it is asked for .getCause() which will
> always be null since copying of CacheKey never copies the cause...
>
> 2. We can make sure that CacheKey copy constructor always copies a
> CacheKey that has non-cleared moduleRef and callerRef. The original
> cacheKey is created in getBundleImpl() from nun-null module and
> callerModule.  getBundleImpl() then calls down to findModule() with this
> cacheKey. If we keep a reference to module and callerModule in
> getBundleImpl() alive until the end of this method, we guarantee that
> moduleRef and callerRef will not be cleared while using such cacheKey to
> construct copies of it.
>
> Here's those two changes applied to your webrev.05 and also a race in
> clearCacheImpl() fixed (as reported by Daniel Fuchs):
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.06/
>
>
> What do you think?
>
> Regards, Peter
>


From peter.levart at gmail.com  Tue Jan 17 14:10:35 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 17 Jan 2017 15:10:35 +0100
Subject: RFR: 8029019: (ann) Optimize annotation handling in core reflection
Message-ID: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>

Hi,

This is a preview of a patch that addresses the following issue:

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

But it is also an attempt to clean-up failure reporting for invalid 
annotation types. Here's the 1st webrev:

http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/webrev.01/

With this patch applied, running the following benchmark:

http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/AnnotationsBench.java

Produces the following results:

Original:

Benchmark                                 Mode  Cnt Score     Error  Units
AnnotationsBench.a1_PrimitiveMember       avgt   10 20.790 ?   1.317  ns/op
AnnotationsBench.a2_ObjectMember          avgt   10 21.550 ?   0.580  ns/op
AnnotationsBench.a3_PrimitiveArrayMember  avgt   10 28.314 ?   1.477  ns/op
AnnotationsBench.a4_ObjectArrayMember     avgt   10 27.094 ?   0.574  ns/op
AnnotationsBench.a5_AnnotationType        avgt   10 13.047 ?   0.983  ns/op
AnnotationsBench.a6_HashCode              avgt   10 158.001 ?   9.347  ns/op
AnnotationsBench.a7_Equals                avgt   10 663.921 ?  27.256  ns/op
AnnotationsBench.a8_ToString              avgt   10 1772.901 ? 107.355  
ns/op

Patched:

Benchmark                                 Mode  Cnt Score    Error  Units
AnnotationsBench.a1_PrimitiveMember       avgt   10 8.547 ?  0.100  ns/op
AnnotationsBench.a2_ObjectMember          avgt   10 8.352 ?  0.340  ns/op
AnnotationsBench.a3_PrimitiveArrayMember  avgt   10 17.526 ?  0.696  ns/op
AnnotationsBench.a4_ObjectArrayMember     avgt   10 15.639 ?  0.116  ns/op
AnnotationsBench.a5_AnnotationType        avgt   10 4.692 ?  0.154  ns/op
AnnotationsBench.a6_HashCode              avgt   10 142.954 ?  7.460  ns/op
AnnotationsBench.a7_Equals                avgt   10 184.535 ?  0.917  ns/op
AnnotationsBench.a8_ToString              avgt   10 1806.685 ? 96.370  ns/op


Allocation rates are also reduced:

Original:

AnnotationsBench.a1_PrimitiveMember:?gc.alloc.rate.norm avgt   10    
16.000 ?   0.001    B/op
AnnotationsBench.a2_ObjectMember:?gc.alloc.rate.norm avgt   10    16.000 
?   0.001    B/op
AnnotationsBench.a3_PrimitiveArrayMember:?gc.alloc.rate.norm avgt   
10    64.000 ?   0.001    B/op
AnnotationsBench.a4_ObjectArrayMember:?gc.alloc.rate.norm avgt   10    
48.000 ?   0.001    B/op
AnnotationsBench.a5_AnnotationType:?gc.alloc.rate.norm avgt   10    
16.000 ?   0.001    B/op
AnnotationsBench.a6_HashCode:?gc.alloc.rate.norm avgt   10   128.000 ?   
0.001    B/op
AnnotationsBench.a7_Equals:?gc.alloc.rate.norm avgt   10   120.001 ?   
0.001    B/op
AnnotationsBench.a8_ToString:?gc.alloc.rate.norm avgt   10  5200.002 ?   
0.001    B/op

Patched:

AnnotationsBench.a1_PrimitiveMember:?gc.alloc.rate.norm avgt   10    ? 
10??              B/op
AnnotationsBench.a2_ObjectMember:?gc.alloc.rate.norm avgt   10    ? 
10??              B/op
AnnotationsBench.a3_PrimitiveArrayMember:?gc.alloc.rate.norm avgt   
10    48.000 ?   0.001    B/op
AnnotationsBench.a4_ObjectArrayMember:?gc.alloc.rate.norm avgt   10    
32.000 ?   0.001    B/op
AnnotationsBench.a5_AnnotationType:?gc.alloc.rate.norm avgt   10    ? 
10??              B/op
AnnotationsBench.a6_HashCode:?gc.alloc.rate.norm avgt   10    64.000 ?   
0.001    B/op
AnnotationsBench.a7_Equals:?gc.alloc.rate.norm avgt   10    24.000 ?   
0.001    B/op
AnnotationsBench.a8_ToString:?gc.alloc.rate.norm avgt   10  5136.002 ?   
0.001    B/op


As for the failure reporting: requesting an annotation for invalid 
annotation type now always produces AnnotationFormatError. Previously, 
some invalid annotations were simply skipped, some produced 
AnnotationFormatError and for some of them, AnnotationFormatError was 
raised only when evaluating Annotation's equals() method.

I would like to discuss this failure behavior more in-depth.

Regards, Peter


From Roger.Riggs at Oracle.com  Tue Jan 17 15:12:35 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 17 Jan 2017 10:12:35 -0500
Subject: Fixing Object.hashCode documentation
In-Reply-To: <447fbc83-78fd-313c-caeb-daf4a0617ff0@yawk.at>
References: <447fbc83-78fd-313c-caeb-daf4a0617ff0@yawk.at>
Message-ID: <ff21aa27-2e59-3a37-8cff-ce5c634890eb@Oracle.com>

Hi,

I would close 6321873.  Informatively, it is already linked as related 
to 8071434.

System.identityHashCode is specified as using the same value as the 
default Object.hashCode
and not say anything to weaken the statements aboutr uniqueness.

Other suggestions?

$.02, Roger

On 1/15/2017 4:37 PM, Jonas Konrad wrote:
> Hi,
>
> https://bugs.openjdk.java.net/browse/JDK-6321873 has been idle since 
> 2005. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/458adf31ad5b changed 
> the wording somewhat (though I still don't think it's explicit enough 
> in that OpenJDK does *not* use the address). Could you further improve 
> the wording, or if you believe it is sufficient, close the jira bug?
>
> Thank you,
> - Jonas Konrad


From andrey.x.nazarov at oracle.com  Tue Jan 17 15:33:39 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Tue, 17 Jan 2017 18:33:39 +0300
Subject: RFR: 8071566 Improve testing for multi-version JAR file maker tool
In-Reply-To: <47195B93-30EA-41B0-AEDE-C88111979003@oracle.com>
References: <12CA06E6-0BCE-4A10-90CD-4968ED1B6FC5@oracle.com>
	<47195B93-30EA-41B0-AEDE-C88111979003@oracle.com>
Message-ID: <70FCCDED-63A6-4890-9126-C138AC3E7E6A@oracle.com>

Thanks for review. I?ve update patch http://cr.openjdk.java.net/~anazarov/8071566/webrev.01/

?Andrey
> On 3 Jan 2017, at 14:25, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> Andrey,
> 
>> On 30 Dec 2016, at 14:11, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
>> 
>> Hi,
>> 
>> Following tests for Jar tool were added:
>> 
>> Tests for API validator. Jar tool should detect API changes between releases. 
>> Test for custom manifest file. 
>> Test for version format in --release option 
>> 
>> Also refactoring of existing tests was made:
>> 1. Common base class ?MRTestBase.java? was extracted. 
>> 2. Result and process builders were substituted by existing library classes jdk/test/lib/process/*
>> 
>> Please review.
>> 
>> Review: http://cr.openjdk.java.net/~anazarov/8071566/webrev.00/
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8071566 <https://bugs.openjdk.java.net/browse/JDK-8071566>
> 
> I think the changes are generally ok. A few comments:
> 
> 1) The webrev shows ApiValidatorTest.java  (was test/tools/jar/multiRelease/Basic.java).
>    I assume ApiValidatorTest.java is just a new file, and not Basic.java copied.
>    These files should have no relationship in mercurial.
> 
> 2) Style. The existing style is a little confused to me.
>    Please check line length, <= 80 chars where possible
>    Align dots ( fluid method invocations ) where possible
>    Align method arguments where possible, and makes sense
> 
> 3) Where deleting files/directories, please use FileUtils from the test library.
> 
> -Chris.


From claes.redestad at oracle.com  Tue Jan 17 16:06:47 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 17 Jan 2017 17:06:47 +0100
Subject: RFR: 8172905: Minor startup cleanup of CallSite and MethodType
Message-ID: <52bb2304-e04f-0a99-8169-6b53240b9c13@oracle.com>

Hi,

as a follow-up to JDK-8086045, further analysis has found a number of 
small, simple improvements that can be made to further improve startup 
characteristics of typical usage of java.lang.invoke:

- CallSite::<clinit> looks up two MethodHandles that aren't used in many 
typical applications and should be lazily constructed
- CallSite.CONTEXT_OFFSET is calculated but never used
- The ConcurrentHashMap in MethodType$ConcurrentWeakInternSet is resized 
multiple times even for relatively trivial tests, and initializing it to 
a larger size is footprint neutral but beneficial to startup to many 
applications

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

This small set of relatively non-intrusive changes has a measurable 
impact to startup - generates fewer classes on some tests, does less 
work on all - which partially help with a number of startup regressions 
tracked in 9 due to heavier and earlier use of j.l.invoke.

Thanks!

/Claes

From naoto.sato at oracle.com  Tue Jan 17 18:23:08 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 17 Jan 2017 10:23:08 -0800
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <b41af12c-4ee2-8c19-f50e-63ca40aa8139@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
	<4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
	<af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
	<30D742E8-4C2C-4A0A-8147-154C4775C5C0@oracle.com>
	<49e94b11-4491-6c33-2afe-76c23066f5af@oracle.com>
	<F72E509E-51E2-456C-A2D1-BA5A7D9F2091@oracle.com>
	<a97b7396-c1c1-910c-583a-cac3cf5b71f5@oracle.com>
	<2085c1ef-8699-8604-11ae-4fef3b1d1778@gmail.com>
	<b41af12c-4ee2-8c19-f50e-63ca40aa8139@oracle.com>
Message-ID: <bfc5b8eb-6dd3-3d2d-9b67-90ec36a04dd2@oracle.com>

Thanks, Peter & Daniel.

I modified the webrevs accordingly:

http://cr.openjdk.java.net/~naoto/8171139/webrev.06/
http://cr.openjdk.java.net/~naoto/8171140/webrev.01/

The one for 8171139 is the same as Peter's latest one, and the latter 
one for 8171140 was modified following that change.

Naoto

On 1/17/17 4:24 AM, Daniel Fuchs wrote:
> +1
>
> With Peter's proposed changes if I'm not mistaken then all methods
> that operate on the CacheKey (findBundle, findBundleInCache,
> putBundleInCache, loadBundle, loadBundleFromProvider) are all
> called from a point originating from within the block now protected
> by the reachability fences, so there should be no opportunity for the
> referents of our KeyElementReference to become null while the
> CacheKey is used.
>
> Thanks Peter!
>
> -- daniel
>
> On 17/01/17 11:53, Peter Levart wrote:
>> Hi Naoto,
>>
>> Sorry for joining late for review. Thanks for taking this on. I think it
>> is shaping well...
>>
>> On 01/14/2017 01:54 AM, Naoto Sato wrote:
>>>
>>>
>>> http://cr.openjdk.java.net/~naoto/8171139/webrev.05/
>>>
>>
>> Tho things...
>>
>> 1. As said, the "cloning" of CacheKey has no purpose in the following
>> section of code (lines 1685...1709):
>>
>>             CacheKey constKey = new CacheKey(cacheKey);
>>             trace("findBundle: %d %s %s formats: %s%n", index,
>> candidateLocales, cacheKey, formats);
>>             try {
>>                 if (module.isNamed()) {
>>                     bundle = loadBundle(cacheKey, formats, control,
>> module, callerModule);
>>                 } else {
>>                     bundle = loadBundle(cacheKey, formats, control,
>> expiredBundle);
>>                 }
>>                 if (bundle != null) {
>>                     if (bundle.parent == null) {
>>                         bundle.setParent(parent);
>>                     }
>>                     bundle.locale = targetLocale;
>>                     bundle = putBundleInCache(cacheKey, bundle, control);
>>                     return bundle;
>>                 }
>>
>>                 // Put NONEXISTENT_BUNDLE in the cache as a mark that
>> there's no bundle
>>                 // instance for the locale.
>>                 putBundleInCache(cacheKey, NONEXISTENT_BUNDLE, control);
>>             } finally {
>>                 if (constKey.getCause() instanceof
>> InterruptedException) {
>>                     Thread.currentThread().interrupt();
>>                 }
>>             }
>>
>> The 'constKey' is copied of the 'cacheKey' and is not used anywhere
>> except in finally block where it is asked for .getCause() which will
>> always be null since copying of CacheKey never copies the cause...
>>
>> 2. We can make sure that CacheKey copy constructor always copies a
>> CacheKey that has non-cleared moduleRef and callerRef. The original
>> cacheKey is created in getBundleImpl() from nun-null module and
>> callerModule.  getBundleImpl() then calls down to findModule() with this
>> cacheKey. If we keep a reference to module and callerModule in
>> getBundleImpl() alive until the end of this method, we guarantee that
>> moduleRef and callerRef will not be cleared while using such cacheKey to
>> construct copies of it.
>>
>> Here's those two changes applied to your webrev.05 and also a race in
>> clearCacheImpl() fixed (as reported by Daniel Fuchs):
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.06/
>>
>>
>>
>> What do you think?
>>
>> Regards, Peter
>>
>

From daniel.fuchs at oracle.com  Tue Jan 17 18:39:08 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 17 Jan 2017 18:39:08 +0000
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <bfc5b8eb-6dd3-3d2d-9b67-90ec36a04dd2@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
	<4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
	<af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
	<30D742E8-4C2C-4A0A-8147-154C4775C5C0@oracle.com>
	<49e94b11-4491-6c33-2afe-76c23066f5af@oracle.com>
	<F72E509E-51E2-456C-A2D1-BA5A7D9F2091@oracle.com>
	<a97b7396-c1c1-910c-583a-cac3cf5b71f5@oracle.com>
	<2085c1ef-8699-8604-11ae-4fef3b1d1778@gmail.com>
	<b41af12c-4ee2-8c19-f50e-63ca40aa8139@oracle.com>
	<bfc5b8eb-6dd3-3d2d-9b67-90ec36a04dd2@oracle.com>
Message-ID: <62258c3b-3681-6bb3-2c23-164f10466d04@oracle.com>

On 17/01/17 18:23, Naoto Sato wrote:
> Thanks, Peter & Daniel.
>
> I modified the webrevs accordingly:
>
> http://cr.openjdk.java.net/~naoto/8171139/webrev.06/
> http://cr.openjdk.java.net/~naoto/8171140/webrev.01/

+1

best regards,

-- daniel

>
> The one for 8171139 is the same as Peter's latest one, and the latter
> one for 8171140 was modified following that change.
>
> Naoto
>
> On 1/17/17 4:24 AM, Daniel Fuchs wrote:
>> +1
>>
>> With Peter's proposed changes if I'm not mistaken then all methods
>> that operate on the CacheKey (findBundle, findBundleInCache,
>> putBundleInCache, loadBundle, loadBundleFromProvider) are all
>> called from a point originating from within the block now protected
>> by the reachability fences, so there should be no opportunity for the
>> referents of our KeyElementReference to become null while the
>> CacheKey is used.
>>
>> Thanks Peter!
>>
>> -- daniel
>>
>> On 17/01/17 11:53, Peter Levart wrote:
>>> Hi Naoto,
>>>
>>> Sorry for joining late for review. Thanks for taking this on. I think it
>>> is shaping well...
>>>
>>> On 01/14/2017 01:54 AM, Naoto Sato wrote:
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8171139/webrev.05/
>>>>
>>>
>>> Tho things...
>>>
>>> 1. As said, the "cloning" of CacheKey has no purpose in the following
>>> section of code (lines 1685...1709):
>>>
>>>             CacheKey constKey = new CacheKey(cacheKey);
>>>             trace("findBundle: %d %s %s formats: %s%n", index,
>>> candidateLocales, cacheKey, formats);
>>>             try {
>>>                 if (module.isNamed()) {
>>>                     bundle = loadBundle(cacheKey, formats, control,
>>> module, callerModule);
>>>                 } else {
>>>                     bundle = loadBundle(cacheKey, formats, control,
>>> expiredBundle);
>>>                 }
>>>                 if (bundle != null) {
>>>                     if (bundle.parent == null) {
>>>                         bundle.setParent(parent);
>>>                     }
>>>                     bundle.locale = targetLocale;
>>>                     bundle = putBundleInCache(cacheKey, bundle,
>>> control);
>>>                     return bundle;
>>>                 }
>>>
>>>                 // Put NONEXISTENT_BUNDLE in the cache as a mark that
>>> there's no bundle
>>>                 // instance for the locale.
>>>                 putBundleInCache(cacheKey, NONEXISTENT_BUNDLE, control);
>>>             } finally {
>>>                 if (constKey.getCause() instanceof
>>> InterruptedException) {
>>>                     Thread.currentThread().interrupt();
>>>                 }
>>>             }
>>>
>>> The 'constKey' is copied of the 'cacheKey' and is not used anywhere
>>> except in finally block where it is asked for .getCause() which will
>>> always be null since copying of CacheKey never copies the cause...
>>>
>>> 2. We can make sure that CacheKey copy constructor always copies a
>>> CacheKey that has non-cleared moduleRef and callerRef. The original
>>> cacheKey is created in getBundleImpl() from nun-null module and
>>> callerModule.  getBundleImpl() then calls down to findModule() with this
>>> cacheKey. If we keep a reference to module and callerModule in
>>> getBundleImpl() alive until the end of this method, we guarantee that
>>> moduleRef and callerRef will not be cleared while using such cacheKey to
>>> construct copies of it.
>>>
>>> Here's those two changes applied to your webrev.05 and also a race in
>>> clearCacheImpl() fixed (as reported by Daniel Fuchs):
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.06/
>>>
>>>
>>>
>>>
>>> What do you think?
>>>
>>> Regards, Peter
>>>
>>


From christoph.dreis at freenet.de  Tue Jan 17 18:38:17 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Tue, 17 Jan 2017 19:38:17 +0100
Subject: 8029019: (ann) Optimize annotation handling in core reflection
In-Reply-To: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>
References: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>
Message-ID: <002c01d270f0$df2101f0$9d6305d0$@freenet.de>

Hi Peter,

I was very happy when I saw this on the mailing list today as I'm the one who brought this up again end of November. Thank you for taking the time! I hope you don't mind my comments on this one.

> This is a preview of a patch that addresses the following issue:
> 
>      https://bugs.openjdk.java.net/browse/JDK-8029019
> 
> But it is also an attempt to clean-up failure reporting for invalid
> annotation types. Here's the 1st webrev:
> 
> http://cr.openjdk.java.net/~plevart/jdk9-
> dev/8029019_Annotations.optimization/webrev.01/
> 
> With this patch applied, running the following benchmark:
> 
> http://cr.openjdk.java.net/~plevart/jdk9-
> dev/8029019_Annotations.optimization/AnnotationsBench.java
> 
> Produces the following results:
> 
> Original:
> 
> Benchmark                                 Mode  Cnt Score     Error  Units
> AnnotationsBench.a1_PrimitiveMember       avgt   10 20.790 ?   1.317  ns/op
> AnnotationsBench.a2_ObjectMember          avgt   10 21.550 ?   0.580  ns/op
> AnnotationsBench.a3_PrimitiveArrayMember  avgt   10 28.314 ?   1.477 ns/op
> AnnotationsBench.a4_ObjectArrayMember     avgt   10 27.094 ?   0.574  ns/op
> AnnotationsBench.a5_AnnotationType        avgt   10 13.047 ?   0.983  ns/op
> AnnotationsBench.a6_HashCode              avgt   10 158.001 ?   9.347  ns/op
> AnnotationsBench.a7_Equals                avgt   10 663.921 ?  27.256  ns/op
> AnnotationsBench.a8_ToString              avgt   10 1772.901 ? 107.355 ns/op
> 
> Patched:
> 
> Benchmark                                 Mode  Cnt Score    Error  Units
> AnnotationsBench.a1_PrimitiveMember       avgt   10 8.547 ?  0.100  ns/op
> AnnotationsBench.a2_ObjectMember          avgt   10 8.352 ?  0.340  ns/op
> AnnotationsBench.a3_PrimitiveArrayMember  avgt   10 17.526 ?  0.696  ns/op
> AnnotationsBench.a4_ObjectArrayMember     avgt   10 15.639 ?  0.116  ns/op
> AnnotationsBench.a5_AnnotationType        avgt   10 4.692 ?  0.154  ns/op
> AnnotationsBench.a6_HashCode              avgt   10 142.954 ?  7.460  ns/op
> AnnotationsBench.a7_Equals                avgt   10 184.535 ?  0.917  ns/op
> AnnotationsBench.a8_ToString              avgt   10 1806.685 ? 96.370  ns/op
>

Nice results! As most of the garbage in my applications (and presumably other Spring applications) comes from calling annotationType() and the unnecessary cloning of parameter types, I wonder why the patched version doesn't have a larger impact on toString() (or hashCode()) as well. toString() seems to be even slightly slower. Any ideas here?

Regardless, I found a possible improvement for toString() in case it needs to convert Class members (around L274-283 in the patch). Instead of creating a StringBuilder for the array brackets only we could use the instance to build up the whole string instead of (presumably) creating another one at the end.

==== PATCH  =====
    private static String toSourceString(Class<?> clazz) {
        Class<?> finalComponent = clazz;
        StringBuilder sb = new StringBuilder();

        while(finalComponent.isArray()) {
            finalComponent = finalComponent.getComponentType();
            sb.append("[]");
        }

        sb.insert(0, finalComponent.getName());
        sb.append(".class");

        return sb.toString();
    }
 
> 
> 
> As for the failure reporting: requesting an annotation for invalid
> annotation type now always produces AnnotationFormatError. Previously,
> some invalid annotations were simply skipped, some produced
> AnnotationFormatError and for some of them, AnnotationFormatError was
> raised only when evaluating Annotation's equals() method.
> 
> I would like to discuss this failure behavior more in-depth.

As I'm fairly new to the OpenJDK project, I can't say too much (of value) about possible implications of this change, but for consistency reasons I like this very much. Though my gut feeling tells me that this might be too big of a (behaviour) change that might prevent the other optimizations from coming in. At least that's my current fear as one of the guys that is actually heavily affected by the performance bug since JDK 8.   

Cheers,
Christoph 


From mandy.chung at oracle.com  Tue Jan 17 19:58:48 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 17 Jan 2017 11:58:48 -0800
Subject: [9] RFR: 8171139: Simplify ResourceBundle.CacheKey and
	ClassLoader may not be needed
In-Reply-To: <bfc5b8eb-6dd3-3d2d-9b67-90ec36a04dd2@oracle.com>
References: <8A8A4346-A026-4A94-92EF-66600B68F179@oracle.com>
	<01c46dde-806e-eae6-30aa-1de5002af291@oracle.com>
	<4feb0ef2-2987-c282-61cc-a8c351c0af9b@oracle.com>
	<af59ef7f-d748-4896-a549-526b84c7f7fa@oracle.com>
	<30D742E8-4C2C-4A0A-8147-154C4775C5C0@oracle.com>
	<49e94b11-4491-6c33-2afe-76c23066f5af@oracle.com>
	<F72E509E-51E2-456C-A2D1-BA5A7D9F2091@oracle.com>
	<a97b7396-c1c1-910c-583a-cac3cf5b71f5@oracle.com>
	<2085c1ef-8699-8604-11ae-4fef3b1d1778@gmail.com>
	<b41af12c-4ee2-8c19-f50e-63ca40aa8139@oracle.com>
	<bfc5b8eb-6dd3-3d2d-9b67-90ec36a04dd2@oracle.com>
Message-ID: <E18EB2D2-0EB4-4F3B-94B5-F6DF7648429B@oracle.com>

+1

I?m happy with the new reachabilityFence calls.

Mandy

> On Jan 17, 2017, at 10:23 AM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Thanks, Peter & Daniel.
> 
> I modified the webrevs accordingly:
> 
> http://cr.openjdk.java.net/~naoto/8171139/webrev.06/
> http://cr.openjdk.java.net/~naoto/8171140/webrev.01/
> 
> The one for 8171139 is the same as Peter's latest one, and the latter one for 8171140 was modified following that change.
> 
> Naoto
> 
> On 1/17/17 4:24 AM, Daniel Fuchs wrote:
>> +1
>> 
>> With Peter's proposed changes if I'm not mistaken then all methods
>> that operate on the CacheKey (findBundle, findBundleInCache,
>> putBundleInCache, loadBundle, loadBundleFromProvider) are all
>> called from a point originating from within the block now protected
>> by the reachability fences, so there should be no opportunity for the
>> referents of our KeyElementReference to become null while the
>> CacheKey is used.
>> 
>> Thanks Peter!
>> 
>> -- daniel
>> 
>> On 17/01/17 11:53, Peter Levart wrote:
>>> Hi Naoto,
>>> 
>>> Sorry for joining late for review. Thanks for taking this on. I think it
>>> is shaping well...
>>> 
>>> On 01/14/2017 01:54 AM, Naoto Sato wrote:
>>>> 
>>>> 
>>>> http://cr.openjdk.java.net/~naoto/8171139/webrev.05/
>>>> 
>>> 
>>> Tho things...
>>> 
>>> 1. As said, the "cloning" of CacheKey has no purpose in the following
>>> section of code (lines 1685...1709):
>>> 
>>>            CacheKey constKey = new CacheKey(cacheKey);
>>>            trace("findBundle: %d %s %s formats: %s%n", index,
>>> candidateLocales, cacheKey, formats);
>>>            try {
>>>                if (module.isNamed()) {
>>>                    bundle = loadBundle(cacheKey, formats, control,
>>> module, callerModule);
>>>                } else {
>>>                    bundle = loadBundle(cacheKey, formats, control,
>>> expiredBundle);
>>>                }
>>>                if (bundle != null) {
>>>                    if (bundle.parent == null) {
>>>                        bundle.setParent(parent);
>>>                    }
>>>                    bundle.locale = targetLocale;
>>>                    bundle = putBundleInCache(cacheKey, bundle, control);
>>>                    return bundle;
>>>                }
>>> 
>>>                // Put NONEXISTENT_BUNDLE in the cache as a mark that
>>> there's no bundle
>>>                // instance for the locale.
>>>                putBundleInCache(cacheKey, NONEXISTENT_BUNDLE, control);
>>>            } finally {
>>>                if (constKey.getCause() instanceof
>>> InterruptedException) {
>>>                    Thread.currentThread().interrupt();
>>>                }
>>>            }
>>> 
>>> The 'constKey' is copied of the 'cacheKey' and is not used anywhere
>>> except in finally block where it is asked for .getCause() which will
>>> always be null since copying of CacheKey never copies the cause...
>>> 
>>> 2. We can make sure that CacheKey copy constructor always copies a
>>> CacheKey that has non-cleared moduleRef and callerRef. The original
>>> cacheKey is created in getBundleImpl() from nun-null module and
>>> callerModule.  getBundleImpl() then calls down to findModule() with this
>>> cacheKey. If we keep a reference to module and callerModule in
>>> getBundleImpl() alive until the end of this method, we guarantee that
>>> moduleRef and callerRef will not be cleared while using such cacheKey to
>>> construct copies of it.
>>> 
>>> Here's those two changes applied to your webrev.05 and also a race in
>>> clearCacheImpl() fixed (as reported by Daniel Fuchs):
>>> 
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.06/
>>> 
>>> 
>>> 
>>> What do you think?
>>> 
>>> Regards, Peter
>>> 
>> 


From xueming.shen at oracle.com  Tue Jan 17 22:39:13 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 17 Jan 2017 14:39:13 -0800
Subject: RFR JDK-8172921: Zip filesystem performance improvement and code
	cleanup
Message-ID: <587E9D11.2000901@oracle.com>

Hi,

Please review the following changes for zipfs implementation.

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


javac has moved to use zipfs (instead of ZipFile) to access jar files in 
jdk9. Here are
some changes to improve the performance of access time and footprint 
(reduce the
unnecessary object allocation ...) The improvement has been measured by 
the jmh
benchmark test as

http://cr.openjdk.java.net/~sherman/8172921/MyBenchmark.java

with the benchmark sores (before-OLD/after-NEW) at:

http://cr.openjdk.java.net/~sherman/8172921/scores


The main change is to change the internal directory path representation 
from the
zip specific format (directory name ends with "/", "/dir/" for directory 
".dir" for
example) to the "normalized" form with the tailing "/", which reduces 
the back and
forth  conversion between the normal "unix style" path and the "zip 
style" path when
doing path creation, path lookup and entry access, which also simplified 
the entry
lookup logic.

We are seeing pretty good performance improvement.

There is another change, which involves the API change, for the 
"non-existing" path
look up (which shows pretty bad numbers as ZFS_ExistsNG"), is not 
included in this
patch. I hope we can address that as well in jdk9, but probably in 
another patch.

Thanks,
Sherman



From claes.redestad at oracle.com  Tue Jan 17 23:24:31 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 18 Jan 2017 00:24:31 +0100
Subject: RFR JDK-8172921: Zip filesystem performance improvement and code
	cleanup
In-Reply-To: <587E9D11.2000901@oracle.com>
References: <587E9D11.2000901@oracle.com>
Message-ID: <5cc580f1-cd0c-94fb-d671-7001847a7b30@oracle.com>

Hi Sherman,

thanks for doing this!

Looks good - I stumbled on the ZipPath::getResolved changes at first,
but they seem sound and I can see how the previous test was likely to
unnecessarily create a new byte[] on most regular files.

Nits:
Code formatting seems unintentionally messed up in places, especially
ZipCoder.java.

ZipCoder$UTF8 has a chunk of commented out code that should likely be
removed.

/Claes

On 2017-01-17 23:39, Xueming Shen wrote:
> Hi,
>
> Please review the following changes for zipfs implementation.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8172921
> webrev: http://cr.openjdk.java.net/~sherman/8172921/webrev/
>
>
> javac has moved to use zipfs (instead of ZipFile) to access jar files in
> jdk9. Here are
> some changes to improve the performance of access time and footprint
> (reduce the
> unnecessary object allocation ...) The improvement has been measured by
> the jmh
> benchmark test as
>
> http://cr.openjdk.java.net/~sherman/8172921/MyBenchmark.java
>
> with the benchmark sores (before-OLD/after-NEW) at:
>
> http://cr.openjdk.java.net/~sherman/8172921/scores
>
>
> The main change is to change the internal directory path representation
> from the
> zip specific format (directory name ends with "/", "/dir/" for directory
> ".dir" for
> example) to the "normalized" form with the tailing "/", which reduces
> the back and
> forth  conversion between the normal "unix style" path and the "zip
> style" path when
> doing path creation, path lookup and entry access, which also simplified
> the entry
> lookup logic.
>
> We are seeing pretty good performance improvement.
>
> There is another change, which involves the API change, for the
> "non-existing" path
> look up (which shows pretty bad numbers as ZFS_ExistsNG"), is not
> included in this
> patch. I hope we can address that as well in jdk9, but probably in
> another patch.
>
> Thanks,
> Sherman
>
>

From xueming.shen at oracle.com  Tue Jan 17 23:56:12 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 17 Jan 2017 15:56:12 -0800
Subject: RFR JDK-8172921: Zip filesystem performance improvement and code
	cleanup
In-Reply-To: <5cc580f1-cd0c-94fb-d671-7001847a7b30@oracle.com>
References: <587E9D11.2000901@oracle.com>
	<5cc580f1-cd0c-94fb-d671-7001847a7b30@oracle.com>
Message-ID: <587EAF1C.6090002@oracle.com>

On 1/17/17, 3:24 PM, Claes Redestad wrote:
>
> Looks good - I stumbled on the ZipPath::getResolved changes at first,
> but they seem sound and I can see how the previous test was likely to
> unnecessarily create a new byte[] on most regular files.
It's a little hacky to only go into resolve0 for "." or ".." with a 
tailing "/"
to avoid a single ".", such in Foo.class, to trigger the expensive 
resolve0().

>
> Nits:
> Code formatting seems unintentionally messed up in places, especially
> ZipCoder.java.

ran the normalizer on the source code.
>
> ZipCoder$UTF8 has a chunk of commented out code that should likely be
> removed.
>
removed

thanks,
Sherman

From paul.sandoz at oracle.com  Wed Jan 18 01:36:56 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 17 Jan 2017 17:36:56 -0800
Subject: JDK 9 RFR of JDK-8146668: Replace custom check/range
	functionality with check index/range methods in java.util.Objects
In-Reply-To: <eeea98c6-0d3a-6830-dea3-d32d436aa8fc@oracle.com>
References: <de138c68-e8e5-ba3b-6e2b-603b8fc49329@oracle.com>
	<44FFB565-3075-49C5-9069-08189E13BE7B@oracle.com>
	<eeea98c6-0d3a-6830-dea3-d32d436aa8fc@oracle.com>
Message-ID: <1E6DCA27-11FF-49CF-BEDF-B2E79B82F023@oracle.com>

Hi Amy,

RangeCheckMicroBenchmark.java measures access for ArrayList. Did you update ArrayList? (i don?t see it in your current patch).

Paul.

> On 16 Jan 2017, at 01:41, Amy Lu <amy.lu at oracle.com> wrote:
> 
> Thank you Paul and Martin for your review.
> 
> On 1/13/17 12:52 AM, Paul Sandoz wrote:
>> HI Amy,
>> 
>> Overall this looks very good, well done.
>> 
>> 
>> At this point we are down to two things:
>> 
>> 1) should we preserve exception messages?
>> 
>> 2) due diligence on the performance.
>> 
>> 
>> On 1) my preference is that uniform (and informative) messages are better for IndexOutOfBounds and subtypes, and defining that in addition to the checks in one place is very valuable. In some sense that does change some behavioural compatibility and i think because of that pushing in 10 (when the repos) open with a CCC would be more preferable.
> Got it. Will wait for 10.
>> 
>> On 2) this is a valuable exercise to perform (either using an existing test and/or writing JMH benchmarks). I don?t expect any major problems. Care was taken to ensure the uncommon exception processing path will optimize away for the common case. The BiFunction parameter passed as the last argument is always a constant, so should fold away from the hot path.
> 
> Tested with java/util/ArrayList/RangeCheckMicroBenchmark.java and java/nio/Buffer/SwapMicroBenchmark.java, no performance regression observed.
> 
> java/util/ArrayList/RangeCheckMicroBenchmark.java
> 
> without 8146668
> --------------------
> get                             26          1
> set                             40.6        1.5707
> get/set                         85.7        3.3002
> add/remove at end               337.5       12.9197
> subList get                     25          0.9747
> subList set                     59.9        2.3
> subList get/set                 92.2        3.5414
> subList add/remove at end       429.8       16.45
> 
> with 8146668
> --------------------
> get                             26          1
> set                             39.1        1.5188
> get/set                         86.8        3.3363
> add/remove at end               335.5       12.8549
> subList get                     24.8        0.9715
> subList set                     59.2        2.2728
> subList get/set                 92.2        3.5473
> subList add/remove at end       427.7       16.3789
> 
> java/nio/Buffer/SwapMicroBenchmark.java
> 
> without 8146668
> --------------------
> swap char LITTLE_ENDIAN         11          1
> swap short LITTLE_ENDIAN        10.2        0.9895
> swap int LITTLE_ENDIAN          5           0.4961
> swap long LITTLE_ENDIAN         3           0.3345
> 
> with 8146668
> --------------------
> swap char LITTLE_ENDIAN         10.1        1
> swap short LITTLE_ENDIAN        10.1        0.9995
> swap int LITTLE_ENDIAN          5           0.5005
> swap long LITTLE_ENDIAN         3           0.3327
> 
> Thanks,
> Amy
>> 
>> Paul.
>> 
>> 
>>> On 11 Jan 2017, at 18:10, Amy Lu <amy.lu at oracle.com> wrote:
>>> 
>>> 8135248 and 8155794 introduced utility methods for checking indexes and ranges. Existing code with custom checkIndex/checkRange can be updated to use these methods. Please review the patch for this purpose:
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146668
>>> webrev: http://cr.openjdk.java.net/~amlu/8146668/webrev.01
>>> 
>>> The type of exception thrown are preserved. Custom checkIndex/checkRange functions that throw IOOBE are now using ?check? utility methods provided by java.lang.Objects (which also throws IOOBE), functions that throw other exceptions use jdk.internal.util.Preconditions to preserve exception types, with the help of new BiFunction vars.
>>> 
>>> I'd like to get this in JDK 9 if it's not too late, otherwise, JDK 10.
>>> 
>>> Thanks,
>>> Amy
> 


From paul.sandoz at oracle.com  Wed Jan 18 01:48:53 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 17 Jan 2017 17:48:53 -0800
Subject: RFR: 8172905: Minor startup cleanup of CallSite and MethodType
In-Reply-To: <52bb2304-e04f-0a99-8169-6b53240b9c13@oracle.com>
References: <52bb2304-e04f-0a99-8169-6b53240b9c13@oracle.com>
Message-ID: <8E0F1FA4-A231-4912-8F4C-AE47A9114FFE@oracle.com>


> On 17 Jan 2017, at 08:06, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Hi,
> 
> as a follow-up to JDK-8086045, further analysis has found a number of small, simple improvements that can be made to further improve startup characteristics of typical usage of java.lang.invoke:
> 
> - CallSite::<clinit> looks up two MethodHandles that aren't used in many typical applications and should be lazily constructed
> - CallSite.CONTEXT_OFFSET is calculated but never used
> - The ConcurrentHashMap in MethodType$ConcurrentWeakInternSet is resized multiple times even for relatively trivial tests, and initializing it to a larger size is footprint neutral but beneficial to startup to many applications
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8172905
> Webrev: http://cr.openjdk.java.net/~redestad/8172905/webrev.01/
> 
> This small set of relatively non-intrusive changes has a measurable impact to startup - generates fewer classes on some tests, does less work on all - which partially help with a number of startup regressions tracked in 9 due to heavier and earlier use of j.l.invoke.
> 

Look ok.

It?s either place the static finals in separate nested classes, or use @Stable on non-final statics with lazy initialization in methods (with the possibility of multiple invocations when concurrently executing). Nested classes seems fine here.

Paul.

From joe.darcy at oracle.com  Wed Jan 18 02:13:00 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 17 Jan 2017 18:13:00 -0800
Subject: Guaranteed order of annotations?
In-Reply-To: <CADGJaX8HfFX7Q2YK-_tpcf6xdMTzrrasAtVbBgGSss8e_uWz3A@mail.gmail.com>
References: <CADGJaX8xu+6XbjxU8G7no31KA17WW9P6hjgh-vvC0Ezg7qgTMg@mail.gmail.com>	<ABC6F6B1F6CA734A9B233369A3750F1531093392@MBX021-W3-CA-4.exch021.domain.local>
	<CADGJaX8HfFX7Q2YK-_tpcf6xdMTzrrasAtVbBgGSss8e_uWz3A@mail.gmail.com>
Message-ID: <587ECF2C.6000505@oracle.com>

Hello,

Following up on Joel's message, IIRC this ordering issue did come up 
during the design and testing of repeating annotations.

As noted previously in the thread, while the ordering of the annotations 
in a container annotation is guaranteed, there is *not* a general 
ordering constraint on the annotations returned by the methods of the 
AnnotatedElement interface.

HTH,

-Joe

On 1/13/2017 1:16 PM, Gunnar Morling wrote:
> Hi Yuri,
>
> Thanks for the pointer.
>
> But do you see any clear description of an order mandated for
> getDeclaredAnnotations()? The only references to an order I can find
> there are for repeatable annotations (where source code order is
> maintained when retrieving them via the container annotation type).
> But I cannot find any guaranteed order when obtaining all declared
> annotations from an element.
>
> The reason why I'm asking is Bean Validation, where we've seen
> requests of people that wish to validate the constraints of an element
> in a fixed order, aborting after the first failed constraint:
>
>      @NotNull
>      @Email
>      String email;
>
> Here one may want to first validate @NotNull and don't proceed with
> validating @Email if the field is null.
>
> Relying on source order would be a very natural way to express the
> order of constraints. Without a guaranteed ordering of annotations
> we'd have to add some other means of ordering, e.g. an attribute with
> the index (@NotNull(order=0) @Email(order=1)) which is more verbose of
> course.
>
> --Gunnar
>
>
>
>
>
> 2017-01-13 21:15 GMT+01:00 Yuri Gaevsky <ygaevsky at azulsystems.com>:
>> Hi Gunnar,
>>
>> Please take a look at JDK-8010679 'Clarify "present" and annotation ordering in Core Reflection for Annotations' [*].
>>
>> Best regards,
>> -Yuri
>>
>> [*] https://bugs.openjdk.java.net/browse/JDK-8010679
>>
>>
>> -----Original Message-----
>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Gunnar Morling
>> Sent: Friday, January 13, 2017 08:14 PM
>> To: core-libs-dev at openjdk.java.net
>> Subject: Guaranteed order of annotations?
>>
>> Hi,
>>
>> Is there any order guaranteed in which an element's annotations are
>> returned by AnnotatedElement#getDeclaredAnnotations()? Specifically,
>> is this the order in which the annotations are given in the source
>> code?
>>
>> Section 9.7.5. of the JLS ("Multiple Annotations of the Same Type")
>> makes a statement of the source order being considered by the array of
>> the implicit container annotation created for a repeatable annotation
>> ("[...] all the base annotations in the left-to-right order in which
>> they appeared in the context").
>>
>> But I couldn't find any authoritative description on the ordering
>> behaviour of getDeclaredAnnotations(). Should we assume that we cannot
>> rely on the order in the source?
>>
>> Thanks for any pointers,
>>
>> --Gunnar


From joe.darcy at oracle.com  Wed Jan 18 02:50:42 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 17 Jan 2017 18:50:42 -0800
Subject: Fixing Object.hashCode documentation
In-Reply-To: <ff21aa27-2e59-3a37-8cff-ce5c634890eb@Oracle.com>
References: <447fbc83-78fd-313c-caeb-daf4a0617ff0@yawk.at>
	<ff21aa27-2e59-3a37-8cff-ce5c634890eb@Oracle.com>
Message-ID: <587ED802.5050909@oracle.com>

Hello,

I just closed out JDK-6321873 adding the comment:

> Much of this contents of this issue was addressed by JDK-8071434; 
> JDK-8172928 has been filed to add additional doc linkages between 
> System.identityHashCode and Object.hashCode. 

-Joe

On 1/17/2017 7:12 AM, Roger Riggs wrote:
> Hi,
>
> I would close 6321873.  Informatively, it is already linked as related 
> to 8071434.
>
> System.identityHashCode is specified as using the same value as the 
> default Object.hashCode
> and not say anything to weaken the statements aboutr uniqueness.
>
> Other suggestions?
>
> $.02, Roger
>
> On 1/15/2017 4:37 PM, Jonas Konrad wrote:
>> Hi,
>>
>> https://bugs.openjdk.java.net/browse/JDK-6321873 has been idle since 
>> 2005. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/458adf31ad5b 
>> changed the wording somewhat (though I still don't think it's 
>> explicit enough in that OpenJDK does *not* use the address). Could 
>> you further improve the wording, or if you believe it is sufficient, 
>> close the jira bug?
>>
>> Thank you,
>> - Jonas Konrad
>


From john.r.rose at oracle.com  Wed Jan 18 03:38:29 2017
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 17 Jan 2017 19:38:29 -0800
Subject: RFR: 8172905: Minor startup cleanup of CallSite and MethodType
In-Reply-To: <8E0F1FA4-A231-4912-8F4C-AE47A9114FFE@oracle.com>
References: <52bb2304-e04f-0a99-8169-6b53240b9c13@oracle.com>
	<8E0F1FA4-A231-4912-8F4C-AE47A9114FFE@oracle.com>
Message-ID: <21422C6B-136A-441A-B8CD-34F94EBEB510@oracle.com>

Using a stable field will consume less meta-space than a nested class, all other things being equal. 

? John

> On Jan 17, 2017, at 5:48 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> It?s either place the static finals in separate nested classes, or use @Stable on non-final statics with lazy initialization in methods (with the possibility of multiple invocations when concurrently executing). Nested classes seems fine here.


From mandy.chung at oracle.com  Wed Jan 18 03:53:19 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 17 Jan 2017 19:53:19 -0800
Subject: RFR: 8172886: Add a test that shows how the LogManager can be
	implemented by a module
In-Reply-To: <ef078150-769b-a74f-c8b3-9255d9f1f03e@oracle.com>
References: <ef078150-769b-a74f-c8b3-9255d9f1f03e@oracle.com>
Message-ID: <198506DF-EA05-4862-AC94-93C1F78A1A3B@oracle.com>


> On Jan 17, 2017, at 3:45 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a patch that adds a test that verifies that
> LogManager, Handlers, and config classes can be implemented
> from within a module (provided they are exported to java.logging).
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8172886
> webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8172886/webrev.00/
> 

This looks good.  Thanks for adding this and also can be used as an example of custom LogManager in a named module.

Mandy

From gunnar at hibernate.org  Wed Jan 18 07:26:31 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 18 Jan 2017 08:26:31 +0100
Subject: Guaranteed order of annotations?
In-Reply-To: <587ECF2C.6000505@oracle.com>
References: <CADGJaX8xu+6XbjxU8G7no31KA17WW9P6hjgh-vvC0Ezg7qgTMg@mail.gmail.com>
	<ABC6F6B1F6CA734A9B233369A3750F1531093392@MBX021-W3-CA-4.exch021.domain.local>
	<CADGJaX8HfFX7Q2YK-_tpcf6xdMTzrrasAtVbBgGSss8e_uWz3A@mail.gmail.com>
	<587ECF2C.6000505@oracle.com>
Message-ID: <CADGJaX9-_KTwNcVYnp7dGN0fbj09FeBLCV3AZWn4jeXZBFA56A@mail.gmail.com>

Joseph, all,

Thanks for the clarification.

Are there chances to establish such guaranteed ordering in a future
Java version? As pointed out, it'd be very helpful to Bean Validation
and I reckon other cases, too.

Thanks,

--Gunnar



2017-01-18 3:13 GMT+01:00 Joseph D. Darcy <joe.darcy at oracle.com>:
> Hello,
>
> Following up on Joel's message, IIRC this ordering issue did come up during
> the design and testing of repeating annotations.
>
> As noted previously in the thread, while the ordering of the annotations in
> a container annotation is guaranteed, there is *not* a general ordering
> constraint on the annotations returned by the methods of the
> AnnotatedElement interface.
>
> HTH,
>
> -Joe
>
>
> On 1/13/2017 1:16 PM, Gunnar Morling wrote:
>>
>> Hi Yuri,
>>
>> Thanks for the pointer.
>>
>> But do you see any clear description of an order mandated for
>> getDeclaredAnnotations()? The only references to an order I can find
>> there are for repeatable annotations (where source code order is
>> maintained when retrieving them via the container annotation type).
>> But I cannot find any guaranteed order when obtaining all declared
>> annotations from an element.
>>
>> The reason why I'm asking is Bean Validation, where we've seen
>> requests of people that wish to validate the constraints of an element
>> in a fixed order, aborting after the first failed constraint:
>>
>>      @NotNull
>>      @Email
>>      String email;
>>
>> Here one may want to first validate @NotNull and don't proceed with
>> validating @Email if the field is null.
>>
>> Relying on source order would be a very natural way to express the
>> order of constraints. Without a guaranteed ordering of annotations
>> we'd have to add some other means of ordering, e.g. an attribute with
>> the index (@NotNull(order=0) @Email(order=1)) which is more verbose of
>> course.
>>
>> --Gunnar
>>
>>
>>
>>
>>
>> 2017-01-13 21:15 GMT+01:00 Yuri Gaevsky <ygaevsky at azulsystems.com>:
>>>
>>> Hi Gunnar,
>>>
>>> Please take a look at JDK-8010679 'Clarify "present" and annotation
>>> ordering in Core Reflection for Annotations' [*].
>>>
>>> Best regards,
>>> -Yuri
>>>
>>> [*] https://bugs.openjdk.java.net/browse/JDK-8010679
>>>
>>>
>>> -----Original Message-----
>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
>>> Behalf Of Gunnar Morling
>>> Sent: Friday, January 13, 2017 08:14 PM
>>> To: core-libs-dev at openjdk.java.net
>>> Subject: Guaranteed order of annotations?
>>>
>>> Hi,
>>>
>>> Is there any order guaranteed in which an element's annotations are
>>> returned by AnnotatedElement#getDeclaredAnnotations()? Specifically,
>>> is this the order in which the annotations are given in the source
>>> code?
>>>
>>> Section 9.7.5. of the JLS ("Multiple Annotations of the Same Type")
>>> makes a statement of the source order being considered by the array of
>>> the implicit container annotation created for a repeatable annotation
>>> ("[...] all the base annotations in the left-to-right order in which
>>> they appeared in the context").
>>>
>>> But I couldn't find any authoritative description on the ordering
>>> behaviour of getDeclaredAnnotations(). Should we assume that we cannot
>>> rely on the order in the source?
>>>
>>> Thanks for any pointers,
>>>
>>> --Gunnar
>
>

From andrej.golovnin at gmail.com  Wed Jan 18 07:56:27 2017
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Wed, 18 Jan 2017 08:56:27 +0100
Subject: RFR JDK-8172921: Zip filesystem performance improvement and code
	cleanup
In-Reply-To: <587E9D11.2000901@oracle.com>
References: <587E9D11.2000901@oracle.com>
Message-ID: <CAM6ZMz_bEOBENTkcvzFic0gjihZ7eLbpjzSKoj9wSOFYxF_xfA@mail.gmail.com>

Hi Sherman,

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipCoder.java

  72     public static ZipCoder get(String csn) {
  73         try {
  74         Charset cs = Charset.forName(csn);
  75         if (cs.name().equals("UTF-8")) {
  76             return utf8;
  77         }
  78         return new ZipCoder(cs);
  79         } catch (Throwable t) {
  80         t.printStackTrace();
  81         }
  82         return new ZipCoder(Charset.defaultCharset());
  83     }

Wouldn't it be better to use System.Logger instead of printStackTrace
in the line 80?

Best regards,
Andrej Golovnin

On Tue, Jan 17, 2017 at 11:39 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> Hi,
>
> Please review the following changes for zipfs implementation.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8172921
> webrev: http://cr.openjdk.java.net/~sherman/8172921/webrev/
>
>
> javac has moved to use zipfs (instead of ZipFile) to access jar files in
> jdk9. Here are
> some changes to improve the performance of access time and footprint (reduce
> the
> unnecessary object allocation ...) The improvement has been measured by the
> jmh
> benchmark test as
>
> http://cr.openjdk.java.net/~sherman/8172921/MyBenchmark.java
>
> with the benchmark sores (before-OLD/after-NEW) at:
>
> http://cr.openjdk.java.net/~sherman/8172921/scores
>
>
> The main change is to change the internal directory path representation from
> the
> zip specific format (directory name ends with "/", "/dir/" for directory
> ".dir" for
> example) to the "normalized" form with the tailing "/", which reduces the
> back and
> forth  conversion between the normal "unix style" path and the "zip style"
> path when
> doing path creation, path lookup and entry access, which also simplified the
> entry
> lookup logic.
>
> We are seeing pretty good performance improvement.
>
> There is another change, which involves the API change, for the
> "non-existing" path
> look up (which shows pretty bad numbers as ZFS_ExistsNG"), is not included
> in this
> patch. I hope we can address that as well in jdk9, but probably in another
> patch.
>
> Thanks,
> Sherman
>
>

From claes.redestad at oracle.com  Wed Jan 18 11:01:16 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 18 Jan 2017 12:01:16 +0100
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
	reflection
In-Reply-To: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>
References: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>
Message-ID: <3a42ee8d-8c05-2f11-7ab1-2e020fac322d@oracle.com>

Hi Peter,

On 01/17/2017 03:10 PM, Peter Levart wrote:
>
> As for the failure reporting: requesting an annotation for invalid 
> annotation type now always produces AnnotationFormatError. Previously, 
> some invalid annotations were simply skipped, some produced 
> AnnotationFormatError and for some of them, AnnotationFormatError was 
> raised only when evaluating Annotation's equals() method.
>
> I would like to discuss this failure behavior more in-depth.

I don't have an example, but if there are applications that have invalid
annotations which are currently ignored completely or until someone
calls equals on them, this behavior change could result in some
application breaking in unexpected ways.

Although this change might be well-intended and align implementation
better with specified intent, I fear this kind this behavior change 
might be
too late for 9 (maybe even for later releases), and think it'd be easier to
accept a patch that took great care not to change observable behavior
and discuss this separately.

Thanks!

/Claes


>
> Regards, Peter 


From claes.redestad at oracle.com  Wed Jan 18 13:40:08 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 18 Jan 2017 14:40:08 +0100
Subject: RFR: 8172905: Minor startup cleanup of CallSite and MethodType
In-Reply-To: <21422C6B-136A-441A-B8CD-34F94EBEB510@oracle.com>
References: <52bb2304-e04f-0a99-8169-6b53240b9c13@oracle.com>
	<8E0F1FA4-A231-4912-8F4C-AE47A9114FFE@oracle.com>
	<21422C6B-136A-441A-B8CD-34F94EBEB510@oracle.com>
Message-ID: <3a87aee9-e23e-6cb2-1ed2-2e5194ea4e73@oracle.com>

Using Stable we could also make the lookup of TARGET_OFFSET lazy:

http://cr.openjdk.java.net/~redestad/8172905/webrev.02/

/Claes

On 01/18/2017 04:38 AM, John Rose wrote:
> Using a stable field will consume less meta-space than a nested class, all other things being equal.
>
> ? John
>
>> On Jan 17, 2017, at 5:48 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>
>> It?s either place the static finals in separate nested classes, or use @Stable on non-final statics with lazy initialization in methods (with the possibility of multiple invocations when concurrently executing). Nested classes seems fine here.


From chris.hegarty at oracle.com  Wed Jan 18 14:59:32 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 18 Jan 2017 14:59:32 +0000
Subject: RFR: 8071566 Improve testing for multi-version JAR file maker tool
In-Reply-To: <70FCCDED-63A6-4890-9126-C138AC3E7E6A@oracle.com>
References: <12CA06E6-0BCE-4A10-90CD-4968ED1B6FC5@oracle.com>
	<47195B93-30EA-41B0-AEDE-C88111979003@oracle.com>
	<70FCCDED-63A6-4890-9126-C138AC3E7E6A@oracle.com>
Message-ID: <6D8F1534-6082-4149-9257-EDA583F7FF13@oracle.com>


> On 17 Jan 2017, at 15:33, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
> 
> Thanks for review. I?ve update patch http://cr.openjdk.java.net/~anazarov/8071566/webrev.01/

I think this is ok.

-Chris.

> 
> ?Andrey
>> On 3 Jan 2017, at 14:25, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> Andrey,
>> 
>>> On 30 Dec 2016, at 14:11, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Following tests for Jar tool were added:
>>> 
>>> Tests for API validator. Jar tool should detect API changes between releases. 
>>> Test for custom manifest file. 
>>> Test for version format in --release option 
>>> 
>>> Also refactoring of existing tests was made:
>>> 1. Common base class ?MRTestBase.java? was extracted. 
>>> 2. Result and process builders were substituted by existing library classes jdk/test/lib/process/*
>>> 
>>> Please review.
>>> 
>>> Review: http://cr.openjdk.java.net/~anazarov/8071566/webrev.00/
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8071566 <https://bugs.openjdk.java.net/browse/JDK-8071566>
>> 
>> I think the changes are generally ok. A few comments:
>> 
>> 1) The webrev shows ApiValidatorTest.java  (was test/tools/jar/multiRelease/Basic.java).
>>    I assume ApiValidatorTest.java is just a new file, and not Basic.java copied.
>>    These files should have no relationship in mercurial.
>> 
>> 2) Style. The existing style is a little confused to me.
>>    Please check line length, <= 80 chars where possible
>>    Align dots ( fluid method invocations ) where possible
>>    Align method arguments where possible, and makes sense
>> 
>> 3) Where deleting files/directories, please use FileUtils from the test library.
>> 
>> -Chris.
> 


From andrey.x.nazarov at oracle.com  Wed Jan 18 16:18:24 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Wed, 18 Jan 2017 19:18:24 +0300
Subject: RFR: 8071566 Improve testing for multi-version JAR file maker tool
In-Reply-To: <6D8F1534-6082-4149-9257-EDA583F7FF13@oracle.com>
References: <12CA06E6-0BCE-4A10-90CD-4968ED1B6FC5@oracle.com>
	<47195B93-30EA-41B0-AEDE-C88111979003@oracle.com>
	<70FCCDED-63A6-4890-9126-C138AC3E7E6A@oracle.com>
	<6D8F1534-6082-4149-9257-EDA583F7FF13@oracle.com>
Message-ID: <8242EB54-C048-48B2-B182-D6B5E80E3557@oracle.com>


> On 18 Jan 2017, at 17:59, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> 
>> On 17 Jan 2017, at 15:33, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
>> 
>> Thanks for review. I?ve update patch http://cr.openjdk.java.net/~anazarov/8071566/webrev.01/
> 
> I think this is ok.
Thanks
> 
> -Chris.
> 
>> 
>> ?Andrey
>>> On 3 Jan 2017, at 14:25, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>> 
>>> Andrey,
>>> 
>>>> On 30 Dec 2016, at 14:11, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Following tests for Jar tool were added:
>>>> 
>>>> Tests for API validator. Jar tool should detect API changes between releases. 
>>>> Test for custom manifest file. 
>>>> Test for version format in --release option 
>>>> 
>>>> Also refactoring of existing tests was made:
>>>> 1. Common base class ?MRTestBase.java? was extracted. 
>>>> 2. Result and process builders were substituted by existing library classes jdk/test/lib/process/*
>>>> 
>>>> Please review.
>>>> 
>>>> Review: http://cr.openjdk.java.net/~anazarov/8071566/webrev.00/
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8071566 <https://bugs.openjdk.java.net/browse/JDK-8071566>
>>> 
>>> I think the changes are generally ok. A few comments:
>>> 
>>> 1) The webrev shows ApiValidatorTest.java  (was test/tools/jar/multiRelease/Basic.java).
>>>   I assume ApiValidatorTest.java is just a new file, and not Basic.java copied.
>>>   These files should have no relationship in mercurial.
>>> 
>>> 2) Style. The existing style is a little confused to me.
>>>   Please check line length, <= 80 chars where possible
>>>   Align dots ( fluid method invocations ) where possible
>>>   Align method arguments where possible, and makes sense
>>> 
>>> 3) Where deleting files/directories, please use FileUtils from the test library.
>>> 
>>> -Chris.
>> 
> 


From christoph.langer at sap.com  Wed Jan 18 16:26:59 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 18 Jan 2017 16:26:59 +0000
Subject: RFR 8172974 [JAXP] XALAN: Wrong result when transforming namespace
	unaware StAX Input
Message-ID: <3d09fd8790484d538b2b864baea214f8@derote13de46.global.corp.sap>

Hi,

please review a change for JAXP.

Bug: https://bugs.openjdk.java.net/browse/JDK-8172974
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/

When enhancing the test for https://bugs.openjdk.java.net/browse/JDK-8023653, I saw that there's still an issue with StAXInputSource which is not namespace aware. This needs a small update in  src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.java. Furthermore, I added the fixed warnings and formattings from the proposal http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ to this webrev, as 8023653 is an enhancement and might not go in in the near future.

I also enhanced the TransformerTest to utilize data providers now and test a comprehensive matrix of XALAN input.

Thanks in advance and Best regards
Christoph


From christoph.langer at sap.com  Wed Jan 18 16:44:11 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 18 Jan 2017 16:44:11 +0000
Subject: RFR: 8023653: xalan inconsistently parses DOMSource and StreamSource
In-Reply-To: <582FA19A.3050305@oracle.com>
References: <fb08dbf848dc454283c4ea96e91276b1@DEWDFE13DE03.global.corp.sap>
	<582E8E30.2030209@oracle.com> <582FA19A.3050305@oracle.com>
Message-ID: <326055b238884072b2c0c0a0cdb127fc@derote13de46.global.corp.sap>

Hi,

I have created a new webrev for this enhancement:
http://cr.openjdk.java.net/~clanger/webrevs/8023653.1/

As it bases on the change proposal for the new bug 8172974 [1], it is much smaller and really only contains the modifications needed for honoring the feature "namespace-aware" on TransformerFactory.

As to your comments, Joe: I can't just use JdkXmlUtils.setXMLReaderPropertyIfSupport, as this one is a feature. So I added a JdkXmlUtils.setXMLReaderFeatureIfSupport. Is that what you want?

The test was already improved in the webrev for 8172974 [2], I just add two more scenarios for StreamSources on Transformers with "namespace-aware == false".

I would certainly also need help from someone in Oracle to run me through the ccc process, as this probably is a behavioral change for TransformerFactory.

Thanks & Best regards
Christoph

[1] https://bugs.openjdk.java.net/browse/JDK-8172974
[2] http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/



> -----Original Message-----
> From: Joe Wang [mailto:huizhe.wang at oracle.com]
> Sent: Samstag, 19. November 2016 01:50
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 8023653: xalan inconsistently parses DOMSource and
> StreamSource
> 
> Hi Christoph,
> 
> XMLReaderManager, 175 - 186 can be replace with:
>          JdkXmlUtils.setXMLReaderPropertyIfSupport(reader,
> NAMESPACES_FEATURE, m_NamespaceAware, false);
>          JdkXmlUtils.setXMLReaderPropertyIfSupport(reader,
> NAMESPACE_PREFIXES_FEATURE, !m_NamespaceAware, false);
> 
> 
> The new test can be improved:
>      Test all 4 source types
>      Use a dataprovider (with data fields: Source, Transformer or
> NamespaceAware, Expected String, etc)
>      Test also Templates to verify the namespace feature is propagated
> properly
> 
> Thanks,
> Joe
> 
> On 11/17/16, 9:14 PM, Joe Wang wrote:
> > Together with 8169631, I think we need to understand your customer's
> > requirement before spending time on a change that would otherwise be
> > unnecesary. Why would turning off namespace-aware help him? As far as
> > the xml standards and parser/processor are concerned, it's a backward
> > development. A namespace-aware parser is compatible with the ones that
> > don't know about namespaces. The norm then is to always turn it on
> > (although the API had to default to off because of the legacy). Is the
> > user processing some legacy xml code?
> >
> > Thanks,
> > Joe
> >
> > On 11/16/16, 5:41 AM, Langer, Christoph wrote:
> >> Hi,
> >>
> >> to address the long standing bug 8023653 I propose the following change:
> >>
> >> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/
> >> bug: https://bugs.openjdk.java.net/browse/JDK-8023653
> >>
> >> I think the bug report in general complains that the default for
> >> DOMSource input is to parse the input "namespace-unaware" whereas, if
> >> XALAN gets a StreamSource as input, it is parsed "namespace-aware".
> >>
> >> Generally I'm against changing either of these defaults (at this time
> >> at least) - XALAN StreamSource should be handled namespace aware and
> >> changing the default for DocumentBuilderFactory is maybe an option
> >> for the Java 10 timeframe, I'd  say. However, at the moment it is not
> >> possible at all to configure XALAN's handling of StreamSource input
> >> to be namespace unaware. That's what I'd like to address with my
> >> change. With my modifications it's possible to set the namespace
> >> feature on the TransformerFactory (to false). It bases on my other
> >> open fix 8169631 which is discussed here:
> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-
> November/044662.html
> >> Only with the corrections for that fix, the SAX parsing that is used
> >> for stream sources will be handled correctly.
> >>
> >> The proposed change from the bugreport (change options for the parser
> >> of the XSL input before compilation) would not help with the reported
> >> issue and also is not a good idea anyway as xsl input needs to be
> >> handled with namespaces obviously.
> >>
> >> I did other cleanups in my change as well, the real functional
> >> changes are in TransformerFactoryImpl.java, XSLTCDTMManager.java and
> >> XMLReaderManager.java.
> >>
> >> Thanks in advance for reviewing.
> >>
> >> Best regards
> >> Christoph
> >>

From aploese at gmx.de  Tue Jan 17 20:07:11 2017
From: aploese at gmx.de (Arne Ploese)
Date: Tue, 17 Jan 2017 21:07:11 +0100
Subject: java.time.Instant.toString() nanosecond bug
Message-ID: <1484683631.6417.2.camel@gmx.de>

Hi,

I'm runnig 

openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-3-b14)
OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)

and I encounter the following bug.

TestCase:

????@Test
????public void testNanos() {
????????DateTimeFormatter formatter =
DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.nnnnnnX");
????????Instant instant = Instant.ofEpochSecond(0, 123400);
????????assertEquals(0, instant.getEpochSecond());
????????assertEquals(123400, instant.getNano());
????????assertEquals("1970-01-01T00:00:00.123400Z",
formatter.format(ZonedDateTime.ofInstant(instant, ZoneId.of("Z"))));
????????assertEquals("1970-01-01T00:00:00.123400Z",
instant.toString());
????}
????
The test fails on the last assertEquals with:

org.junit.ComparisonFailure: expected:<1970-01-01T00:00:00.[]123400Z>
but was:<1970-01-01T00:00:00.[000]123400Z>

the nanos getting three leading zeros.

Arne Pl?se

From sebastian.bathke at gmail.com  Wed Jan 18 17:11:41 2017
From: sebastian.bathke at gmail.com (Sebastian Bathke)
Date: Wed, 18 Jan 2017 17:11:41 +0000
Subject: JDK-7132728: is a patch welcome?
Message-ID: <CAEUOGzOxeEjDmPNy8rsKDxC5yoLTOtv=twxD_AsrfgXefDtYMQ@mail.gmail.com>

Hi,

I hope this is the correct mailing list for this imageIO issue.

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

I found several workarounds for this by patched ImageReaders but would
rather see it get fixed in the JDK.
I wonder whether a path addressing the issue would be welcome as ?

Regards
Sebastian

From Roger.Riggs at Oracle.com  Wed Jan 18 18:24:10 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 18 Jan 2017 13:24:10 -0500
Subject: java.time.Instant.toString() nanosecond bug
In-Reply-To: <1484683631.6417.2.camel@gmx.de>
References: <1484683631.6417.2.camel@gmx.de>
Message-ID: <abb573f6-944e-a4a8-a76e-8e87d2c176cd@Oracle.com>

Hi Arne,

The arguments to Instant.ofEpochSecond[1] are seconds and nanoseconds.
So 123400 nanoseconds is more clearly written as 000_123_400.

Regards, Roger


[1] 
http://download.java.net/java/jdk9/docs/api/java/time/Instant.html#ofEpochSecond-long-long-

On 1/17/2017 3:07 PM, Arne Ploese wrote:
> Hi,
>
> I'm runnig
>
> openjdk version "1.8.0_111"
> OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-3-b14)
> OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)
>
> and I encounter the following bug.
>
> TestCase:
>
>      @Test
>      public void testNanos() {
>          DateTimeFormatter formatter =
> DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.nnnnnnX");
>          Instant instant = Instant.ofEpochSecond(0, 123400);
>          assertEquals(0, instant.getEpochSecond());
>          assertEquals(123400, instant.getNano());
>          assertEquals("1970-01-01T00:00:00.123400Z",
> formatter.format(ZonedDateTime.ofInstant(instant, ZoneId.of("Z"))));
>          assertEquals("1970-01-01T00:00:00.123400Z",
> instant.toString());
>      }
>      
> The test fails on the last assertEquals with:
>
> org.junit.ComparisonFailure: expected:<1970-01-01T00:00:00.[]123400Z>
> but was:<1970-01-01T00:00:00.[000]123400Z>
>
> the nanos getting three leading zeros.
>
> Arne Pl?se


From brian.burkhalter at oracle.com  Wed Jan 18 18:34:18 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 18 Jan 2017 10:34:18 -0800
Subject: JDK-7132728: is a patch welcome?
In-Reply-To: <CAEUOGzOxeEjDmPNy8rsKDxC5yoLTOtv=twxD_AsrfgXefDtYMQ@mail.gmail.com>
References: <CAEUOGzOxeEjDmPNy8rsKDxC5yoLTOtv=twxD_AsrfgXefDtYMQ@mail.gmail.com>
Message-ID: <F187899C-1A1D-4E9D-B113-48E57414C103@oracle.com>

Hello Sebastian,

CCing the 2d-dev mailing list which is the apt forum for this topic.

Patches are most welcome but need to be contributed according to the protocol delineated in [1].

Regards,

Brian

[1] http://openjdk.java.net/contribute/

On Jan 18, 2017, at 9:11 AM, Sebastian Bathke <sebastian.bathke at gmail.com> wrote:

> Hi,
> 
> I hope this is the correct mailing list for this imageIO issue.
> 
> https://bugs.openjdk.java.net/browse/JDK-7132728
> 
> I found several workarounds for this by patched ImageReaders but would
> rather see it get fixed in the JDK.
> I wonder whether a path addressing the issue would be welcome as ?
> 
> Regards
> Sebastian


From xueming.shen at oracle.com  Wed Jan 18 18:43:10 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 18 Jan 2017 10:43:10 -0800
Subject: RFR JDK-8172921: Zip filesystem performance improvement and code
	cleanup
In-Reply-To: <CAM6ZMz_bEOBENTkcvzFic0gjihZ7eLbpjzSKoj9wSOFYxF_xfA@mail.gmail.com>
References: <587E9D11.2000901@oracle.com>
	<CAM6ZMz_bEOBENTkcvzFic0gjihZ7eLbpjzSKoj9wSOFYxF_xfA@mail.gmail.com>
Message-ID: <587FB73E.6060302@oracle.com>

Hi Andrej,

Thanks for the review.

I was debating with myself if it's really a good idea to "silently" go with the
default charset in case the specified charset can not be obtained. Given the
charset name is passed via the env map, it might be better to simply let the
runtime exception  get thrown to communicate to the caller that the encoding
property is wrong.

The webrev has been updated accordingly.

Sherman

On 01/17/2017 11:56 PM, Andrej Golovnin wrote:
> Hi Sherman,
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipCoder.java
>
>    72     public static ZipCoder get(String csn) {
>    73         try {
>    74         Charset cs = Charset.forName(csn);
>    75         if (cs.name().equals("UTF-8")) {
>    76             return utf8;
>    77         }
>    78         return new ZipCoder(cs);
>    79         } catch (Throwable t) {
>    80         t.printStackTrace();
>    81         }
>    82         return new ZipCoder(Charset.defaultCharset());
>    83     }
>
> Wouldn't it be better to use System.Logger instead of printStackTrace
> in the line 80?
>
> Best regards,
> Andrej Golovnin
>
> On Tue, Jan 17, 2017 at 11:39 PM, Xueming Shen<xueming.shen at oracle.com>  wrote:
>> Hi,
>>
>> Please review the following changes for zipfs implementation.
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8172921
>> webrev: http://cr.openjdk.java.net/~sherman/8172921/webrev/
>>
>>
>> javac has moved to use zipfs (instead of ZipFile) to access jar files in
>> jdk9. Here are
>> some changes to improve the performance of access time and footprint (reduce
>> the
>> unnecessary object allocation ...) The improvement has been measured by the
>> jmh
>> benchmark test as
>>
>> http://cr.openjdk.java.net/~sherman/8172921/MyBenchmark.java
>>
>> with the benchmark sores (before-OLD/after-NEW) at:
>>
>> http://cr.openjdk.java.net/~sherman/8172921/scores
>>
>>
>> The main change is to change the internal directory path representation from
>> the
>> zip specific format (directory name ends with "/", "/dir/" for directory
>> ".dir" for
>> example) to the "normalized" form with the tailing "/", which reduces the
>> back and
>> forth  conversion between the normal "unix style" path and the "zip style"
>> path when
>> doing path creation, path lookup and entry access, which also simplified the
>> entry
>> lookup logic.
>>
>> We are seeing pretty good performance improvement.
>>
>> There is another change, which involves the API change, for the
>> "non-existing" path
>> look up (which shows pretty bad numbers as ZFS_ExistsNG"), is not included
>> in this
>> patch. I hope we can address that as well in jdk9, but probably in another
>> patch.
>>
>> Thanks,
>> Sherman
>>
>>


From paul.sandoz at oracle.com  Wed Jan 18 18:57:52 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 18 Jan 2017 10:57:52 -0800
Subject: RFR: 8172905: Minor startup cleanup of CallSite and MethodType
In-Reply-To: <3a87aee9-e23e-6cb2-1ed2-2e5194ea4e73@oracle.com>
References: <52bb2304-e04f-0a99-8169-6b53240b9c13@oracle.com>
	<8E0F1FA4-A231-4912-8F4C-AE47A9114FFE@oracle.com>
	<21422C6B-136A-441A-B8CD-34F94EBEB510@oracle.com>
	<3a87aee9-e23e-6cb2-1ed2-2e5194ea4e73@oracle.com>
Message-ID: <ED9CD003-DC59-4590-B481-BC707736A046@oracle.com>


> On 18 Jan 2017, at 05:40, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Using Stable we could also make the lookup of TARGET_OFFSET lazy:
> 
> http://cr.openjdk.java.net/~redestad/8172905/webrev.02/
> 

+1

You are definitely on a mission to shame off every spare micro-second :-)

Paul.

> /Claes
> 
> On 01/18/2017 04:38 AM, John Rose wrote:
>> Using a stable field will consume less meta-space than a nested class, all other things being equal.
>> 
>> ? John
>> 
>>> On Jan 17, 2017, at 5:48 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>> 
>>> It?s either place the static finals in separate nested classes, or use @Stable on non-final statics with lazy initialization in methods (with the possibility of multiple invocations when concurrently executing). Nested classes seems fine here.
> 


From claes.redestad at oracle.com  Wed Jan 18 20:01:46 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 18 Jan 2017 21:01:46 +0100
Subject: RFR: 8172905: Minor startup cleanup of CallSite and MethodType
In-Reply-To: <ED9CD003-DC59-4590-B481-BC707736A046@oracle.com>
References: <52bb2304-e04f-0a99-8169-6b53240b9c13@oracle.com>
	<8E0F1FA4-A231-4912-8F4C-AE47A9114FFE@oracle.com>
	<21422C6B-136A-441A-B8CD-34F94EBEB510@oracle.com>
	<3a87aee9-e23e-6cb2-1ed2-2e5194ea4e73@oracle.com>
	<ED9CD003-DC59-4590-B481-BC707736A046@oracle.com>
Message-ID: <d55d376e-523e-6cda-8c0c-0ce6434b9233@oracle.com>



On 2017-01-18 19:57, Paul Sandoz wrote:
>
>> On 18 Jan 2017, at 05:40, Claes Redestad <claes.redestad at oracle.com> wrote:
>>
>> Using Stable we could also make the lookup of TARGET_OFFSET lazy:
>>
>> http://cr.openjdk.java.net/~redestad/8172905/webrev.02/
>>
>
> +1

Thanks!

>
> You are definitely on a mission to shame off every spare micro-second :-)

Thanks? :-)

/Claes


From paul.sandoz at oracle.com  Wed Jan 18 20:11:27 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 18 Jan 2017 12:11:27 -0800
Subject: RFR: 8172905: Minor startup cleanup of CallSite and MethodType
In-Reply-To: <d55d376e-523e-6cda-8c0c-0ce6434b9233@oracle.com>
References: <52bb2304-e04f-0a99-8169-6b53240b9c13@oracle.com>
	<8E0F1FA4-A231-4912-8F4C-AE47A9114FFE@oracle.com>
	<21422C6B-136A-441A-B8CD-34F94EBEB510@oracle.com>
	<3a87aee9-e23e-6cb2-1ed2-2e5194ea4e73@oracle.com>
	<ED9CD003-DC59-4590-B481-BC707736A046@oracle.com>
	<d55d376e-523e-6cda-8c0c-0ce6434b9233@oracle.com>
Message-ID: <3983B72D-EABD-4AFF-9CF2-34E31021F81D@oracle.com>


> On 18 Jan 2017, at 12:01, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> 
> 
> On 2017-01-18 19:57, Paul Sandoz wrote:
>> 
>>> On 18 Jan 2017, at 05:40, Claes Redestad <claes.redestad at oracle.com> wrote:
>>> 
>>> Using Stable we could also make the lookup of TARGET_OFFSET lazy:
>>> 
>>> http://cr.openjdk.java.net/~redestad/8172905/webrev.02/
>>> 
>> 
>> +1
> 
> Thanks!
> 
>> 
>> You are definitely on a mission to shame off every spare micro-second :-)
> 
> Thanks? :-)
> 

Grrr.. autocorrect fail, s/shame/shave !

Paul.

From huizhe.wang at oracle.com  Wed Jan 18 21:11:32 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 18 Jan 2017 13:11:32 -0800
Subject: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
	namespace unaware StAX Input
In-Reply-To: <3d09fd8790484d538b2b864baea214f8@derote13de46.global.corp.sap>
References: <3d09fd8790484d538b2b864baea214f8@derote13de46.global.corp.sap>
Message-ID: <b7782f18-c421-1199-8365-932028212935@oracle.com>

Hi Christoph,

Xalan requires the underlying parser to be namespace aware. Please refer 
to https://xml.apache.org/xalan-j/faq.html#faq-N10207

Thanks,
Joe

On 1/18/2017 8:26 AM, Langer, Christoph wrote:
> Hi,
>
> please review a change for JAXP.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8172974
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/
>
> When enhancing the test for https://bugs.openjdk.java.net/browse/JDK-8023653, I saw that there's still an issue with StAXInputSource which is not namespace aware. This needs a small update in  src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.java. Furthermore, I added the fixed warnings and formattings from the proposal http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ to this webrev, as 8023653 is an enhancement and might not go in in the near future.
>
> I also enhanced the TransformerTest to utilize data providers now and test a comprehensive matrix of XALAN input.
>
> Thanks in advance and Best regards
> Christoph
>


From huizhe.wang at oracle.com  Wed Jan 18 21:15:23 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 18 Jan 2017 13:15:23 -0800
Subject: RFR: 8023653: xalan inconsistently parses DOMSource and
	StreamSource
In-Reply-To: <326055b238884072b2c0c0a0cdb127fc@derote13de46.global.corp.sap>
References: <fb08dbf848dc454283c4ea96e91276b1@DEWDFE13DE03.global.corp.sap>
	<582E8E30.2030209@oracle.com> <582FA19A.3050305@oracle.com>
	<326055b238884072b2c0c0a0cdb127fc@derote13de46.global.corp.sap>
Message-ID: <3a08341a-5897-bc32-e4d1-b0956c7c4e35@oracle.com>

Hi Christoph,

Refer to the previous email, I know we discussed your customer's need to 
process legacy sources. However, Xalan inherently requires namespace 
aware. I also don't think adding a SAX feature to the Transform API is 
appropriate.

Thanks,
Joe

On 1/18/2017 8:44 AM, Langer, Christoph wrote:
> Hi,
>
> I have created a new webrev for this enhancement:
> http://cr.openjdk.java.net/~clanger/webrevs/8023653.1/
>
> As it bases on the change proposal for the new bug 8172974 [1], it is much smaller and really only contains the modifications needed for honoring the feature "namespace-aware" on TransformerFactory.
>
> As to your comments, Joe: I can't just use JdkXmlUtils.setXMLReaderPropertyIfSupport, as this one is a feature. So I added a JdkXmlUtils.setXMLReaderFeatureIfSupport. Is that what you want?
>
> The test was already improved in the webrev for 8172974 [2], I just add two more scenarios for StreamSources on Transformers with "namespace-aware == false".
>
> I would certainly also need help from someone in Oracle to run me through the ccc process, as this probably is a behavioral change for TransformerFactory.
>
> Thanks & Best regards
> Christoph
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8172974
> [2] http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/
>
>
>
>> -----Original Message-----
>> From: Joe Wang [mailto:huizhe.wang at oracle.com]
>> Sent: Samstag, 19. November 2016 01:50
>> To: Langer, Christoph <christoph.langer at sap.com>
>> Cc: core-libs-dev at openjdk.java.net
>> Subject: Re: RFR: 8023653: xalan inconsistently parses DOMSource and
>> StreamSource
>>
>> Hi Christoph,
>>
>> XMLReaderManager, 175 - 186 can be replace with:
>>           JdkXmlUtils.setXMLReaderPropertyIfSupport(reader,
>> NAMESPACES_FEATURE, m_NamespaceAware, false);
>>           JdkXmlUtils.setXMLReaderPropertyIfSupport(reader,
>> NAMESPACE_PREFIXES_FEATURE, !m_NamespaceAware, false);
>>
>>
>> The new test can be improved:
>>       Test all 4 source types
>>       Use a dataprovider (with data fields: Source, Transformer or
>> NamespaceAware, Expected String, etc)
>>       Test also Templates to verify the namespace feature is propagated
>> properly
>>
>> Thanks,
>> Joe
>>
>> On 11/17/16, 9:14 PM, Joe Wang wrote:
>>> Together with 8169631, I think we need to understand your customer's
>>> requirement before spending time on a change that would otherwise be
>>> unnecesary. Why would turning off namespace-aware help him? As far as
>>> the xml standards and parser/processor are concerned, it's a backward
>>> development. A namespace-aware parser is compatible with the ones that
>>> don't know about namespaces. The norm then is to always turn it on
>>> (although the API had to default to off because of the legacy). Is the
>>> user processing some legacy xml code?
>>>
>>> Thanks,
>>> Joe
>>>
>>> On 11/16/16, 5:41 AM, Langer, Christoph wrote:
>>>> Hi,
>>>>
>>>> to address the long standing bug 8023653 I propose the following change:
>>>>
>>>> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8023653
>>>>
>>>> I think the bug report in general complains that the default for
>>>> DOMSource input is to parse the input "namespace-unaware" whereas, if
>>>> XALAN gets a StreamSource as input, it is parsed "namespace-aware".
>>>>
>>>> Generally I'm against changing either of these defaults (at this time
>>>> at least) - XALAN StreamSource should be handled namespace aware and
>>>> changing the default for DocumentBuilderFactory is maybe an option
>>>> for the Java 10 timeframe, I'd  say. However, at the moment it is not
>>>> possible at all to configure XALAN's handling of StreamSource input
>>>> to be namespace unaware. That's what I'd like to address with my
>>>> change. With my modifications it's possible to set the namespace
>>>> feature on the TransformerFactory (to false). It bases on my other
>>>> open fix 8169631 which is discussed here:
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-
>> November/044662.html
>>>> Only with the corrections for that fix, the SAX parsing that is used
>>>> for stream sources will be handled correctly.
>>>>
>>>> The proposed change from the bugreport (change options for the parser
>>>> of the XSL input before compilation) would not help with the reported
>>>> issue and also is not a good idea anyway as xsl input needs to be
>>>> handled with namespaces obviously.
>>>>
>>>> I did other cleanups in my change as well, the real functional
>>>> changes are in TransformerFactoryImpl.java, XSLTCDTMManager.java and
>>>> XMLReaderManager.java.
>>>>
>>>> Thanks in advance for reviewing.
>>>>
>>>> Best regards
>>>> Christoph
>>>>


From andrej.golovnin at gmail.com  Wed Jan 18 21:16:25 2017
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Wed, 18 Jan 2017 22:16:25 +0100
Subject: RFR JDK-8172921: Zip filesystem performance improvement and code
	cleanup
In-Reply-To: <587FB73E.6060302@oracle.com>
References: <587E9D11.2000901@oracle.com>
	<CAM6ZMz_bEOBENTkcvzFic0gjihZ7eLbpjzSKoj9wSOFYxF_xfA@mail.gmail.com>
	<587FB73E.6060302@oracle.com>
Message-ID: <862DD833-1BD4-4305-AF9E-B4E98B2D0234@gmail.com>

Hi Sherman,

thanks for the update. It looks much better now.
One more thing:

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipCoder.java

70     private static ZipCoder utf8 = new UTF8();

I think this field can be final as it never changes.

Best regards,
Andrej Golovnin

> On 18 Jan 2017, at 19:43, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi Andrej,
> 
> Thanks for the review.
> 
> I was debating with myself if it's really a good idea to "silently" go with the
> default charset in case the specified charset can not be obtained. Given the
> charset name is passed via the env map, it might be better to simply let the
> runtime exception  get thrown to communicate to the caller that the encoding
> property is wrong.
> 
> The webrev has been updated accordingly.
> 
> Sherman
> 
> On 01/17/2017 11:56 PM, Andrej Golovnin wrote:
>> Hi Sherman,
>> 
>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipCoder.java
>> 
>>   72     public static ZipCoder get(String csn) {
>>   73         try {
>>   74         Charset cs = Charset.forName(csn);
>>   75         if (cs.name().equals("UTF-8")) {
>>   76             return utf8;
>>   77         }
>>   78         return new ZipCoder(cs);
>>   79         } catch (Throwable t) {
>>   80         t.printStackTrace();
>>   81         }
>>   82         return new ZipCoder(Charset.defaultCharset());
>>   83     }
>> 
>> Wouldn't it be better to use System.Logger instead of printStackTrace
>> in the line 80?
>> 
>> Best regards,
>> Andrej Golovnin
>> 
>> On Tue, Jan 17, 2017 at 11:39 PM, Xueming Shen<xueming.shen at oracle.com>  wrote:
>>> Hi,
>>> 
>>> Please review the following changes for zipfs implementation.
>>> 
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8172921
>>> webrev: http://cr.openjdk.java.net/~sherman/8172921/webrev/
>>> 
>>> 
>>> javac has moved to use zipfs (instead of ZipFile) to access jar files in
>>> jdk9. Here are
>>> some changes to improve the performance of access time and footprint (reduce
>>> the
>>> unnecessary object allocation ...) The improvement has been measured by the
>>> jmh
>>> benchmark test as
>>> 
>>> http://cr.openjdk.java.net/~sherman/8172921/MyBenchmark.java
>>> 
>>> with the benchmark sores (before-OLD/after-NEW) at:
>>> 
>>> http://cr.openjdk.java.net/~sherman/8172921/scores
>>> 
>>> 
>>> The main change is to change the internal directory path representation from
>>> the
>>> zip specific format (directory name ends with "/", "/dir/" for directory
>>> ".dir" for
>>> example) to the "normalized" form with the tailing "/", which reduces the
>>> back and
>>> forth  conversion between the normal "unix style" path and the "zip style"
>>> path when
>>> doing path creation, path lookup and entry access, which also simplified the
>>> entry
>>> lookup logic.
>>> 
>>> We are seeing pretty good performance improvement.
>>> 
>>> There is another change, which involves the API change, for the
>>> "non-existing" path
>>> look up (which shows pretty bad numbers as ZFS_ExistsNG"), is not included
>>> in this
>>> patch. I hope we can address that as well in jdk9, but probably in another
>>> patch.
>>> 
>>> Thanks,
>>> Sherman
>>> 
>>> 
> 


From sean.mullan at oracle.com  Wed Jan 18 21:23:10 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 18 Jan 2017 16:23:10 -0500
Subject: RFR: 8055206: Update SecurityManager::checkPackageAccess to
	restrict non-exported JDK packages by default
In-Reply-To: <F83F4FB7-AB97-47EE-969B-B96838A02010@oracle.com>
References: <ad636b2b-64f4-1923-22d5-0abd914912c8@oracle.com>
	<F83F4FB7-AB97-47EE-969B-B96838A02010@oracle.com>
Message-ID: <a966a982-ebc3-1c95-047c-fb66e5586912@oracle.com>

On 1/13/17 2:38 AM, Mandy Chung wrote:
>
>> On Jan 9, 2017, at 11:25 AM, Sean Mullan <sean.mullan at oracle.com>
>> wrote:
>>
>> Please review this JDK 9 change to make the
>> SecurityManager::checkPackageAccess and checkPackageDefinition
>> implementations restrict access to the same set of internal JDK
>> packages as the module system.
>>
>> This overall change will improve security by making these two
>> mechanisms consistent and reduce the amount of work needed to
>> maintain the package.access and package.definition security
>> properties going forward.
>>
>> JBS issue: https://bugs.openjdk.java.net/browse/JDK-8055206 JDK
>> webrev:
>> http://cr.openjdk.java.net/~mullan/webrevs/8055206/jdk/webrev.00/
>> JAXP webrev:
>> http://cr.openjdk.java.net/~mullan/webrevs/8055206/jaxp/webrev.00/
>>
>
> This looks quite good.  It?s good that the restricted package list
> for the system modules is no longer modifiable.  This change may
> impact existing applications that are running with security manager
> and uses a JDK internal API from the runtime that was not in the
> package.access list.  It may require  the application to grant
> additional ?accessClassInPackage.<pkg>? permissions in addition to
> using `?-add-exports` to break into encapsulation.

Correct.

> Similar to the feedback I suggest for JDK-8168075.  We can move this
> initialization to the holder class and trigger the initialization in
> the SecurityManager constructor.

For now, I would prefer to leave it as is. In an earlier revision, I 
experimented with delaying the initialization of nonExportedPkgs until 
checkPackageAccess was called and ran into some circular permission 
checking issues. It could be moving it to the ctor is ok, but since I 
have every test passing right now, I'd rather not tinker with it :)

>> : Several tests also had to be modified to be granted additional
>> permission(s) to access the newly restricted packages under a
>> SecurityManager. JAXP also needed a change to grant additional
>> permissions to access internal packages that are exported to the
>> modules that are dynamically created for use with XSLT.
>
> We will have to see if any dynamic generated bytecode in the field
> will need access to internal API like XSLT case.

Yes. I have checked several other use cases in the JDK that create 
dynamic modules (nashorn, rmi, jmx) and not found any issues.

> It seems something
> not right for a module that has access to an internal package in
> another module via qualified exports is required to have
> ?accessClassInPackage.<pkg>? runtime permission.  I believe the
> ?accessClassInPackage.<pkg>? permission is checked when a
> deprivileged module loads an internal class in a module defined by
> the boot loader even if the package of that internal class is
> exported to it to access.  I do think we should follow up and look
> into the potential solutions to respect the qualified exports.

I agree.

 > In addition, we should file an issue to look into any possibility to
> respect `?-add-exports` if specified (perhaps automatically add an
> entry in the default policy?).  I?m okay to follow up these with
> separate JBS issues.

Will do.

> Otherwise looks good. Mandy

Thanks,
Sean

From mandy.chung at oracle.com  Wed Jan 18 21:25:48 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 18 Jan 2017 13:25:48 -0800
Subject: RFR: 8055206: Update SecurityManager::checkPackageAccess to
	restrict non-exported JDK packages by default
In-Reply-To: <a966a982-ebc3-1c95-047c-fb66e5586912@oracle.com>
References: <ad636b2b-64f4-1923-22d5-0abd914912c8@oracle.com>
	<F83F4FB7-AB97-47EE-969B-B96838A02010@oracle.com>
	<a966a982-ebc3-1c95-047c-fb66e5586912@oracle.com>
Message-ID: <2ED35CE6-8755-4ED0-AE3B-39967060C094@oracle.com>


> On Jan 18, 2017, at 1:23 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
>> Similar to the feedback I suggest for JDK-8168075.  We can move this
>> initialization to the holder class and trigger the initialization in
>> the SecurityManager constructor.
> 
> For now, I would prefer to leave it as is. In an earlier revision, I experimented with delaying the initialization of nonExportedPkgs until checkPackageAccess was called and ran into some circular permission checking issues. It could be moving it to the ctor is ok, but since I have every test passing right now, I'd rather not tinker with it :)

Okay with me.

> 
>>> : Several tests also had to be modified to be granted additional
>>> permission(s) to access the newly restricted packages under a
>>> SecurityManager. JAXP also needed a change to grant additional
>>> permissions to access internal packages that are exported to the
>>> modules that are dynamically created for use with XSLT.
>> 
>> We will have to see if any dynamic generated bytecode in the field
>> will need access to internal API like XSLT case.
> 
> Yes. I have checked several other use cases in the JDK that create dynamic modules (nashorn, rmi, jmx) and not found any issues.

Thanks for the confirmation.
Mandy

From christoph.langer at sap.com  Wed Jan 18 21:55:03 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 18 Jan 2017 21:55:03 +0000
Subject: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
	namespace unaware StAX Input
In-Reply-To: <b7782f18-c421-1199-8365-932028212935@oracle.com>
References: <3d09fd8790484d538b2b864baea214f8@derote13de46.global.corp.sap>
	<b7782f18-c421-1199-8365-932028212935@oracle.com>
Message-ID: <a71f0d7ef4b74c079b20d601fa6d7696@derote13de46.global.corp.sap>

Hi Joe,

generally, you are right, XSLT requires namespace support. For parsing the stylesheet, it is definitely a hard requirement. Otherwise this would not make sense at all. For instance xsl directives are in the xsl namespace. That requirement is what the FAQ you are referencing [1] is talking about.

As for the InputSource which is to be processed, it is probably also not a right to use non namespace aware parsing. But still it's not forbidden. For instance, the JavaDoc for SAXSource [2] states this:
"Note that XSLT requires namespace support. Attempting to transform an input source that is not generated with a namespace-aware parser may result in errors. Parsers can be made namespace aware by calling the SAXParserFactory.setNamespaceAware(boolean awareness) method."

So, I agree, we are in the error space here. But still I think the result of non namespace aware parsing should be the same for all types of input source. And at the moment it is the same for DOMSource and SAXSource but not for StAXSource. From that point of view I think my fix makes sense (along with the other cleanups).

Best regards
Christoph
 
[1] https://xml.apache.org/xalan-j/faq.html#faq-N10207
[2] https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource.html


> -----Original Message-----
> From: huizhe wang [mailto:huizhe.wang at oracle.com]
> Sent: Mittwoch, 18. Januar 2017 22:12
> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-
> dev at openjdk.java.net
> Subject: Re: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
> namespace unaware StAX Input
> 
> Hi Christoph,
> 
> Xalan requires the underlying parser to be namespace aware. Please refer
> to https://xml.apache.org/xalan-j/faq.html#faq-N10207
> 
> Thanks,
> Joe
> 
> On 1/18/2017 8:26 AM, Langer, Christoph wrote:
> > Hi,
> >
> > please review a change for JAXP.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8172974
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/
> >
> > When enhancing the test for https://bugs.openjdk.java.net/browse/JDK-
> 8023653, I saw that there's still an issue with StAXInputSource which is not
> namespace aware. This needs a small update in
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dt
> m/SAX2DTM2.java. Furthermore, I added the fixed warnings and formattings
> from the proposal http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ to
> this webrev, as 8023653 is an enhancement and might not go in in the near
> future.
> >
> > I also enhanced the TransformerTest to utilize data providers now and test a
> comprehensive matrix of XALAN input.
> >
> > Thanks in advance and Best regards
> > Christoph
> >


From amy.lu at oracle.com  Thu Jan 19 13:11:44 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 19 Jan 2017 21:11:44 +0800
Subject: JDK 9 RFR of JDK-8146668: Replace custom check/range
	functionality with check index/range methods in java.util.Objects
In-Reply-To: <1E6DCA27-11FF-49CF-BEDF-B2E79B82F023@oracle.com>
References: <de138c68-e8e5-ba3b-6e2b-603b8fc49329@oracle.com>
	<44FFB565-3075-49C5-9069-08189E13BE7B@oracle.com>
	<eeea98c6-0d3a-6830-dea3-d32d436aa8fc@oracle.com>
	<1E6DCA27-11FF-49CF-BEDF-B2E79B82F023@oracle.com>
Message-ID: <92770fc1-b617-cd78-2f65-c008dc2d4ab4@oracle.com>

No, no change to ArrayList, sorry for the confusion. I just thought 
ArrayList/RangeCheckMicroBenchmark.java can also give some data for 
reference to the Arrays change.

So I tried a modified ArraysEquals JMH test, the test is originally for
equals(char[] a, char[] a2) and I changed it to perform
equals(char[] a, int aFromIndex, int aToIndex,
        char[] b, int bFromIndex, int bToIndex)
which is changed in this patch.

No performance regression.

without 8146668

Benchmark                                              Mode Cnt          
Score         Error  Units
ArraysEqualsFromTo.testCharArrayEqualsFalseBeginning  thrpt 200  
117773032.914 ?  837866.545  ops/s
ArraysEqualsFromTo.testCharArrayEqualsFalseEnd        thrpt 200   
68162413.018 ?  252693.599  ops/s
ArraysEqualsFromTo.testCharArrayEqualsFalseMid        thrpt 200   
87845305.867 ?  434145.358  ops/s
ArraysEqualsFromTo.testCharArrayEqualsTrue            thrpt 200   
57665790.396 ? 1144777.344  ops/s

With 8146668

Benchmark                                              Mode Cnt          
Score         Error  Units
ArraysEqualsFromTo.testCharArrayEqualsFalseBeginning  thrpt 200  
118754451.736 ?  395812.217  ops/s
ArraysEqualsFromTo.testCharArrayEqualsFalseEnd        thrpt 200   
68263418.139 ?  161477.719  ops/s
ArraysEqualsFromTo.testCharArrayEqualsFalseMid        thrpt 200   
87429210.156 ?  483026.299  ops/s
ArraysEqualsFromTo.testCharArrayEqualsTrue            thrpt 200   
57694918.966 ? 1163825.417  ops/s


Thanks,
Amy

On 1/18/17 9:36 AM, Paul Sandoz wrote:
> Hi Amy,
>
> RangeCheckMicroBenchmark.java measures access for ArrayList. Did you update ArrayList? (i don?t see it in your current patch).
>
> Paul.
>
>> On 16 Jan 2017, at 01:41, Amy Lu <amy.lu at oracle.com> wrote:
>>
>> Thank you Paul and Martin for your review.
>>
>> On 1/13/17 12:52 AM, Paul Sandoz wrote:
>>> HI Amy,
>>>
>>> Overall this looks very good, well done.
>>>
>>>
>>> At this point we are down to two things:
>>>
>>> 1) should we preserve exception messages?
>>>
>>> 2) due diligence on the performance.
>>>
>>>
>>> On 1) my preference is that uniform (and informative) messages are better for IndexOutOfBounds and subtypes, and defining that in addition to the checks in one place is very valuable. In some sense that does change some behavioural compatibility and i think because of that pushing in 10 (when the repos) open with a CCC would be more preferable.
>> Got it. Will wait for 10.
>>> On 2) this is a valuable exercise to perform (either using an existing test and/or writing JMH benchmarks). I don?t expect any major problems. Care was taken to ensure the uncommon exception processing path will optimize away for the common case. The BiFunction parameter passed as the last argument is always a constant, so should fold away from the hot path.
>> Tested with java/util/ArrayList/RangeCheckMicroBenchmark.java and java/nio/Buffer/SwapMicroBenchmark.java, no performance regression observed.
>>
>> java/util/ArrayList/RangeCheckMicroBenchmark.java
>>
>> without 8146668
>> --------------------
>> get                             26          1
>> set                             40.6        1.5707
>> get/set                         85.7        3.3002
>> add/remove at end               337.5       12.9197
>> subList get                     25          0.9747
>> subList set                     59.9        2.3
>> subList get/set                 92.2        3.5414
>> subList add/remove at end       429.8       16.45
>>
>> with 8146668
>> --------------------
>> get                             26          1
>> set                             39.1        1.5188
>> get/set                         86.8        3.3363
>> add/remove at end               335.5       12.8549
>> subList get                     24.8        0.9715
>> subList set                     59.2        2.2728
>> subList get/set                 92.2        3.5473
>> subList add/remove at end       427.7       16.3789
>>
>> java/nio/Buffer/SwapMicroBenchmark.java
>>
>> without 8146668
>> --------------------
>> swap char LITTLE_ENDIAN         11          1
>> swap short LITTLE_ENDIAN        10.2        0.9895
>> swap int LITTLE_ENDIAN          5           0.4961
>> swap long LITTLE_ENDIAN         3           0.3345
>>
>> with 8146668
>> --------------------
>> swap char LITTLE_ENDIAN         10.1        1
>> swap short LITTLE_ENDIAN        10.1        0.9995
>> swap int LITTLE_ENDIAN          5           0.5005
>> swap long LITTLE_ENDIAN         3           0.3327
>>
>> Thanks,
>> Amy
>>> Paul.
>>>
>>>
>>>> On 11 Jan 2017, at 18:10, Amy Lu <amy.lu at oracle.com> wrote:
>>>>
>>>> 8135248 and 8155794 introduced utility methods for checking indexes and ranges. Existing code with custom checkIndex/checkRange can be updated to use these methods. Please review the patch for this purpose:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146668
>>>> webrev: http://cr.openjdk.java.net/~amlu/8146668/webrev.01
>>>>
>>>> The type of exception thrown are preserved. Custom checkIndex/checkRange functions that throw IOOBE are now using ?check? utility methods provided by java.lang.Objects (which also throws IOOBE), functions that throw other exceptions use jdk.internal.util.Preconditions to preserve exception types, with the help of new BiFunction vars.
>>>>
>>>> I'd like to get this in JDK 9 if it's not too late, otherwise, JDK 10.
>>>>
>>>> Thanks,
>>>> Amy


From amy.lu at oracle.com  Thu Jan 19 13:34:36 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 19 Jan 2017 21:34:36 +0800
Subject: JDK 9 RFR of JDK-8169903: Refactor spliterator traversing tests into
	a library
Message-ID: <8f7822d7-e66c-8d53-89f4-9d9b7f9a713f@oracle.com>

java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
java/util/Spliterator/SpliteratorCollisions.java

Test functions in above tests are almost duplicate with functions in 
java/util/stream/SpliteratorTestHelper.java. Test can reuse test 
functions from SpliteratorTestHelper, but with it?s own DataProvider.

Please review the patch for refactoring spliterator traversing tests.

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

SpliteratorTestHelper.java has a minor update, added one small testcase 
that originally from SpliteratorCollisions.testForEach.

The two skipped tests in SpliteratorCollisions.java are now enabled 
back, as mentioned bug has already been fixed.
256 /* skip this test until 8013649 is fixed
...
268 */

This patch also brings back Integer.MAX_VALUE test data which requires 
big memory (and removed in JDK-8169838), in a separate test.

Thanks,
Amy

From amy.lu at oracle.com  Thu Jan 19 13:37:35 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 19 Jan 2017 21:37:35 +0800
Subject: JDK 9 RFR of JDK-8169903: Refactor spliterator traversing tests
	into a library
In-Reply-To: <8f7822d7-e66c-8d53-89f4-9d9b7f9a713f@oracle.com>
References: <8f7822d7-e66c-8d53-89f4-9d9b7f9a713f@oracle.com>
Message-ID: <e78193c5-565b-3034-1131-2fd1a0f94624@oracle.com>

This is test-only change, can still go into JDK 9?

Thanks,
Amy

On 1/19/17 9:34 PM, Amy Lu wrote:
> java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
> java/util/Spliterator/SpliteratorCollisions.java
>
> Test functions in above tests are almost duplicate with functions in 
> java/util/stream/SpliteratorTestHelper.java. Test can reuse test 
> functions from SpliteratorTestHelper, but with it?s own DataProvider.
>
> Please review the patch for refactoring spliterator traversing tests.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8169903
> webrev: http://cr.openjdk.java.net/~amlu/8169903/webrev.00/
>
> SpliteratorTestHelper.java has a minor update, added one small 
> testcase that originally from SpliteratorCollisions.testForEach.
>
> The two skipped tests in SpliteratorCollisions.java are now enabled 
> back, as mentioned bug has already been fixed.
> 256 /* skip this test until 8013649 is fixed
> ...
> 268 */
>
> This patch also brings back Integer.MAX_VALUE test data which requires 
> big memory (and removed in JDK-8169838), in a separate test.
>
> Thanks,
> Amy


From lance.andersen at oracle.com  Thu Jan 19 15:20:36 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 19 Jan 2017 10:20:36 -0500
Subject: RFR 8172350:  Typo in Timestamp.toString()
Message-ID: <B7071F32-E1A0-41D6-AE60-B7DD8AFEAF72@oracle.com>

Hi all,

Following trivial javadoc update to Timestamp.toString() needs a review

?????????
ljanders-mac:jdk ljanders$ hg diff
diff -r 051e7d9159a7 src/java.sql/share/classes/java/sql/Timestamp.java
--- a/src/java.sql/share/classes/java/sql/Timestamp.java	Tue Jan 17 11:34:47 2017 -0800
+++ b/src/java.sql/share/classes/java/sql/Timestamp.java	Thu Jan 19 10:07:23 2017 -0500
@@ -259,7 +259,7 @@
     /**
      * Formats a timestamp in JDBC timestamp escape format.
      *         {@code yyyy-mm-dd hh:mm:ss.fffffffff},
-     * where {@code ffffffffff} indicates nanoseconds.
+     * where {@code fffffffff} indicates nanoseconds.
      *
      * @return a {@code String} object in
      *           {@code yyyy-mm-dd hh:mm:ss.fffffffff} format
ljanders-mac:jdk 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 daniel.fuchs at oracle.com  Thu Jan 19 15:28:56 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Jan 2017 15:28:56 +0000
Subject: RFR 8172350: Typo in Timestamp.toString()
In-Reply-To: <B7071F32-E1A0-41D6-AE60-B7DD8AFEAF72@oracle.com>
References: <B7071F32-E1A0-41D6-AE60-B7DD8AFEAF72@oracle.com>
Message-ID: <140dbfa9-03a6-ce5d-9652-bae49c952cc1@oracle.com>

Hi Lance,

On 19/01/17 15:20, Lance Andersen wrote:
> Hi all,
>
> Following trivial javadoc update to Timestamp.toString() needs a review

Looks good!

-- daniel

>
> ?????????
> ljanders-mac:jdk ljanders$ hg diff
> diff -r 051e7d9159a7 src/java.sql/share/classes/java/sql/Timestamp.java
> --- a/src/java.sql/share/classes/java/sql/Timestamp.java	Tue Jan 17 11:34:47 2017 -0800
> +++ b/src/java.sql/share/classes/java/sql/Timestamp.java	Thu Jan 19 10:07:23 2017 -0500
> @@ -259,7 +259,7 @@
>      /**
>       * Formats a timestamp in JDBC timestamp escape format.
>       *         {@code yyyy-mm-dd hh:mm:ss.fffffffff},
> -     * where {@code ffffffffff} indicates nanoseconds.
> +     * where {@code fffffffff} indicates nanoseconds.
>       *
>       * @return a {@code String} object in
>       *           {@code yyyy-mm-dd hh:mm:ss.fffffffff} format
> ljanders-mac:jdk 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 daniel.fuchs at oracle.com  Thu Jan 19 15:30:51 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Jan 2017 15:30:51 +0000
Subject: 8172971: java.management could use System.Logger
Message-ID: <de015d3e-639c-aba5-03d7-305de9d304b6@oracle.com>

Hi,

Please find below a patch for:

8172971: java.management could use System.Logger
https://bugs.openjdk.java.net/browse/JDK-8172971

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.00/

I have also added a new test:
test/sun/management/LoggingTest/LoggingTest.java

This is a simple smoke test that verifies that we still
get expected debug traces when creating and populating
the platform MBeanServer.
This test should always pass - whether the fix is present
or not.

best regards,

-- daniel

From peter.levart at gmail.com  Thu Jan 19 15:58:08 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Jan 2017 16:58:08 +0100
Subject: RFR: 8173056: Add test that captures current behavior of annotations
	with invalid annotation types
In-Reply-To: <3a42ee8d-8c05-2f11-7ab1-2e020fac322d@oracle.com>
References: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>
	<3a42ee8d-8c05-2f11-7ab1-2e020fac322d@oracle.com>
Message-ID: <235779c0-a726-fb7b-68b9-421c2c8ee293@gmail.com>

Hi Claes,

On 01/18/2017 12:01 PM, Claes Redestad wrote:
> Hi Peter,
>
> On 01/17/2017 03:10 PM, Peter Levart wrote:
>>
>> As for the failure reporting: requesting an annotation for invalid 
>> annotation type now always produces AnnotationFormatError. 
>> Previously, some invalid annotations were simply skipped, some 
>> produced AnnotationFormatError and for some of them, 
>> AnnotationFormatError was raised only when evaluating Annotation's 
>> equals() method.
>>
>> I would like to discuss this failure behavior more in-depth.
>
> I don't have an example, but if there are applications that have invalid
> annotations which are currently ignored completely or until someone
> calls equals on them, this behavior change could result in some
> application breaking in unexpected ways.
>
> Although this change might be well-intended and align implementation
> better with specified intent, I fear this kind this behavior change 
> might be
> too late for 9 (maybe even for later releases), and think it'd be 
> easier to
> accept a patch that took great care not to change observable behavior
> and discuss this separately.
>
> Thanks!

Mind you that we are talking about the behavior of invalid annotations 
types (class files containing annotation interfaces which are invalid 
according to JLS) and not about the behavior of invalid annotation data 
(annotation attributes in the class files containing annotated 
types/members/...). The later behavior is not changed with the presented 
patch, just the behavior when an annotation type is encountered which 
must have been created by some other tool - not javac - and violates JLS 
for annotation types.

Anyway, the behavior of such invalid annotation types has already 
changed in the past (with a patch for the issue: 8035781: Improve 
equality for annotations) which introduced additional checks into the 
AnnotationInvocationHandler constructor and the equalsImpl() method 
which implements annotation's equals() method.

I extended the AnnotationVerifier test with additional cases that cover 
various "wrongs" in annotation types:

http://cr.openjdk.java.net/~plevart/jdk9-dev/8173056_AnnotationVerifier/webrev.01/

Running this on current jdk9 shows all the shades of behavior for 
different "wrongs":

HolderA.class.getAnnotations() = [@GoodAnnotation()]
test AnnotationVerifier.holderA_annotations(): success

HolderA.class.getAnnotation(GoodAnnotation.class) = @GoodAnnotation()
test AnnotationVerifier.holderA_goodAnnotation(): success

HolderB.class.getAnnotation(AnnotationWithParameter.class) = null
test AnnotationVerifier.holderB_annotationWithParameter(): success

HolderB.class.getAnnotations() = [@GoodAnnotation()]
test AnnotationVerifier.holderB_annotations(): success

HolderB.class.getAnnotation(GoodAnnotation.class) = @GoodAnnotation()
test AnnotationVerifier.holderB_goodAnnotation(): success

HolderC.class.getAnnotation(AnnotationWithVoidReturn.class) = 
java.lang.annotation.AnnotationFormatError: Invalid default: public 
abstract void AnnotationWithVoidReturn.m()
test AnnotationVerifier.holderC_annotationWithVoidReturn(): success

HolderC.class.getAnnotations() = 
java.lang.annotation.AnnotationFormatError: Invalid default: public 
abstract void AnnotationWithVoidReturn.m()
test AnnotationVerifier.holderC_annotations(): success

HolderC.class.getAnnotation(GoodAnnotation.class) = 
java.lang.annotation.AnnotationFormatError: Invalid default: public 
abstract void AnnotationWithVoidReturn.m()
test AnnotationVerifier.holderC_goodAnnotation(): success

HolderD.class.getAnnotation(AnnotationWithExtraInterface.class) = 
java.lang.annotation.AnnotationFormatError: Attempt to create proxy for 
a non-annotation type.
test AnnotationVerifier.holderD_annotationWithExtraInterface(): success

HolderD.class.getAnnotations() = 
java.lang.annotation.AnnotationFormatError: Attempt to create proxy for 
a non-annotation type.
test AnnotationVerifier.holderD_annotations(): success

HolderD.class.getAnnotation(GoodAnnotation.class) = 
java.lang.annotation.AnnotationFormatError: Attempt to create proxy for 
a non-annotation type.
test AnnotationVerifier.holderD_goodAnnotation(): success

HolderE.class.getAnnotation(AnnotationWithException.class) = 
@AnnotationWithException(m=1)
test AnnotationVerifier.holderE_annotationWithException(): success

@AnnotationWithException(m=1).equals(@AnnotationWithException(m=1)) = 
java.lang.annotation.AnnotationFormatError: Malformed method on an 
annotation type
test AnnotationVerifier.holderE_annotationWithException_equals(): success

HolderE.class.getAnnotations() = [@GoodAnnotation(), 
@AnnotationWithException(m=1)]
test AnnotationVerifier.holderE_annotations(): success

HolderE.class.getAnnotation(GoodAnnotation.class) = @GoodAnnotation()
test AnnotationVerifier.holderE_goodAnnotation(): success

HolderF.class.getAnnotation(AnnotationWithHashCode.class) = 
@AnnotationWithHashCode(hashCode=1)
test AnnotationVerifier.holderF_annotationWithHashCode(): success

@AnnotationWithHashCode(hashCode=1).equals(@AnnotationWithHashCode(hashCode=1)) 
= java.lang.annotation.AnnotationFormatError: Malformed method on an 
annotation type
test AnnotationVerifier.holderF_annotationWithHashCode_equals(): success

HolderF.class.getAnnotations() = [@GoodAnnotation(), 
@AnnotationWithHashCode(hashCode=1)]
test AnnotationVerifier.holderF_annotations(): success

HolderF.class.getAnnotation(GoodAnnotation.class) = @GoodAnnotation()
test AnnotationVerifier.holderF_goodAnnotation(): success

HolderG.class.getAnnotation(AnnotationWithDefaultMember.class) = 
@AnnotationWithDefaultMember(m=1)
test AnnotationVerifier.holderG_annotationWithDefaultMember(): success

@AnnotationWithDefaultMember(m=1).equals(@AnnotationWithDefaultMember(m=1)) 
= java.lang.annotation.AnnotationFormatError: Malformed method on an 
annotation type
test AnnotationVerifier.holderG_annotationWithDefaultMember_equals(): 
success

HolderG.class.getAnnotations() = [@GoodAnnotation(), 
@AnnotationWithDefaultMember(m=1)]
test AnnotationVerifier.holderG_annotations(): success

HolderG.class.getAnnotation(GoodAnnotation.class) = @GoodAnnotation()
test AnnotationVerifier.holderG_goodAnnotation(): success

HolderX.class.getAnnotation(AnnotationWithoutAnnotationAccessModifier.class) 
= null
test 
AnnotationVerifier.holderX_annotationWithoutAnnotationAccessModifier(): 
success

HolderX.class.getAnnotations() = [@GoodAnnotation()]
test AnnotationVerifier.holderX_annotations(): success

HolderX.class.getAnnotation(GoodAnnotation.class) = @GoodAnnotation()
test AnnotationVerifier.holderX_goodAnnotation(): success


Cases that throw "AnnotationFormatError: Malformed method on an 
annotation type" and "AnnotationFormatError: Attempt to create proxy for 
a non-annotation type" are the cases that changed behavior with a patch 
for 8035781 and nobody complained. This patch causes 
AnnotationFormatError even for some valid cases (see bellow).

When AnnotationType.getInstance() throws IllegalArgumentException, the 
annotation is skipped while parsing it. This currently happens only when:
- the annotation interface is not marked with ACC_ANNOTATION access 
modifier (Class.isAnnotation() == false).
- the annotation interface contains a non-synthetic public abstract 
method with parameters.

But AnnotationType.getInstance() can also throw AnnotationFormatError 
which is propagated out of parsing logic and out of public 
annotation-obtaining method(s). This currently happens only when:
- the annotation interface contains a non-synthetic public abstract 
method with invalid return type (such as void) because 
Method.getDefaultValue() throws such error which is propagated out of 
AnnotationType constructor.

AnnotationInvocationHandler constructor throws AnnotationFormatError 
which is propagated out of parsing logic and out of public 
annotation-obtaining method(s). This currently happens only when:
- the annotation interface is marked with ACC_ANNOTATION access modifier 
but it either doesn't extend java.lang.annotation.Annotation or it 
extends any additional interfaces.

In all other "wrong annotation type" cases (and some valid cases too), 
the annotation is successfully constructed and returned, but such 
annotation later fails with AnnotationFormatError when .equals() method 
is evaluated on it. Those cases are:

- the annotation interface contains a method (of any kind: synthetic, 
abstract, default, static, private) that declares a thrown exception or 
when it contains a non-abstract or non-public method. The perfectly 
valid situation when this happens is the following example:

public class AnnotationWithLambda {

     @Retention(RetentionPolicy.RUNTIME)
     @interface Ann {
         Callable<Void> callable = () -> {throw new Exception();};
     }

     @Ann
     static class Holder1 {}

     @Ann
     static class Holder2 {}

     public static void main(String[] args) {
         Ann ann1 = Holder1.class.getAnnotation(Ann.class);
         Ann ann2 = Holder1.class.getAnnotation(Ann.class);

         // throws AnnotationFormatError: Malformed method on an 
annotation type
         ann1.equals(ann2);
     }
}

This happens as a consequence of fix for 8035781 which introduced a very 
rigorous validation in annotation's equals method which is more rigorous 
than it should be.

- the annotation interface contains a method (of any kind: synthetic, 
abstract, default, static, private) that has an invalid return type
- the annotation interface contains a method (of any kind: synthetic, 
abstract, default, static, private) which is override equivalent with 
public/protected methods in Object class or Annotation interface.


Do we really want to keep this behavior?

I suggest that when an annotation type is not marked with ACC_ANNOTATION 
modifier (Class.isAnnotation() == false) such annotations are skipped 
when parsing. This can happen when a former annotation type is changed 
to be a normal interface and separately compiled. In all other cases the 
invalid annotation type should be reported when annotations are parsed.

Perhaps this could be performed lazily. An idea:

During parsing of annotations, if an annotation for invalid annotation 
type that has ACC_ANNOTATION modifier is being parsed, the parsing skips 
such annotation and returns a special Proxy implementation implementing 
the invalid annotation type, but this proxy throws AnnotationFormatError 
on any method being invoked on it. This would not prevent other valid 
annotations to be obtained on annotated elements just because they are 
also annotated with invalid annotations.

What do you think?

Regards, Peter


From mandy.chung at oracle.com  Thu Jan 19 17:12:03 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 19 Jan 2017 09:12:03 -0800
Subject: 8172971: java.management could use System.Logger
In-Reply-To: <de015d3e-639c-aba5-03d7-305de9d304b6@oracle.com>
References: <de015d3e-639c-aba5-03d7-305de9d304b6@oracle.com>
Message-ID: <9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com>


> On Jan 19, 2017, at 7:30 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a patch for:
> 
> 8172971: java.management could use System.Logger
> https://bugs.openjdk.java.net/browse/JDK-8172971
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.00/
> 

This looks good in general and pretty straight forward change.  

Is it intentional to change the level FINEST to DEBUG as opposed to TRACE in a couple places?  For example,

src/java.management/share/classes/javax/management/MBeanServerFactory.java
-            if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) {
+            if (MBEANSERVER_LOGGER.isLoggable(Level.DEBUG)) {

src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanServerDelegateImpl.java
-                if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) {
-                    MBEANSERVER_LOGGER.logp(Level.FINEST,
-                            MBeanServerDelegateImpl.class.getName(),
-                            "getAttributes",
+                if (MBEANSERVER_LOGGER.isLoggable(Level.TRACE)) {
+                    MBEANSERVER_LOGGER.log(Level.TRACE,
                             "Attribute " + attn[i] + " not found");
                 }

> I have also added a new test:
> test/sun/management/LoggingTest/LoggingTest.java

This test should have @modules java.logging and java.management.

Mandy

From sean.coffey at oracle.com  Thu Jan 19 17:59:01 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 19 Jan 2017 17:59:01 +0000
Subject: RFR: 8077395: org.omg.CORBA_2_3.portable.InputStream constructor
	should not specify JDK-specific property
Message-ID: <8da604c6-74f5-d9ac-d690-0d659e6a6a89@oracle.com>

Changes made to the CORBA InputStream/OutputStream class back in 2013 
contained javadoc comments which should have been marked as 
implementation specific. The minor edits here should correct that.

webrev : http://cr.openjdk.java.net/~coffeys/webrev.8077395/webrev/
JBS : https://bugs.openjdk.java.net/browse/JDK-8077395

regards,
Sean.


From Roger.Riggs at Oracle.com  Thu Jan 19 18:22:43 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 19 Jan 2017 13:22:43 -0500
Subject: 8172971: java.management could use System.Logger
In-Reply-To: <9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com>
References: <de015d3e-639c-aba5-03d7-305de9d304b6@oracle.com>
	<9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com>
Message-ID: <1f151a43-5f87-3afa-aed3-59fcc317fdfd@Oracle.com>

Hi Daniel,

Very straight-forward.

I can see many places where the supplier form of logging could be used 
instead
of the if (loggable...) {log(...) }; pattern.  But maybe not worth the 
conversion effort or not part of this change.

And in some places there is both the if(loggable) and the supplier pattern
which results in a double check of isLoggable,  Explicitly calling the 
sb.toString(),
instead of using the supplier form would avoid the double check. For 
example,

new/src/java.management/share/classes/javax/management/MBeanServerFactory.java:

@@ -504,15 +502,12 @@
                  throw new JMRuntimeException(msg, x);
              }
          } catch (RuntimeException x) {
-            if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) {
+            if (MBEANSERVER_LOGGER.isLoggable(Level.DEBUG)) {
                  StringBuilder strb = new StringBuilder()
                  .append("Failed to instantiate MBeanServerBuilder: ").append(x)
                  .append("\n\t\tCheck the value of the ")
                  .append(JMX_INITIAL_BUILDER).append(" property.");
-                MBEANSERVER_LOGGER.logp(Level.FINEST,
-                        MBeanServerFactory.class.getName(),
-                        "checkMBeanServerBuilder",
-                        strb.toString());
+                MBEANSERVER_LOGGER.log(Level.DEBUG, strb::toString);


There are a few files with very long lines that could be wrapped if it 
was convenient.
(To make future reviews easier).
  - JmxMBeanServer.java, MLet.java, ModelMBeanAttributeInfo.java, 
ModelMBeanConstructorInfo.java,
    ModelMBeanNotificationInfo.java, ModelMBeanOperationInfo.java, 
RequiredModelMBean.java,
    RelationService.java, Timer.java,


Roger

On 1/19/2017 12:12 PM, Mandy Chung wrote:
>> On Jan 19, 2017, at 7:30 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi,
>>
>> Please find below a patch for:
>>
>> 8172971: java.management could use System.Logger
>> https://bugs.openjdk.java.net/browse/JDK-8172971
>>
>> webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.00/
>>
> This looks good in general and pretty straight forward change.
>
> Is it intentional to change the level FINEST to DEBUG as opposed to TRACE in a couple places?  For example,
>
> src/java.management/share/classes/javax/management/MBeanServerFactory.java
> -            if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) {
> +            if (MBEANSERVER_LOGGER.isLoggable(Level.DEBUG)) {
>
> src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanServerDelegateImpl.java
> -                if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) {
> -                    MBEANSERVER_LOGGER.logp(Level.FINEST,
> -                            MBeanServerDelegateImpl.class.getName(),
> -                            "getAttributes",
> +                if (MBEANSERVER_LOGGER.isLoggable(Level.TRACE)) {
> +                    MBEANSERVER_LOGGER.log(Level.TRACE,
>                               "Attribute " + attn[i] + " not found");
>                   }
>
>> I have also added a new test:
>> test/sun/management/LoggingTest/LoggingTest.java
> This test should have @modules java.logging and java.management.
>
> Mandy


From Roger.Riggs at Oracle.com  Thu Jan 19 18:28:04 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 19 Jan 2017 13:28:04 -0500
Subject: RFR: 8077395: org.omg.CORBA_2_3.portable.InputStream constructor
	should not specify JDK-specific property
In-Reply-To: <8da604c6-74f5-d9ac-d690-0d659e6a6a89@oracle.com>
References: <8da604c6-74f5-d9ac-d690-0d659e6a6a89@oracle.com>
Message-ID: <ada2249c-4467-3729-26f6-0aec6874c0cb@Oracle.com>

Hi Sean,

Looks ok but can you turn those texts into a sentence (capitalize it and 
final ".').

Thanks, Roger


On 1/19/2017 12:59 PM, Se?n Coffey wrote:
> Changes made to the CORBA InputStream/OutputStream class back in 2013 
> contained javadoc comments which should have been marked as 
> implementation specific. The minor edits here should correct that.
>
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8077395/webrev/
> JBS : https://bugs.openjdk.java.net/browse/JDK-8077395
>
> regards,
> Sean.
>


From lance.andersen at oracle.com  Thu Jan 19 18:34:06 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 19 Jan 2017 13:34:06 -0500
Subject: RFR: 8077395: org.omg.CORBA_2_3.portable.InputStream constructor
	should not specify JDK-specific property
In-Reply-To: <8da604c6-74f5-d9ac-d690-0d659e6a6a89@oracle.com>
References: <8da604c6-74f5-d9ac-d690-0d659e6a6a89@oracle.com>
Message-ID: <2479C560-F53C-4A46-8E46-8F533BB7D26D@oracle.com>

Hi Sean,

The changes look OK.  I would capitalize ?throws? and looks like you are missing a period

HTH

Lance
> On Jan 19, 2017, at 12:59 PM, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> Changes made to the CORBA InputStream/OutputStream class back in 2013 contained javadoc comments which should have been marked as implementation specific. The minor edits here should correct that.
> 
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8077395/webrev/
> JBS : https://bugs.openjdk.java.net/browse/JDK-8077395
> 
> regards,
> Sean.
> 

 <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 daniel.fuchs at oracle.com  Thu Jan 19 18:50:47 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Jan 2017 18:50:47 +0000
Subject: 8172971: java.management could use System.Logger
In-Reply-To: <9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com>
References: <de015d3e-639c-aba5-03d7-305de9d304b6@oracle.com>
	<9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com>
Message-ID: <b0579dff-4a65-2ee1-347f-bbe39ae85ca2@oracle.com>

Hi Mandy,

Thanks for the review!

On 19/01/17 17:12, Mandy Chung wrote:
>
>> On Jan 19, 2017, at 7:30 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi,
>>
>> Please find below a patch for:
>>
>> 8172971: java.management could use System.Logger
>> https://bugs.openjdk.java.net/browse/JDK-8172971
>>
>> webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.00/
>>
>
> This looks good in general and pretty straight forward change.
>
> Is it intentional to change the level FINEST to DEBUG as opposed to TRACE in a couple places?  For example,

The regular mapping would be:
   [CONFIG,FINE]  -> DEBUG,
   [FINER,FINEST] -> TRACE.

There are a couple of places were unexpected exceptions where traced
at level FINEST, and I arbitrarily decided that they should rather
be traced with level DEBUG.

> src/java.management/share/classes/javax/management/MBeanServerFactory.java
> -            if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) {
> +            if (MBEANSERVER_LOGGER.isLoggable(Level.DEBUG)) {
>
> src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanServerDelegateImpl.java
> -                if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) {
> -                    MBEANSERVER_LOGGER.logp(Level.FINEST,
> -                            MBeanServerDelegateImpl.class.getName(),
> -                            "getAttributes",
> +                if (MBEANSERVER_LOGGER.isLoggable(Level.TRACE)) {
> +                    MBEANSERVER_LOGGER.log(Level.TRACE,
>                              "Attribute " + attn[i] + " not found");
>                  }
>
>> I have also added a new test:
>> test/sun/management/LoggingTest/LoggingTest.java
>
> This test should have @modules java.logging and java.management.

OK - I believed @modules java.management should already be in TEST.ROOT
I will double check.

best regards,

-- daniel
>
> Mandy
>


From daniel.fuchs at oracle.com  Thu Jan 19 18:58:50 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 19 Jan 2017 18:58:50 +0000
Subject: 8172971: java.management could use System.Logger
In-Reply-To: <1f151a43-5f87-3afa-aed3-59fcc317fdfd@Oracle.com>
References: <de015d3e-639c-aba5-03d7-305de9d304b6@oracle.com>
	<9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com>
	<1f151a43-5f87-3afa-aed3-59fcc317fdfd@Oracle.com>
Message-ID: <1b2e3ae9-0fc8-6e3a-3d38-c601e3d02132@oracle.com>

Hi Roger,

On 19/01/17 18:22, Roger Riggs wrote:
> Hi Daniel,
>
> Very straight-forward.
>
> I can see many places where the supplier form of logging could be used
> instead
> of the if (loggable...) {log(...) }; pattern.  But maybe not worth the
> conversion effort or not part of this change.
>
> And in some places there is both the if(loggable) and the supplier pattern
> which results in a double check of isLoggable,  Explicitly calling the
> sb.toString(),
> instead of using the supplier form would avoid the double check. For
> example,

Well - yes - I don't think it matters much. I didn't want to attempt
to capture all the parameters inside the supplier, and so I simply
changed strb.toString() into strb::toString.

> new/src/java.management/share/classes/javax/management/MBeanServerFactory.java:
>
>
> @@ -504,15 +502,12 @@
>                  throw new JMRuntimeException(msg, x);
>              }
>          } catch (RuntimeException x) {
> -            if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) {
> +            if (MBEANSERVER_LOGGER.isLoggable(Level.DEBUG)) {
>                  StringBuilder strb = new StringBuilder()
>                  .append("Failed to instantiate MBeanServerBuilder:
> ").append(x)
>                  .append("\n\t\tCheck the value of the ")
>                  .append(JMX_INITIAL_BUILDER).append(" property.");
> -                MBEANSERVER_LOGGER.logp(Level.FINEST,
> -                        MBeanServerFactory.class.getName(),
> -                        "checkMBeanServerBuilder",
> -                        strb.toString());
> +                MBEANSERVER_LOGGER.log(Level.DEBUG, strb::toString);


> There are a few files with very long lines that could be wrapped if it
> was convenient.
> (To make future reviews easier).
>  - JmxMBeanServer.java, MLet.java, ModelMBeanAttributeInfo.java,
> ModelMBeanConstructorInfo.java,
>    ModelMBeanNotificationInfo.java, ModelMBeanOperationInfo.java,
> RequiredModelMBean.java,
>    RelationService.java, Timer.java,

Agreed - but I'd rather not do that now - as this changeset has many
files it would make the changes much more difficult to review.

best regards,

-- daniel

>
>
> Roger
>
> On 1/19/2017 12:12 PM, Mandy Chung wrote:
>>> On Jan 19, 2017, at 7:30 AM, Daniel Fuchs <daniel.fuchs at oracle.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> Please find below a patch for:
>>>
>>> 8172971: java.management could use System.Logger
>>> https://bugs.openjdk.java.net/browse/JDK-8172971
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.00/
>>>
>> This looks good in general and pretty straight forward change.
>>
>> Is it intentional to change the level FINEST to DEBUG as opposed to
>> TRACE in a couple places?  For example,
>>
>> src/java.management/share/classes/javax/management/MBeanServerFactory.java
>>
>> -            if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) {
>> +            if (MBEANSERVER_LOGGER.isLoggable(Level.DEBUG)) {
>>
>> src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanServerDelegateImpl.java
>>
>> -                if (MBEANSERVER_LOGGER.isLoggable(Level.FINEST)) {
>> -                    MBEANSERVER_LOGGER.logp(Level.FINEST,
>> -                            MBeanServerDelegateImpl.class.getName(),
>> -                            "getAttributes",
>> +                if (MBEANSERVER_LOGGER.isLoggable(Level.TRACE)) {
>> +                    MBEANSERVER_LOGGER.log(Level.TRACE,
>>                               "Attribute " + attn[i] + " not found");
>>                   }
>>
>>> I have also added a new test:
>>> test/sun/management/LoggingTest/LoggingTest.java
>> This test should have @modules java.logging and java.management.
>>
>> Mandy
>


From mandy.chung at oracle.com  Thu Jan 19 19:07:11 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 19 Jan 2017 11:07:11 -0800
Subject: 8172971: java.management could use System.Logger
In-Reply-To: <b0579dff-4a65-2ee1-347f-bbe39ae85ca2@oracle.com>
References: <de015d3e-639c-aba5-03d7-305de9d304b6@oracle.com>
	<9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com>
	<b0579dff-4a65-2ee1-347f-bbe39ae85ca2@oracle.com>
Message-ID: <0ED0BC42-B8ED-4AA7-A0E9-B1423524A507@oracle.com>


> On Jan 19, 2017, at 10:50 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Mandy,
> 
> Thanks for the review!
> 
> On 19/01/17 17:12, Mandy Chung wrote:
>> 
>> 
>> Is it intentional to change the level FINEST to DEBUG as opposed to TRACE in a couple places?  For example,
> 
> The regular mapping would be:
>  [CONFIG,FINE]  -> DEBUG,
>  [FINER,FINEST] -> TRACE.
> 
> There are a couple of places were unexpected exceptions where traced
> at level FINEST, and I arbitrarily decided that they should rather
> be traced with level DEBUG.
> 

That?s fine since there isn?t a very clear policy when to use FINEST and FINER anyway.

>> 
>> This test should have @modules java.logging and java.management.
> 
> OK - I believed @modules java.management should already be in TEST.ROOT
> I will double check.

If @modules is specified in a test, it will override the one in TEST.properties (I think that?s what you meant).  In any case, this test depends on java.logging.

Mandy

From paul.sandoz at oracle.com  Thu Jan 19 19:22:36 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 19 Jan 2017 11:22:36 -0800
Subject: JDK 9 RFR of JDK-8169903: Refactor spliterator traversing tests
	into a library
In-Reply-To: <e78193c5-565b-3034-1131-2fd1a0f94624@oracle.com>
References: <8f7822d7-e66c-8d53-89f4-9d9b7f9a713f@oracle.com>
	<e78193c5-565b-3034-1131-2fd1a0f94624@oracle.com>
Message-ID: <39AF9B61-1680-4D3E-8523-EAC6DC8EB550@oracle.com>


> On 19 Jan 2017, at 05:37, Amy Lu <amy.lu at oracle.com> wrote:
> 
> This is test-only change, can still go into JDK 9?
> 

Yes.

It?s verbose but i would prefer if you can explicitly declare each test rather than having one test deferring to SpliteratorTestHelper.testSpliterator. So in effect the test methods are proxies to the equivalent methods on the helper. That way it?s easier to diagnose test failures.

The expected contents (collection) has also been removed. It?s important in many cases to be able to pass this independently and not derive the expected result from traversing the spliterator, as that could mask bugs.

There is no need to create separate classes for primitive tests (you only added explicit for int traversing and not long and double).


Independently i wonder if test/java/util/stream/bootlib/java.base/java/util/stream/SpliteratorTestHelper.java is the right location. I know it?s used in Streams, but perhaps it and the provider should be placed within a library?

Paul.

> Thanks,
> Amy
> 
> On 1/19/17 9:34 PM, Amy Lu wrote:
>> java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
>> java/util/Spliterator/SpliteratorCollisions.java
>> 
>> Test functions in above tests are almost duplicate with functions in java/util/stream/SpliteratorTestHelper.java. Test can reuse test functions from SpliteratorTestHelper, but with it?s own DataProvider.
>> 
>> Please review the patch for refactoring spliterator traversing tests.
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8169903
>> webrev: http://cr.openjdk.java.net/~amlu/8169903/webrev.00/
>> 
>> SpliteratorTestHelper.java has a minor update, added one small testcase that originally from SpliteratorCollisions.testForEach.
>> 
>> The two skipped tests in SpliteratorCollisions.java are now enabled back, as mentioned bug has already been fixed.
>> 256 /* skip this test until 8013649 is fixed
>> ...
>> 268 */
>> 
>> This patch also brings back Integer.MAX_VALUE test data which requires big memory (and removed in JDK-8169838), in a separate test.
>> 
>> Thanks,
>> Amy
> 


From paul.sandoz at oracle.com  Thu Jan 19 19:40:11 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 19 Jan 2017 11:40:11 -0800
Subject: JDK 9 RFR of JDK-8146668: Replace custom check/range
	functionality with check index/range methods in java.util.Objects
In-Reply-To: <92770fc1-b617-cd78-2f65-c008dc2d4ab4@oracle.com>
References: <de138c68-e8e5-ba3b-6e2b-603b8fc49329@oracle.com>
	<44FFB565-3075-49C5-9069-08189E13BE7B@oracle.com>
	<eeea98c6-0d3a-6830-dea3-d32d436aa8fc@oracle.com>
	<1E6DCA27-11FF-49CF-BEDF-B2E79B82F023@oracle.com>
	<92770fc1-b617-cd78-2f65-c008dc2d4ab4@oracle.com>
Message-ID: <849BE476-4A47-4F33-B880-DA429C3221A3@oracle.com>

Hi Amy,

As an exercise it might useful to modify ArrayList and test with the existing benchmark. One could follow up with ArrayList changes as a separate issue. If your investigations show no regressions then we have good confidence the current patch is ok.

Another useful learning exercise is to rewrite the ArrayList range check benchmark to JMH.

I am piling more work on you :-) but it?s a good for learning.

The important aspect when testing for regression on range checks is to ensure the cost is not dwarfed by the other work. What array size/range values did you use in the test below?

Paul.

> On 19 Jan 2017, at 05:11, Amy Lu <amy.lu at oracle.com> wrote:
> 
> No, no change to ArrayList, sorry for the confusion. I just thought ArrayList/RangeCheckMicroBenchmark.java can also give some data for reference to the Arrays change.
> 
> So I tried a modified ArraysEquals JMH test, the test is originally for
> equals(char[] a, char[] a2) and I changed it to perform
> equals(char[] a, int aFromIndex, int aToIndex,
>       char[] b, int bFromIndex, int bToIndex)
> which is changed in this patch.
> 
> No performance regression.
> 
> without 8146668
> 
> Benchmark                                              Mode Cnt          Score         Error  Units
> ArraysEqualsFromTo.testCharArrayEqualsFalseBeginning  thrpt 200  117773032.914 ?  837866.545  ops/s
> ArraysEqualsFromTo.testCharArrayEqualsFalseEnd        thrpt 200   68162413.018 ?  252693.599  ops/s
> ArraysEqualsFromTo.testCharArrayEqualsFalseMid        thrpt 200   87845305.867 ?  434145.358  ops/s
> ArraysEqualsFromTo.testCharArrayEqualsTrue            thrpt 200   57665790.396 ? 1144777.344  ops/s
> 
> With 8146668
> 
> Benchmark                                              Mode Cnt          Score         Error  Units
> ArraysEqualsFromTo.testCharArrayEqualsFalseBeginning  thrpt 200  118754451.736 ?  395812.217  ops/s
> ArraysEqualsFromTo.testCharArrayEqualsFalseEnd        thrpt 200   68263418.139 ?  161477.719  ops/s
> ArraysEqualsFromTo.testCharArrayEqualsFalseMid        thrpt 200   87429210.156 ?  483026.299  ops/s
> ArraysEqualsFromTo.testCharArrayEqualsTrue            thrpt 200   57694918.966 ? 1163825.417  ops/s
> 
> 
> Thanks,
> Amy
> 
> On 1/18/17 9:36 AM, Paul Sandoz wrote:
>> Hi Amy,
>> 
>> RangeCheckMicroBenchmark.java measures access for ArrayList. Did you update ArrayList? (i don?t see it in your current patch).
>> 
>> Paul.
>> 
>>> On 16 Jan 2017, at 01:41, Amy Lu <amy.lu at oracle.com> wrote:
>>> 
>>> Thank you Paul and Martin for your review.
>>> 
>>> On 1/13/17 12:52 AM, Paul Sandoz wrote:
>>>> HI Amy,
>>>> 
>>>> Overall this looks very good, well done.
>>>> 
>>>> 
>>>> At this point we are down to two things:
>>>> 
>>>> 1) should we preserve exception messages?
>>>> 
>>>> 2) due diligence on the performance.
>>>> 
>>>> 
>>>> On 1) my preference is that uniform (and informative) messages are better for IndexOutOfBounds and subtypes, and defining that in addition to the checks in one place is very valuable. In some sense that does change some behavioural compatibility and i think because of that pushing in 10 (when the repos) open with a CCC would be more preferable.
>>> Got it. Will wait for 10.
>>>> On 2) this is a valuable exercise to perform (either using an existing test and/or writing JMH benchmarks). I don?t expect any major problems. Care was taken to ensure the uncommon exception processing path will optimize away for the common case. The BiFunction parameter passed as the last argument is always a constant, so should fold away from the hot path.
>>> Tested with java/util/ArrayList/RangeCheckMicroBenchmark.java and java/nio/Buffer/SwapMicroBenchmark.java, no performance regression observed.
>>> 
>>> java/util/ArrayList/RangeCheckMicroBenchmark.java
>>> 
>>> without 8146668
>>> --------------------
>>> get                             26          1
>>> set                             40.6        1.5707
>>> get/set                         85.7        3.3002
>>> add/remove at end               337.5       12.9197
>>> subList get                     25          0.9747
>>> subList set                     59.9        2.3
>>> subList get/set                 92.2        3.5414
>>> subList add/remove at end       429.8       16.45
>>> 
>>> with 8146668
>>> --------------------
>>> get                             26          1
>>> set                             39.1        1.5188
>>> get/set                         86.8        3.3363
>>> add/remove at end               335.5       12.8549
>>> subList get                     24.8        0.9715
>>> subList set                     59.2        2.2728
>>> subList get/set                 92.2        3.5473
>>> subList add/remove at end       427.7       16.3789
>>> 
>>> java/nio/Buffer/SwapMicroBenchmark.java
>>> 
>>> without 8146668
>>> --------------------
>>> swap char LITTLE_ENDIAN         11          1
>>> swap short LITTLE_ENDIAN        10.2        0.9895
>>> swap int LITTLE_ENDIAN          5           0.4961
>>> swap long LITTLE_ENDIAN         3           0.3345
>>> 
>>> with 8146668
>>> --------------------
>>> swap char LITTLE_ENDIAN         10.1        1
>>> swap short LITTLE_ENDIAN        10.1        0.9995
>>> swap int LITTLE_ENDIAN          5           0.5005
>>> swap long LITTLE_ENDIAN         3           0.3327
>>> 
>>> Thanks,
>>> Amy
>>>> Paul.
>>>> 
>>>> 
>>>>> On 11 Jan 2017, at 18:10, Amy Lu <amy.lu at oracle.com> wrote:
>>>>> 
>>>>> 8135248 and 8155794 introduced utility methods for checking indexes and ranges. Existing code with custom checkIndex/checkRange can be updated to use these methods. Please review the patch for this purpose:
>>>>> 
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8146668
>>>>> webrev: http://cr.openjdk.java.net/~amlu/8146668/webrev.01
>>>>> 
>>>>> The type of exception thrown are preserved. Custom checkIndex/checkRange functions that throw IOOBE are now using ?check? utility methods provided by java.lang.Objects (which also throws IOOBE), functions that throw other exceptions use jdk.internal.util.Preconditions to preserve exception types, with the help of new BiFunction vars.
>>>>> 
>>>>> I'd like to get this in JDK 9 if it's not too late, otherwise, JDK 10.
>>>>> 
>>>>> Thanks,
>>>>> Amy
> 


From xueming.shen at oracle.com  Thu Jan 19 21:39:38 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 19 Jan 2017 13:39:38 -0800
Subject: JDK-8173072: zipfs fails to handle incorrect info-zip "extended
	timestamp extra field"
Message-ID: <5881321A.9070105@oracle.com>

Hi

Please review the change for

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


As described in the issue, the root cause is that the offending zip/jar file
has a "extended timestamp extra field" that does not strictly follow the
spec, AND the zipfs implementation does not do a good job to do sanity
check on the data size like what the ZipEntry code does when check the
timestamps. The change here is to check both the flag and the length,
stop reading a/ctime if there is no more data, even the flags field says
there are more data.

I have run the test manually to verify the change, but decided not to check
in a binary zip/jar file (which is not encouraged for jdk repo) for the
regression test.

Thanks,
Sherman

From claes.redestad at oracle.com  Thu Jan 19 23:04:28 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 20 Jan 2017 00:04:28 +0100
Subject: JDK-8173072: zipfs fails to handle incorrect info-zip "extended
	timestamp extra field"
In-Reply-To: <5881321A.9070105@oracle.com>
References: <5881321A.9070105@oracle.com>
Message-ID: <c0296d19-3805-07b4-6e8d-75964ede1509@oracle.com>

Looks good to me.

You could simplify a bit and write: int end = locPos + locSZ - 4;
and use direct comparisons instead of adding 4 in each test.

Thanks!

/Claes

On 2017-01-19 22:39, Xueming Shen wrote:
> Hi
>
> Please review the change for
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8173072
> webrev: http://cr.openjdk.java.net/~sherman/8173072/webrev
>
>
> As described in the issue, the root cause is that the offending zip/jar
> file
> has a "extended timestamp extra field" that does not strictly follow the
> spec, AND the zipfs implementation does not do a good job to do sanity
> check on the data size like what the ZipEntry code does when check the
> timestamps. The change here is to check both the flag and the length,
> stop reading a/ctime if there is no more data, even the flags field says
> there are more data.
>
> I have run the test manually to verify the change, but decided not to check
> in a binary zip/jar file (which is not encouraged for jdk repo) for the
> regression test.
>
> Thanks,
> Sherman

From xueming.shen at oracle.com  Thu Jan 19 23:35:28 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 19 Jan 2017 15:35:28 -0800
Subject: JDK-8173072: zipfs fails to handle incorrect info-zip "extended
	timestamp extra field"
In-Reply-To: <c0296d19-3805-07b4-6e8d-75964ede1509@oracle.com>
References: <5881321A.9070105@oracle.com>
	<c0296d19-3805-07b4-6e8d-75964ede1509@oracle.com>
Message-ID: <58814D40.8030804@oracle.com>

Thanks Claes!

webrev has been updated accordingly

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

On 01/19/2017 03:04 PM, Claes Redestad wrote:
> Looks good to me.
>
> You could simplify a bit and write: int end = locPos + locSZ - 4;
> and use direct comparisons instead of adding 4 in each test.
>
> Thanks!
>
> /Claes
>
> On 2017-01-19 22:39, Xueming Shen wrote:
>> Hi
>>
>> Please review the change for
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8173072
>> webrev: http://cr.openjdk.java.net/~sherman/8173072/webrev
>>
>>
>> As described in the issue, the root cause is that the offending zip/jar
>> file
>> has a "extended timestamp extra field" that does not strictly follow the
>> spec, AND the zipfs implementation does not do a good job to do sanity
>> check on the data size like what the ZipEntry code does when check the
>> timestamps. The change here is to check both the flag and the length,
>> stop reading a/ctime if there is no more data, even the flags field says
>> there are more data.
>>
>> I have run the test manually to verify the change, but decided not to check
>> in a binary zip/jar file (which is not encouraged for jdk repo) for the
>> regression test.
>>
>> Thanks,
>> Sherman


From claes.redestad at oracle.com  Fri Jan 20 00:11:07 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 20 Jan 2017 01:11:07 +0100
Subject: JDK-8173072: zipfs fails to handle incorrect info-zip "extended
	timestamp extra field"
In-Reply-To: <58814D40.8030804@oracle.com>
References: <5881321A.9070105@oracle.com>
	<c0296d19-3805-07b4-6e8d-75964ede1509@oracle.com>
	<58814D40.8030804@oracle.com>
Message-ID: <d8906b85-49db-42bc-8878-ba663b834dd5@oracle.com>


On 2017-01-20 00:35, Xueming Shen wrote:
> Thanks Claes!
>
> webrev has been updated accordingly
>
> http://cr.openjdk.java.net/~sherman/8173072/webrev

+1

/Claes

>
> On 01/19/2017 03:04 PM, Claes Redestad wrote:
>> Looks good to me.
>>
>> You could simplify a bit and write: int end = locPos + locSZ - 4;
>> and use direct comparisons instead of adding 4 in each test.
>>
>> Thanks!
>>
>> /Claes
>>
>> On 2017-01-19 22:39, Xueming Shen wrote:
>>> Hi
>>>
>>> Please review the change for
>>>
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8173072
>>> webrev: http://cr.openjdk.java.net/~sherman/8173072/webrev
>>>
>>>
>>> As described in the issue, the root cause is that the offending zip/jar
>>> file
>>> has a "extended timestamp extra field" that does not strictly follow the
>>> spec, AND the zipfs implementation does not do a good job to do sanity
>>> check on the data size like what the ZipEntry code does when check the
>>> timestamps. The change here is to check both the flag and the length,
>>> stop reading a/ctime if there is no more data, even the flags field says
>>> there are more data.
>>>
>>> I have run the test manually to verify the change, but decided not to
>>> check
>>> in a binary zip/jar file (which is not encouraged for jdk repo) for the
>>> regression test.
>>>
>>> Thanks,
>>> Sherman
>

From paul.sandoz at oracle.com  Fri Jan 20 02:52:47 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 19 Jan 2017 18:52:47 -0800
Subject: RFR 8173083: VarHandle usages in LockSupport and ThreadLocalRandom
	result in circularity issues
Message-ID: <B0E0995A-44AC-4015-91EE-8D0477233EBB@oracle.com>

Hi,

Unfortunately the switch from Unsafe to VarHandle in LockSupport and ThreadLocalRandom caused some circularity issues (similar to those for AtomicInteger) that have shown up in continuous testing (but not when i tested explicitly using the infrastructure).

The main problem is MethodType leverages ConcurrentHashMap which under certain conditions uses TLR [*].

We know we want to replace CHM usage in MethodType with an alternative Peter created, which i think we can pursue post 9 and break the circularity.

This patch reverts the back to Unsafe usage:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8173083-vh-to-unsafe-ls-tlr/webrev/index.html

I did not revert the changes to Striped64 and ForkJoinWorkerThread.

Thanks,
Paul.

[*]
1) The clinit of LockSupport creates a VarHandle;

2) a VarHandle creates MethodTypes;

3) that are stored in a CHM;

4) which on occasion uses TLR

5) that uses a VarHandle whose VarForm is being initalized in 1)



From martinrb at google.com  Fri Jan 20 03:23:38 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 19 Jan 2017 19:23:38 -0800
Subject: RFR 8173083: VarHandle usages in LockSupport and
	ThreadLocalRandom result in circularity issues
In-Reply-To: <B0E0995A-44AC-4015-91EE-8D0477233EBB@oracle.com>
References: <B0E0995A-44AC-4015-91EE-8D0477233EBB@oracle.com>
Message-ID: <CA+kOe0-oQh07AurAheLarQGHnHoukDWczvysuQDH_nqn=Ud48A@mail.gmail.com>

Seems OK.  It would be nice to somehow get more confidence we don't have
remaining circularities.  I agree a specialized concurrent hash table to
replace ConcurrentHashMap might help.

I was surprised to see below a change in parentheses that seems to change
the behavior.

     final long nextSeed() {
         Thread t; long r; // read and update per-thread seed
-        SEED.set(t = Thread.currentThread(),
-                 (r = (long) SEED.get(t)) + GAMMA);
+        U.putLong(t = Thread.currentThread(), SEED,
+                  r = U.getLong(t, SEED) + GAMMA);
         return r;
     }



On Thu, Jan 19, 2017 at 6:52 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> Unfortunately the switch from Unsafe to VarHandle in LockSupport and
> ThreadLocalRandom caused some circularity issues (similar to those for
> AtomicInteger) that have shown up in continuous testing (but not when i
> tested explicitly using the infrastructure).
>
> The main problem is MethodType leverages ConcurrentHashMap which under
> certain conditions uses TLR [*].
>
> We know we want to replace CHM usage in MethodType with an alternative
> Peter created, which i think we can pursue post 9 and break the circularity.
>
> This patch reverts the back to Unsafe usage:
>
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8173083-vh-
> to-unsafe-ls-tlr/webrev/index.html
>
> I did not revert the changes to Striped64 and ForkJoinWorkerThread.
>
> Thanks,
> Paul.
>
> [*]
> 1) The clinit of LockSupport creates a VarHandle;
>
> 2) a VarHandle creates MethodTypes;
>
> 3) that are stored in a CHM;
>
> 4) which on occasion uses TLR
>
> 5) that uses a VarHandle whose VarForm is being initalized in 1)
>
>
>

From Alan.Bateman at oracle.com  Fri Jan 20 07:44:21 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Jan 2017 07:44:21 +0000
Subject: JDK-8173072: zipfs fails to handle incorrect info-zip "extended
	timestamp extra field"
In-Reply-To: <58814D40.8030804@oracle.com>
References: <5881321A.9070105@oracle.com>
	<c0296d19-3805-07b4-6e8d-75964ede1509@oracle.com>
	<58814D40.8030804@oracle.com>
Message-ID: <ca35fe90-ed8d-3d45-4ce1-cce24a4a0da5@oracle.com>



On 19/01/2017 23:35, Xueming Shen wrote:
> Thanks Claes!
>
> webrev has been updated accordingly
>
> http://cr.openjdk.java.net/~sherman/8173072/webrev
>
The changes looks okay although I'd to understand more as to why tools 
might be generating the extra fields in this way.

Also is the "zipinfo-time" property needed now?

-Alan

From xueming.shen at oracle.com  Fri Jan 20 08:28:24 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 20 Jan 2017 00:28:24 -0800
Subject: JDK-8173072: zipfs fails to handle incorrect info-zip "extended
	timestamp extra field"
In-Reply-To: <ca35fe90-ed8d-3d45-4ce1-cce24a4a0da5@oracle.com>
References: <5881321A.9070105@oracle.com>
	<c0296d19-3805-07b4-6e8d-75964ede1509@oracle.com>
	<58814D40.8030804@oracle.com>
	<ca35fe90-ed8d-3d45-4ce1-cce24a4a0da5@oracle.com>
Message-ID: <5881CA28.8010802@oracle.com>

On 1/19/17, 11:44 PM, Alan Bateman wrote:
>
>
> On 19/01/2017 23:35, Xueming Shen wrote:
>> Thanks Claes!
>>
>> webrev has been updated accordingly
>>
>> http://cr.openjdk.java.net/~sherman/8173072/webrev
>>
> The changes looks okay although I'd to understand more as to why tools 
> might be generating the extra fields in this way.

I'm reading info-zip ZIP file spec again.  it turned out this might be a 
legitimate extra fields.
The spec suggests the "flags" in BOTH headers indicate what are in the 
"local" extra field. So
The flags in central header also indicates the local entry, not the cen 
entry at all, confirmed
with info zip tool.

-----------------------------

          The lower three bits of Flags in both headers indicate which time-
          stamps are present in the LOCAL extra field:

                 bit 0           if set, modification time is present
                 bit 1           if set, access time is present
                 bit 2           if set, creation time is present
                 bits 3-7        reserved for additional timestamps; not set

------------------------------

It means we need to fix the ZipOutputStream to output the correct cen 
entry flags, if there
are more extra timestamps. (jar does not create them)

>
> Also is the "zipinfo-time" property needed now?

Yes, that property basically serves the purpose of helping performance. 
If you are interested
at mtime ony and care about performance. The flag will help not go up to 
read the loc entry,
even there are a/ctime entries there.

-Sherman


From Alan.Bateman at oracle.com  Fri Jan 20 08:40:11 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Jan 2017 08:40:11 +0000
Subject: JDK-8173072: zipfs fails to handle incorrect info-zip "extended
	timestamp extra field"
In-Reply-To: <58814D40.8030804@oracle.com>
References: <5881321A.9070105@oracle.com>
	<c0296d19-3805-07b4-6e8d-75964ede1509@oracle.com>
	<58814D40.8030804@oracle.com>
Message-ID: <3b0ef252-d44c-dd92-2ce4-a12c8b174bf3@oracle.com>

BTW: Do we need to create some test infrastructure to allow tests create 
specially crafted zip files? With changes like this then the 
implementation tolerates truncated extended timestamps but we don't have 
anything in the tests to be confident that such changes will keep working.

-Alan


From xueming.shen at oracle.com  Fri Jan 20 08:46:49 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 20 Jan 2017 00:46:49 -0800
Subject: JDK-8173072: zipfs fails to handle incorrect info-zip "extended
	timestamp extra field"
In-Reply-To: <3b0ef252-d44c-dd92-2ce4-a12c8b174bf3@oracle.com>
References: <5881321A.9070105@oracle.com>
	<c0296d19-3805-07b4-6e8d-75964ede1509@oracle.com>
	<58814D40.8030804@oracle.com>
	<3b0ef252-d44c-dd92-2ce4-a12c8b174bf3@oracle.com>
Message-ID: <5881CE79.70809@oracle.com>

Can put in something together with the fix. Probably a variant of ZOS 
that remove
those sanity check.

-Sherman

On 1/20/17, 12:40 AM, Alan Bateman wrote:
> BTW: Do we need to create some test infrastructure to allow tests 
> create specially crafted zip files? With changes like this then the 
> implementation tolerates truncated extended timestamps but we don't 
> have anything in the tests to be confident that such changes will keep 
> working.
>
> -Alan
>


From xueming.shen at oracle.com  Fri Jan 20 09:03:49 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 20 Jan 2017 01:03:49 -0800
Subject: JDK-8173072: zipfs fails to handle incorrect info-zip "extended
	timestamp extra field"
Message-ID: <5881D275.1040404@oracle.com>

On 1/20/17, 12:28 AM, Xueming Shen wrote:
>
> -----------------------------
>
>          The lower three bits of Flags in both headers indicate which 
> time-
>          stamps are present in the LOCAL extra field:
>
>                 bit 0           if set, modification time is present
>                 bit 1           if set, access time is present
>                 bit 2           if set, creation time is present
>                 bits 3-7        reserved for additional timestamps; 
> not set
>
> ------------------------------
>
> It means we need to fix the ZipOutputStream to output the correct cen 
> entry flags, if there
> are more extra timestamps. (jar does not create them)
>

False alarm, It has been years since I wrote this part of the code Just 
doubt checked the code,
it appears both ZipOutputStream and zipfs.Entry.writeCEN() are 
implemented correctly to output
the correct flags that indicate the timestamps in loc only.

ZFS.Entry.writeCEN
            if (elenEXTT != 0) {
                 writeShort(os, EXTID_EXTT);
                 writeShort(os, elenEXTT - 4);
                 if (ctime == -1)
                     os.write(0x3);          // mtime and atime
                 else
                     os.write(0x7);          // mtime, atime and ctime
                 writeInt(os, javaToUnixTime(mtime));
             }


ZOS.writeCEN
        {
                writeShort(EXTID_EXTT);
                 if (e.mtime != null) {
                     writeShort(5);      // flag + mtime
                     writeByte(flagEXTT);
                     writeInt(umtime);
         } else {
                     writeShort(1);      // flag only
                     writeByte(flagEXTT);
         }

So the better fix for this one should simply not try to read a/ctime at all
in cen reading code.

-Sherman


From kasperni at gmail.com  Fri Jan 20 10:03:41 2017
From: kasperni at gmail.com (Kasper Nielsen)
Date: Fri, 20 Jan 2017 11:03:41 +0100
Subject: Stream based API for tree like structures
Message-ID: <CAPs6150GGF9QNXqnhcVSu0aASTtoPqvXqkkxfVaq+eHpnMkkpg@mail.gmail.com>

Hi,

Sorry if this is a bit off-topic, but I thought but I thought it might have
some general interest if Java ever got some proper tree/graph collection
classes.

Has anyone developed a stream based API that allows for tree based travels.
I'm mainly thinking about functionality for

1)
Whether or not to do recursive traversal of all child nodes, only 1 level
of child nodes, or just siblings

2)
Order of traversal: depth/breadth first.

I'm trying to avoid an explosion of methods such as
streamSieblingsDepthOrderFirst.
One thought I had was taking a var arg of options to stream and
parallelStream such as:
enum TreeStreamOptions {
   SIEBLINGS_ONLY, RECURSIVELY, DEPTH_FIRST, BREATH_FIRST;
}
Stream<T> stream(TreeStreamOptions... options)
Stream<T> parallelStream(TreeStreamOptions... options)

another one could be

class TreeStreamOptions {
   TreeStreamOptions setDepthFirst();
   TreeStreamOptions setBreathFirst();
   TreeStreamOptions setDepth(); (0 sieblings only, Integer.MAX->infinity)
}
Stream<T> stream(TreeStreamOptions options)
Stream<T> parallelStream(TreeStreamOptions options)

While a visitor pattern would make sense for many use cases. I really like
the simplicity of just working with streams.

Maybe someone has some thoughts on this.

Best
  Kasper

From daniel.fuchs at oracle.com  Fri Jan 20 13:07:24 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 20 Jan 2017 13:07:24 +0000
Subject: 8172971: java.management could use System.Logger
In-Reply-To: <0ED0BC42-B8ED-4AA7-A0E9-B1423524A507@oracle.com>
References: <de015d3e-639c-aba5-03d7-305de9d304b6@oracle.com>
	<9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com>
	<b0579dff-4a65-2ee1-347f-bbe39ae85ca2@oracle.com>
	<0ED0BC42-B8ED-4AA7-A0E9-B1423524A507@oracle.com>
Message-ID: <ba7c627c-7fff-eb4e-16c9-3d7d0aeabc99@oracle.com>

Hi Mandy,

On 19/01/17 19:07, Mandy Chung wrote:
>>> This test should have @modules java.logging and java.management.
>> OK - I believed @modules java.management should already be in TEST.ROOT
>> I will double check.
> If @modules is specified in a test, it will override the one in TEST.properties (I think that?s what you meant).  In any case, this test depends on java.logging.

I fixed the @modules tag, and added a second test that installs
its own LoggerFinder and doesn't depend on java.logging.

The rest is unchanged (only test changes).

http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.01/

best regards,

-- daniel

From ramanand.patil at oracle.com  Fri Jan 20 13:21:30 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Fri, 20 Jan 2017 05:21:30 -0800 (PST)
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
Message-ID: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>

Hi all,
Please review the following bug fix:
Bug: https://bugs.openjdk.java.net/browse/JDK-8167063
Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.00/

Handled the SecurityException and LinkageError which can be thrown from Class.forName(...) method used in LauncherHelper.java and added corresponding error messages to launcher.properties.
Though the reported bug is because of the LinkageError, Security exception is also handled to be safe from calling Class.forName method.

Regards,
Ramanand.

From Alan.Bateman at oracle.com  Fri Jan 20 14:32:48 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 20 Jan 2017 14:32:48 +0000
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
In-Reply-To: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>
References: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>
Message-ID: <07c4c8b9-695b-6ba8-2cf8-09423e467379@oracle.com>

On 20/01/2017 13:21, Ramanand Patil wrote:

> Hi all,
> Please review the following bug fix:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167063
> Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.00/
>
> Handled the SecurityException and LinkageError which can be thrown from Class.forName(...) method used in LauncherHelper.java and added corresponding error messages to launcher.properties.
> Though the reported bug is because of the LinkageError, Security exception is also handled to be safe from calling Class.forName method.
>
I see this changes loadMainClass to abort with resources that are keyed 
on java.launcher.cls.error6 and java.launcher.cls.error7 but they don't 
appear in the launcher.properties file. Does this work? I would assume 
MissingResourceException is thrown.

For java.launcher.module.error3 and java.launcher.module.error4 then 
"link" is likely to confuse people. Sure, there may be linkage errors 
but there are many linkage errors and I think would be a lot clearer if 
the message was "Unable to load main class {0} from module {1}\n\{2}".

It's not clear to me that having a different message for security 
exceptions make sense, esp. when the exception is printed. So I think I 
would drop that.

Also loadModuleMainClass0 is unusual method name, we've mostly (not 
always) used the 0 suffix on native methods. In any case, it doesn't 
look like it is needed, the code was okay in loadModuleMainClass as it was.

One final point is that is the nesting catching of LinkageError and 
SecurityException in loadMainClass, I assume you don't need the inner catch.

-Alan

From forax at univ-mlv.fr  Fri Jan 20 15:00:06 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 20 Jan 2017 16:00:06 +0100 (CET)
Subject: Stream based API for tree like structures
In-Reply-To: <CAPs6150GGF9QNXqnhcVSu0aASTtoPqvXqkkxfVaq+eHpnMkkpg@mail.gmail.com>
References: <CAPs6150GGF9QNXqnhcVSu0aASTtoPqvXqkkxfVaq+eHpnMkkpg@mail.gmail.com>
Message-ID: <1135864861.2372237.1484924406655.JavaMail.zimbra@u-pem.fr>

https://gist.github.com/forax/bca6877e019d134f87c4cb1e8efae9cd

R?mi

----- Mail original -----
> De: "Kasper Nielsen" <kasperni at gmail.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 20 Janvier 2017 11:03:41
> Objet: Stream based API for tree like structures

> Hi,
> 
> Sorry if this is a bit off-topic, but I thought but I thought it might have
> some general interest if Java ever got some proper tree/graph collection
> classes.
> 
> Has anyone developed a stream based API that allows for tree based travels.
> I'm mainly thinking about functionality for
> 
> 1)
> Whether or not to do recursive traversal of all child nodes, only 1 level
> of child nodes, or just siblings
> 
> 2)
> Order of traversal: depth/breadth first.
> 
> I'm trying to avoid an explosion of methods such as
> streamSieblingsDepthOrderFirst.
> One thought I had was taking a var arg of options to stream and
> parallelStream such as:
> enum TreeStreamOptions {
>   SIEBLINGS_ONLY, RECURSIVELY, DEPTH_FIRST, BREATH_FIRST;
> }
> Stream<T> stream(TreeStreamOptions... options)
> Stream<T> parallelStream(TreeStreamOptions... options)
> 
> another one could be
> 
> class TreeStreamOptions {
>   TreeStreamOptions setDepthFirst();
>   TreeStreamOptions setBreathFirst();
>   TreeStreamOptions setDepth(); (0 sieblings only, Integer.MAX->infinity)
> }
> Stream<T> stream(TreeStreamOptions options)
> Stream<T> parallelStream(TreeStreamOptions options)
> 
> While a visitor pattern would make sense for many use cases. I really like
> the simplicity of just working with streams.
> 
> Maybe someone has some thoughts on this.
> 
> Best
>   Kasper

From sean.coffey at oracle.com  Fri Jan 20 15:08:18 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 20 Jan 2017 15:08:18 +0000
Subject: RFR: 8077395: org.omg.CORBA_2_3.portable.InputStream constructor
	should not specify JDK-specific property
In-Reply-To: <ada2249c-4467-3729-26f6-0aec6874c0cb@Oracle.com>
References: <8da604c6-74f5-d9ac-d690-0d659e6a6a89@oracle.com>
	<ada2249c-4467-3729-26f6-0aec6874c0cb@Oracle.com>
Message-ID: <588227E2.8080706@oracle.com>

Roger, Lance,

Thanks for the reviews. I'll make the suggested edit before pushing. 
Just waiting on CCC approval now.

Regards,
Sean.

On 19/01/17 18:28, Roger Riggs wrote:
> Hi Sean,
>
> Looks ok but can you turn those texts into a sentence (capitalize it 
> and final ".').
>
> Thanks, Roger
>
>
> On 1/19/2017 12:59 PM, Se?n Coffey wrote:
>> Changes made to the CORBA InputStream/OutputStream class back in 2013 
>> contained javadoc comments which should have been marked as 
>> implementation specific. The minor edits here should correct that.
>>
>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8077395/webrev/
>> JBS : https://bugs.openjdk.java.net/browse/JDK-8077395
>>
>> regards,
>> Sean.
>>
>


From mandy.chung at oracle.com  Fri Jan 20 15:42:48 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 20 Jan 2017 07:42:48 -0800
Subject: 8172971: java.management could use System.Logger
In-Reply-To: <ba7c627c-7fff-eb4e-16c9-3d7d0aeabc99@oracle.com>
References: <de015d3e-639c-aba5-03d7-305de9d304b6@oracle.com>
	<9D6C2F96-6375-40BC-B33D-200D38B0F27C@oracle.com>
	<b0579dff-4a65-2ee1-347f-bbe39ae85ca2@oracle.com>
	<0ED0BC42-B8ED-4AA7-A0E9-B1423524A507@oracle.com>
	<ba7c627c-7fff-eb4e-16c9-3d7d0aeabc99@oracle.com>
Message-ID: <16CD0F6E-EC28-4191-9662-88EA0C5EF4CA@oracle.com>


> On Jan 20, 2017, at 5:07 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> The rest is unchanged (only test changes).
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8172971/webrev.01/
> 

+1

Mandy

From paul.sandoz at oracle.com  Fri Jan 20 15:58:23 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 20 Jan 2017 07:58:23 -0800
Subject: RFR 8173083: VarHandle usages in LockSupport and
	ThreadLocalRandom result in circularity issues
In-Reply-To: <CA+kOe0-oQh07AurAheLarQGHnHoukDWczvysuQDH_nqn=Ud48A@mail.gmail.com>
References: <B0E0995A-44AC-4015-91EE-8D0477233EBB@oracle.com>
	<CA+kOe0-oQh07AurAheLarQGHnHoukDWczvysuQDH_nqn=Ud48A@mail.gmail.com>
Message-ID: <FD8EEC2C-1D08-4617-B6E0-E5261B0FD8FE@oracle.com>


> On 19 Jan 2017, at 19:23, Martin Buchholz <martinrb at google.com> wrote:
> 
> Seems OK.

Thanks.


> It would be nice to somehow get more confidence we don't have remaining circularities.

From my experience usually these kind of circularities show up intermittently but regularly enough. Tricky to induce locally.


>   I agree a specialized concurrent hash table to replace ConcurrentHashMap might help.
> 

Yes, it should reliably break the cycle.


> I was surprised to see below a change in parentheses that seems to change the behavior.
> 
>      final long nextSeed() {
>          Thread t; long r; // read and update per-thread seed
> -        SEED.set(t = Thread.currentThread(),
> -                 (r = (long) SEED.get(t)) + GAMMA);
> +        U.putLong(t = Thread.currentThread(), SEED,
> +                  r = U.getLong(t, SEED) + GAMMA);
>          return r;
>      }

The update reverted to the previous code:

http://hg.openjdk.java.net/jdk9/dev/jdk/file/7901a13a051c/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java <http://hg.openjdk.java.net/jdk9/dev/jdk/file/7901a13a051c/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java>

I added the parentheses to bound the cast.

Thanks,
Paul.

> 
> 
> 
> On Thu, Jan 19, 2017 at 6:52 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
> Hi,
> 
> Unfortunately the switch from Unsafe to VarHandle in LockSupport and ThreadLocalRandom caused some circularity issues (similar to those for AtomicInteger) that have shown up in continuous testing (but not when i tested explicitly using the infrastructure).
> 
> The main problem is MethodType leverages ConcurrentHashMap which under certain conditions uses TLR [*].
> 
> We know we want to replace CHM usage in MethodType with an alternative Peter created, which i think we can pursue post 9 and break the circularity.
> 
> This patch reverts the back to Unsafe usage:
> 
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8173083-vh-to-unsafe-ls-tlr/webrev/index.html <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8173083-vh-to-unsafe-ls-tlr/webrev/index.html>
> 
> I did not revert the changes to Striped64 and ForkJoinWorkerThread.
> 
> Thanks,
> Paul.
> 
> [*]
> 1) The clinit of LockSupport creates a VarHandle;
> 
> 2) a VarHandle creates MethodTypes;
> 
> 3) that are stored in a CHM;
> 
> 4) which on occasion uses TLR
> 
> 5) that uses a VarHandle whose VarForm is being initalized in 1)
> 
> 
> 


From jbluettduncan at gmail.com  Fri Jan 20 16:48:51 2017
From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan)
Date: Fri, 20 Jan 2017 16:48:51 +0000
Subject: Stream based API for tree like structures
In-Reply-To: <1135864861.2372237.1484924406655.JavaMail.zimbra@u-pem.fr>
References: <CAPs6150GGF9QNXqnhcVSu0aASTtoPqvXqkkxfVaq+eHpnMkkpg@mail.gmail.com>
	<1135864861.2372237.1484924406655.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAPMys85cBQ=bCB4NF8-xFZqaVPhTbziedtHKNRmbphgxwYwB-g@mail.gmail.com>

Hi Kasper,

If what you're looking for is a more immediate solution, I can think of a
couple of libraries which may do the trick:

   1. Durian <https://github.com/diffplug/durian>'s TreeDef and TreeStream.
   Difficult to understand and use at first, but I believe it ticks a good
   number of boxes for you.
   2. Guava 21 <https://github.com/google/guava/wiki/Release21>'s
   `TreeTraverser` with the library's new Java 8 support. For example,

   `Streams.stream(TreeTraverser.using(Node::getChildNodes).{preOrder|postOrder|breadthFirst}Traversal(rootNode));`

Both of these solutions allow depth- and breadth-first traversals (the
Guava solution allows both preOrder and postOrder depth traversals), but
it's not clear to me if either of them allows you to set a maximum depth to
traverse into.

Hope this helps.

Best regards,
Jonathan

On 20 January 2017 at 15:00, Remi Forax <forax at univ-mlv.fr> wrote:

> https://gist.github.com/forax/bca6877e019d134f87c4cb1e8efae9cd
>
> R?mi
>
> ----- Mail original -----
> > De: "Kasper Nielsen" <kasperni at gmail.com>
> > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Envoy?: Vendredi 20 Janvier 2017 11:03:41
> > Objet: Stream based API for tree like structures
>
> > Hi,
> >
> > Sorry if this is a bit off-topic, but I thought but I thought it might
> have
> > some general interest if Java ever got some proper tree/graph collection
> > classes.
> >
> > Has anyone developed a stream based API that allows for tree based
> travels.
> > I'm mainly thinking about functionality for
> >
> > 1)
> > Whether or not to do recursive traversal of all child nodes, only 1 level
> > of child nodes, or just siblings
> >
> > 2)
> > Order of traversal: depth/breadth first.
> >
> > I'm trying to avoid an explosion of methods such as
> > streamSieblingsDepthOrderFirst.
> > One thought I had was taking a var arg of options to stream and
> > parallelStream such as:
> > enum TreeStreamOptions {
> >   SIEBLINGS_ONLY, RECURSIVELY, DEPTH_FIRST, BREATH_FIRST;
> > }
> > Stream<T> stream(TreeStreamOptions... options)
> > Stream<T> parallelStream(TreeStreamOptions... options)
> >
> > another one could be
> >
> > class TreeStreamOptions {
> >   TreeStreamOptions setDepthFirst();
> >   TreeStreamOptions setBreathFirst();
> >   TreeStreamOptions setDepth(); (0 sieblings only, Integer.MAX->infinity)
> > }
> > Stream<T> stream(TreeStreamOptions options)
> > Stream<T> parallelStream(TreeStreamOptions options)
> >
> > While a visitor pattern would make sense for many use cases. I really
> like
> > the simplicity of just working with streams.
> >
> > Maybe someone has some thoughts on this.
> >
> > Best
> >   Kasper
>

From martinrb at google.com  Fri Jan 20 17:45:49 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 20 Jan 2017 09:45:49 -0800
Subject: RFR 8173083: VarHandle usages in LockSupport and
	ThreadLocalRandom result in circularity issues
In-Reply-To: <FD8EEC2C-1D08-4617-B6E0-E5261B0FD8FE@oracle.com>
References: <B0E0995A-44AC-4015-91EE-8D0477233EBB@oracle.com>
	<CA+kOe0-oQh07AurAheLarQGHnHoukDWczvysuQDH_nqn=Ud48A@mail.gmail.com>
	<FD8EEC2C-1D08-4617-B6E0-E5261B0FD8FE@oracle.com>
Message-ID: <CA+kOe0_=PmJogocO688Je1kvanN2vn+gFQkYk05j0_YEwmiPvg@mail.gmail.com>

On Fri, Jan 20, 2017 at 7:58 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> I was surprised to see below a change in parentheses that seems to change
> the behavior.
>
>      final long nextSeed() {
>          Thread t; long r; // read and update per-thread seed
> -        SEED.set(t = Thread.currentThread(),
> -                 (r = (long) SEED.get(t)) + GAMMA);
> +        U.putLong(t = Thread.currentThread(), SEED,
> +                  r = U.getLong(t, SEED) + GAMMA);
>          return r;
>      }
>
>
> The update reverted to the previous code:
>
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/7901a13a051c/src/java.base/
> share/classes/java/util/concurrent/ThreadLocalRandom.java
>
> I added the parentheses to bound the cast.
>

It still looks to me like the parenthesis got added to the wrong place (in
the previous changeset!), changing the behavior, and the current reverted
code is correct.

From paul.sandoz at oracle.com  Fri Jan 20 17:48:51 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 20 Jan 2017 09:48:51 -0800
Subject: RFR 8173083: VarHandle usages in LockSupport and
	ThreadLocalRandom result in circularity issues
In-Reply-To: <CA+kOe0_=PmJogocO688Je1kvanN2vn+gFQkYk05j0_YEwmiPvg@mail.gmail.com>
References: <B0E0995A-44AC-4015-91EE-8D0477233EBB@oracle.com>
	<CA+kOe0-oQh07AurAheLarQGHnHoukDWczvysuQDH_nqn=Ud48A@mail.gmail.com>
	<FD8EEC2C-1D08-4617-B6E0-E5261B0FD8FE@oracle.com>
	<CA+kOe0_=PmJogocO688Je1kvanN2vn+gFQkYk05j0_YEwmiPvg@mail.gmail.com>
Message-ID: <70AEC3C1-E8A8-4EC6-BCCE-D97FF6758774@oracle.com>


> On 20 Jan 2017, at 09:45, Martin Buchholz <martinrb at google.com> wrote:
> 
> 
> 
> On Fri, Jan 20, 2017 at 7:58 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
> 
>> I was surprised to see below a change in parentheses that seems to change the behavior.
>> 
>>      final long nextSeed() {
>>          Thread t; long r; // read and update per-thread seed
>> -        SEED.set(t = Thread.currentThread(),
>> -                 (r = (long) SEED.get(t)) + GAMMA);
>> +        U.putLong(t = Thread.currentThread(), SEED,
>> +                  r = U.getLong(t, SEED) + GAMMA);
>>          return r;
>>      }
> 
> The update reverted to the previous code:
> 
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/7901a13a051c/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java <http://hg.openjdk.java.net/jdk9/dev/jdk/file/7901a13a051c/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java>
> 
> I added the parentheses to bound the cast.
> 
> It still looks to me like the parenthesis got added to the wrong place (in the previous changeset!),

What place do you think they should be?

Paul.

From martinrb at google.com  Fri Jan 20 17:54:11 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 20 Jan 2017 09:54:11 -0800
Subject: RFR 8173083: VarHandle usages in LockSupport and
	ThreadLocalRandom result in circularity issues
In-Reply-To: <70AEC3C1-E8A8-4EC6-BCCE-D97FF6758774@oracle.com>
References: <B0E0995A-44AC-4015-91EE-8D0477233EBB@oracle.com>
	<CA+kOe0-oQh07AurAheLarQGHnHoukDWczvysuQDH_nqn=Ud48A@mail.gmail.com>
	<FD8EEC2C-1D08-4617-B6E0-E5261B0FD8FE@oracle.com>
	<CA+kOe0_=PmJogocO688Je1kvanN2vn+gFQkYk05j0_YEwmiPvg@mail.gmail.com>
	<70AEC3C1-E8A8-4EC6-BCCE-D97FF6758774@oracle.com>
Message-ID: <CA+kOe08JY3xinam+0thAurY-xDZ6KA+eC9WcidPNtvDovZFjzQ@mail.gmail.com>

> (r = (long) SEED.get(t)) + GAMMA);
=>
 r = ((long) SEED.get(t)) + GAMMA);
or I think you can just leave them out
 r = (long) SEED.get(t) + GAMMA);

On Fri, Jan 20, 2017 at 9:48 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> On 20 Jan 2017, at 09:45, Martin Buchholz <martinrb at google.com> wrote:
>
>
>
> On Fri, Jan 20, 2017 at 7:58 AM, Paul Sandoz <paul.sandoz at oracle.com>
> wrote:
>
>>
>> I was surprised to see below a change in parentheses that seems to change
>> the behavior.
>>
>>      final long nextSeed() {
>>          Thread t; long r; // read and update per-thread seed
>> -        SEED.set(t = Thread.currentThread(),
>> -                 (r = (long) SEED.get(t)) + GAMMA);
>> +        U.putLong(t = Thread.currentThread(), SEED,
>> +                  r = U.getLong(t, SEED) + GAMMA);
>>          return r;
>>      }
>>
>>
>> The update reverted to the previous code:
>>
>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/7901a13a051c/
>> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java
>>
>> I added the parentheses to bound the cast.
>>
>
> It still looks to me like the parenthesis got added to the wrong place (in
> the previous changeset!),
>
>
> What place do you think they should be?
>
> Paul.
>

From paul.sandoz at oracle.com  Fri Jan 20 18:35:00 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 20 Jan 2017 10:35:00 -0800
Subject: RFR 8173083: VarHandle usages in LockSupport and
	ThreadLocalRandom result in circularity issues
In-Reply-To: <CA+kOe08JY3xinam+0thAurY-xDZ6KA+eC9WcidPNtvDovZFjzQ@mail.gmail.com>
References: <B0E0995A-44AC-4015-91EE-8D0477233EBB@oracle.com>
	<CA+kOe0-oQh07AurAheLarQGHnHoukDWczvysuQDH_nqn=Ud48A@mail.gmail.com>
	<FD8EEC2C-1D08-4617-B6E0-E5261B0FD8FE@oracle.com>
	<CA+kOe0_=PmJogocO688Je1kvanN2vn+gFQkYk05j0_YEwmiPvg@mail.gmail.com>
	<70AEC3C1-E8A8-4EC6-BCCE-D97FF6758774@oracle.com>
	<CA+kOe08JY3xinam+0thAurY-xDZ6KA+eC9WcidPNtvDovZFjzQ@mail.gmail.com>
Message-ID: <B437A4E3-0A63-4393-9A59-A12AE4261C7F@oracle.com>


> On 20 Jan 2017, at 09:54, Martin Buchholz <martinrb at google.com> wrote:
> 
>>> 
> (r = (long) SEED.get(t)) + GAMMA);
> =>
>  r = ((long) SEED.get(t)) + GAMMA);
> or I think you can just leave them out
>  r = (long) SEED.get(t) + GAMMA);
> 

Doh, yes i see now, cross eyed! either of those two is fine.

Thanks,
Paul.

> On Fri, Jan 20, 2017 at 9:48 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
> 
>> On 20 Jan 2017, at 09:45, Martin Buchholz <martinrb at google.com <mailto:martinrb at google.com>> wrote:
>> 
>> 
>> 
>> On Fri, Jan 20, 2017 at 7:58 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>> 
>>> I was surprised to see below a change in parentheses that seems to change the behavior.
>>> 
>>>      final long nextSeed() {
>>>          Thread t; long r; // read and update per-thread seed
>>> -        SEED.set(t = Thread.currentThread(),
>>> -                 (r = (long) SEED.get(t)) + GAMMA);
>>> +        U.putLong(t = Thread.currentThread(), SEED,
>>> +                  r = U.getLong(t, SEED) + GAMMA);
>>>          return r;
>>>      }
>> 
>> The update reverted to the previous code:
>> 
>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/7901a13a051c/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java <http://hg.openjdk.java.net/jdk9/dev/jdk/file/7901a13a051c/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java>
>> 
>> I added the parentheses to bound the cast.
>> 
>> It still looks to me like the parenthesis got added to the wrong place (in the previous changeset!),
> 
> What place do you think they should be?
> 
> Paul.
> 


From xueming.shen at oracle.com  Fri Jan 20 20:15:30 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 20 Jan 2017 12:15:30 -0800
Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to 1.2.11
Message-ID: <58826FE2.4050709@oracle.com>

Hi,

Please review the change to upgrade the zlib bundled in jdk repo from v1.2.8
to v1.2.11. jdk9 by default has been configured to build by using the 
native/
platform/os's zlib on all non-windows platform [1] So the change will 
only have
effect on the Windows' binaries.

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

As always, any source level changes, compared to the official zlib 
release, other
than the copyright notes addition,  is logged at

http://cr.openjdk.java.net/~sherman/8173140/webrev/src/java.base/share/native/libzip/zlib-1.2.11/patches/ChangeLog_java.html

most are for removing the compiler warning. Compared ot 1.2.8 the gz* code
are removed from the repo. as they are actually not used really by the jdk.

(arguably, it appears the version number in directory path zlib-1.2.11 
in the
repo is not necessary. The make file changes would not be necessary if the
path is simply src/java.base/share/native/libzip/zlib)

Thanks,
Sherman

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

From vitalyd at gmail.com  Fri Jan 20 22:14:58 2017
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 20 Jan 2017 17:14:58 -0500
Subject: Reading subprocess stdout susceptible to deadlock
In-Reply-To: <CAHjP37Hy65oi0fVyuuh9TWUf5TRFoJUSwXM2T9hd2=J9Qtnp=Q@mail.gmail.com>
References: <CAHjP37E+_x9v6JmJ8dB38wsEPYLHbjfhCHzu_xZde+KcA37zrA@mail.gmail.com>
	<56FBDE18.1000809@Oracle.com>
	<CAHjP37Hy65oi0fVyuuh9TWUf5TRFoJUSwXM2T9hd2=J9Qtnp=Q@mail.gmail.com>
Message-ID: <CAHjP37GBD+_71Oiv9Otj7Fv7Fz=KFXFuLR-snFxDtYq+-FNAeQ@mail.gmail.com>

Hi all,

Just wanted to revisit this issue again.  I haven't filed a JBS entry for
it, primarily because I'd like some validation/confirmation/hunch that this
is, indeed, a bug before proceeding.  Does anyone have thoughts on this
scenario?

Thanks

On Wed, Mar 30, 2016 at 10:45 AM, Vitaly Davidovich <vitalyd at gmail.com>
wrote:

> Hi Roger,
>
> The stack traces are:
>
> "process reaper" #44 daemon prio=10 os_prio=0 tid=0x0000000004083000 nid=0x7b1c waiting for monitor entry [0x00002b703ffbe000]
>
>    java.lang.Thread.State: BLOCKED (on object monitor)
>
>         at java.lang.UNIXProcess$ProcessPipeInputStream.processExited(UNIXProcess.java:528)
>
>         - waiting to lock <0x00000000aba7a790> (a java.lang.UNIXProcess$ProcessPipeInputStream)
>
>         at java.lang.UNIXProcess.lambda$initStreams$275(UNIXProcess.java:299)
>
>         at java.lang.UNIXProcess$$Lambda$10/523574157.run(Unknown Source)
>
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
>
>
>
>
> "pool-1-thread-1" #43 prio=5 os_prio=0 tid=0x0000000003ee3800 nid=0x7b13 runnable [0x00002b7050837000]
>
>    java.lang.Thread.State: RUNNABLE
>
>         at java.io.FileInputStream.readBytes(Native Method)
>
>         at java.io.FileInputStream.read(FileInputStream.java:255)
>
>         at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
>
>         at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
>
>         at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
>
>         - locked <0x00000000aba7a790> (a java.lang.UNIXProcess$ProcessPipeInputStream)
>
>         at SomeClass.callReadOnInputStream()
>
>
> SomeClass.callReadOnInputStream() is something that invokes
> InputStream.read(byte[], int, int) on the stream.
>
> Thanks
>
>
> On Wed, Mar 30, 2016 at 10:09 AM, Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
>> Hi Vitaly,
>>
>> I haven't seen that before, please create a bug and include the stack
>> traces.
>>
>> Thanks, Roger
>>
>>
>>
>> On 3/30/2016 9:56 AM, Vitaly Davidovich wrote:
>>
>>> Hi,
>>>
>>> It seems that doing a blocking read on a subprocess's stdout can lead to
>>> deadlock between the thread doing the read and the process reaper thread.
>>> The deadlock occurs because the reader is synchronized on the
>>> ProcessPipeInputStream, blocks for more data to consume, and process
>>> reaper
>>> comes along trying to call processExited, which also synchronizes on the
>>> same PPIS.  The reader appears stuck because it's not seeing the EOF due
>>> to
>>> process reaper not being able to close the stream.
>>>
>>> I couldn't find any existing reports of this via quick search, which
>>> makes
>>> me wonder if I'm missing something.  Is this a known issue?
>>>
>>> Thanks
>>>
>>>
>>>
>>
>

From paul.sandoz at oracle.com  Fri Jan 20 23:48:36 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 20 Jan 2017 15:48:36 -0800
Subject: RFR 8172732: spec clarification for URLClassLoader for Multirelease
	jars
Message-ID: <0B08BA3A-3752-477C-9A75-533A2FD27C96@oracle.com>

Hi,

Please review this small clarification to the specification of URLClassLoader for multi-release jars.

Thanks,
Paul.

diff -r 467b3b7aeb1b src/java.base/share/classes/java/net/URLClassLoader.java
--- a/src/java.base/share/classes/java/net/URLClassLoader.java	Fri Jan 20 07:05:40 2017 -0800
+++ b/src/java.base/share/classes/java/net/URLClassLoader.java	Fri Jan 20 15:47:54 2017 -0800
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1997, 2016, 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
@@ -73,9 +73,9 @@
  * The classes that are loaded are by default granted permission only to
  * access the URLs specified when the URLClassLoader was created.
  * <p>
- * This class loader supports the loading of classes from the contents of a
- * <a href="../util/jar/JarFile.html#multirelease">multi-release</a> JAR file
- * that is referred to by a given URL.
+ * This class loader supports the loading of classes and resources from the
+ * contents of a <a href="../util/jar/JarFile.html#multirelease">multi-release</a>
+ * JAR file that is referred to by a given URL.
  *
  * @author  David Connelly
  * @since   1.2


From mandy.chung at oracle.com  Fri Jan 20 23:51:20 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 20 Jan 2017 15:51:20 -0800
Subject: RFR 8172732: spec clarification for URLClassLoader for
	Multirelease jars
In-Reply-To: <0B08BA3A-3752-477C-9A75-533A2FD27C96@oracle.com>
References: <0B08BA3A-3752-477C-9A75-533A2FD27C96@oracle.com>
Message-ID: <5CBCA784-FFF3-4930-9701-40ACA0907108@oracle.com>

+1

Mandy

> On Jan 20, 2017, at 3:48 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Please review this small clarification to the specification of URLClassLoader for multi-release jars.
> 
> Thanks,
> Paul.
> 
> diff -r 467b3b7aeb1b src/java.base/share/classes/java/net/URLClassLoader.java
> --- a/src/java.base/share/classes/java/net/URLClassLoader.java	Fri Jan 20 07:05:40 2017 -0800
> +++ b/src/java.base/share/classes/java/net/URLClassLoader.java	Fri Jan 20 15:47:54 2017 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1997, 2016, 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
> @@ -73,9 +73,9 @@
>  * The classes that are loaded are by default granted permission only to
>  * access the URLs specified when the URLClassLoader was created.
>  * <p>
> - * This class loader supports the loading of classes from the contents of a
> - * <a href="../util/jar/JarFile.html#multirelease">multi-release</a> JAR file
> - * that is referred to by a given URL.
> + * This class loader supports the loading of classes and resources from the
> + * contents of a <a href="../util/jar/JarFile.html#multirelease">multi-release</a>
> + * JAR file that is referred to by a given URL.
>  *
>  * @author  David Connelly
>  * @since   1.2
> 


From felix.yang at oracle.com  Sat Jan 21 05:43:36 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Fri, 20 Jan 2017 21:43:36 -0800
Subject: RFR 8173159, Problem list
	java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java
	on Windows
Message-ID: <AAAD148E-1130-4078-B04A-D10F1FB177E0@oracle.com>

Hi there,
   please review the  request to problem-list the test on Windows platform. It has been observed to be failing frequently.

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

Thanks,
Felix


diff -r 1045f9722697 test/ProblemList.txt
--- a/test/ProblemList.txt	Sat Jan 21 03:53:21 2017 +0000
+++ b/test/ProblemList.txt	Fri Jan 20 21:15:34 2017 -0800
@@ -228,6 +228,8 @@
 
 java/rmi/activation/Activatable/extLoadedImpl/ext.sh            8062724 generic-all
 
+java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java 8169569 windows-all
+
 sun/rmi/rmic/newrmic/equivalence/run.sh                         8145980 generic-all
 
 ############################################################################


From erik.joelsson at oracle.com  Sat Jan 21 08:30:17 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Sat, 21 Jan 2017 09:30:17 +0100
Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to
	1.2.11
In-Reply-To: <58826FE2.4050709@oracle.com>
References: <58826FE2.4050709@oracle.com>
Message-ID: <2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com>

Hello,

Build changes look ok. I'm in favor with dropping the version number 
from the path. There is a README that clearly states the current version 
and we don't keep multiple versions in the repo anyway. Doing so would 
also reduce repo meta data bloat from doing these upgrades in the future 
(since mercurial will not recognize the relationship between the removed 
and added files if they aren't in the same place).

/Erik


On 2017-01-20 21:15, Xueming Shen wrote:
> Hi,
>
> Please review the change to upgrade the zlib bundled in jdk repo from 
> v1.2.8
> to v1.2.11. jdk9 by default has been configured to build by using the 
> native/
> platform/os's zlib on all non-windows platform [1] So the change will 
> only have
> effect on the Windows' binaries.
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8173140
> webrev: http://cr.openjdk.java.net/~sherman/8173140
>
> As always, any source level changes, compared to the official zlib 
> release, other
> than the copyright notes addition,  is logged at
>
> http://cr.openjdk.java.net/~sherman/8173140/webrev/src/java.base/share/native/libzip/zlib-1.2.11/patches/ChangeLog_java.html 
>
>
> most are for removing the compiler warning. Compared ot 1.2.8 the gz* 
> code
> are removed from the repo. as they are actually not used really by the 
> jdk.
>
> (arguably, it appears the version number in directory path zlib-1.2.11 
> in the
> repo is not necessary. The make file changes would not be necessary if 
> the
> path is simply src/java.base/share/native/libzip/zlib)
>
> Thanks,
> Sherman
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8031767


From thomas.stuefe at gmail.com  Sat Jan 21 10:30:18 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 21 Jan 2017 11:30:18 +0100
Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to
	1.2.11
In-Reply-To: <2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com>
References: <58826FE2.4050709@oracle.com>
	<2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com>
Message-ID: <CAA-vtUzdWVA5TWvh-Hh2wJ0Vv5dz4patEhNWj5s8Vc-T=i0sTA@mail.gmail.com>

Hi,

On Sat, Jan 21, 2017 at 9:30 AM, Erik Joelsson <erik.joelsson at oracle.com>
wrote:

> Hello,
>
> Build changes look ok. I'm in favor with dropping the version number from
> the path. There is a README that clearly states the current version and we
> don't keep multiple versions in the repo anyway. Doing so would also reduce
> repo meta data bloat from doing these upgrades in the future (since
> mercurial will not recognize the relationship between the removed and added
> files if they aren't in the same place).


I second that. We also would be able to more easily see the diffs between
one zlib version and the other.

.Thomas


>
>
> /Erik
>
>
>
> On 2017-01-20 21:15, Xueming Shen wrote:
>
>> Hi,
>>
>> Please review the change to upgrade the zlib bundled in jdk repo from
>> v1.2.8
>> to v1.2.11. jdk9 by default has been configured to build by using the
>> native/
>> platform/os's zlib on all non-windows platform [1] So the change will
>> only have
>> effect on the Windows' binaries.
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8173140
>> webrev: http://cr.openjdk.java.net/~sherman/8173140
>>
>> As always, any source level changes, compared to the official zlib
>> release, other
>> than the copyright notes addition,  is logged at
>>
>> http://cr.openjdk.java.net/~sherman/8173140/webrev/src/java.
>> base/share/native/libzip/zlib-1.2.11/patches/ChangeLog_java.html
>>
>> most are for removing the compiler warning. Compared ot 1.2.8 the gz* code
>> are removed from the repo. as they are actually not used really by the
>> jdk.
>>
>> (arguably, it appears the version number in directory path zlib-1.2.11 in
>> the
>> repo is not necessary. The make file changes would not be necessary if the
>> path is simply src/java.base/share/native/libzip/zlib)
>>
>> Thanks,
>> Sherman
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8031767
>>
>
>

From daniel.fuchs at oracle.com  Sat Jan 21 11:01:03 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Sat, 21 Jan 2017 11:01:03 +0000
Subject: RFR 8173159, Problem list
	java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java
	on Windows
In-Reply-To: <AAAD148E-1130-4078-B04A-D10F1FB177E0@oracle.com>
References: <AAAD148E-1130-4078-B04A-D10F1FB177E0@oracle.com>
Message-ID: <961cd2d4-9d8b-c132-576a-da23ddd997aa@oracle.com>

+1

-- daniel

On 21/01/17 05:43, Felix Yang wrote:
> Hi there,
>    please review the  request to problem-list the test on Windows platform. It has been observed to be failing frequently.
>
> Bug  https://bugs.openjdk.java.net/browse/JDK-8173159 <https://bugs.openjdk.java.net/browse/JDK-8173159>
>
> Thanks,
> Felix
>
>
> diff -r 1045f9722697 test/ProblemList.txt
> --- a/test/ProblemList.txt	Sat Jan 21 03:53:21 2017 +0000
> +++ b/test/ProblemList.txt	Fri Jan 20 21:15:34 2017 -0800
> @@ -228,6 +228,8 @@
>
>  java/rmi/activation/Activatable/extLoadedImpl/ext.sh            8062724 generic-all
>
> +java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java 8169569 windows-all
> +
>  sun/rmi/rmic/newrmic/equivalence/run.sh                         8145980 generic-all
>
>  ############################################################################
>


From Alan.Bateman at oracle.com  Sat Jan 21 13:12:04 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 21 Jan 2017 13:12:04 +0000
Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to
	1.2.11
In-Reply-To: <58826FE2.4050709@oracle.com>
References: <58826FE2.4050709@oracle.com>
Message-ID: <5becb596-babf-cdb1-d08c-8079182bd1c6@oracle.com>

On 20/01/2017 20:15, Xueming Shen wrote:
> Hi,
>
> Please review the change to upgrade the zlib bundled in jdk repo from 
> v1.2.8
> to v1.2.11. jdk9 by default has been configured to build by using the 
> native/
> platform/os's zlib on all non-windows platform [1] So the change will 
> only have
> effect on the Windows' binaries.
The upgrade looks okay to me. Erik's suggestion to drop the version from 
the location seems a good idea, that would at least allow us to see the 
diffs when there are upgrades.

-Alan

From xueming.shen at oracle.com  Sat Jan 21 20:41:06 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sat, 21 Jan 2017 12:41:06 -0800
Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to
	1.2.11
In-Reply-To: <2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com>
References: <58826FE2.4050709@oracle.com>
	<2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com>
Message-ID: <5883C762.7060908@oracle.com>

Erik, Alan

Here is the webrev that dropped the version number from the name.

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

Thanks,
Sherman

On 1/21/17, 12:30 AM, Erik Joelsson wrote:
> Hello,
>
> Build changes look ok. I'm in favor with dropping the version number 
> from the path. There is a README that clearly states the current 
> version and we don't keep multiple versions in the repo anyway. Doing 
> so would also reduce repo meta data bloat from doing these upgrades in 
> the future (since mercurial will not recognize the relationship 
> between the removed and added files if they aren't in the same place).
>
> /Erik
>
>
> On 2017-01-20 21:15, Xueming Shen wrote:
>> Hi,
>>
>> Please review the change to upgrade the zlib bundled in jdk repo from 
>> v1.2.8
>> to v1.2.11. jdk9 by default has been configured to build by using the 
>> native/
>> platform/os's zlib on all non-windows platform [1] So the change will 
>> only have
>> effect on the Windows' binaries.
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8173140
>> webrev: http://cr.openjdk.java.net/~sherman/8173140
>>
>> As always, any source level changes, compared to the official zlib 
>> release, other
>> than the copyright notes addition,  is logged at
>>
>> http://cr.openjdk.java.net/~sherman/8173140/webrev/src/java.base/share/native/libzip/zlib-1.2.11/patches/ChangeLog_java.html 
>>
>>
>> most are for removing the compiler warning. Compared ot 1.2.8 the gz* 
>> code
>> are removed from the repo. as they are actually not used really by 
>> the jdk.
>>
>> (arguably, it appears the version number in directory path 
>> zlib-1.2.11 in the
>> repo is not necessary. The make file changes would not be necessary 
>> if the
>> path is simply src/java.base/share/native/libzip/zlib)
>>
>> Thanks,
>> Sherman
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8031767
>


From john_platts at hotmail.com  Sun Jan 22 01:44:48 2017
From: john_platts at hotmail.com (John Platts)
Date: Sun, 22 Jan 2017 01:44:48 +0000
Subject: Possible memory leak in java.nio.DirectByteBuffer and
	java.nio.ByteBuffer.allocateDirect if OutOfMemoryError is thrown
Message-ID: <DM3PR15MB09126D52463703BC3CEBD9689D700@DM3PR15MB0912.namprd15.prod.outlook.com>

Here is the code for the java.nio.DirectByteBuffer(int) constructor, which is contained in the?Direct-X-Buffer.java.template file, starting at line 117:
Direct$Type$Buffer$RW$(int cap) {                   // package-private
#if[rw]
        super(-1, 0, cap, cap);
        boolean pa = VM.isDirectMemoryPageAligned();
        int ps = Bits.pageSize();
        long size = Math.max(1L, (long)cap + (pa ? ps : 0));
        Bits.reserveMemory(size, cap);

        long base = 0;
        try {
            base = unsafe.allocateMemory(size);
        } catch (OutOfMemoryError x) {
            Bits.unreserveMemory(size, cap);
            throw x;
        }
        unsafe.setMemory(base, size, (byte) 0);
        if (pa && (base % ps != 0)) {
            // Round up to page boundary
            address = base + ps - (base & (ps - 1));
        } else {
            address = base;
        }
        cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
        att = null;
#else[rw]
        super(cap);
        this.isReadOnly = true;
#end[rw]
    }

A memory leak of the memory allocated by the base = unsafe.allocateMemory(size) statement in line 127 of the Direct-X-Buffer.java.template file can occur if an OutOfMemoryError is thrown by the cleaner = Cleaner.create(this, new Deallocator(base, size, cap)) statement in line 139 of the Direct-X-Buffer.java.template file.

Here is one way to fix the issue:
Bits.reserveMemory(size, cap);

long base = 0;
try {
    base = unsafe.allocateMemory(size);
    unsafe.setMemory(base, size, (byte)0);
    if (pa && (base % ps != 0)) {
        // Round up to page boundary
        address = base + ps - (base & (ps - 1));
    } else {
        address = base;
    }
    cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
} catch(OutOfMemoryError x) {
    Bits.unreserveMemory(size, cap);
    if(base != 0 && cleaner == null) {
        // If the memory block has been allocated, but cleaner has not yet been allocated, free the allocated
        // memory block before rethrowing the OutOfMemoryError.
        address = 0;
        unsafe.freeMemory(base);
    }
    throw x;
}
att = null;

From peter.levart at gmail.com  Sun Jan 22 11:58:24 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 22 Jan 2017 12:58:24 +0100
Subject: RFR: 8173056: Add test that captures current behavior of
	annotations with invalid annotation types
In-Reply-To: <235779c0-a726-fb7b-68b9-421c2c8ee293@gmail.com>
References: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>
	<3a42ee8d-8c05-2f11-7ab1-2e020fac322d@oracle.com>
	<235779c0-a726-fb7b-68b9-421c2c8ee293@gmail.com>
Message-ID: <f158686f-fd17-acda-92fd-12c187c1b07e@gmail.com>

Hi,

On 01/19/2017 04:58 PM, Peter Levart wrote:
> I extended the AnnotationVerifier test with additional cases that 
> cover various "wrongs" in annotation types:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8173056_AnnotationVerifier/webrev.01/ 


My plan is to 1st get this test in as a separate patch for the following 
issue:

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

..., so I would kindly ask for a review. This test will make any 
possible further refactorings in annotation handling code less risky as 
the exceptional behavior will be tracked by this test.

After the test is in, I will prepare a variant of fix for:

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

... that doesn't change current exceptional behavior for invalid 
annotation types or just changes it slightly to fix obvious conformance 
bugs like the following:

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

What behavior will or will not be changed will be directly visible from 
the changes required to this test.


Regards, Peter


From claes.redestad at oracle.com  Sun Jan 22 16:59:13 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sun, 22 Jan 2017 17:59:13 +0100
Subject: RFR: 8173056: Add test that captures current behavior of
	annotations with invalid annotation types
In-Reply-To: <f158686f-fd17-acda-92fd-12c187c1b07e@gmail.com>
References: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>
	<3a42ee8d-8c05-2f11-7ab1-2e020fac322d@oracle.com>
	<235779c0-a726-fb7b-68b9-421c2c8ee293@gmail.com>
	<f158686f-fd17-acda-92fd-12c187c1b07e@gmail.com>
Message-ID: <95c46457-ac63-e56d-3e3e-d9c31ae794be@oracle.com>

Hi Peter,

this looks good to me (and enhancements to existing tests are
allowed even though we're in rampdown).

As you've also clarified that only behavior for annotations that javac
wouldn't have allowed in the first place have changed I retract my
reservations against the fix for 8029019 - but I hope with more
experience in the area can help out reviewing.

Thanks!

/Claes

On 2017-01-22 12:58, Peter Levart wrote:
> Hi,
>
> On 01/19/2017 04:58 PM, Peter Levart wrote:
>> I extended the AnnotationVerifier test with additional cases that
>> cover various "wrongs" in annotation types:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8173056_AnnotationVerifier/webrev.01/
>
>
> My plan is to 1st get this test in as a separate patch for the following
> issue:
>
>     https://bugs.openjdk.java.net/browse/JDK-8173056
>
> ..., so I would kindly ask for a review. This test will make any
> possible further refactorings in annotation handling code less risky as
> the exceptional behavior will be tracked by this test.
>
> After the test is in, I will prepare a variant of fix for:
>
>     https://bugs.openjdk.java.net/browse/JDK-8029019
>
> ... that doesn't change current exceptional behavior for invalid
> annotation types or just changes it slightly to fix obvious conformance
> bugs like the following:
>
>     https://bugs.openjdk.java.net/browse/JDK-8169629
>
> What behavior will or will not be changed will be directly visible from
> the changes required to this test.
>
>
> Regards, Peter
>

From Alan.Bateman at oracle.com  Sun Jan 22 17:46:04 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 22 Jan 2017 17:46:04 +0000
Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to
	1.2.11
In-Reply-To: <5883C762.7060908@oracle.com>
References: <58826FE2.4050709@oracle.com>
	<2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com>
	<5883C762.7060908@oracle.com>
Message-ID: <bfc00765-4361-fc4b-b326-2e3f18dcdc1a@oracle.com>



On 21/01/2017 20:41, Xueming Shen wrote:
> Erik, Alan
>
> Here is the webrev that dropped the version number from the name.
>
> http://cr.openjdk.java.net/~sherman/8173140/webrev
Switching to zlib looks good although it's impossible to see the changes 
in this webrev because all the files show up as new.

-Alan.

From xueming.shen at oracle.com  Sun Jan 22 19:27:21 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sun, 22 Jan 2017 11:27:21 -0800
Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to
	1.2.11
In-Reply-To: <bfc00765-4361-fc4b-b326-2e3f18dcdc1a@oracle.com>
References: <58826FE2.4050709@oracle.com>
	<2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com>
	<5883C762.7060908@oracle.com>
	<bfc00765-4361-fc4b-b326-2e3f18dcdc1a@oracle.com>
Message-ID: <58850799.5070506@oracle.com>

On 1/22/17, 9:46 AM, Alan Bateman wrote:
>
>
> On 21/01/2017 20:41, Xueming Shen wrote:
>> Erik, Alan
>>
>> Here is the webrev that dropped the version number from the name.
>>
>> http://cr.openjdk.java.net/~sherman/8173140/webrev
> Switching to zlib looks good although it's impossible to see the 
> changes in this webrev because all the files show up as new.
>
The assumption is the remove of the version tag can help us to easily 
get the
diffs from the webrev directly in future upgrade.

Here is the webrev with the diff by listing old and new files in a 
webrev list file.

http://cr.openjdk.java.net/~sherman/8173140/webrev.diff

wevrev failed to create the diffs for couple files, I wonder if it is 
because of the
order I did the change (renamed the zlib.1.2.8->zlib first, then applied 
the file level
change in the repo, or applied the file level changes and then rename 
the dir )

sherman

From huaming.li at oracle.com  Mon Jan 23 06:38:01 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Mon, 23 Jan 2017 14:38:01 +0800
Subject: RFR of JDK-8171142: jdk_rmi registry test fail to clean up on failure
Message-ID: <64b48f04-92b0-d31e-2e27-3a0ab2e58629@oracle.com>

Would you please review the below patch?

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

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


Thank you

-Hamlin



From erik.joelsson at oracle.com  Mon Jan 23 08:14:56 2017
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 23 Jan 2017 09:14:56 +0100
Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to
	1.2.11
In-Reply-To: <5883C762.7060908@oracle.com>
References: <58826FE2.4050709@oracle.com>
	<2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com>
	<5883C762.7060908@oracle.com>
Message-ID: <e3a28f81-68b5-5841-a465-e153e0a78346@oracle.com>

Build changes look good. Thanks!

/Erik


On 2017-01-21 21:41, Xueming Shen wrote:
> Erik, Alan
>
> Here is the webrev that dropped the version number from the name.
>
> http://cr.openjdk.java.net/~sherman/8173140/webrev
>
> Thanks,
> Sherman
>
> On 1/21/17, 12:30 AM, Erik Joelsson wrote:
>> Hello,
>>
>> Build changes look ok. I'm in favor with dropping the version number 
>> from the path. There is a README that clearly states the current 
>> version and we don't keep multiple versions in the repo anyway. Doing 
>> so would also reduce repo meta data bloat from doing these upgrades 
>> in the future (since mercurial will not recognize the relationship 
>> between the removed and added files if they aren't in the same place).
>>
>> /Erik
>>
>>
>> On 2017-01-20 21:15, Xueming Shen wrote:
>>> Hi,
>>>
>>> Please review the change to upgrade the zlib bundled in jdk repo 
>>> from v1.2.8
>>> to v1.2.11. jdk9 by default has been configured to build by using 
>>> the native/
>>> platform/os's zlib on all non-windows platform [1] So the change 
>>> will only have
>>> effect on the Windows' binaries.
>>>
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8173140
>>> webrev: http://cr.openjdk.java.net/~sherman/8173140
>>>
>>> As always, any source level changes, compared to the official zlib 
>>> release, other
>>> than the copyright notes addition,  is logged at
>>>
>>> http://cr.openjdk.java.net/~sherman/8173140/webrev/src/java.base/share/native/libzip/zlib-1.2.11/patches/ChangeLog_java.html 
>>>
>>>
>>> most are for removing the compiler warning. Compared ot 1.2.8 the 
>>> gz* code
>>> are removed from the repo. as they are actually not used really by 
>>> the jdk.
>>>
>>> (arguably, it appears the version number in directory path 
>>> zlib-1.2.11 in the
>>> repo is not necessary. The make file changes would not be necessary 
>>> if the
>>> path is simply src/java.base/share/native/libzip/zlib)
>>>
>>> Thanks,
>>> Sherman
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8031767
>>
>


From Alan.Bateman at oracle.com  Mon Jan 23 09:10:00 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Jan 2017 09:10:00 +0000
Subject: RFR JDK-8173140: To upgrade bundled zlib version from 1.2.8 to
	1.2.11
In-Reply-To: <58850799.5070506@oracle.com>
References: <58826FE2.4050709@oracle.com>
	<2cf5b372-51c7-f673-768d-fce02aef995f@oracle.com>
	<5883C762.7060908@oracle.com>
	<bfc00765-4361-fc4b-b326-2e3f18dcdc1a@oracle.com>
	<58850799.5070506@oracle.com>
Message-ID: <6bfbc784-fc96-c635-9e83-098dd5c1e438@oracle.com>

On 22/01/2017 19:27, Xueming Shen wrote:

> The assumption is the remove of the version tag can help us to easily 
> get the
> diffs from the webrev directly in future upgrade.
>
> Here is the webrev with the diff by listing old and new files in a 
> webrev list file.
>
> http://cr.openjdk.java.net/~sherman/8173140/webrev.diff
>
> wevrev failed to create the diffs for couple files, I wonder if it is 
> because of the
> order I did the change (renamed the zlib.1.2.8->zlib first, then 
> applied the file level
> change in the repo, or applied the file level changes and then rename 
> the dir )
It might be although I haven't had problems with renames + edits like this.

Anyway, the changes in the webrev look okay and for the next update then 
it should be a lot easier to see the changes.

-Alan

From christoph.langer at sap.com  Mon Jan 23 10:03:46 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 23 Jan 2017 10:03:46 +0000
Subject: RFR (JAXP) 8169827:
	javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
Message-ID: <eadaad631dae47278030f243a7afb9c6@derote13de46.global.corp.sap>

Hi,

while working on jaxp changes and running jtreg tests I found that test javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh does not work. I then saw that this was already reported with bug 8169827. But, as I had already spent some time to fix this test I'd like to contribute my fix:

Bug: https://bugs.openjdk.java.net/browse/JDK-8169827
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169827.0/

I converted the test to Java and removed the shell script PropertiesTest.sh. This resolves the compilation issue.

However, the test needs to copy an isolated jdk as it modifies files in the JDK. So I'm still using the copy script to first copy the jdk and afterwards remove the copy. These are separate 'shell' test steps. And in the actual test I'm running a child process with the isolated JDK.

I also don't know if the test should be kept in the problem list and/or also be tagged as 'intermittent' as the whole jdk copying procedure by means of a shell script seems error prone. In case we keep the entry in the problem list, I can also open a separate bug for my change.

@Frank: I don't know if you have some larger change in mind which improves the isolated jdk type testing greatly, otherwise I think this fix could at least make things better than they are at the moment.

Thanks & Best regards
Christoph


From chris.hegarty at oracle.com  Mon Jan 23 10:41:22 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 23 Jan 2017 10:41:22 +0000
Subject: RFR 8172732: spec clarification for URLClassLoader for
	Multirelease jars
In-Reply-To: <0B08BA3A-3752-477C-9A75-533A2FD27C96@oracle.com>
References: <0B08BA3A-3752-477C-9A75-533A2FD27C96@oracle.com>
Message-ID: <7ab199da-8fee-1807-e5fc-0d5c439d45be@oracle.com>

Looks good to me Paul.

-Chris.

On 20/01/17 23:48, Paul Sandoz wrote:
> Hi,
>
> Please review this small clarification to the specification of URLClassLoader for multi-release jars.
>
> Thanks,
> Paul.
>
> diff -r 467b3b7aeb1b src/java.base/share/classes/java/net/URLClassLoader.java
> --- a/src/java.base/share/classes/java/net/URLClassLoader.java	Fri Jan 20 07:05:40 2017 -0800
> +++ b/src/java.base/share/classes/java/net/URLClassLoader.java	Fri Jan 20 15:47:54 2017 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1997, 2016, 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
> @@ -73,9 +73,9 @@
>   * The classes that are loaded are by default granted permission only to
>   * access the URLs specified when the URLClassLoader was created.
>   * <p>
> - * This class loader supports the loading of classes from the contents of a
> - * <a href="../util/jar/JarFile.html#multirelease">multi-release</a> JAR file
> - * that is referred to by a given URL.
> + * This class loader supports the loading of classes and resources from the
> + * contents of a <a href="../util/jar/JarFile.html#multirelease">multi-release</a>
> + * JAR file that is referred to by a given URL.
>   *
>   * @author  David Connelly
>   * @since   1.2
>

From Alan.Bateman at oracle.com  Mon Jan 23 11:04:34 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Jan 2017 11:04:34 +0000
Subject: RFR 8172732: spec clarification for URLClassLoader for
	Multirelease jars
In-Reply-To: <0B08BA3A-3752-477C-9A75-533A2FD27C96@oracle.com>
References: <0B08BA3A-3752-477C-9A75-533A2FD27C96@oracle.com>
Message-ID: <fac36b65-1049-329b-c4f2-e12823339bcb@oracle.com>



On 20/01/2017 23:48, Paul Sandoz wrote:
> Hi,
>
> Please review this small clarification to the specification of URLClassLoader for multi-release jars.
>
>
This looks okay to me. One suggestion is to move this paragraph up to 
before the two paragraphs on security so that the statement on 
supporting MR JAR follows the main description of URLClassLoader.

-Alan

From Roger.Riggs at Oracle.com  Mon Jan 23 15:21:23 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 23 Jan 2017 10:21:23 -0500
Subject: RFR of JDK-8171142: jdk_rmi registry test fail to clean up on
	failure
In-Reply-To: <64b48f04-92b0-d31e-2e27-3a0ab2e58629@oracle.com>
References: <64b48f04-92b0-d31e-2e27-3a0ab2e58629@oracle.com>
Message-ID: <3356cacb-627e-89e7-f834-88d5f09fb361@Oracle.com>

Hi Hamlin,

test/javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java:

   line 130: trivial, but please add a space in "!=null"...

Note: on Windows there is no difference between Process.destroy vs 
Process.destroyForcibly,
but on Linux it it is the difference between kill -15 and kill -9.

Using destroyForcibly would be more certain as to the death of the 
subprocess.

Otherwise looks fine

Thanks, Roger


On 1/23/2017 1:38 AM, Hamlin Li wrote:
> Would you please review the below patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8171142
>
> webrev: http://cr.openjdk.java.net/~mli/8171142/webrev.00/
>
>
> Thank you
>
> -Hamlin
>
>


From Roger.Riggs at Oracle.com  Mon Jan 23 16:05:50 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 23 Jan 2017 11:05:50 -0500
Subject: Reading subprocess stdout susceptible to deadlock
In-Reply-To: <CAHjP37GBD+_71Oiv9Otj7Fv7Fz=KFXFuLR-snFxDtYq+-FNAeQ@mail.gmail.com>
References: <CAHjP37E+_x9v6JmJ8dB38wsEPYLHbjfhCHzu_xZde+KcA37zrA@mail.gmail.com>
	<56FBDE18.1000809@Oracle.com>
	<CAHjP37Hy65oi0fVyuuh9TWUf5TRFoJUSwXM2T9hd2=J9Qtnp=Q@mail.gmail.com>
	<CAHjP37GBD+_71Oiv9Otj7Fv7Fz=KFXFuLR-snFxDtYq+-FNAeQ@mail.gmail.com>
Message-ID: <300a0e96-fedf-f5b2-c22a-0c5328ca54fe@Oracle.com>

Hi Vitaly,

There probably is something that can be done to avoid the deadlock.
ProcessExited may need to use a different lock.
Please file an issue.

Roger




On 1/20/2017 5:14 PM, Vitaly Davidovich wrote:
> Hi all,
>
> Just wanted to revisit this issue again.  I haven't filed a JBS entry 
> for it, primarily because I'd like some validation/confirmation/hunch 
> that this is, indeed, a bug before proceeding.  Does anyone have 
> thoughts on this scenario?
>
> Thanks
>
> On Wed, Mar 30, 2016 at 10:45 AM, Vitaly Davidovich <vitalyd at gmail.com 
> <mailto:vitalyd at gmail.com>> wrote:
>
>     Hi Roger,
>
>     The stack traces are:
>
>     "process reaper" #44 daemon prio=10 os_prio=0 tid=0x0000000004083000 nid=0x7b1c waiting for monitor entry [0x00002b703ffbe000]
>
>         java.lang.Thread.State: BLOCKED (on object monitor)
>
>              at java.lang.UNIXProcess$ProcessPipeInputStream.processExited(UNIXProcess.java:528)
>
>              - waiting to lock <0x00000000aba7a790> (a java.lang.UNIXProcess$ProcessPipeInputStream)
>
>              at java.lang.UNIXProcess.lambda$initStreams$275(UNIXProcess.java:299)
>
>              at java.lang.UNIXProcess$$Lambda$10/523574157.run(Unknown Source)
>
>              at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
>       
>
>       
>
>     "pool-1-thread-1" #43 prio=5 os_prio=0 tid=0x0000000003ee3800 nid=0x7b13 runnable [0x00002b7050837000]
>
>         java.lang.Thread.State: RUNNABLE
>
>              at java.io.FileInputStream.readBytes(Native Method)
>
>              at java.io.FileInputStream.read(FileInputStream.java:255)
>
>              at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
>
>              at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
>
>              at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
>
>              - locked <0x00000000aba7a790> (a java.lang.UNIXProcess$ProcessPipeInputStream)
>
>             at SomeClass.callReadOnInputStream()
>     SomeClass.callReadOnInputStream() is something that invokes
>     InputStream.read(byte[], int, int) on the stream.
>     Thanks
>     On Wed, Mar 30, 2016 at 10:09 AM, Roger Riggs
>     <Roger.Riggs at oracle.com <mailto:Roger.Riggs at oracle.com>> wrote:
>
>         Hi Vitaly, I haven't seen that before, please create a bug and
>         include the stack traces. Thanks, Roger
>         On 3/30/2016 9:56 AM, Vitaly Davidovich wrote:
>
>             Hi, It seems that doing a blocking read on a subprocess's
>             stdout can lead to deadlock between the thread doing the
>             read and the process reaper thread. The deadlock occurs
>             because the reader is synchronized on the
>             ProcessPipeInputStream, blocks for more data to consume,
>             and process reaper comes along trying to call
>             processExited, which also synchronizes on the same PPIS. 
>             The reader appears stuck because it's not seeing the EOF
>             due to process reaper not being able to close the stream.
>             I couldn't find any existing reports of this via quick
>             search, which makes me wonder if I'm missing something. 
>             Is this a known issue? Thanks 
>

From daniel.fuchs at oracle.com  Mon Jan 23 16:12:25 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 23 Jan 2017 16:12:25 +0000
Subject: RFR (JAXP) 8169827:
	javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
In-Reply-To: <eadaad631dae47278030f243a7afb9c6@derote13de46.global.corp.sap>
References: <eadaad631dae47278030f243a7afb9c6@derote13de46.global.corp.sap>
Message-ID: <9e9fb81a-92cf-57ad-5851-a2d8a704811c@oracle.com>

Hi Christoph,

Thanks for fixing this test!

I imported your patch, modified ProblemList.txt to not skip the test,
and sent it through our test system, and I'm happy to report that
the test was run on all available platforms with no failure.

So I think you should simply remove the line from ProblemList.txt
(no need for a new webrev).
If it fails again on more exotic platform we'll simply add it
back to ProblemList.txt for those platforms where it fails
(I guess it could happen if there's not enough disk space).

Otherwise I have looked over the changes you proposed and they
do seem OK to me.

+1

best regards,

-- daniel

On 23/01/17 10:03, Langer, Christoph wrote:
> Hi,
>
> while working on jaxp changes and running jtreg tests I found that test javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh does not work. I then saw that this was already reported with bug 8169827. But, as I had already spent some time to fix this test I'd like to contribute my fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8169827
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169827.0/
>
> I converted the test to Java and removed the shell script PropertiesTest.sh. This resolves the compilation issue.
>
> However, the test needs to copy an isolated jdk as it modifies files in the JDK. So I'm still using the copy script to first copy the jdk and afterwards remove the copy. These are separate 'shell' test steps. And in the actual test I'm running a child process with the isolated JDK.
>
> I also don't know if the test should be kept in the problem list and/or also be tagged as 'intermittent' as the whole jdk copying procedure by means of a shell script seems error prone. In case we keep the entry in the problem list, I can also open a separate bug for my change.
>
> @Frank: I don't know if you have some larger change in mind which improves the isolated jdk type testing greatly, otherwise I think this fix could at least make things better than they are at the moment.
>
> Thanks & Best regards
> Christoph
>


From naoto.sato at oracle.com  Mon Jan 23 17:13:44 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 23 Jan 2017 09:13:44 -0800
Subject: [9] RFR: 8172365: Provide a better migration path for
	ResourceBundleControlProvider
Message-ID: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>

Hi,

Please review the changes for the following issue:

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

The proposed fix is located at:

http://cr.openjdk.java.net/~rgoel/JDK-8167273/webrev.05/

The fix is to reinstate the code that has been removed with 8171189, 
with modification to load implementations with ServiceLoader.load() 
method. That way, SPI implementations can be searched on application's 
class path.

Naoto

From naoto.sato at oracle.com  Mon Jan 23 17:14:46 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 23 Jan 2017 09:14:46 -0800
Subject: [9] RFR: 8172365: Provide a better migration path for
	ResourceBundleControlProvider
In-Reply-To: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>
References: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>
Message-ID: <a9cfe32d-456f-2ac5-77bc-c688047ad56b@oracle.com>

Correct link to the changes:

http://cr.openjdk.java.net/~naoto/8172365/webrev.05/

Naoto

On 1/23/17 9:13 AM, Naoto Sato wrote:
> Hi,
>
> Please review the changes for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8172365
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~rgoel/JDK-8167273/webrev.05/
>
> The fix is to reinstate the code that has been removed with 8171189,
> with modification to load implementations with ServiceLoader.load()
> method. That way, SPI implementations can be searched on application's
> class path.
>
> Naoto

From daniel.fuchs at oracle.com  Mon Jan 23 17:48:12 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 23 Jan 2017 17:48:12 +0000
Subject: (JAXP) RFR: 8173111: Excessive recursion in EventFilterSupport when
	filtering over large number of XML events can cause StackOverflow
Message-ID: <cf473666-1a3b-9c49-4ef2-a1f6714a4430@oracle.com>

Hi,

Please find below a fix for:

8173111: Excessive recursion in EventFilterSupport when filtering
          over large number of XML events can cause StackOverflow
https://bugs.openjdk.java.net/browse/JDK-8173111

The fix is almost trivial: it replaces a recursion by a loop in
two places.

http://cr.openjdk.java.net/~dfuchs/webrev_8173111/webrev.00/

The test will fail without the fix (at least on my machine)
and pass with it (on my machine and in our test system).

best regards,

-- daniel

From paul.sandoz at oracle.com  Mon Jan 23 17:50:19 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 23 Jan 2017 09:50:19 -0800
Subject: RFR 8172732: spec clarification for URLClassLoader for
	Multirelease jars
In-Reply-To: <fac36b65-1049-329b-c4f2-e12823339bcb@oracle.com>
References: <0B08BA3A-3752-477C-9A75-533A2FD27C96@oracle.com>
	<fac36b65-1049-329b-c4f2-e12823339bcb@oracle.com>
Message-ID: <696F4284-7421-4298-85F1-EFEBED0F526C@oracle.com>


> On 23 Jan 2017, at 03:04, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 20/01/2017 23:48, Paul Sandoz wrote:
>> Hi,
>> 
>> Please review this small clarification to the specification of URLClassLoader for multi-release jars.
>> 
>> 
> This looks okay to me. One suggestion is to move this paragraph up to before the two paragraphs on security so that the statement on supporting MR JAR follows the main description of URLClassLoader.
> 

Suggestion taken, thanks,
Paul.

From mandy.chung at oracle.com  Mon Jan 23 18:51:40 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Jan 2017 10:51:40 -0800
Subject: [9] RFR: 8172365: Provide a better migration path for
	ResourceBundleControlProvider
In-Reply-To: <a9cfe32d-456f-2ac5-77bc-c688047ad56b@oracle.com>
References: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>
	<a9cfe32d-456f-2ac5-77bc-c688047ad56b@oracle.com>
Message-ID: <87DD942F-6FA0-4679-B726-9835F64AACF7@oracle.com>


> On Jan 23, 2017, at 9:14 AM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~naoto/8172365/webrev.05/
> 
>> 
>> The fix is to reinstate the code that has been removed with 8171189,
>> with modification to load implementations with ServiceLoader.load()
>> method. That way, SPI implementations can be searched on application's
>> class path.

This change is reasonable.  The custom control provider can only be used for loading of resource bundles in unnamed modules which maintains JDK 8 behavior.

For the getBundle factory methods taking Module parameter, I suggest to explain the spec to clarify that the custom control provider will be used to load the resource bundle if the specified module is unnamed module.

Otherwise looks good.
Mandy

From lance.andersen at oracle.com  Mon Jan 23 19:03:34 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 23 Jan 2017 14:03:34 -0500
Subject: (JAXP) RFR: 8173111: Excessive recursion in EventFilterSupport
	when filtering over large number of XML events can cause StackOverflow
In-Reply-To: <cf473666-1a3b-9c49-4ef2-a1f6714a4430@oracle.com>
References: <cf473666-1a3b-9c49-4ef2-a1f6714a4430@oracle.com>
Message-ID: <4D1747D2-0F4F-4E34-A1C1-D66D53F04CB9@oracle.com>

Hi Daniel,

The changes look fine.

Did you give any consideration to using assertFalse in the smokeTest  at line 73?

Probably want to consider a back port at some point to 8u when time permits.

Best
Lance
> On Jan 23, 2017, at 12:48 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a fix for:
> 
> 8173111: Excessive recursion in EventFilterSupport when filtering
>         over large number of XML events can cause StackOverflow
> https://bugs.openjdk.java.net/browse/JDK-8173111
> 
> The fix is almost trivial: it replaces a recursion by a loop in
> two places.
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8173111/webrev.00/
> 
> The test will fail without the fix (at least on my machine)
> and pass with it (on my machine and in our test system).
> 
> best regards,
> 
> -- daniel

 <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 christoph.langer at sap.com  Mon Jan 23 19:44:00 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 23 Jan 2017 19:44:00 +0000
Subject: RFR (JAXP) 8169827:
	javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
In-Reply-To: <9e9fb81a-92cf-57ad-5851-a2d8a704811c@oracle.com>
References: <eadaad631dae47278030f243a7afb9c6@derote13de46.global.corp.sap>
	<9e9fb81a-92cf-57ad-5851-a2d8a704811c@oracle.com>
Message-ID: <42b9f71db0534e7985f761130713295f@derote13de46.global.corp.sap>

Hi Daniel,

thanks for checking/reviewing. So I'll submit with removing the ProblemList.txt entry and I'll also remove the intermittent flag.

Sounds fair to check later if problems will still show up. Although I have the feeling that the issue of https://bugs.openjdk.java.net/browse/JDK-8147431 might appear again...

Best regards
Christoph

> -----Original Message-----
> From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> Sent: Montag, 23. Januar 2017 17:12
> To: Langer, Christoph <christoph.langer at sap.com>; Frank Yuan
> <frank.yuan at oracle.com>; core-libs-dev at openjdk.java.net
> Subject: Re: RFR (JAXP) 8169827:
> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> 
> Hi Christoph,
> 
> Thanks for fixing this test!
> 
> I imported your patch, modified ProblemList.txt to not skip the test,
> and sent it through our test system, and I'm happy to report that
> the test was run on all available platforms with no failure.
> 
> So I think you should simply remove the line from ProblemList.txt
> (no need for a new webrev).
> If it fails again on more exotic platform we'll simply add it
> back to ProblemList.txt for those platforms where it fails
> (I guess it could happen if there's not enough disk space).
> 
> Otherwise I have looked over the changes you proposed and they
> do seem OK to me.
> 
> +1
> 
> best regards,
> 
> -- daniel
> 
> On 23/01/17 10:03, Langer, Christoph wrote:
> > Hi,
> >
> > while working on jaxp changes and running jtreg tests I found that test
> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh does not work. I then saw
> that this was already reported with bug 8169827. But, as I had already spent
> some time to fix this test I'd like to contribute my fix:
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8169827
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169827.0/
> >
> > I converted the test to Java and removed the shell script PropertiesTest.sh.
> This resolves the compilation issue.
> >
> > However, the test needs to copy an isolated jdk as it modifies files in the JDK.
> So I'm still using the copy script to first copy the jdk and afterwards remove the
> copy. These are separate 'shell' test steps. And in the actual test I'm running a
> child process with the isolated JDK.
> >
> > I also don't know if the test should be kept in the problem list and/or also be
> tagged as 'intermittent' as the whole jdk copying procedure by means of a shell
> script seems error prone. In case we keep the entry in the problem list, I can
> also open a separate bug for my change.
> >
> > @Frank: I don't know if you have some larger change in mind which improves
> the isolated jdk type testing greatly, otherwise I think this fix could at least
> make things better than they are at the moment.
> >
> > Thanks & Best regards
> > Christoph
> >


From ramanand.patil at oracle.com  Mon Jan 23 19:51:41 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 23 Jan 2017 11:51:41 -0800 (PST)
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
In-Reply-To: <07c4c8b9-695b-6ba8-2cf8-09423e467379@oracle.com>
References: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>
	<07c4c8b9-695b-6ba8-2cf8-09423e467379@oracle.com>
Message-ID: <18089cd3-4cfb-4e55-b02b-e11cb637daa9@default>

Hi Alan,
Thank you for the review.
My comments are inline and Webrev is updated here: http://cr.openjdk.java.net/~rpatil/8167063/webrev.01/

Change Summary:
- Removed SecurityException handling
- Updated the error message in launcher.properties
- Removed loadModuleMainClass0 method and moved the code back into original loadModuleMainClass
- NoClassDefFoundError is replaced by its parent class LinkageError in method loadMainClass 

Regards,
Ramanand.

-----Original Message-----
From: Alan Bateman 
Sent: Friday, January 20, 2017 8:03 PM
To: Ramanand Patil <ramanand.patil at oracle.com>; core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized

On 20/01/2017 13:21, Ramanand Patil wrote:

> Hi all,
> Please review the following bug fix:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167063
> Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.00/
>
> Handled the SecurityException and LinkageError which can be thrown from Class.forName(...) method used in LauncherHelper.java and added corresponding error messages to launcher.properties.
> Though the reported bug is because of the LinkageError, Security exception is also handled to be safe from calling Class.forName method.
>
I see this changes loadMainClass to abort with resources that are keyed on java.launcher.cls.error6 and java.launcher.cls.error7 but they don't appear in the launcher.properties file. Does this work? I would assume MissingResourceException is thrown.
Thanks for pointing this. I missed to add it to launcher.properties. But now I have changed error6 to point to java.launcher.cls.error1 and removed security exception handling.

For java.launcher.module.error3 and java.launcher.module.error4 then "link" is likely to confuse people. Sure, there may be linkage errors but there are many linkage errors and I think would be a lot clearer if the message was "Unable to load main class {0} from module {1}\n\{2}".
Updated the message as suggested.

It's not clear to me that having a different message for security exceptions make sense, esp. when the exception is printed. So I think I would drop that.
Yes, I agree to drop out the Security exceptions handling.

Also loadModuleMainClass0 is unusual method name, we've mostly (not
always) used the 0 suffix on native methods. In any case, it doesn't look like it is needed, the code was okay in loadModuleMainClass as it was.
The method was added just to look the exception handling easier. I have removed the extra method and placed the code back into loadModuleMainClass.

One final point is that is the nesting catching of LinkageError and SecurityException in loadMainClass, I assume you don't need the inner catch.
I think both the catch blocks were needed, because the first(inner) catch was already inside catch.(This was same as NoClassDefFoundError catching twice in the same method). Now since NoClassDefFoundError is subclass of LinkageError, I have replaced it with LinkageError. And  I think still the same abort message holds good. Please let me know if this is ok.

-Alan

From aleksej.efimov at oracle.com  Mon Jan 23 20:24:36 2017
From: aleksej.efimov at oracle.com (Aleks Efimov)
Date: Mon, 23 Jan 2017 23:24:36 +0300
Subject: (JAXP) RFR: 8173111: Excessive recursion in EventFilterSupport
	when filtering over large number of XML events can cause StackOverflow
In-Reply-To: <4D1747D2-0F4F-4E34-A1C1-D66D53F04CB9@oracle.com>
References: <cf473666-1a3b-9c49-4ef2-a1f6714a4430@oracle.com>
	<4D1747D2-0F4F-4E34-A1C1-D66D53F04CB9@oracle.com>
Message-ID: <33d066cc-1fd6-d997-eb9b-bab55d27674a@oracle.com>

Hi Daniel, Lance,

It looks like Assert.assertEquals(String actual, String expected, String 
message) suites better and lines 73-77 can be replaced with: 
assertEquals(sb.toString(), SMOKE, "Smoke test failed" ).
And do we really need 'main' here? All test methods are annotated with 
@Test tags already.
The changes looks good (not a reviewer).

Best,
Aleksej

On 23/01/17 22:03, Lance Andersen wrote:
> Hi Daniel,
>
> The changes look fine.
>
> Did you give any consideration to using assertFalse in the smokeTest  at line 73?
>
> Probably want to consider a back port at some point to 8u when time permits.
>
> Best
> Lance
>> On Jan 23, 2017, at 12:48 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi,
>>
>> Please find below a fix for:
>>
>> 8173111: Excessive recursion in EventFilterSupport when filtering
>>          over large number of XML events can cause StackOverflow
>> https://bugs.openjdk.java.net/browse/JDK-8173111
>>
>> The fix is almost trivial: it replaces a recursion by a loop in
>> two places.
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8173111/webrev.00/
>>
>> The test will fail without the fix (at least on my machine)
>> and pass with it (on my machine and in our test system).
>>
>> best regards,
>>
>> -- daniel
>   <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 lance.andersen at oracle.com  Mon Jan 23 20:29:32 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 23 Jan 2017 15:29:32 -0500
Subject: (JAXP) RFR: 8173111: Excessive recursion in EventFilterSupport
	when filtering over large number of XML events can cause StackOverflow
In-Reply-To: <33d066cc-1fd6-d997-eb9b-bab55d27674a@oracle.com>
References: <cf473666-1a3b-9c49-4ef2-a1f6714a4430@oracle.com>
	<4D1747D2-0F4F-4E34-A1C1-D66D53F04CB9@oracle.com>
	<33d066cc-1fd6-d997-eb9b-bab55d27674a@oracle.com>
Message-ID: <873FDC7C-E381-4CFF-80B0-762509AA712C@oracle.com>

Hi Aleks,
> On Jan 23, 2017, at 3:24 PM, Aleks Efimov <aleksej.efimov at oracle.com> wrote:
> 
> Hi Daniel, Lance,
> 
> It looks like Assert.assertEquals(String actual, String expected, String message) suites better and lines 73-77 can be replaced with: assertEquals(sb.toString(), SMOKE, "Smoke test failed" ).

Yep, that works also?.. :-)

> And do we really need 'main' here?

Not really but allows for running outside of  a testNG run  ?.

Best
lance
> All test methods are annotated with @Test tags already.
> The changes looks good (not a reviewer).
> 
> Best,
> Aleksej
> 
> On 23/01/17 22:03, Lance Andersen wrote:
>> Hi Daniel,
>> 
>> The changes look fine.
>> 
>> Did you give any consideration to using assertFalse in the smokeTest  at line 73?
>> 
>> Probably want to consider a back port at some point to 8u when time permits.
>> 
>> Best
>> Lance
>>> On Jan 23, 2017, at 12:48 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Please find below a fix for:
>>> 
>>> 8173111: Excessive recursion in EventFilterSupport when filtering
>>>         over large number of XML events can cause StackOverflow
>>> https://bugs.openjdk.java.net/browse/JDK-8173111
>>> 
>>> The fix is almost trivial: it replaces a recursion by a loop in
>>> two places.
>>> 
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8173111/webrev.00/
>>> 
>>> The test will fail without the fix (at least on my machine)
>>> and pass with it (on my machine and in our test system).
>>> 
>>> best regards,
>>> 
>>> -- daniel
>>  <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>> <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> <mailto:Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>>

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <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  Mon Jan 23 20:30:03 2017
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 23 Jan 2017 15:30:03 -0500
Subject: (JAXP) RFR: 8173111: Excessive recursion in EventFilterSupport
	when filtering over large number of XML events can cause StackOverflow
In-Reply-To: <33d066cc-1fd6-d997-eb9b-bab55d27674a@oracle.com>
References: <cf473666-1a3b-9c49-4ef2-a1f6714a4430@oracle.com>
	<4D1747D2-0F4F-4E34-A1C1-D66D53F04CB9@oracle.com>
	<33d066cc-1fd6-d997-eb9b-bab55d27674a@oracle.com>
Message-ID: <41a147bc-5207-53bd-5411-a8897eafef37@oracle.com>

Hi,

I would keep the main, it is handy to debug the test standalone. (It 
will still need testng.jar).

$02, Roger


On 1/23/17 3:24 PM, Aleks Efimov wrote:
> Hi Daniel, Lance,
>
> It looks like Assert.assertEquals(String actual, String expected, 
> String message) suites better and lines 73-77 can be replaced with: 
> assertEquals(sb.toString(), SMOKE, "Smoke test failed" ).
> And do we really need 'main' here? All test methods are annotated with 
> @Test tags already.
> The changes looks good (not a reviewer).
>
> Best,
> Aleksej
>
> On 23/01/17 22:03, Lance Andersen wrote:
>> Hi Daniel,
>>
>> The changes look fine.
>>
>> Did you give any consideration to using assertFalse in the smokeTest  
>> at line 73?
>>
>> Probably want to consider a back port at some point to 8u when time 
>> permits.
>>
>> Best
>> Lance
>>> On Jan 23, 2017, at 12:48 PM, Daniel Fuchs <daniel.fuchs at oracle.com> 
>>> wrote:
>>>
>>> Hi,
>>>
>>> Please find below a fix for:
>>>
>>> 8173111: Excessive recursion in EventFilterSupport when filtering
>>>          over large number of XML events can cause StackOverflow
>>> https://bugs.openjdk.java.net/browse/JDK-8173111
>>>
>>> The fix is almost trivial: it replaces a recursion by a loop in
>>> two places.
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8173111/webrev.00/
>>>
>>> The test will fail without the fix (at least on my machine)
>>> and pass with it (on my machine and in our test system).
>>>
>>> best regards,
>>>
>>> -- daniel
>> <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  Mon Jan 23 21:19:33 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 23 Jan 2017 13:19:33 -0800
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
In-Reply-To: <18089cd3-4cfb-4e55-b02b-e11cb637daa9@default>
References: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>
	<07c4c8b9-695b-6ba8-2cf8-09423e467379@oracle.com>
	<18089cd3-4cfb-4e55-b02b-e11cb637daa9@default>
Message-ID: <58867365.5070608@oracle.com>


Hi Ramanand,
test/tools/launcher/LauncherMessageTest.java

1)

116         String[] commands = {"java", "--module-path", modules.getPath(),
117             "-m", "mod.b/pkgB.ClassB"};

The execution PATH may or may not contain the JAVA_HOME_UNDER_TEST/bin,
so the right "java" may not be picked up,  suggest using the TestHelper's
javaCmd field that will be set correctly.

2)

  122         if (!result.isOK() && result.contains("JNI error")) {
  123             result.testOutput.forEach(System.err::println);
  124             throw new RuntimeException("Test Failed with JNI error!");
  125         } else {
  126             System.out.println("Test Passed...");
  127         }

The problem with 122 if it the test returns back with non-zero code, it will
still fail with "Test Failed with JNI error", I prefer it to be broken 
up and return
back the right message ie. if the test returns with non-zero code say that.

3)
Also usage of RuntimeException is over the top, you can simply throw an
Exception and have the main throws Exception, jtreg will do the needful.

4)

  102         FileUtils.deleteFileWithRetry(Paths.get(modules.getPath() + File.separator + "mod.a.jar"));

there are redundant use of File.separator, Paths.get should create
the FS correctly on the target platform
ex: Paths.get(modules.getPath(), "mod.a.jar");

Personally I stay away from using raw File.separator, instead
have the APIs do the work for me.


Kumar


> Hi Alan,
> Thank you for the review.
> My comments are inline and Webrev is updated here: http://cr.openjdk.java.net/~rpatil/8167063/webrev.01/
>
> Change Summary:
> - Removed SecurityException handling
> - Updated the error message in launcher.properties
> - Removed loadModuleMainClass0 method and moved the code back into original loadModuleMainClass
> - NoClassDefFoundError is replaced by its parent class LinkageError in method loadMainClass
>
> Regards,
> Ramanand.
>
> -----Original Message-----
> From: Alan Bateman
> Sent: Friday, January 20, 2017 8:03 PM
> To: Ramanand Patil <ramanand.patil at oracle.com>; core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized
>
> On 20/01/2017 13:21, Ramanand Patil wrote:
>
>> Hi all,
>> Please review the following bug fix:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167063
>> Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.00/
>>
>> Handled the SecurityException and LinkageError which can be thrown from Class.forName(...) method used in LauncherHelper.java and added corresponding error messages to launcher.properties.
>> Though the reported bug is because of the LinkageError, Security exception is also handled to be safe from calling Class.forName method.
>>
> I see this changes loadMainClass to abort with resources that are keyed on java.launcher.cls.error6 and java.launcher.cls.error7 but they don't appear in the launcher.properties file. Does this work? I would assume MissingResourceException is thrown.
> Thanks for pointing this. I missed to add it to launcher.properties. But now I have changed error6 to point to java.launcher.cls.error1 and removed security exception handling.
>
> For java.launcher.module.error3 and java.launcher.module.error4 then "link" is likely to confuse people. Sure, there may be linkage errors but there are many linkage errors and I think would be a lot clearer if the message was "Unable to load main class {0} from module {1}\n\{2}".
> Updated the message as suggested.
>
> It's not clear to me that having a different message for security exceptions make sense, esp. when the exception is printed. So I think I would drop that.
> Yes, I agree to drop out the Security exceptions handling.
>
> Also loadModuleMainClass0 is unusual method name, we've mostly (not
> always) used the 0 suffix on native methods. In any case, it doesn't look like it is needed, the code was okay in loadModuleMainClass as it was.
> The method was added just to look the exception handling easier. I have removed the extra method and placed the code back into loadModuleMainClass.
>
> One final point is that is the nesting catching of LinkageError and SecurityException in loadMainClass, I assume you don't need the inner catch.
> I think both the catch blocks were needed, because the first(inner) catch was already inside catch.(This was same as NoClassDefFoundError catching twice in the same method). Now since NoClassDefFoundError is subclass of LinkageError, I have replaced it with LinkageError. And  I think still the same abort message holds good. Please let me know if this is ok.
>
> -Alan


From christoph.langer at sap.com  Mon Jan 23 21:38:52 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 23 Jan 2017 21:38:52 +0000
Subject: (JAXP) RFR: 8173111: Excessive recursion in EventFilterSupport
	when	filtering over large number of XML events can cause StackOverflow
In-Reply-To: <cf473666-1a3b-9c49-4ef2-a1f6714a4430@oracle.com>
References: <cf473666-1a3b-9c49-4ef2-a1f6714a4430@oracle.com>
Message-ID: <e9b762f54aa04daeae37a3876c692335@derote13de46.global.corp.sap>

Hi Daniel,

your fix looks good, pretty straightforward, +1.

A minor thing, src/java.xml/share/classes/com/sun/xml/internal/stream/EventFilterSupport.java:
67         while (super.hasNext()){
As you are touching this line, you could add a blank between ')' and '{'.

Disclaimer: I'm no reviewer.

Best regards
Christoph

> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf
> Of Daniel Fuchs
> Sent: Montag, 23. Januar 2017 18:48
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: (JAXP) RFR: 8173111: Excessive recursion in EventFilterSupport when
> filtering over large number of XML events can cause StackOverflow
> 
> Hi,
> 
> Please find below a fix for:
> 
> 8173111: Excessive recursion in EventFilterSupport when filtering
>           over large number of XML events can cause StackOverflow
> https://bugs.openjdk.java.net/browse/JDK-8173111
> 
> The fix is almost trivial: it replaces a recursion by a loop in
> two places.
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8173111/webrev.00/
> 
> The test will fail without the fix (at least on my machine)
> and pass with it (on my machine and in our test system).
> 
> best regards,
> 
> -- daniel

From naoto.sato at oracle.com  Mon Jan 23 21:51:55 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 23 Jan 2017 13:51:55 -0800
Subject: [9] RFR: 8172365: Provide a better migration path for
	ResourceBundleControlProvider
In-Reply-To: <87DD942F-6FA0-4679-B726-9835F64AACF7@oracle.com>
References: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>
	<a9cfe32d-456f-2ac5-77bc-c688047ad56b@oracle.com>
	<87DD942F-6FA0-4679-B726-9835F64AACF7@oracle.com>
Message-ID: <f7fe70f0-b479-87cf-6314-1af792319461@oracle.com>

OK, I will clarify the method description of getBundle(String, Locale, 
Module) as follows:

diff -r 290145dc2c96 
src/java.base/share/classes/java/util/ResourceBundle.java
--- a/src/java.base/share/classes/java/util/ResourceBundle.java
+++ b/src/java.base/share/classes/java/util/ResourceBundle.java
@@ -972,7 +972,11 @@
       * equivalent to calling {@link #getBundle(String, Locale, 
ClassLoader)
       * getBundle(baseName, targetLocale, module.getClassLoader()} to load
       * resource bundles that are visible to the class loader of the given
-     * unnamed module.
+     * unnamed module. The <a href="#default_behavior">default behavior</a>
+     * of resource bundle loading can be modified with custom {@link
+     * ResourceBundleControlProvider} implementations. Refer to the
+     * description of <a href="#modify_default_behavior">modifying the 
default
+     * behavior</a>.
       *
       * @param baseName the base name of the resource bundle,
       *                 a fully qualified class name

Naoto

On 01/23/2017 10:51 AM, Mandy Chung wrote:
>
>> On Jan 23, 2017, at 9:14 AM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>
>> http://cr.openjdk.java.net/~naoto/8172365/webrev.05/
>>
>>>
>>> The fix is to reinstate the code that has been removed with 8171189,
>>> with modification to load implementations with ServiceLoader.load()
>>> method. That way, SPI implementations can be searched on application's
>>> class path.
>
> This change is reasonable.  The custom control provider can only be used for loading of resource bundles in unnamed modules which maintains JDK 8 behavior.
>
> For the getBundle factory methods taking Module parameter, I suggest to explain the spec to clarify that the custom control provider will be used to load the resource bundle if the specified module is unnamed module.
>
> Otherwise looks good.
> Mandy
>


From joe.darcy at oracle.com  Mon Jan 23 22:05:58 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 23 Jan 2017 14:05:58 -0800
Subject: Guaranteed order of annotations?
In-Reply-To: <CADGJaX9-_KTwNcVYnp7dGN0fbj09FeBLCV3AZWn4jeXZBFA56A@mail.gmail.com>
References: <CADGJaX8xu+6XbjxU8G7no31KA17WW9P6hjgh-vvC0Ezg7qgTMg@mail.gmail.com>
	<ABC6F6B1F6CA734A9B233369A3750F1531093392@MBX021-W3-CA-4.exch021.domain.local>
	<CADGJaX8HfFX7Q2YK-_tpcf6xdMTzrrasAtVbBgGSss8e_uWz3A@mail.gmail.com>
	<587ECF2C.6000505@oracle.com>
	<CADGJaX9-_KTwNcVYnp7dGN0fbj09FeBLCV3AZWn4jeXZBFA56A@mail.gmail.com>
Message-ID: <49ec5a37-11e5-0c9c-d17b-9784a34ae0b3@oracle.com>

Hi Gunnar,

Annotations went into the platform way back in Java SE 5.0, with a GA 
during 2004. When working on repeating annotations, I was surprised to 
find there weren't stronger ordering guarantees for annotations from 
core reflection. However, requests to tighten this aspect of the 
platform haven't come up very often in the interim and I don't like it 
is likely to happen at this point.

HTH,

-Joe


On 1/17/2017 11:26 PM, Gunnar Morling wrote:
> Joseph, all,
>
> Thanks for the clarification.
>
> Are there chances to establish such guaranteed ordering in a future
> Java version? As pointed out, it'd be very helpful to Bean Validation
> and I reckon other cases, too.
>
> Thanks,
>
> --Gunnar
>
>
>
> 2017-01-18 3:13 GMT+01:00 Joseph D. Darcy <joe.darcy at oracle.com>:
>> Hello,
>>
>> Following up on Joel's message, IIRC this ordering issue did come up during
>> the design and testing of repeating annotations.
>>
>> As noted previously in the thread, while the ordering of the annotations in
>> a container annotation is guaranteed, there is *not* a general ordering
>> constraint on the annotations returned by the methods of the
>> AnnotatedElement interface.
>>
>> HTH,
>>
>> -Joe
>>
>>
>> On 1/13/2017 1:16 PM, Gunnar Morling wrote:
>>> Hi Yuri,
>>>
>>> Thanks for the pointer.
>>>
>>> But do you see any clear description of an order mandated for
>>> getDeclaredAnnotations()? The only references to an order I can find
>>> there are for repeatable annotations (where source code order is
>>> maintained when retrieving them via the container annotation type).
>>> But I cannot find any guaranteed order when obtaining all declared
>>> annotations from an element.
>>>
>>> The reason why I'm asking is Bean Validation, where we've seen
>>> requests of people that wish to validate the constraints of an element
>>> in a fixed order, aborting after the first failed constraint:
>>>
>>>       @NotNull
>>>       @Email
>>>       String email;
>>>
>>> Here one may want to first validate @NotNull and don't proceed with
>>> validating @Email if the field is null.
>>>
>>> Relying on source order would be a very natural way to express the
>>> order of constraints. Without a guaranteed ordering of annotations
>>> we'd have to add some other means of ordering, e.g. an attribute with
>>> the index (@NotNull(order=0) @Email(order=1)) which is more verbose of
>>> course.
>>>
>>> --Gunnar
>>>
>>>
>>>
>>>
>>>
>>> 2017-01-13 21:15 GMT+01:00 Yuri Gaevsky <ygaevsky at azulsystems.com>:
>>>> Hi Gunnar,
>>>>
>>>> Please take a look at JDK-8010679 'Clarify "present" and annotation
>>>> ordering in Core Reflection for Annotations' [*].
>>>>
>>>> Best regards,
>>>> -Yuri
>>>>
>>>> [*] https://bugs.openjdk.java.net/browse/JDK-8010679
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
>>>> Behalf Of Gunnar Morling
>>>> Sent: Friday, January 13, 2017 08:14 PM
>>>> To: core-libs-dev at openjdk.java.net
>>>> Subject: Guaranteed order of annotations?
>>>>
>>>> Hi,
>>>>
>>>> Is there any order guaranteed in which an element's annotations are
>>>> returned by AnnotatedElement#getDeclaredAnnotations()? Specifically,
>>>> is this the order in which the annotations are given in the source
>>>> code?
>>>>
>>>> Section 9.7.5. of the JLS ("Multiple Annotations of the Same Type")
>>>> makes a statement of the source order being considered by the array of
>>>> the implicit container annotation created for a repeatable annotation
>>>> ("[...] all the base annotations in the left-to-right order in which
>>>> they appeared in the context").
>>>>
>>>> But I couldn't find any authoritative description on the ordering
>>>> behaviour of getDeclaredAnnotations(). Should we assume that we cannot
>>>> rely on the order in the source?
>>>>
>>>> Thanks for any pointers,
>>>>
>>>> --Gunnar
>>


From naoto.sato at oracle.com  Mon Jan 23 22:07:24 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 23 Jan 2017 14:07:24 -0800
Subject: <i18n dev> [9] RFR: 8172365: Provide a better migration path for
	ResourceBundleControlProvider
In-Reply-To: <f7fe70f0-b479-87cf-6314-1af792319461@oracle.com>
References: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>
	<a9cfe32d-456f-2ac5-77bc-c688047ad56b@oracle.com>
	<87DD942F-6FA0-4679-B726-9835F64AACF7@oracle.com>
	<f7fe70f0-b479-87cf-6314-1af792319461@oracle.com>
Message-ID: <3a530274-a02a-e5b5-19e0-bd0ad7d1a91d@oracle.com>

More concise version:

--- a/src/java.base/share/classes/java/util/ResourceBundle.java
+++ b/src/java.base/share/classes/java/util/ResourceBundle.java
@@ -972,7 +972,9 @@
       * equivalent to calling {@link #getBundle(String, Locale, 
ClassLoader)
       * getBundle(baseName, targetLocale, module.getClassLoader()} to load
       * resource bundles that are visible to the class loader of the given
-     * unnamed module.
+     * unnamed module. Custom {@link * ResourceBundleControlProvider}
+     * implementations, if present, will only be invoked if the specified
+     * module is an unnamed module.
       *
       * @param baseName the base name of the resource bundle,
       *                 a fully qualified class name

Naoto

On 01/23/2017 01:51 PM, Naoto Sato wrote:
> OK, I will clarify the method description of getBundle(String, Locale,
> Module) as follows:
>
> diff -r 290145dc2c96
> src/java.base/share/classes/java/util/ResourceBundle.java
> --- a/src/java.base/share/classes/java/util/ResourceBundle.java
> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java
> @@ -972,7 +972,11 @@
>       * equivalent to calling {@link #getBundle(String, Locale,
> ClassLoader)
>       * getBundle(baseName, targetLocale, module.getClassLoader()} to load
>       * resource bundles that are visible to the class loader of the given
> -     * unnamed module.
> +     * unnamed module. The <a href="#default_behavior">default
> behavior</a>
> +     * of resource bundle loading can be modified with custom {@link
> +     * ResourceBundleControlProvider} implementations. Refer to the
> +     * description of <a href="#modify_default_behavior">modifying the
> default
> +     * behavior</a>.
>       *
>       * @param baseName the base name of the resource bundle,
>       *                 a fully qualified class name
>
> Naoto
>
> On 01/23/2017 10:51 AM, Mandy Chung wrote:
>>
>>> On Jan 23, 2017, at 9:14 AM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>
>>> http://cr.openjdk.java.net/~naoto/8172365/webrev.05/
>>>
>>>>
>>>> The fix is to reinstate the code that has been removed with 8171189,
>>>> with modification to load implementations with ServiceLoader.load()
>>>> method. That way, SPI implementations can be searched on application's
>>>> class path.
>>
>> This change is reasonable.  The custom control provider can only be
>> used for loading of resource bundles in unnamed modules which
>> maintains JDK 8 behavior.
>>
>> For the getBundle factory methods taking Module parameter, I suggest
>> to explain the spec to clarify that the custom control provider will
>> be used to load the resource bundle if the specified module is unnamed
>> module.
>>
>> Otherwise looks good.
>> Mandy
>>
>


From peter.levart at gmail.com  Mon Jan 23 22:29:04 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 23 Jan 2017 23:29:04 +0100
Subject: RFR [9]: 8173201:
	java/lang/reflect/PublicMethods/PublicMethodsTest.java fails because of
	too many open files
Message-ID: <10de207b-d4f0-958e-48b3-a84d49d381b1@gmail.com>

Hi,

I have a fix for intermittently failing test that I created recently:

http://cr.openjdk.java.net/~plevart/jdk9-dev/8173201_PublicMethodsTest.fix/webrev.01/

The test has been found to fail with a strange compilation error:

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

...which is just a consequence of javac (used via JavaCompiler API) not 
being able to open another file.

I have debuged the test with "lsof" Linux utility and saw the test 
opening several thousand files. It creates 1379 StandardJavaFileManager 
objects as delegates for custom ForwardingJavaFileManager objects 
encapsulating individual test case sources to be compiled. The test then 
uses those file manager objects but never closes them explicitly. The 
fix is to close those file manager objects as soon as they are not 
needed any more. After applying the fix, I re-checked with "lsof" 
utility to confirm that the test keeps just a few files open now.

Regards, Peter


From claes.redestad at oracle.com  Mon Jan 23 22:37:49 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 23 Jan 2017 23:37:49 +0100
Subject: RFR [9]: 8173201:
	java/lang/reflect/PublicMethods/PublicMethodsTest.java fails because of
	too many open files
In-Reply-To: <10de207b-d4f0-958e-48b3-a84d49d381b1@gmail.com>
References: <10de207b-d4f0-958e-48b3-a84d49d381b1@gmail.com>
Message-ID: <9cc6b1c5-c3e7-3316-67be-0e50caa6ebfd@oracle.com>

+1

/Claes

On 2017-01-23 23:29, Peter Levart wrote:
> Hi,
>
> I have a fix for intermittently failing test that I created recently:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8173201_PublicMethodsTest.fix/webrev.01/
>
>
> The test has been found to fail with a strange compilation error:
>
>     https://bugs.openjdk.java.net/browse/JDK-8173201
>
> ...which is just a consequence of javac (used via JavaCompiler API) not
> being able to open another file.
>
> I have debuged the test with "lsof" Linux utility and saw the test
> opening several thousand files. It creates 1379 StandardJavaFileManager
> objects as delegates for custom ForwardingJavaFileManager objects
> encapsulating individual test case sources to be compiled. The test then
> uses those file manager objects but never closes them explicitly. The
> fix is to close those file manager objects as soon as they are not
> needed any more. After applying the fix, I re-checked with "lsof"
> utility to confirm that the test keeps just a few files open now.
>
> Regards, Peter
>

From paul.sandoz at oracle.com  Mon Jan 23 22:53:37 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 23 Jan 2017 14:53:37 -0800
Subject: RFR [9]: 8173201:
	java/lang/reflect/PublicMethods/PublicMethodsTest.java fails
	because of too many open files
In-Reply-To: <10de207b-d4f0-958e-48b3-a84d49d381b1@gmail.com>
References: <10de207b-d4f0-958e-48b3-a84d49d381b1@gmail.com>
Message-ID: <F1597EE0-FF71-42BA-B9E5-EF94DBF163DB@oracle.com>

+1

Paul.

> On 23 Jan 2017, at 14:29, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi,
> 
> I have a fix for intermittently failing test that I created recently:
> 
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8173201_PublicMethodsTest.fix/webrev.01/
> 
> The test has been found to fail with a strange compilation error:
> 
>    https://bugs.openjdk.java.net/browse/JDK-8173201
> 
> ...which is just a consequence of javac (used via JavaCompiler API) not being able to open another file.
> 
> I have debuged the test with "lsof" Linux utility and saw the test opening several thousand files. It creates 1379 StandardJavaFileManager objects as delegates for custom ForwardingJavaFileManager objects encapsulating individual test case sources to be compiled. The test then uses those file manager objects but never closes them explicitly. The fix is to close those file manager objects as soon as they are not needed any more. After applying the fix, I re-checked with "lsof" utility to confirm that the test keeps just a few files open now.
> 
> Regards, Peter
> 


From david.holmes at oracle.com  Mon Jan 23 23:50:48 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Jan 2017 09:50:48 +1000
Subject: RFR of JDK-8171142: jdk_rmi registry test fail to clean up on
	failure
In-Reply-To: <64b48f04-92b0-d31e-2e27-3a0ab2e58629@oracle.com>
References: <64b48f04-92b0-d31e-2e27-3a0ab2e58629@oracle.com>
Message-ID: <730188cd-2a94-bc5a-f23f-9238939a8b94@oracle.com>

Hi Hamlin,

Thanks for tackling this one.

On 23/01/2017 4:38 PM, Hamlin Li wrote:
> Would you please review the below patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8171142
>
> webrev: http://cr.openjdk.java.net/~mli/8171142/webrev.00/

As I commented in the bug report, and as Roger also mentioned, 
destroyForcibly() should be used here.

Thanks,
David
-----

>
> Thank you
>
> -Hamlin
>
>

From luke.hutch at gmail.com  Tue Jan 24 04:41:46 2017
From: luke.hutch at gmail.com (Luke Hutchison)
Date: Mon, 23 Jan 2017 20:41:46 -0800
Subject: Calling a lambda expression from a new thread before the main method
	is run causes the thread to lock up
Message-ID: <CAHLUFO=tCcmi8BLCU_tLxxQrSxGCd43PfsDEaTjvPDnsnfnwtg@mail.gmail.com>

If you run the code below, the active JVM thread (in the ExecutorService)
locks up when the lambda expression is called. The Eclipse debugger is not
able to stop the locked-up thread, or get a stacktrace beyond the call into
the lambda.

The problem seems to be that some part of the Java 8 lambda system is not
properly initialized until just before the main method is called. This
problem is only exhibited if you call a lambda expression from a new
thread, spawned by a static initializer block, before the main method is
executed.

Reproducibility: 100%. (If you change the value of either or both of the
static boolean fields, the code completes as expected.)

This problem exists in both Oracle jdk1.8.0_121 and Fedora OpenJDK
1.8.0.111 (64 bit).



import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class LambdaBug {

    // Code will hang after "Entering startUp()" if both of these are true
    private static final boolean RUN_AS_STATIC_INITIALIZER = true;
    private static final boolean RUN_USING_LAMBDA = true;

    static {
        if (RUN_AS_STATIC_INITIALIZER) {
            startUp();
        }
    }

    private static void startUp() {
        System.out.println("Entering startUp()");
        ExecutorService es = Executors.newSingleThreadExecutor();
        try {
            Callable<Void> callable;
            if (RUN_USING_LAMBDA) {
                callable = () -> {
                    System.out.println("Lambda executed");
                    return null;
                };
            } else {
                callable = new Callable<Void>() {
                    @Override
                    public Void call() throws Exception {
                        System.out.println("Inner class method executed");
                        return null;
                    }
                };
            }
            es.submit(callable).get();
        } catch (InterruptedException | ExecutionException e) {
            throw new RuntimeException(e);
        } finally {
            es.shutdown();
        }
        System.out.println("Exiting startUp()");
    }

    public static void main(String[] args) {
        if (!RUN_AS_STATIC_INITIALIZER) {
            startUp();
        }
        System.out.println("Exiting main");
    }
}

From mandy.chung at oracle.com  Tue Jan 24 05:06:27 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 23 Jan 2017 21:06:27 -0800
Subject: <i18n dev> [9] RFR: 8172365: Provide a better migration path for
	ResourceBundleControlProvider
In-Reply-To: <3a530274-a02a-e5b5-19e0-bd0ad7d1a91d@oracle.com>
References: <441f86fe-25e8-179b-b072-ebe02c8da62d@oracle.com>
	<a9cfe32d-456f-2ac5-77bc-c688047ad56b@oracle.com>
	<87DD942F-6FA0-4679-B726-9835F64AACF7@oracle.com>
	<f7fe70f0-b479-87cf-6314-1af792319461@oracle.com>
	<3a530274-a02a-e5b5-19e0-bd0ad7d1a91d@oracle.com>
Message-ID: <C5020D2B-1F90-428A-A2BA-3092BF3B039B@oracle.com>

+1

Mandy

> On Jan 23, 2017, at 2:07 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> More concise version:
> 
> --- a/src/java.base/share/classes/java/util/ResourceBundle.java
> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java
> @@ -972,7 +972,9 @@
>      * equivalent to calling {@link #getBundle(String, Locale, ClassLoader)
>      * getBundle(baseName, targetLocale, module.getClassLoader()} to load
>      * resource bundles that are visible to the class loader of the given
> -     * unnamed module.
> +     * unnamed module. Custom {@link * ResourceBundleControlProvider}
> +     * implementations, if present, will only be invoked if the specified
> +     * module is an unnamed module.
>      *
>      * @param baseName the base name of the resource bundle,
>      *                 a fully qualified class name
> 
> Naoto
> 
> On 01/23/2017 01:51 PM, Naoto Sato wrote:
>> OK, I will clarify the method description of getBundle(String, Locale,
>> Module) as follows:
>> 
>> diff -r 290145dc2c96
>> src/java.base/share/classes/java/util/ResourceBundle.java
>> --- a/src/java.base/share/classes/java/util/ResourceBundle.java
>> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java
>> @@ -972,7 +972,11 @@
>>      * equivalent to calling {@link #getBundle(String, Locale,
>> ClassLoader)
>>      * getBundle(baseName, targetLocale, module.getClassLoader()} to load
>>      * resource bundles that are visible to the class loader of the given
>> -     * unnamed module.
>> +     * unnamed module. The <a href="#default_behavior">default
>> behavior</a>
>> +     * of resource bundle loading can be modified with custom {@link
>> +     * ResourceBundleControlProvider} implementations. Refer to the
>> +     * description of <a href="#modify_default_behavior">modifying the
>> default
>> +     * behavior</a>.
>>      *
>>      * @param baseName the base name of the resource bundle,
>>      *                 a fully qualified class name
>> 
>> Naoto
>> 
>> On 01/23/2017 10:51 AM, Mandy Chung wrote:
>>> 
>>>> On Jan 23, 2017, at 9:14 AM, Naoto Sato <naoto.sato at oracle.com> wrote:
>>>> 
>>>> http://cr.openjdk.java.net/~naoto/8172365/webrev.05/
>>>> 
>>>>> 
>>>>> The fix is to reinstate the code that has been removed with 8171189,
>>>>> with modification to load implementations with ServiceLoader.load()
>>>>> method. That way, SPI implementations can be searched on application's
>>>>> class path.
>>> 
>>> This change is reasonable.  The custom control provider can only be
>>> used for loading of resource bundles in unnamed modules which
>>> maintains JDK 8 behavior.
>>> 
>>> For the getBundle factory methods taking Module parameter, I suggest
>>> to explain the spec to clarify that the custom control provider will
>>> be used to load the resource bundle if the specified module is unnamed
>>> module.
>>> 
>>> Otherwise looks good.
>>> Mandy
>>> 
>> 
> 


From david.holmes at oracle.com  Tue Jan 24 06:48:28 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Jan 2017 16:48:28 +1000
Subject: Calling a lambda expression from a new thread before the main
	method is run causes the thread to lock up
In-Reply-To: <CAHLUFO=tCcmi8BLCU_tLxxQrSxGCd43PfsDEaTjvPDnsnfnwtg@mail.gmail.com>
References: <CAHLUFO=tCcmi8BLCU_tLxxQrSxGCd43PfsDEaTjvPDnsnfnwtg@mail.gmail.com>
Message-ID: <431dbd47-19fe-45ef-4f7c-42e5e5c9ca15@oracle.com>

Hi Luke,

On 24/01/2017 2:41 PM, Luke Hutchison wrote:
> If you run the code below, the active JVM thread (in the ExecutorService)
> locks up when the lambda expression is called. The Eclipse debugger is not
> able to stop the locked-up thread, or get a stacktrace beyond the call into
> the lambda.

That looks like a variation of the classic class initialization deadlock 
problem. Your main thread is blocked in es.submit(callable).get(); while 
still within the static initializer of the LambdaBug class. If the 
executor thread also needs to ensure LambdaBug is initialized (which it 
will in the lambda case) then it will wait for the main thread to 
complete the initialization. Hence deadlock.

David
-----

> The problem seems to be that some part of the Java 8 lambda system is not
> properly initialized until just before the main method is called. This
> problem is only exhibited if you call a lambda expression from a new
> thread, spawned by a static initializer block, before the main method is
> executed.
>
> Reproducibility: 100%. (If you change the value of either or both of the
> static boolean fields, the code completes as expected.)
>
> This problem exists in both Oracle jdk1.8.0_121 and Fedora OpenJDK
> 1.8.0.111 (64 bit).
>
>
>
> import java.util.concurrent.Callable;
> import java.util.concurrent.ExecutionException;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
>
> public class LambdaBug {
>
>     // Code will hang after "Entering startUp()" if both of these are true
>     private static final boolean RUN_AS_STATIC_INITIALIZER = true;
>     private static final boolean RUN_USING_LAMBDA = true;
>
>     static {
>         if (RUN_AS_STATIC_INITIALIZER) {
>             startUp();
>         }
>     }
>
>     private static void startUp() {
>         System.out.println("Entering startUp()");
>         ExecutorService es = Executors.newSingleThreadExecutor();
>         try {
>             Callable<Void> callable;
>             if (RUN_USING_LAMBDA) {
>                 callable = () -> {
>                     System.out.println("Lambda executed");
>                     return null;
>                 };
>             } else {
>                 callable = new Callable<Void>() {
>                     @Override
>                     public Void call() throws Exception {
>                         System.out.println("Inner class method executed");
>                         return null;
>                     }
>                 };
>             }
>             es.submit(callable).get();
>         } catch (InterruptedException | ExecutionException e) {
>             throw new RuntimeException(e);
>         } finally {
>             es.shutdown();
>         }
>         System.out.println("Exiting startUp()");
>     }
>
>     public static void main(String[] args) {
>         if (!RUN_AS_STATIC_INITIALIZER) {
>             startUp();
>         }
>         System.out.println("Exiting main");
>     }
> }
>

From luke.hutch at gmail.com  Tue Jan 24 07:21:39 2017
From: luke.hutch at gmail.com (Luke Hutchison)
Date: Mon, 23 Jan 2017 23:21:39 -0800
Subject: Calling a lambda expression from a new thread before the main
	method is run causes the thread to lock up
In-Reply-To: <431dbd47-19fe-45ef-4f7c-42e5e5c9ca15@oracle.com>
References: <CAHLUFO=tCcmi8BLCU_tLxxQrSxGCd43PfsDEaTjvPDnsnfnwtg@mail.gmail.com>
	<431dbd47-19fe-45ef-4f7c-42e5e5c9ca15@oracle.com>
Message-ID: <CAHLUFOm8rRo_KqmzFmNHjeEpiXrz43pHUyQL4UC6ML_bm6NyAQ@mail.gmail.com>

On Mon, Jan 23, 2017 at 10:48 PM, David Holmes <david.holmes at oracle.com>
wrote:

> On 24/01/2017 2:41 PM, Luke Hutchison wrote:
>
>> If you run the code below, the active JVM thread (in the ExecutorService)
>> locks up when the lambda expression is called. The Eclipse debugger is not
>> able to stop the locked-up thread, or get a stacktrace beyond the call
>> into
>> the lambda.
>>
>
> That looks like a variation of the classic class initialization deadlock
> problem. Your main thread is blocked in es.submit(callable).get(); while
> still within the static initializer of the LambdaBug class. If the executor
> thread also needs to ensure LambdaBug is initialized (which it will in the
> lambda case) then it will wait for the main thread to complete the
> initialization. Hence deadlock.
>

Thanks for the explanation -- although I don't understand why a lambda
expression requires its defining class to be initialized, whereas an
anonymous inner class does not. The lambda body does not refer to the
LambdaBug class. This must be due to an implicit reference to the defining
class being added by the compiler for purposes of capturing the lexical
scope (with this issue not getting triggered in the case of anonymous inner
classes due to scoping differences)? However, why is the containing class
reference even used in this case, when variables in the containing scope
are not referenced?

If this is due to lexical scoping, shouldn't the compiler be able to add
some runtime code to detect cases of this kind of deadlock, and throw a
RuntimeException, or potentially even detect some of these cases statically?

Why is it possible to directly call lambdas inside a static initializer
block without causing a deadlock (in other words, why is there no deadlock
as long as the lambdas are not executed on a different thread while the
main thread blocks)? The calling class is still not completely initialized
when calling lambdas directly in a static initializer block on the main
thread.

From luke.hutch at gmail.com  Tue Jan 24 07:37:24 2017
From: luke.hutch at gmail.com (Luke Hutchison)
Date: Mon, 23 Jan 2017 23:37:24 -0800
Subject: Calling a lambda expression from a new thread before the main
	method is run causes the thread to lock up
In-Reply-To: <CAHLUFOm8rRo_KqmzFmNHjeEpiXrz43pHUyQL4UC6ML_bm6NyAQ@mail.gmail.com>
References: <CAHLUFO=tCcmi8BLCU_tLxxQrSxGCd43PfsDEaTjvPDnsnfnwtg@mail.gmail.com>
	<431dbd47-19fe-45ef-4f7c-42e5e5c9ca15@oracle.com>
	<CAHLUFOm8rRo_KqmzFmNHjeEpiXrz43pHUyQL4UC6ML_bm6NyAQ@mail.gmail.com>
Message-ID: <CAHLUFOkhv2HyT+xh+kL-89ZSYNf8GAs-gQDYfuw9BRkL1CYo1w@mail.gmail.com>

On Mon, Jan 23, 2017 at 11:21 PM, Luke Hutchison <luke.hutch at gmail.com>
wrote:

> That looks like a variation of the classic class initialization deadlock
>> problem. Your main thread is blocked in es.submit(callable).get(); while
>> still within the static initializer of the LambdaBug class. If the executor
>> thread also needs to ensure LambdaBug is initialized (which it will in the
>> lambda case) then it will wait for the main thread to complete the
>> initialization. Hence deadlock.
>>
>
> Thanks for the explanation -- although I don't understand why a lambda
> expression requires its defining class to be initialized, whereas an
> anonymous inner class does not.
>

Also, I'm trying to determine if it is possible to detect cases like this
at runtime without triggering the deadlock, since I have already had one
bug report from a user of FastClasspathScanner running into this problem:

https://github.com/lukehutch/fast-classpath-scanner/issues/103


This user could not understand why FastClasspathScanner appeared to
deadlock when he passed in a lambda, but not when he passed in an anonymous
inner class.

Is it possible to examine an object to determine (1) if it was defined as a
lambda, and (2) if the enclosing class (i.e. the class that defined the
lambda) is initialized? (I can't see foolproof ways to do either of these
things, based on a cursory search.)  If so, at least I will be able to
throw an exception in my code, which will be better than hitting a deadlock
situation.

From luke.hutch at gmail.com  Tue Jan 24 07:52:10 2017
From: luke.hutch at gmail.com (Luke Hutchison)
Date: Mon, 23 Jan 2017 23:52:10 -0800
Subject: Calling a lambda expression from a new thread before the main
	method is run causes the thread to lock up
In-Reply-To: <CAHLUFOkhv2HyT+xh+kL-89ZSYNf8GAs-gQDYfuw9BRkL1CYo1w@mail.gmail.com>
References: <CAHLUFO=tCcmi8BLCU_tLxxQrSxGCd43PfsDEaTjvPDnsnfnwtg@mail.gmail.com>
	<431dbd47-19fe-45ef-4f7c-42e5e5c9ca15@oracle.com>
	<CAHLUFOm8rRo_KqmzFmNHjeEpiXrz43pHUyQL4UC6ML_bm6NyAQ@mail.gmail.com>
	<CAHLUFOkhv2HyT+xh+kL-89ZSYNf8GAs-gQDYfuw9BRkL1CYo1w@mail.gmail.com>
Message-ID: <CAHLUFOnEwXh4pdMEdzzMEob2ebsnpLV2vkgiPjoMWSzm0Wc-Rg@mail.gmail.com>

On Mon, Jan 23, 2017 at 11:37 PM, Luke Hutchison <luke.hutch at gmail.com>
wrote:

> On Mon, Jan 23, 2017 at 11:21 PM, Luke Hutchison <luke.hutch at gmail.com>
> wrote:
>
>> That looks like a variation of the classic class initialization deadlock
>>> problem. Your main thread is blocked in es.submit(callable).get(); while
>>> still within the static initializer of the LambdaBug class. If the executor
>>> thread also needs to ensure LambdaBug is initialized (which it will in the
>>> lambda case) then it will wait for the main thread to complete the
>>> initialization. Hence deadlock.
>>
>>
PS I submitted a bug report before finding core-libs-dev, and that bug was
just posted to Jira:

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8173252

From frank.yuan at oracle.com  Tue Jan 24 07:59:11 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 24 Jan 2017 15:59:11 +0800
Subject: RFR (JAXP) 8169827:
	javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
In-Reply-To: <42b9f71db0534e7985f761130713295f@derote13de46.global.corp.sap>
References: <eadaad631dae47278030f243a7afb9c6@derote13de46.global.corp.sap>
	<9e9fb81a-92cf-57ad-5851-a2d8a704811c@oracle.com>
	<42b9f71db0534e7985f761130713295f@derote13de46.global.corp.sap>
Message-ID: <038c01d27617$c1771d20$44655760$@oracle.com>

Hi Christoph

Many thanks for your effort!

It's really better than the old version! However I have 2 comments although I am not a reviewer(as you often stated :))
1. we could also write java code to copy/delete JDK.
2. 8169827 is to track PropertiesTest failed in copying JDK intermittently. I suggest to use another bug for your improvement
because I am not sure if this patch can improve the issue of 8169827.

To Christoph and Daniel

Btw, Christoph's patch inspired me. You know, PropertiesTest copies a JDK in order to isolate the file change of the JDK, actually
there are some other similar tests(to test some other JDK property or config files) in JDK repo, they take the same way as well as
have similar code...
I have another idea for this test, that is we can only make symbolic link to the JDK files/directories except conf directory, create
a directory named with "conf" under the new jdk directory, and then make symbolic link to the files/directories in conf to the real
jdk/conf except jaxp.properties. This will reduce the most of copying work and may reduce the risk of copying work. What's your
opinion?

Thanks
Frank

> -----Original Message-----
> From: Langer, Christoph [mailto:christoph.langer at sap.com]
> To: Daniel Fuchs; Frank Yuan; core-libs-dev at openjdk.java.net
> Subject: RE: RFR (JAXP) 8169827: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> 
> Hi Daniel,
> 
> thanks for checking/reviewing. So I'll submit with removing the ProblemList.txt entry and I'll also remove the intermittent flag.
> 
> Sounds fair to check later if problems will still show up. Although I have the feeling that the issue of
> https://bugs.openjdk.java.net/browse/JDK-8147431 might appear again...
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> > Sent: Montag, 23. Januar 2017 17:12
> > To: Langer, Christoph <christoph.langer at sap.com>; Frank Yuan
> > <frank.yuan at oracle.com>; core-libs-dev at openjdk.java.net
> > Subject: Re: RFR (JAXP) 8169827:
> > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> >
> > Hi Christoph,
> >
> > Thanks for fixing this test!
> >
> > I imported your patch, modified ProblemList.txt to not skip the test,
> > and sent it through our test system, and I'm happy to report that
> > the test was run on all available platforms with no failure.
> >
> > So I think you should simply remove the line from ProblemList.txt
> > (no need for a new webrev).
> > If it fails again on more exotic platform we'll simply add it
> > back to ProblemList.txt for those platforms where it fails
> > (I guess it could happen if there's not enough disk space).
> >
> > Otherwise I have looked over the changes you proposed and they
> > do seem OK to me.
> >
> > +1
> >
> > best regards,
> >
> > -- daniel
> >
> > On 23/01/17 10:03, Langer, Christoph wrote:
> > > Hi,
> > >
> > > while working on jaxp changes and running jtreg tests I found that test
> > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh does not work. I then saw
> > that this was already reported with bug 8169827. But, as I had already spent
> > some time to fix this test I'd like to contribute my fix:
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169827
> > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169827.0/
> > >
> > > I converted the test to Java and removed the shell script PropertiesTest.sh.
> > This resolves the compilation issue.
> > >
> > > However, the test needs to copy an isolated jdk as it modifies files in the JDK.
> > So I'm still using the copy script to first copy the jdk and afterwards remove the
> > copy. These are separate 'shell' test steps. And in the actual test I'm running a
> > child process with the isolated JDK.
> > >
> > > I also don't know if the test should be kept in the problem list and/or also be
> > tagged as 'intermittent' as the whole jdk copying procedure by means of a shell
> > script seems error prone. In case we keep the entry in the problem list, I can
> > also open a separate bug for my change.
> > >
> > > @Frank: I don't know if you have some larger change in mind which improves
> > the isolated jdk type testing greatly, otherwise I think this fix could at least
> > make things better than they are at the moment.
> > >
> > > Thanks & Best regards
> > > Christoph
> > >



From forax at univ-mlv.fr  Tue Jan 24 08:02:39 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 24 Jan 2017 09:02:39 +0100 (CET)
Subject: Calling a lambda expression from a new thread before the main
	method is run causes the thread to lock up
In-Reply-To: <CAHLUFOm8rRo_KqmzFmNHjeEpiXrz43pHUyQL4UC6ML_bm6NyAQ@mail.gmail.com>
References: <CAHLUFO=tCcmi8BLCU_tLxxQrSxGCd43PfsDEaTjvPDnsnfnwtg@mail.gmail.com>
	<431dbd47-19fe-45ef-4f7c-42e5e5c9ca15@oracle.com>
	<CAHLUFOm8rRo_KqmzFmNHjeEpiXrz43pHUyQL4UC6ML_bm6NyAQ@mail.gmail.com>
Message-ID: <1339677733.497617.1485244959135.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Luke Hutchison" <luke.hutch at gmail.com>
> ?: "David Holmes" <david.holmes at oracle.com>
> Cc: core-libs-dev at openjdk.java.net
> Envoy?: Mardi 24 Janvier 2017 08:21:39
> Objet: Re: Calling a lambda expression from a new thread before the main	method is run causes the thread to lock up

> On Mon, Jan 23, 2017 at 10:48 PM, David Holmes <david.holmes at oracle.com>
> wrote:
> 
>> On 24/01/2017 2:41 PM, Luke Hutchison wrote:
>>
>>> If you run the code below, the active JVM thread (in the ExecutorService)
>>> locks up when the lambda expression is called. The Eclipse debugger is not
>>> able to stop the locked-up thread, or get a stacktrace beyond the call
>>> into
>>> the lambda.
>>>
>>
>> That looks like a variation of the classic class initialization deadlock
>> problem. Your main thread is blocked in es.submit(callable).get(); while
>> still within the static initializer of the LambdaBug class. If the executor
>> thread also needs to ensure LambdaBug is initialized (which it will in the
>> lambda case) then it will wait for the main thread to complete the
>> initialization. Hence deadlock.
>>
> 
> Thanks for the explanation -- although I don't understand why a lambda
> expression requires its defining class to be initialized, whereas an
> anonymous inner class does not. The lambda body does not refer to the
> LambdaBug class. This must be due to an implicit reference to the defining
> class being added by the compiler for purposes of capturing the lexical
> scope (with this issue not getting triggered in the case of anonymous inner
> classes due to scoping differences)? However, why is the containing class
> reference even used in this case, when variables in the containing scope
> are not referenced?

The body of a lambda is desugared by the compiler into a static method, so when you submit the callable, a worker thread of the executor will try to execute the code of the static method but because the static initializer is not finished, the worker thread has to wait, then you call get() inside the static block that waits that the worker thread to finish its work => deadlock.

In case of an inner class, your code is in the inner class so the worker thread don't wait the static block to be finished, so no deadlock

As a rule of thumb, never starts a thread in a static block, you will get this classical deadlock AND your code is hard to test because static blocks tend to  be executed in a random order (i.e. class loading is lazy so execution of static blocks are lazy too). 

> 
> If this is due to lexical scoping, shouldn't the compiler be able to add
> some runtime code to detect cases of this kind of deadlock, and throw a
> RuntimeException, or potentially even detect some of these cases statically?
> 
> Why is it possible to directly call lambdas inside a static initializer
> block without causing a deadlock (in other words, why is there no deadlock
> as long as the lambdas are not executed on a different thread while the
> main thread blocks)? The calling class is still not completely initialized
> when calling lambdas directly in a static initializer block on the main
> thread.

cheers,
R?mi

From luke.hutch at gmail.com  Tue Jan 24 08:13:17 2017
From: luke.hutch at gmail.com (Luke Hutchison)
Date: Tue, 24 Jan 2017 00:13:17 -0800
Subject: Calling a lambda expression from a new thread before the main
	method is run causes the thread to lock up
In-Reply-To: <1339677733.497617.1485244959135.JavaMail.zimbra@u-pem.fr>
References: <CAHLUFO=tCcmi8BLCU_tLxxQrSxGCd43PfsDEaTjvPDnsnfnwtg@mail.gmail.com>
	<431dbd47-19fe-45ef-4f7c-42e5e5c9ca15@oracle.com>
	<CAHLUFOm8rRo_KqmzFmNHjeEpiXrz43pHUyQL4UC6ML_bm6NyAQ@mail.gmail.com>
	<1339677733.497617.1485244959135.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAHLUFO=hgNUos8WtOvO7g0NHn4R72ja_-V0-7AWokTpL5nc4yQ@mail.gmail.com>

On Tue, Jan 24, 2017 at 12:02 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> a worker thread of the executor will try to execute the code of the static
> method but because the static initializer is not finished, the worker
> thread has to wait


But what is the worker thread waiting for in the case of the lambda that it
is not waiting for in the case of the AIC? I assume this is due to the
lexical scoping of the lambda?

As a rule of thumb, never starts a thread in a static block, you will get
> this classical deadlock AND your code is hard to test because static blocks
> tend to  be executed in a random order (i.e. class loading is lazy so
> execution of static blocks are lazy too).
>

This is the problem: I am a library author, and a user of my library ran
into this problem. The user did not necessarily know that I was launching
new threads in my library, and as a library author, I did not know I needed
to advise users that they should not call my library from static blocks. It
seems to be quite a big problem that a static block is not a standard
execution context and can lead to deadlocks.

Is there any way I can detect this in my code? I guess I could just get a
stacktrace, and look for "<init>" or similar somewhere in the stacktrace,
then throw an exception if called in this context? Is this a reliable
enough test for being run in a static initializer block?

From christoph.langer at sap.com  Tue Jan 24 08:23:51 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Jan 2017 08:23:51 +0000
Subject: RFR (JAXP) 8169827:
	javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
In-Reply-To: <038c01d27617$c1771d20$44655760$@oracle.com>
References: <eadaad631dae47278030f243a7afb9c6@derote13de46.global.corp.sap>
	<9e9fb81a-92cf-57ad-5851-a2d8a704811c@oracle.com>
	<42b9f71db0534e7985f761130713295f@derote13de46.global.corp.sap>
	<038c01d27617$c1771d20$44655760$@oracle.com>
Message-ID: <0ced3294426d4c0abb583cdc3e316f54@derote13de46.global.corp.sap>

Hi Frank,

thanks for your comments.

I already thought it might be better to create a new bug for my repair work - as 8169827 actually is about the intermittent failure which will perhaps not be solved with my changes. So I'll create a new item and submit my changes for that one.

Furthermore, I would also support creating Java code to do the copy work instead of using the shell script, though doing this is rather out of scope for me, at the moment. This should be done in a common library, e.g. /test/javax/xml/jaxp/libs/jaxp/library. I also see that the same requirement exists for tests in the jdk repo - unfortunately there is no shared testing library with 'jdk'. So we'll probably end up with some duplicated code :(

By the way: In the jaxp test tree, there exists a lib /test/javax/xml/jaxp/libs/jdk/testlibrary out of which at least some stuff seems to be obsolete for jaxp testing and/or significantly behind jdk's test/lib/testlibrary. I guess here's some room for cleanup/modernization.

As for the idea with the links - it sounds interesting, but it also adds more complexity. And maybe it is not such a good idea for Windows systems...

Best regards
Christoph

> -----Original Message-----
> From: Frank Yuan [mailto:frank.yuan at oracle.com]
> Sent: Dienstag, 24. Januar 2017 08:59
> To: Langer, Christoph <christoph.langer at sap.com>; 'Daniel Fuchs'
> <daniel.fuchs at oracle.com>; core-libs-dev at openjdk.java.net
> Subject: RE: RFR (JAXP) 8169827:
> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> 
> Hi Christoph
> 
> Many thanks for your effort!
> 
> It's really better than the old version! However I have 2 comments although I
> am not a reviewer(as you often stated :))
> 1. we could also write java code to copy/delete JDK.
> 2. 8169827 is to track PropertiesTest failed in copying JDK intermittently. I
> suggest to use another bug for your improvement
> because I am not sure if this patch can improve the issue of 8169827.
> 
> To Christoph and Daniel
> 
> Btw, Christoph's patch inspired me. You know, PropertiesTest copies a JDK in
> order to isolate the file change of the JDK, actually
> there are some other similar tests(to test some other JDK property or config
> files) in JDK repo, they take the same way as well as
> have similar code...
> I have another idea for this test, that is we can only make symbolic link to the
> JDK files/directories except conf directory, create
> a directory named with "conf" under the new jdk directory, and then make
> symbolic link to the files/directories in conf to the real
> jdk/conf except jaxp.properties. This will reduce the most of copying work and
> may reduce the risk of copying work. What's your
> opinion?
> 
> Thanks
> Frank
> 
> > -----Original Message-----
> > From: Langer, Christoph [mailto:christoph.langer at sap.com]
> > To: Daniel Fuchs; Frank Yuan; core-libs-dev at openjdk.java.net
> > Subject: RE: RFR (JAXP) 8169827:
> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> >
> > Hi Daniel,
> >
> > thanks for checking/reviewing. So I'll submit with removing the
> ProblemList.txt entry and I'll also remove the intermittent flag.
> >
> > Sounds fair to check later if problems will still show up. Although I have the
> feeling that the issue of
> > https://bugs.openjdk.java.net/browse/JDK-8147431 might appear again...
> >
> > Best regards
> > Christoph
> >
> > > -----Original Message-----
> > > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> > > Sent: Montag, 23. Januar 2017 17:12
> > > To: Langer, Christoph <christoph.langer at sap.com>; Frank Yuan
> > > <frank.yuan at oracle.com>; core-libs-dev at openjdk.java.net
> > > Subject: Re: RFR (JAXP) 8169827:
> > > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> > >
> > > Hi Christoph,
> > >
> > > Thanks for fixing this test!
> > >
> > > I imported your patch, modified ProblemList.txt to not skip the test,
> > > and sent it through our test system, and I'm happy to report that
> > > the test was run on all available platforms with no failure.
> > >
> > > So I think you should simply remove the line from ProblemList.txt
> > > (no need for a new webrev).
> > > If it fails again on more exotic platform we'll simply add it
> > > back to ProblemList.txt for those platforms where it fails
> > > (I guess it could happen if there's not enough disk space).
> > >
> > > Otherwise I have looked over the changes you proposed and they
> > > do seem OK to me.
> > >
> > > +1
> > >
> > > best regards,
> > >
> > > -- daniel
> > >
> > > On 23/01/17 10:03, Langer, Christoph wrote:
> > > > Hi,
> > > >
> > > > while working on jaxp changes and running jtreg tests I found that test
> > > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh does not work. I then
> saw
> > > that this was already reported with bug 8169827. But, as I had already
> spent
> > > some time to fix this test I'd like to contribute my fix:
> > > >
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169827
> > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169827.0/
> > > >
> > > > I converted the test to Java and removed the shell script
> PropertiesTest.sh.
> > > This resolves the compilation issue.
> > > >
> > > > However, the test needs to copy an isolated jdk as it modifies files in the
> JDK.
> > > So I'm still using the copy script to first copy the jdk and afterwards remove
> the
> > > copy. These are separate 'shell' test steps. And in the actual test I'm running
> a
> > > child process with the isolated JDK.
> > > >
> > > > I also don't know if the test should be kept in the problem list and/or also
> be
> > > tagged as 'intermittent' as the whole jdk copying procedure by means of a
> shell
> > > script seems error prone. In case we keep the entry in the problem list, I
> can
> > > also open a separate bug for my change.
> > > >
> > > > @Frank: I don't know if you have some larger change in mind which
> improves
> > > the isolated jdk type testing greatly, otherwise I think this fix could at least
> > > make things better than they are at the moment.
> > > >
> > > > Thanks & Best regards
> > > > Christoph
> > > >
> 


From forax at univ-mlv.fr  Tue Jan 24 08:39:30 2017
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 24 Jan 2017 09:39:30 +0100 (CET)
Subject: Calling a lambda expression from a new thread before the main
	method is run causes the thread to lock up
In-Reply-To: <CAHLUFO=hgNUos8WtOvO7g0NHn4R72ja_-V0-7AWokTpL5nc4yQ@mail.gmail.com>
References: <CAHLUFO=tCcmi8BLCU_tLxxQrSxGCd43PfsDEaTjvPDnsnfnwtg@mail.gmail.com>
	<431dbd47-19fe-45ef-4f7c-42e5e5c9ca15@oracle.com>
	<CAHLUFOm8rRo_KqmzFmNHjeEpiXrz43pHUyQL4UC6ML_bm6NyAQ@mail.gmail.com>
	<1339677733.497617.1485244959135.JavaMail.zimbra@u-pem.fr>
	<CAHLUFO=hgNUos8WtOvO7g0NHn4R72ja_-V0-7AWokTpL5nc4yQ@mail.gmail.com>
Message-ID: <1627232710.522106.1485247170236.JavaMail.zimbra@u-pem.fr>

> De: "Luke Hutchison" <luke.hutch at gmail.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "David Holmes" <david.holmes at oracle.com>, core-libs-dev at openjdk.java.net
> Envoy?: Mardi 24 Janvier 2017 09:13:17
> Objet: Re: Calling a lambda expression from a new thread before the main method
> is run causes the thread to lock up

> On Tue, Jan 24, 2017 at 12:02 AM, Remi Forax < forax at univ-mlv.fr > wrote:

>> a worker thread of the executor will try to execute the code of the static
>> method but because the static initializer is not finished, the worker thread
>> has to wait
> But what is the worker thread waiting for in the case of the lambda that it is
> not waiting for in the case of the AIC? I assume this is due to the lexical
> scoping of the lambda?

it's not directly related to the lexical scoping of a lambda, it's related to the fact that the body of a lambda is not inside the class created when you transform a lambda to a class that implements the functional interface but the body of a lambda is part of the class that declares the lambda. 

>> As a rule of thumb, never starts a thread in a static block, you will get this
>> classical deadlock AND your code is hard to test because static blocks tend to
>> be executed in a random order (i.e. class loading is lazy so execution of
>> static blocks are lazy too).

> This is the problem: I am a library author, and a user of my library ran into
> this problem. The user did not necessarily know that I was launching new
> threads in my library, and as a library author, I did not know I needed to
> advise users that they should not call my library from static blocks. It seems
> to be quite a big problem that a static block is not a standard execution
> context and can lead to deadlocks.

Users should always know when they starts a thread, otherwise they may send you objects that are not thread safe, multi-threading is not something you can hide to your users. 
Concurrency is already hard, hidden concurrency is harder :) 

static blocks are executed with a kind of class lock to prevent several threads to initialize the same class, so like any synchronized-like block, they should be as small as possible. 

> Is there any way I can detect this in my code? I guess I could just get a
> stacktrace, and look for "<init>" or similar somewhere in the stacktrace, then
> throw an exception if called in this context? Is this a reliable enough test
> for being run in a static initializer block?

The real name of a static block is <clinit>, not <init> which is used for constructor. 
If your API clearly states that you will start a thread, the burden to fix deadlocks is transferred to your users :) 
The extreme of that is that some people use the javadoc to cover their own ass, "yes, i know this behavior is stupid but look, it's written in the javadoc". 

Here is your code slightly modified, with no lambda, that deadlock too: 

import java.util.concurrent.Callable; 
import java.util.concurrent.ExecutionException; 
import java.util.concurrent.ExecutorService; 
import java.util.concurrent.Executors; 

public class NoLambdaBug { 
static { 
startUp(); 
} 

static void iamstatic() { 
System.out.println("Inner class method executed"); 
} 

private static void startUp() { 
System.out.println("Entering startUp()"); 
ExecutorService es = Executors.newSingleThreadExecutor(); 
try { 
Callable<Void> callable = new Callable<Void>() { 
@Override 
public Void call() throws Exception { 
iamstatic(); 
return null; 
} 
}; 
es.submit(callable).get(); 
} catch (InterruptedException | ExecutionException e) { 
throw new RuntimeException(e); 
} finally { 
es.shutdown(); 
} 
System.out.println("Exiting startUp()"); 
} 

public static void main(String[] args) { 
System.out.println("Exiting main"); 
} 
} 

R?mi 

From frank.yuan at oracle.com  Tue Jan 24 08:44:54 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 24 Jan 2017 16:44:54 +0800
Subject: RFR (JAXP) 8169827:
	javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
In-Reply-To: <0ced3294426d4c0abb583cdc3e316f54@derote13de46.global.corp.sap>
References: <eadaad631dae47278030f243a7afb9c6@derote13de46.global.corp.sap>
	<9e9fb81a-92cf-57ad-5851-a2d8a704811c@oracle.com>
	<42b9f71db0534e7985f761130713295f@derote13de46.global.corp.sap>
	<038c01d27617$c1771d20$44655760$@oracle.com>
	<0ced3294426d4c0abb583cdc3e316f54@derote13de46.global.corp.sap>
Message-ID: <03dc01d2761e$27b2c750$771855f0$@oracle.com>

> From: Langer, Christoph [mailto:christoph.langer at sap.com]
> To: Frank Yuan
> Cc: 'Daniel Fuchs'; core-libs-dev at openjdk.java.net
> Subject: RE: RFR (JAXP) 8169827: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> 
> Hi Frank,
> 
> thanks for your comments.
> 
> I already thought it might be better to create a new bug for my repair work - as 8169827 actually is about the intermittent
failure which will
> perhaps not be solved with my changes. So I'll create a new item and submit my changes for that one.
> 
> Furthermore, I would also support creating Java code to do the copy work instead of using the shell script, though doing this is
rather out of
> scope for me, at the moment. 

Just a suggestion, please feel free to leave it:)

>This should be done in a common library, e.g. /test/javax/xml/jaxp/libs/jaxp/library. I also see that the same
> requirement exists for tests in the jdk repo - unfortunately there is no shared testing library with 'jdk'. So we'll probably end
up with some
> duplicated code :(
> 
> By the way: In the jaxp test tree, there exists a lib /test/javax/xml/jaxp/libs/jdk/testlibrary out of which at least some stuff
seems to be
> obsolete for jaxp testing and/or significantly behind jdk's test/lib/testlibrary. I guess here's some room for
cleanup/modernization.
> 

Yes, testlibrary is a copy from jdk repo, there are a few JAXP tests using the library, so we didn't keep it synced with JDK. In my
mind, we don't need spend too much effort on it unless it impacts JAXP tests.

> As for the idea with the links - it sounds interesting, but it also adds more complexity. And maybe it is not such a good idea for
Windows
> systems...

I didn't test it in Windows, please leave it to me. I will update to you and Joe when I have the result. Thanks

Frank

> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: Frank Yuan [mailto:frank.yuan at oracle.com]
> > Sent: Dienstag, 24. Januar 2017 08:59
> > To: Langer, Christoph <christoph.langer at sap.com>; 'Daniel Fuchs'
> > <daniel.fuchs at oracle.com>; core-libs-dev at openjdk.java.net
> > Subject: RE: RFR (JAXP) 8169827:
> > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> >
> > Hi Christoph
> >
> > Many thanks for your effort!
> >
> > It's really better than the old version! However I have 2 comments although I
> > am not a reviewer(as you often stated :))
> > 1. we could also write java code to copy/delete JDK.
> > 2. 8169827 is to track PropertiesTest failed in copying JDK intermittently. I
> > suggest to use another bug for your improvement
> > because I am not sure if this patch can improve the issue of 8169827.
> >
> > To Christoph and Daniel
> >
> > Btw, Christoph's patch inspired me. You know, PropertiesTest copies a JDK in
> > order to isolate the file change of the JDK, actually
> > there are some other similar tests(to test some other JDK property or config
> > files) in JDK repo, they take the same way as well as
> > have similar code...
> > I have another idea for this test, that is we can only make symbolic link to the
> > JDK files/directories except conf directory, create
> > a directory named with "conf" under the new jdk directory, and then make
> > symbolic link to the files/directories in conf to the real
> > jdk/conf except jaxp.properties. This will reduce the most of copying work and
> > may reduce the risk of copying work. What's your
> > opinion?
> >
> > Thanks
> > Frank
> >
> > > -----Original Message-----
> > > From: Langer, Christoph [mailto:christoph.langer at sap.com]
> > > To: Daniel Fuchs; Frank Yuan; core-libs-dev at openjdk.java.net
> > > Subject: RE: RFR (JAXP) 8169827:
> > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> > >
> > > Hi Daniel,
> > >
> > > thanks for checking/reviewing. So I'll submit with removing the
> > ProblemList.txt entry and I'll also remove the intermittent flag.
> > >
> > > Sounds fair to check later if problems will still show up. Although I have the
> > feeling that the issue of
> > > https://bugs.openjdk.java.net/browse/JDK-8147431 might appear again...
> > >
> > > Best regards
> > > Christoph
> > >
> > > > -----Original Message-----
> > > > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> > > > Sent: Montag, 23. Januar 2017 17:12
> > > > To: Langer, Christoph <christoph.langer at sap.com>; Frank Yuan
> > > > <frank.yuan at oracle.com>; core-libs-dev at openjdk.java.net
> > > > Subject: Re: RFR (JAXP) 8169827:
> > > > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> > > >
> > > > Hi Christoph,
> > > >
> > > > Thanks for fixing this test!
> > > >
> > > > I imported your patch, modified ProblemList.txt to not skip the test,
> > > > and sent it through our test system, and I'm happy to report that
> > > > the test was run on all available platforms with no failure.
> > > >
> > > > So I think you should simply remove the line from ProblemList.txt
> > > > (no need for a new webrev).
> > > > If it fails again on more exotic platform we'll simply add it
> > > > back to ProblemList.txt for those platforms where it fails
> > > > (I guess it could happen if there's not enough disk space).
> > > >
> > > > Otherwise I have looked over the changes you proposed and they
> > > > do seem OK to me.
> > > >
> > > > +1
> > > >
> > > > best regards,
> > > >
> > > > -- daniel
> > > >
> > > > On 23/01/17 10:03, Langer, Christoph wrote:
> > > > > Hi,
> > > > >
> > > > > while working on jaxp changes and running jtreg tests I found that test
> > > > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh does not work. I then
> > saw
> > > > that this was already reported with bug 8169827. But, as I had already
> > spent
> > > > some time to fix this test I'd like to contribute my fix:
> > > > >
> > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169827
> > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169827.0/
> > > > >
> > > > > I converted the test to Java and removed the shell script
> > PropertiesTest.sh.
> > > > This resolves the compilation issue.
> > > > >
> > > > > However, the test needs to copy an isolated jdk as it modifies files in the
> > JDK.
> > > > So I'm still using the copy script to first copy the jdk and afterwards remove
> > the
> > > > copy. These are separate 'shell' test steps. And in the actual test I'm running
> > a
> > > > child process with the isolated JDK.
> > > > >
> > > > > I also don't know if the test should be kept in the problem list and/or also
> > be
> > > > tagged as 'intermittent' as the whole jdk copying procedure by means of a
> > shell
> > > > script seems error prone. In case we keep the entry in the problem list, I
> > can
> > > > also open a separate bug for my change.
> > > > >
> > > > > @Frank: I don't know if you have some larger change in mind which
> > improves
> > > > the isolated jdk type testing greatly, otherwise I think this fix could at least
> > > > make things better than they are at the moment.
> > > > >
> > > > > Thanks & Best regards
> > > > > Christoph
> > > > >
> >



From huaming.li at oracle.com  Tue Jan 24 08:51:58 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Tue, 24 Jan 2017 16:51:58 +0800
Subject: RFR of JDK-8171142: jdk_rmi registry test fail to clean up on
	failure
In-Reply-To: <3356cacb-627e-89e7-f834-88d5f09fb361@Oracle.com>
References: <64b48f04-92b0-d31e-2e27-3a0ab2e58629@oracle.com>
	<3356cacb-627e-89e7-f834-88d5f09fb361@Oracle.com>
Message-ID: <dda7f0c6-7843-f3c2-5439-cedbfdf21669@oracle.com>

Hi Roger, David,

Thank you for reviewing, modified as you suggested, and the code is pushed.

-Hamlin


On 2017/1/23 23:21, Roger Riggs wrote:
> Hi Hamlin,
>
> test/javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java:
>
>   line 130: trivial, but please add a space in "!=null"...
>
> Note: on Windows there is no difference between Process.destroy vs 
> Process.destroyForcibly,
> but on Linux it it is the difference between kill -15 and kill -9.
>
> Using destroyForcibly would be more certain as to the death of the 
> subprocess.
>
> Otherwise looks fine
>
> Thanks, Roger
>
>
> On 1/23/2017 1:38 AM, Hamlin Li wrote:
>> Would you please review the below patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8171142
>>
>> webrev: http://cr.openjdk.java.net/~mli/8171142/webrev.00/
>>
>>
>> Thank you
>>
>> -Hamlin
>>
>>
>


From david.holmes at oracle.com  Tue Jan 24 09:24:25 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Jan 2017 19:24:25 +1000
Subject: Calling a lambda expression from a new thread before the main
	method is run causes the thread to lock up
In-Reply-To: <CAHLUFOm8rRo_KqmzFmNHjeEpiXrz43pHUyQL4UC6ML_bm6NyAQ@mail.gmail.com>
References: <CAHLUFO=tCcmi8BLCU_tLxxQrSxGCd43PfsDEaTjvPDnsnfnwtg@mail.gmail.com>
	<431dbd47-19fe-45ef-4f7c-42e5e5c9ca15@oracle.com>
	<CAHLUFOm8rRo_KqmzFmNHjeEpiXrz43pHUyQL4UC6ML_bm6NyAQ@mail.gmail.com>
Message-ID: <e79751a6-b66c-54cc-0af5-1f9c194be999@oracle.com>

On 24/01/2017 5:21 PM, Luke Hutchison wrote:
> On Mon, Jan 23, 2017 at 10:48 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     On 24/01/2017 2:41 PM, Luke Hutchison wrote:
>
>         If you run the code below, the active JVM thread (in the
>         ExecutorService)
>         locks up when the lambda expression is called. The Eclipse
>         debugger is not
>         able to stop the locked-up thread, or get a stacktrace beyond
>         the call into
>         the lambda.
>
>
>     That looks like a variation of the classic class initialization
>     deadlock problem. Your main thread is blocked in
>     es.submit(callable).get(); while still within the static initializer
>     of the LambdaBug class. If the executor thread also needs to ensure
>     LambdaBug is initialized (which it will in the lambda case) then it
>     will wait for the main thread to complete the initialization. Hence
>     deadlock.
>
>
> Thanks for the explanation -- although I don't understand why a lambda
> expression requires its defining class to be initialized, whereas an
> anonymous inner class does not. The lambda body does not refer to the
> LambdaBug class. This must be due to an implicit reference to the
> defining class being added by the compiler for purposes of capturing the
> lexical scope (with this issue not getting triggered in the case of
> anonymous inner classes due to scoping differences)? However, why is the
> containing class reference even used in this case, when variables in the
> containing scope are not referenced?

I'd have to look at the exact code being generated for the lambda, but 
the enclosing class plays as special role with lambdas and so needs to 
be initialized before it can be used. There may be some scope for 
adjusting this.

> If this is due to lexical scoping, shouldn't the compiler be able to add
> some runtime code to detect cases of this kind of deadlock, and throw a
> RuntimeException, or potentially even detect some of these cases statically?

Deadlock detection is out of scope for javac.

> Why is it possible to directly call lambdas inside a static initializer
> block without causing a deadlock (in other words, why is there no
> deadlock as long as the lambdas are not executed on a different thread
> while the main thread blocks)? The calling class is still not completely
> initialized when calling lambdas directly in a static initializer block
> on the main thread.

You need two threads for a deadlock. If the lambda code is called on the 
main thread and accesses the LambdaBug class it will see it as a 
recursive initialization attempt and simply return.

David

From david.holmes at oracle.com  Tue Jan 24 09:39:15 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Jan 2017 19:39:15 +1000
Subject: Calling a lambda expression from a new thread before the main
	method is run causes the thread to lock up
In-Reply-To: <1627232710.522106.1485247170236.JavaMail.zimbra@u-pem.fr>
References: <CAHLUFO=tCcmi8BLCU_tLxxQrSxGCd43PfsDEaTjvPDnsnfnwtg@mail.gmail.com>
	<431dbd47-19fe-45ef-4f7c-42e5e5c9ca15@oracle.com>
	<CAHLUFOm8rRo_KqmzFmNHjeEpiXrz43pHUyQL4UC6ML_bm6NyAQ@mail.gmail.com>
	<1339677733.497617.1485244959135.JavaMail.zimbra@u-pem.fr>
	<CAHLUFO=hgNUos8WtOvO7g0NHn4R72ja_-V0-7AWokTpL5nc4yQ@mail.gmail.com>
	<1627232710.522106.1485247170236.JavaMail.zimbra@u-pem.fr>
Message-ID: <96036048-37e9-1c63-1b8c-20d417c7455d@oracle.com>

I have to second Remi's view here - hidden concurrency is an accident 
waiting to happen, far too many things can go wrong if the users of your 
API don't know that new threads can be involved.

It's not wrong, per-se, to start threads from a static initializer - 
just wrong to do something that has to wait, in the static initializer, 
for that other thread to do something, which in turn depends on being 
able to access the class being initialized.

In this case, as Remi explained (thanks!), the desugared lambda-code 
becomes a static method on the enclosing class, and executing a static 
method requires that the class is initialized.

David

On 24/01/2017 6:39 PM, forax at univ-mlv.fr wrote:
>
>
> ------------------------------------------------------------------------
>
>     *De: *"Luke Hutchison" <luke.hutch at gmail.com>
>     *?: *"Remi Forax" <forax at univ-mlv.fr>
>     *Cc: *"David Holmes" <david.holmes at oracle.com>,
>     core-libs-dev at openjdk.java.net
>     *Envoy?: *Mardi 24 Janvier 2017 09:13:17
>     *Objet: *Re: Calling a lambda expression from a new thread before
>     the main method is run causes the thread to lock up
>
>     On Tue, Jan 24, 2017 at 12:02 AM, Remi Forax <forax at univ-mlv.fr
>     <mailto:forax at univ-mlv.fr>> wrote:
>
>         a worker thread of the executor will try to execute the code of
>         the static method but because the static initializer is not
>         finished, the worker thread has to wait
>
>
>     But what is the worker thread waiting for in the case of the lambda
>     that it is not waiting for in the case of the AIC? I assume this is
>     due to the lexical scoping of the lambda?
>
>
> it's not directly related to the lexical scoping of a lambda, it's
> related to the fact that the body of a lambda is not inside the class
> created when you transform a lambda to a class that implements the
> functional interface but the body of a lambda is part of the class that
> declares the lambda.
>
>
>         As a rule of thumb, never starts a thread in a static block, you
>         will get this classical deadlock AND your code is hard to test
>         because static blocks tend to  be executed in a random order
>         (i.e. class loading is lazy so execution of static blocks are
>         lazy too).
>
>
>     This is the problem: I am a library author, and a user of my library
>     ran into this problem. The user did not necessarily know that I was
>     launching new threads in my library, and as a library author, I did
>     not know I needed to advise users that they should not call my
>     library from static blocks. It seems to be quite a big problem that
>     a static block is not a standard execution context and can lead to
>     deadlocks.
>
>
> Users should always know when they starts a thread, otherwise they may
> send you objects that are not thread safe, multi-threading is not
> something you can hide to your users.
> Concurrency is already hard, hidden concurrency is harder :)
>
> static blocks are executed with a kind of class lock to prevent several
> threads to initialize the same class, so like any synchronized-like
> block, they should be as small as possible.
>
>
>     Is there any way I can detect this in my code? I guess I could just
>     get a stacktrace, and look for "<init>" or similar somewhere in the
>     stacktrace, then throw an exception if called in this context? Is
>     this a reliable enough test for being run in a static initializer block?
>
>
> The real name of a static block is <clinit>, not <init> which is used
> for constructor.
> If your API clearly states that you will start a thread, the burden to
> fix deadlocks is transferred to your users :)
> The extreme of that is that some people use the javadoc to cover their
> own ass, "yes, i know this behavior is stupid but look, it's written in
> the javadoc".
>
>
> Here is your code slightly modified, with no lambda, that deadlock too:
>
> import java.util.concurrent.Callable;
> import java.util.concurrent.ExecutionException;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
>
> public class NoLambdaBug {
>   static {
>     startUp();
>   }
>
>   static void iamstatic() {
>     System.out.println("Inner class method executed");
>   }
>
>   private static void startUp() {
>     System.out.println("Entering startUp()");
>     ExecutorService es = Executors.newSingleThreadExecutor();
>     try {
>       Callable<Void> callable = new Callable<Void>() {
>         @Override
>         public Void call() throws Exception {
>           iamstatic();
>           return null;
>         }
>       };
>       es.submit(callable).get();
>     } catch (InterruptedException | ExecutionException e) {
>       throw new RuntimeException(e);
>     } finally {
>       es.shutdown();
>     }
>     System.out.println("Exiting startUp()");
>   }
>
>   public static void main(String[] args) {
>     System.out.println("Exiting main");
>   }
> }
>
> R?mi
>

From luke.hutch at gmail.com  Tue Jan 24 09:56:47 2017
From: luke.hutch at gmail.com (Luke Hutchison)
Date: Tue, 24 Jan 2017 01:56:47 -0800
Subject: Calling a lambda expression from a new thread before the main
	method is run causes the thread to lock up
In-Reply-To: <1627232710.522106.1485247170236.JavaMail.zimbra@u-pem.fr>
References: <CAHLUFO=tCcmi8BLCU_tLxxQrSxGCd43PfsDEaTjvPDnsnfnwtg@mail.gmail.com>
	<431dbd47-19fe-45ef-4f7c-42e5e5c9ca15@oracle.com>
	<CAHLUFOm8rRo_KqmzFmNHjeEpiXrz43pHUyQL4UC6ML_bm6NyAQ@mail.gmail.com>
	<1339677733.497617.1485244959135.JavaMail.zimbra@u-pem.fr>
	<CAHLUFO=hgNUos8WtOvO7g0NHn4R72ja_-V0-7AWokTpL5nc4yQ@mail.gmail.com>
	<1627232710.522106.1485247170236.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAHLUFOkXREaKR8neKEam7Kfa4GQqGejZWA-Ard6-EivAkssUAQ@mail.gmail.com>

Thank you Remi and David for your detailed explanations, this was very
helpful, and I understand the issues now. Please go ahead and close the
Jira bug I created for this (JDK-8173252), I see this is WAI.

On Tue, Jan 24, 2017 at 12:39 AM, <forax at univ-mlv.fr> wrote:

> Here is your code slightly modified, with no lambda, that deadlock too:


Thanks, I discovered that I hit a deadlock with anonymous inner classes
when I access fields in the enclosing class too.

On Tue, Jan 24, 2017 at 1:39 AM, David Holmes <david.holmes at oracle.com>
 wrote:

> I have to second Remi's view here - hidden concurrency is an accident
> waiting to happen, far too many things can go wrong if the users of your
> API don't know that new threads can be involved.


FastClasspathScanner only uses concurrency for its own internal processing.
The standard API that most users call is synchronous, and blocks on
response. The user-provided lambdas in question are run single-threaded on
a separate thread, but it does not execute concurrently with the main
thread (which is blocked), precisely to prevent surprises. If the user
calls the async API, they should understand about concurrency. I agree that
in general the burden falls to the user to read the docs and understand the
threading considerations of a given library.

In the end I decided to throw an exception if there is a "<clinit>" line in
the stacktrace. This is better than the possibility of hitting a deadlock.
The following makes me think though that I should refactor my code to
ensure that, for the synchronous API, user-supplied methods are always
executed on the calling thread:

If the lambda code is called on the main thread and accesses the LambdaBug
> class it will see it as a recursive initialization attempt and simply
> return.

From christoph.langer at sap.com  Tue Jan 24 10:29:38 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Jan 2017 10:29:38 +0000
Subject: RFR (JAXP) 8169827:
	javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
In-Reply-To: <03dc01d2761e$27b2c750$771855f0$@oracle.com>
References: <eadaad631dae47278030f243a7afb9c6@derote13de46.global.corp.sap>
	<9e9fb81a-92cf-57ad-5851-a2d8a704811c@oracle.com>
	<42b9f71db0534e7985f761130713295f@derote13de46.global.corp.sap>
	<038c01d27617$c1771d20$44655760$@oracle.com>
	<0ced3294426d4c0abb583cdc3e316f54@derote13de46.global.corp.sap>
	<03dc01d2761e$27b2c750$771855f0$@oracle.com>
Message-ID: <b7c193ef38e44c16867bf1423790d562@derote13de46.global.corp.sap>

Hi,

I submitted my fix under Bug https://bugs.openjdk.java.net/browse/JDK-8173261: http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/620d0c38581f

I also added a comment to https://bugs.openjdk.java.net/browse/JDK-8169827

Best regards
Christoph


> -----Original Message-----
> From: Frank Yuan [mailto:frank.yuan at oracle.com]
> Sent: Dienstag, 24. Januar 2017 09:45
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: 'Daniel Fuchs' <daniel.fuchs at oracle.com>; core-libs-dev at openjdk.java.net
> Subject: RE: RFR (JAXP) 8169827:
> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> 
> > From: Langer, Christoph [mailto:christoph.langer at sap.com]
> > To: Frank Yuan
> > Cc: 'Daniel Fuchs'; core-libs-dev at openjdk.java.net
> > Subject: RE: RFR (JAXP) 8169827:
> javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> >
> > Hi Frank,
> >
> > thanks for your comments.
> >
> > I already thought it might be better to create a new bug for my repair work -
> as 8169827 actually is about the intermittent
> failure which will
> > perhaps not be solved with my changes. So I'll create a new item and submit
> my changes for that one.
> >
> > Furthermore, I would also support creating Java code to do the copy work
> instead of using the shell script, though doing this is
> rather out of
> > scope for me, at the moment.
> 
> Just a suggestion, please feel free to leave it:)
> 
> >This should be done in a common library, e.g.
> /test/javax/xml/jaxp/libs/jaxp/library. I also see that the same
> > requirement exists for tests in the jdk repo - unfortunately there is no shared
> testing library with 'jdk'. So we'll probably end
> up with some
> > duplicated code :(
> >
> > By the way: In the jaxp test tree, there exists a lib
> /test/javax/xml/jaxp/libs/jdk/testlibrary out of which at least some stuff
> seems to be
> > obsolete for jaxp testing and/or significantly behind jdk's test/lib/testlibrary. I
> guess here's some room for
> cleanup/modernization.
> >
> 
> Yes, testlibrary is a copy from jdk repo, there are a few JAXP tests using the
> library, so we didn't keep it synced with JDK. In my
> mind, we don't need spend too much effort on it unless it impacts JAXP tests.
> 
> > As for the idea with the links - it sounds interesting, but it also adds more
> complexity. And maybe it is not such a good idea for
> Windows
> > systems...
> 
> I didn't test it in Windows, please leave it to me. I will update to you and Joe
> when I have the result. Thanks
> 
> Frank
> 
> >
> > Best regards
> > Christoph
> >
> > > -----Original Message-----
> > > From: Frank Yuan [mailto:frank.yuan at oracle.com]
> > > Sent: Dienstag, 24. Januar 2017 08:59
> > > To: Langer, Christoph <christoph.langer at sap.com>; 'Daniel Fuchs'
> > > <daniel.fuchs at oracle.com>; core-libs-dev at openjdk.java.net
> > > Subject: RE: RFR (JAXP) 8169827:
> > > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> > >
> > > Hi Christoph
> > >
> > > Many thanks for your effort!
> > >
> > > It's really better than the old version! However I have 2 comments although
> I
> > > am not a reviewer(as you often stated :))
> > > 1. we could also write java code to copy/delete JDK.
> > > 2. 8169827 is to track PropertiesTest failed in copying JDK intermittently. I
> > > suggest to use another bug for your improvement
> > > because I am not sure if this patch can improve the issue of 8169827.
> > >
> > > To Christoph and Daniel
> > >
> > > Btw, Christoph's patch inspired me. You know, PropertiesTest copies a JDK
> in
> > > order to isolate the file change of the JDK, actually
> > > there are some other similar tests(to test some other JDK property or config
> > > files) in JDK repo, they take the same way as well as
> > > have similar code...
> > > I have another idea for this test, that is we can only make symbolic link to
> the
> > > JDK files/directories except conf directory, create
> > > a directory named with "conf" under the new jdk directory, and then make
> > > symbolic link to the files/directories in conf to the real
> > > jdk/conf except jaxp.properties. This will reduce the most of copying work
> and
> > > may reduce the risk of copying work. What's your
> > > opinion?
> > >
> > > Thanks
> > > Frank
> > >
> > > > -----Original Message-----
> > > > From: Langer, Christoph [mailto:christoph.langer at sap.com]
> > > > To: Daniel Fuchs; Frank Yuan; core-libs-dev at openjdk.java.net
> > > > Subject: RE: RFR (JAXP) 8169827:
> > > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> > > >
> > > > Hi Daniel,
> > > >
> > > > thanks for checking/reviewing. So I'll submit with removing the
> > > ProblemList.txt entry and I'll also remove the intermittent flag.
> > > >
> > > > Sounds fair to check later if problems will still show up. Although I have
> the
> > > feeling that the issue of
> > > > https://bugs.openjdk.java.net/browse/JDK-8147431 might appear again...
> > > >
> > > > Best regards
> > > > Christoph
> > > >
> > > > > -----Original Message-----
> > > > > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> > > > > Sent: Montag, 23. Januar 2017 17:12
> > > > > To: Langer, Christoph <christoph.langer at sap.com>; Frank Yuan
> > > > > <frank.yuan at oracle.com>; core-libs-dev at openjdk.java.net
> > > > > Subject: Re: RFR (JAXP) 8169827:
> > > > > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> > > > >
> > > > > Hi Christoph,
> > > > >
> > > > > Thanks for fixing this test!
> > > > >
> > > > > I imported your patch, modified ProblemList.txt to not skip the test,
> > > > > and sent it through our test system, and I'm happy to report that
> > > > > the test was run on all available platforms with no failure.
> > > > >
> > > > > So I think you should simply remove the line from ProblemList.txt
> > > > > (no need for a new webrev).
> > > > > If it fails again on more exotic platform we'll simply add it
> > > > > back to ProblemList.txt for those platforms where it fails
> > > > > (I guess it could happen if there's not enough disk space).
> > > > >
> > > > > Otherwise I have looked over the changes you proposed and they
> > > > > do seem OK to me.
> > > > >
> > > > > +1
> > > > >
> > > > > best regards,
> > > > >
> > > > > -- daniel
> > > > >
> > > > > On 23/01/17 10:03, Langer, Christoph wrote:
> > > > > > Hi,
> > > > > >
> > > > > > while working on jaxp changes and running jtreg tests I found that test
> > > > > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh does not work. I
> then
> > > saw
> > > > > that this was already reported with bug 8169827. But, as I had already
> > > spent
> > > > > some time to fix this test I'd like to contribute my fix:
> > > > > >
> > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169827
> > > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169827.0/
> > > > > >
> > > > > > I converted the test to Java and removed the shell script
> > > PropertiesTest.sh.
> > > > > This resolves the compilation issue.
> > > > > >
> > > > > > However, the test needs to copy an isolated jdk as it modifies files in
> the
> > > JDK.
> > > > > So I'm still using the copy script to first copy the jdk and afterwards
> remove
> > > the
> > > > > copy. These are separate 'shell' test steps. And in the actual test I'm
> running
> > > a
> > > > > child process with the isolated JDK.
> > > > > >
> > > > > > I also don't know if the test should be kept in the problem list and/or
> also
> > > be
> > > > > tagged as 'intermittent' as the whole jdk copying procedure by means of
> a
> > > shell
> > > > > script seems error prone. In case we keep the entry in the problem list, I
> > > can
> > > > > also open a separate bug for my change.
> > > > > >
> > > > > > @Frank: I don't know if you have some larger change in mind which
> > > improves
> > > > > the isolated jdk type testing greatly, otherwise I think this fix could at
> least
> > > > > make things better than they are at the moment.
> > > > > >
> > > > > > Thanks & Best regards
> > > > > > Christoph
> > > > > >
> > >
> 


From daniel.fuchs at oracle.com  Tue Jan 24 12:10:02 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 24 Jan 2017 12:10:02 +0000
Subject: (JAXP) RFR: 8173111: Excessive recursion in EventFilterSupport
	when filtering over large number of XML events can cause StackOverflow
In-Reply-To: <cf473666-1a3b-9c49-4ef2-a1f6714a4430@oracle.com>
References: <cf473666-1a3b-9c49-4ef2-a1f6714a4430@oracle.com>
Message-ID: <d9443b1f-0b9d-477e-dd16-03fe71bd7c78@oracle.com>

Hi,

Thanks for all the feedback.

I have updated the webrev
http://cr.openjdk.java.net/~dfuchs/webrev_8173111/webrev.01

The test now uses assertEquals as suggested by Lance and Aleksej
(thanks for the suggestion).
I also fixed the missing white space in the code that Christoph
spotted at line 67.
I kept the main method (useful when you tweak the test in
NetBeans).

I'm going to launch it again through our test system and if
successful I'll consider it reviewed and push it, unless I
hear otherwise by then :-)

best regards,

-- daniel



On 23/01/17 17:48, Daniel Fuchs wrote:
> Hi,
>
> Please find below a fix for:
>
> 8173111: Excessive recursion in EventFilterSupport when filtering
>          over large number of XML events can cause StackOverflow
> https://bugs.openjdk.java.net/browse/JDK-8173111
>
> The fix is almost trivial: it replaces a recursion by a loop in
> two places.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8173111/webrev.00/
>
> The test will fail without the fix (at least on my machine)
> and pass with it (on my machine and in our test system).
>
> best regards,
>
> -- daniel


From claes.redestad at oracle.com  Tue Jan 24 14:34:28 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 24 Jan 2017 15:34:28 +0100
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
	reflection
In-Reply-To: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>
References: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>
Message-ID: <1d8c06cf-ddba-ff49-bd61-2edd496efb48@oracle.com>

Hi Peter,

thanks for the thorough examination of this issue. After going through
the patch I do like what I see, but I have a few comments:

AnnotationInvocationHandler:
in invoke, cleaning up and replacing the explicit AssertionError should
be fine, but perhaps convert it to an assert that the number of
arguments is 1 when methodName is "equals" and 0 otherwise?

Adding @Stable is fine if that has a performance impact, but I think
we might preserve clarity of intent if you kept the fields as final and
kept using Unsafe to deserialize properly.

AnnotationSupport:
I dislike that this code was already catching Throwable, and that
you're now copying that approach.  Could the new the catch clause mimic
the one that previously wrapped the entire method?

AnnotationType:
accessibleMembers might not need to be volatile.

validateAnnotationMethod:
the block: label and break block seems unnecessary. I'd not worry
about optimizing for such invalid cases and simply run through all the
checks and set valid = false multiple times if so be it.

Thanks!

/Claes

On 2017-01-17 15:10, Peter Levart wrote:
> Hi,
>
> This is a preview of a patch that addresses the following issue:
>
>     https://bugs.openjdk.java.net/browse/JDK-8029019
>
> But it is also an attempt to clean-up failure reporting for invalid
> annotation types. Here's the 1st webrev:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/webrev.01/
>
>
> With this patch applied, running the following benchmark:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/AnnotationsBench.java
>
>
> Produces the following results:
>
> Original:
>
> Benchmark                                 Mode  Cnt Score     Error  Units
> AnnotationsBench.a1_PrimitiveMember       avgt   10 20.790 ?   1.317  ns/op
> AnnotationsBench.a2_ObjectMember          avgt   10 21.550 ?   0.580  ns/op
> AnnotationsBench.a3_PrimitiveArrayMember  avgt   10 28.314 ?   1.477  ns/op
> AnnotationsBench.a4_ObjectArrayMember     avgt   10 27.094 ?   0.574  ns/op
> AnnotationsBench.a5_AnnotationType        avgt   10 13.047 ?   0.983  ns/op
> AnnotationsBench.a6_HashCode              avgt   10 158.001 ?   9.347
> ns/op
> AnnotationsBench.a7_Equals                avgt   10 663.921 ?  27.256
> ns/op
> AnnotationsBench.a8_ToString              avgt   10 1772.901 ? 107.355
> ns/op
>
> Patched:
>
> Benchmark                                 Mode  Cnt Score    Error  Units
> AnnotationsBench.a1_PrimitiveMember       avgt   10 8.547 ?  0.100  ns/op
> AnnotationsBench.a2_ObjectMember          avgt   10 8.352 ?  0.340  ns/op
> AnnotationsBench.a3_PrimitiveArrayMember  avgt   10 17.526 ?  0.696  ns/op
> AnnotationsBench.a4_ObjectArrayMember     avgt   10 15.639 ?  0.116  ns/op
> AnnotationsBench.a5_AnnotationType        avgt   10 4.692 ?  0.154  ns/op
> AnnotationsBench.a6_HashCode              avgt   10 142.954 ?  7.460  ns/op
> AnnotationsBench.a7_Equals                avgt   10 184.535 ?  0.917  ns/op
> AnnotationsBench.a8_ToString              avgt   10 1806.685 ? 96.370
> ns/op
>
>
> Allocation rates are also reduced:
>
> Original:
>
> AnnotationsBench.a1_PrimitiveMember:?gc.alloc.rate.norm avgt   10
> 16.000 ?   0.001    B/op
> AnnotationsBench.a2_ObjectMember:?gc.alloc.rate.norm avgt   10    16.000
> ?   0.001    B/op
> AnnotationsBench.a3_PrimitiveArrayMember:?gc.alloc.rate.norm avgt
> 10    64.000 ?   0.001    B/op
> AnnotationsBench.a4_ObjectArrayMember:?gc.alloc.rate.norm avgt   10
> 48.000 ?   0.001    B/op
> AnnotationsBench.a5_AnnotationType:?gc.alloc.rate.norm avgt   10
> 16.000 ?   0.001    B/op
> AnnotationsBench.a6_HashCode:?gc.alloc.rate.norm avgt   10   128.000 ?
> 0.001    B/op
> AnnotationsBench.a7_Equals:?gc.alloc.rate.norm avgt   10   120.001 ?
> 0.001    B/op
> AnnotationsBench.a8_ToString:?gc.alloc.rate.norm avgt   10  5200.002 ?
> 0.001    B/op
>
> Patched:
>
> AnnotationsBench.a1_PrimitiveMember:?gc.alloc.rate.norm avgt   10    ?
> 10??              B/op
> AnnotationsBench.a2_ObjectMember:?gc.alloc.rate.norm avgt   10    ?
> 10??              B/op
> AnnotationsBench.a3_PrimitiveArrayMember:?gc.alloc.rate.norm avgt
> 10    48.000 ?   0.001    B/op
> AnnotationsBench.a4_ObjectArrayMember:?gc.alloc.rate.norm avgt   10
> 32.000 ?   0.001    B/op
> AnnotationsBench.a5_AnnotationType:?gc.alloc.rate.norm avgt   10    ?
> 10??              B/op
> AnnotationsBench.a6_HashCode:?gc.alloc.rate.norm avgt   10    64.000 ?
> 0.001    B/op
> AnnotationsBench.a7_Equals:?gc.alloc.rate.norm avgt   10    24.000 ?
> 0.001    B/op
> AnnotationsBench.a8_ToString:?gc.alloc.rate.norm avgt   10  5136.002 ?
> 0.001    B/op
>
>
> As for the failure reporting: requesting an annotation for invalid
> annotation type now always produces AnnotationFormatError. Previously,
> some invalid annotations were simply skipped, some produced
> AnnotationFormatError and for some of them, AnnotationFormatError was
> raised only when evaluating Annotation's equals() method.
>
> I would like to discuss this failure behavior more in-depth.
>
> Regards, Peter
>

From chris.hegarty at oracle.com  Tue Jan 24 15:07:06 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 24 Jan 2017 15:07:06 +0000
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
	reflection
In-Reply-To: <1d8c06cf-ddba-ff49-bd61-2edd496efb48@oracle.com>
References: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>
	<1d8c06cf-ddba-ff49-bd61-2edd496efb48@oracle.com>
Message-ID: <9462D17E-1827-4B04-ACE2-AE2E1BE4CB78@oracle.com>

Peter, 

> On 2017-01-17 15:10, Peter Levart wrote:
>> Hi,
>> 
>> This is a preview of a patch that addresses the following issue:
>> 
>>    https://bugs.openjdk.java.net/browse/JDK-8029019

This very good work. I have not done a complete review, but what
jumps out at me is that you have removed some of the validation
code and checks from AnnotationInvocationHandler ( in one place
there is an assert and a comment that ?good? data is expected.
AnnotationInvocationHandler has shown up in many interesting
places, I wonder if it is wise to remove these.

-Chris.

>> But it is also an attempt to clean-up failure reporting for invalid
>> annotation types. Here's the 1st webrev:
>> 
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/webrev.01/
>> 
>> 
>> With this patch applied, running the following benchmark:
>> 
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/AnnotationsBench.java
>> 
>> 
>> Produces the following results:
>> 
>> Original:
>> 
>> Benchmark                                 Mode  Cnt Score     Error  Units
>> AnnotationsBench.a1_PrimitiveMember       avgt   10 20.790 ?   1.317  ns/op
>> AnnotationsBench.a2_ObjectMember          avgt   10 21.550 ?   0.580  ns/op
>> AnnotationsBench.a3_PrimitiveArrayMember  avgt   10 28.314 ?   1.477  ns/op
>> AnnotationsBench.a4_ObjectArrayMember     avgt   10 27.094 ?   0.574  ns/op
>> AnnotationsBench.a5_AnnotationType        avgt   10 13.047 ?   0.983  ns/op
>> AnnotationsBench.a6_HashCode              avgt   10 158.001 ?   9.347
>> ns/op
>> AnnotationsBench.a7_Equals                avgt   10 663.921 ?  27.256
>> ns/op
>> AnnotationsBench.a8_ToString              avgt   10 1772.901 ? 107.355
>> ns/op
>> 
>> Patched:
>> 
>> Benchmark                                 Mode  Cnt Score    Error  Units
>> AnnotationsBench.a1_PrimitiveMember       avgt   10 8.547 ?  0.100  ns/op
>> AnnotationsBench.a2_ObjectMember          avgt   10 8.352 ?  0.340  ns/op
>> AnnotationsBench.a3_PrimitiveArrayMember  avgt   10 17.526 ?  0.696  ns/op
>> AnnotationsBench.a4_ObjectArrayMember     avgt   10 15.639 ?  0.116  ns/op
>> AnnotationsBench.a5_AnnotationType        avgt   10 4.692 ?  0.154  ns/op
>> AnnotationsBench.a6_HashCode              avgt   10 142.954 ?  7.460  ns/op
>> AnnotationsBench.a7_Equals                avgt   10 184.535 ?  0.917  ns/op
>> AnnotationsBench.a8_ToString              avgt   10 1806.685 ? 96.370
>> ns/op
>> 
>> 
>> Allocation rates are also reduced:
>> 
>> Original:
>> 
>> AnnotationsBench.a1_PrimitiveMember:?gc.alloc.rate.norm avgt   10
>> 16.000 ?   0.001    B/op
>> AnnotationsBench.a2_ObjectMember:?gc.alloc.rate.norm avgt   10    16.000
>> ?   0.001    B/op
>> AnnotationsBench.a3_PrimitiveArrayMember:?gc.alloc.rate.norm avgt
>> 10    64.000 ?   0.001    B/op
>> AnnotationsBench.a4_ObjectArrayMember:?gc.alloc.rate.norm avgt   10
>> 48.000 ?   0.001    B/op
>> AnnotationsBench.a5_AnnotationType:?gc.alloc.rate.norm avgt   10
>> 16.000 ?   0.001    B/op
>> AnnotationsBench.a6_HashCode:?gc.alloc.rate.norm avgt   10   128.000 ?
>> 0.001    B/op
>> AnnotationsBench.a7_Equals:?gc.alloc.rate.norm avgt   10   120.001 ?
>> 0.001    B/op
>> AnnotationsBench.a8_ToString:?gc.alloc.rate.norm avgt   10  5200.002 ?
>> 0.001    B/op
>> 
>> Patched:
>> 
>> AnnotationsBench.a1_PrimitiveMember:?gc.alloc.rate.norm avgt   10    ?
>> 10??              B/op
>> AnnotationsBench.a2_ObjectMember:?gc.alloc.rate.norm avgt   10    ?
>> 10??              B/op
>> AnnotationsBench.a3_PrimitiveArrayMember:?gc.alloc.rate.norm avgt
>> 10    48.000 ?   0.001    B/op
>> AnnotationsBench.a4_ObjectArrayMember:?gc.alloc.rate.norm avgt   10
>> 32.000 ?   0.001    B/op
>> AnnotationsBench.a5_AnnotationType:?gc.alloc.rate.norm avgt   10    ?
>> 10??              B/op
>> AnnotationsBench.a6_HashCode:?gc.alloc.rate.norm avgt   10    64.000 ?
>> 0.001    B/op
>> AnnotationsBench.a7_Equals:?gc.alloc.rate.norm avgt   10    24.000 ?
>> 0.001    B/op
>> AnnotationsBench.a8_ToString:?gc.alloc.rate.norm avgt   10  5136.002 ?
>> 0.001    B/op
>> 
>> 
>> As for the failure reporting: requesting an annotation for invalid
>> annotation type now always produces AnnotationFormatError. Previously,
>> some invalid annotations were simply skipped, some produced
>> AnnotationFormatError and for some of them, AnnotationFormatError was
>> raised only when evaluating Annotation's equals() method.
>> 
>> I would like to discuss this failure behavior more in-depth.
>> 
>> Regards, Peter
>> 


From henry.jen at oracle.com  Tue Jan 24 18:20:16 2017
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 24 Jan 2017 10:20:16 -0800
Subject: RFR: 8170832: Add a new launcher environment variable JAVA_OPTIONS
Message-ID: <E18D7570-2AE6-47BE-8143-4057376C1348@oracle.com>

Hi,

Please review the webrev[1] that add support for JAVA_OPTIONS environment variable. The bug[2] describes how JAVA_OPTIONS works.

[1] http://cr.openjdk.java.net/~henryjen/jdk9/8170832/4/webrev/
[2] https://bugs.openjdk.java.net/browse/JDK-8170832

Cheers,
Henry


From christoph.dreis at freenet.de  Tue Jan 24 19:33:27 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Tue, 24 Jan 2017 20:33:27 +0100
Subject: Cleanup String.replace() occurences with single characters 
Message-ID: <008501d27678$bcd73820$3685a860$@freenet.de>

Hey,

 

similar to https://bugs.openjdk.java.net/browse/JDK-8044461 I noticed two
(newly introduced) places where we could avoid the regex overhead

when replacing single chars.

 

I'd be happy if this is sponsored.

 

Cheers,

Christoph

 

=========== PATCH ============

# User Christoph Dreis < <mailto:christoph.dreis at freenet.de>
christoph.dreis at freenet.de>

Cleanup String.replace() occurences with single characters

 

diff --git
a/src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java
b/src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java

--- a/src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java

+++ b/src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java

@@ -39,7 +39,7 @@

     public static String getPackageName(String name) {

         int index = name.lastIndexOf('/');

         if (index != -1) {

-            return name.substring(0, index).replace("/", ".");

+            return name.substring(0, index).replace('/', '.');

         } else {

             return "";

         }

diff --git a/src/java.base/share/classes/jdk/internal/module/ModulePath.java
b/src/java.base/share/classes/jdk/internal/module/ModulePath.java

--- a/src/java.base/share/classes/jdk/internal/module/ModulePath.java

+++ b/src/java.base/share/classes/jdk/internal/module/ModulePath.java

@@ -495,7 +495,7 @@

             Attributes attrs = man.getMainAttributes();

             String mainClass = attrs.getValue(Attributes.Name.MAIN_CLASS);

             if (mainClass != null)

-                builder.mainClass(mainClass.replace("/", "."));

+                builder.mainClass(mainClass.replace('/', '.'));

         }

 

         return builder.build();


From mandy.chung at oracle.com  Tue Jan 24 20:41:52 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 24 Jan 2017 12:41:52 -0800
Subject: RFR: 8170832: Add a new launcher environment variable JAVA_OPTIONS
In-Reply-To: <E18D7570-2AE6-47BE-8143-4057376C1348@oracle.com>
References: <E18D7570-2AE6-47BE-8143-4057376C1348@oracle.com>
Message-ID: <CEDCF2D3-5EF5-4F06-8B21-32D40A9C34F4@oracle.com>


> On Jan 24, 2017, at 10:20 AM, Henry Jen <henry.jen at oracle.com> wrote:
> 
> Hi,
> 
> Please review the webrev[1] that add support for JAVA_OPTIONS environment variable. The bug[2] describes how JAVA_OPTIONS works.
> 
> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8170832/4/webrev/

This looks quite good.  A couple of minor comments:

 503         // Must be after expansion so we can caught if main class specified @argfile

typo: s/caught/catch.  It?d be clear to simply say:
 // Check if Main class specified after argument checked.
 // This check must be done after expansion.

  42 #define JAVA_OPTIONS ?JAVA_OPTIONS"

I think java.h is the appropriate file to declare this instead of jli_util.h.

emessages.h
  Would it be clearer to rename ARG_INFO to ARG_INFO_ENVVAR?

thanks
Mandy

From claes.redestad at oracle.com  Tue Jan 24 22:31:58 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 24 Jan 2017 23:31:58 +0100
Subject: Cleanup String.replace() occurences with single characters
In-Reply-To: <008501d27678$bcd73820$3685a860$@freenet.de>
References: <008501d27678$bcd73820$3685a860$@freenet.de>
Message-ID: <aa35f919-52df-83c6-aa5f-1dbecb3ec228@oracle.com>

Hi,

String::replace(CharSequence, CharSequence) does not use a regex, but
String::replace(char, char) can still be slightly more efficient,

As this is relatively new code that wasn't around when 8044461 was done
I'm sure we can get it cleaned up.

Thanks!

/Claes

On 2017-01-24 20:33, Christoph Dreis wrote:
> Hey,
>
>
>
> similar to https://bugs.openjdk.java.net/browse/JDK-8044461 I noticed two
> (newly introduced) places where we could avoid the regex overhead
>
> when replacing single chars.
>
>
>
> I'd be happy if this is sponsored.
>
>
>
> Cheers,
>
> Christoph
>
>
>
> =========== PATCH ============
>
> # User Christoph Dreis < <mailto:christoph.dreis at freenet.de>
> christoph.dreis at freenet.de>
>
> Cleanup String.replace() occurences with single characters
>
>
>
> diff --git
> a/src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java
> b/src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java
>
> --- a/src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java
>
> +++ b/src/java.base/share/classes/jdk/internal/loader/ResourceHelper.java
>
> @@ -39,7 +39,7 @@
>
>      public static String getPackageName(String name) {
>
>          int index = name.lastIndexOf('/');
>
>          if (index != -1) {
>
> -            return name.substring(0, index).replace("/", ".");
>
> +            return name.substring(0, index).replace('/', '.');
>
>          } else {
>
>              return "";
>
>          }
>
> diff --git a/src/java.base/share/classes/jdk/internal/module/ModulePath.java
> b/src/java.base/share/classes/jdk/internal/module/ModulePath.java
>
> --- a/src/java.base/share/classes/jdk/internal/module/ModulePath.java
>
> +++ b/src/java.base/share/classes/jdk/internal/module/ModulePath.java
>
> @@ -495,7 +495,7 @@
>
>              Attributes attrs = man.getMainAttributes();
>
>              String mainClass = attrs.getValue(Attributes.Name.MAIN_CLASS);
>
>              if (mainClass != null)
>
> -                builder.mainClass(mainClass.replace("/", "."));
>
> +                builder.mainClass(mainClass.replace('/', '.'));
>
>          }
>
>
>
>          return builder.build();
>

From frank.yuan at oracle.com  Wed Jan 25 02:11:06 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Wed, 25 Jan 2017 10:11:06 +0800
Subject: RFR (JAXP) 8169827:
	javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
In-Reply-To: <b7c193ef38e44c16867bf1423790d562@derote13de46.global.corp.sap>
References: <eadaad631dae47278030f243a7afb9c6@derote13de46.global.corp.sap>
	<9e9fb81a-92cf-57ad-5851-a2d8a704811c@oracle.com>
	<42b9f71db0534e7985f761130713295f@derote13de46.global.corp.sap>
	<038c01d27617$c1771d20$44655760$@oracle.com>
	<0ced3294426d4c0abb583cdc3e316f54@derote13de46.global.corp.sap>
	<03dc01d2761e$27b2c750$771855f0$@oracle.com>
	<b7c193ef38e44c16867bf1423790d562@derote13de46.global.corp.sap>
Message-ID: <012b01d276b0$4d0af0d0$e720d270$@oracle.com>

Thank you, Christoph

Frank

> -----Original Message-----
> From: Langer, Christoph [mailto:christoph.langer at sap.com]
> Sent: Tuesday, January 24, 2017 6:30 PM
> To: Frank Yuan
> Cc: 'Daniel Fuchs'; core-libs-dev at openjdk.java.net
> Subject: RE: RFR (JAXP) 8169827: javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> 
> Hi,
> 
> I submitted my fix under Bug https://bugs.openjdk.java.net/browse/JDK-8173261:
> http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/620d0c38581f
> 
> I also added a comment to https://bugs.openjdk.java.net/browse/JDK-8169827
> 
> Best regards
> Christoph
> 
> 
> > -----Original Message-----
> > From: Frank Yuan [mailto:frank.yuan at oracle.com]
> > Sent: Dienstag, 24. Januar 2017 09:45
> > To: Langer, Christoph <christoph.langer at sap.com>
> > Cc: 'Daniel Fuchs' <daniel.fuchs at oracle.com>; core-libs-dev at openjdk.java.net
> > Subject: RE: RFR (JAXP) 8169827:
> > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> >
> > > From: Langer, Christoph [mailto:christoph.langer at sap.com]
> > > To: Frank Yuan
> > > Cc: 'Daniel Fuchs'; core-libs-dev at openjdk.java.net
> > > Subject: RE: RFR (JAXP) 8169827:
> > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> > >
> > > Hi Frank,
> > >
> > > thanks for your comments.
> > >
> > > I already thought it might be better to create a new bug for my repair work -
> > as 8169827 actually is about the intermittent
> > failure which will
> > > perhaps not be solved with my changes. So I'll create a new item and submit
> > my changes for that one.
> > >
> > > Furthermore, I would also support creating Java code to do the copy work
> > instead of using the shell script, though doing this is
> > rather out of
> > > scope for me, at the moment.
> >
> > Just a suggestion, please feel free to leave it:)
> >
> > >This should be done in a common library, e.g.
> > /test/javax/xml/jaxp/libs/jaxp/library. I also see that the same
> > > requirement exists for tests in the jdk repo - unfortunately there is no shared
> > testing library with 'jdk'. So we'll probably end
> > up with some
> > > duplicated code :(
> > >
> > > By the way: In the jaxp test tree, there exists a lib
> > /test/javax/xml/jaxp/libs/jdk/testlibrary out of which at least some stuff
> > seems to be
> > > obsolete for jaxp testing and/or significantly behind jdk's test/lib/testlibrary. I
> > guess here's some room for
> > cleanup/modernization.
> > >
> >
> > Yes, testlibrary is a copy from jdk repo, there are a few JAXP tests using the
> > library, so we didn't keep it synced with JDK. In my
> > mind, we don't need spend too much effort on it unless it impacts JAXP tests.
> >
> > > As for the idea with the links - it sounds interesting, but it also adds more
> > complexity. And maybe it is not such a good idea for
> > Windows
> > > systems...
> >
> > I didn't test it in Windows, please leave it to me. I will update to you and Joe
> > when I have the result. Thanks
> >
> > Frank
> >
> > >
> > > Best regards
> > > Christoph
> > >
> > > > -----Original Message-----
> > > > From: Frank Yuan [mailto:frank.yuan at oracle.com]
> > > > Sent: Dienstag, 24. Januar 2017 08:59
> > > > To: Langer, Christoph <christoph.langer at sap.com>; 'Daniel Fuchs'
> > > > <daniel.fuchs at oracle.com>; core-libs-dev at openjdk.java.net
> > > > Subject: RE: RFR (JAXP) 8169827:
> > > > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> > > >
> > > > Hi Christoph
> > > >
> > > > Many thanks for your effort!
> > > >
> > > > It's really better than the old version! However I have 2 comments although
> > I
> > > > am not a reviewer(as you often stated :))
> > > > 1. we could also write java code to copy/delete JDK.
> > > > 2. 8169827 is to track PropertiesTest failed in copying JDK intermittently. I
> > > > suggest to use another bug for your improvement
> > > > because I am not sure if this patch can improve the issue of 8169827.
> > > >
> > > > To Christoph and Daniel
> > > >
> > > > Btw, Christoph's patch inspired me. You know, PropertiesTest copies a JDK
> > in
> > > > order to isolate the file change of the JDK, actually
> > > > there are some other similar tests(to test some other JDK property or config
> > > > files) in JDK repo, they take the same way as well as
> > > > have similar code...
> > > > I have another idea for this test, that is we can only make symbolic link to
> > the
> > > > JDK files/directories except conf directory, create
> > > > a directory named with "conf" under the new jdk directory, and then make
> > > > symbolic link to the files/directories in conf to the real
> > > > jdk/conf except jaxp.properties. This will reduce the most of copying work
> > and
> > > > may reduce the risk of copying work. What's your
> > > > opinion?
> > > >
> > > > Thanks
> > > > Frank
> > > >
> > > > > -----Original Message-----
> > > > > From: Langer, Christoph [mailto:christoph.langer at sap.com]
> > > > > To: Daniel Fuchs; Frank Yuan; core-libs-dev at openjdk.java.net
> > > > > Subject: RE: RFR (JAXP) 8169827:
> > > > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > thanks for checking/reviewing. So I'll submit with removing the
> > > > ProblemList.txt entry and I'll also remove the intermittent flag.
> > > > >
> > > > > Sounds fair to check later if problems will still show up. Although I have
> > the
> > > > feeling that the issue of
> > > > > https://bugs.openjdk.java.net/browse/JDK-8147431 might appear again...
> > > > >
> > > > > Best regards
> > > > > Christoph
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com]
> > > > > > Sent: Montag, 23. Januar 2017 17:12
> > > > > > To: Langer, Christoph <christoph.langer at sap.com>; Frank Yuan
> > > > > > <frank.yuan at oracle.com>; core-libs-dev at openjdk.java.net
> > > > > > Subject: Re: RFR (JAXP) 8169827:
> > > > > > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh copied JDK failed
> > > > > >
> > > > > > Hi Christoph,
> > > > > >
> > > > > > Thanks for fixing this test!
> > > > > >
> > > > > > I imported your patch, modified ProblemList.txt to not skip the test,
> > > > > > and sent it through our test system, and I'm happy to report that
> > > > > > the test was run on all available platforms with no failure.
> > > > > >
> > > > > > So I think you should simply remove the line from ProblemList.txt
> > > > > > (no need for a new webrev).
> > > > > > If it fails again on more exotic platform we'll simply add it
> > > > > > back to ProblemList.txt for those platforms where it fails
> > > > > > (I guess it could happen if there's not enough disk space).
> > > > > >
> > > > > > Otherwise I have looked over the changes you proposed and they
> > > > > > do seem OK to me.
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > best regards,
> > > > > >
> > > > > > -- daniel
> > > > > >
> > > > > > On 23/01/17 10:03, Langer, Christoph wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > while working on jaxp changes and running jtreg tests I found that test
> > > > > > javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh does not work. I
> > then
> > > > saw
> > > > > > that this was already reported with bug 8169827. But, as I had already
> > > > spent
> > > > > > some time to fix this test I'd like to contribute my fix:
> > > > > > >
> > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169827
> > > > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169827.0/
> > > > > > >
> > > > > > > I converted the test to Java and removed the shell script
> > > > PropertiesTest.sh.
> > > > > > This resolves the compilation issue.
> > > > > > >
> > > > > > > However, the test needs to copy an isolated jdk as it modifies files in
> > the
> > > > JDK.
> > > > > > So I'm still using the copy script to first copy the jdk and afterwards
> > remove
> > > > the
> > > > > > copy. These are separate 'shell' test steps. And in the actual test I'm
> > running
> > > > a
> > > > > > child process with the isolated JDK.
> > > > > > >
> > > > > > > I also don't know if the test should be kept in the problem list and/or
> > also
> > > > be
> > > > > > tagged as 'intermittent' as the whole jdk copying procedure by means of
> > a
> > > > shell
> > > > > > script seems error prone. In case we keep the entry in the problem list, I
> > > > can
> > > > > > also open a separate bug for my change.
> > > > > > >
> > > > > > > @Frank: I don't know if you have some larger change in mind which
> > > > improves
> > > > > > the isolated jdk type testing greatly, otherwise I think this fix could at
> > least
> > > > > > make things better than they are at the moment.
> > > > > > >
> > > > > > > Thanks & Best regards
> > > > > > > Christoph
> > > > > > >
> > > >
> >



From huaming.li at oracle.com  Wed Jan 25 07:10:48 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 25 Jan 2017 15:10:48 +0800
Subject: RFR of JDK-8173326: Problem list
	java/rmi/registry/readTest/CodebaseTest.java on Windows
Message-ID: <0eb405ea-b6b8-0a5a-e70e-35d31aa4e20f@oracle.com>

Would you please review the below patch?

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

Thank you
-Hamlin
------------------------------------------------------------------------

diff -r a468135ebe8e test/ProblemList.txt
--- a/test/ProblemList.txt    Tue Jan 24 18:41:36 2017 -0800
+++ b/test/ProblemList.txt    Tue Jan 24 23:08:59 2017 -0800
@@ -203,6 +203,8 @@

  sun/rmi/rmic/newrmic/equivalence/run.sh 8145980 generic-all

+java/rmi/registry/readTest/CodebaseTest.java 8173324 windows-all
+
  ############################################################################

  # jdk_security


From david.holmes at oracle.com  Wed Jan 25 08:02:03 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Jan 2017 18:02:03 +1000
Subject: RFR of JDK-8173326: Problem list
	java/rmi/registry/readTest/CodebaseTest.java on Windows
In-Reply-To: <0eb405ea-b6b8-0a5a-e70e-35d31aa4e20f@oracle.com>
References: <0eb405ea-b6b8-0a5a-e70e-35d31aa4e20f@oracle.com>
Message-ID: <bc108dc2-1ffd-1a85-587d-e2da15ef98ba@oracle.com>

Looks good!

Thanks,
David

On 25/01/2017 5:10 PM, Hamlin Li wrote:
> Would you please review the below patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8173326
>
> Thank you
> -Hamlin
> ------------------------------------------------------------------------
>
> diff -r a468135ebe8e test/ProblemList.txt
> --- a/test/ProblemList.txt    Tue Jan 24 18:41:36 2017 -0800
> +++ b/test/ProblemList.txt    Tue Jan 24 23:08:59 2017 -0800
> @@ -203,6 +203,8 @@
>
>  sun/rmi/rmic/newrmic/equivalence/run.sh 8145980 generic-all
>
> +java/rmi/registry/readTest/CodebaseTest.java 8173324 windows-all
> +
>  ############################################################################
>
>
>  # jdk_security
>

From ramanand.patil at oracle.com  Wed Jan 25 10:10:07 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Wed, 25 Jan 2017 02:10:07 -0800 (PST)
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
In-Reply-To: <58867365.5070608@oracle.com>
References: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>
	<07c4c8b9-695b-6ba8-2cf8-09423e467379@oracle.com>
	<18089cd3-4cfb-4e55-b02b-e11cb637daa9@default>
	<58867365.5070608@oracle.com>
Message-ID: <cdafe37b-7d8a-46a0-ac89-1c013764a030@default>

Hi Kumar,
Thank you for the review and suggestions for the test case.
Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.02/


Regards,
Ramanand.

-----Original Message-----
From: Kumar Srinivasan 
Sent: Tuesday, January 24, 2017 2:50 AM
To: Ramanand Patil <ramanand.patil at oracle.com>
Cc: Alan Bateman <alan.bateman at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized


Hi Ramanand,
test/tools/launcher/LauncherMessageTest.java

1)

116         String[] commands = {"java", "--module-path", modules.getPath(),
117             "-m", "mod.b/pkgB.ClassB"};

The execution PATH may or may not contain the JAVA_HOME_UNDER_TEST/bin, so the right "java" may not be picked up,  suggest using the TestHelper's javaCmd field that will be set correctly.
Used TestHelper.javaCmd for instead of "java"

2)

  122         if (!result.isOK() && result.contains("JNI error")) {
  123             result.testOutput.forEach(System.err::println);
  124             throw new RuntimeException("Test Failed with JNI error!");
  125         } else {
  126             System.out.println("Test Passed...");
  127         }

The problem with 122 if it the test returns back with non-zero code, it will still fail with "Test Failed with JNI error", I prefer it to be broken up and return back the right message ie. if the test returns with non-zero code say that.
Changed the way test results were checked to include the check for unexpected failure when result is not non-zero.(i.e. when isOK() returns true).
3)
Also usage of RuntimeException is over the top, you can simply throw an Exception and have the main throws Exception, jtreg will do the needful.
Changed. Used an Exception instead of RuntimeException

4)

  102         FileUtils.deleteFileWithRetry(Paths.get(modules.getPath() + File.separator + "mod.a.jar"));

there are redundant use of File.separator, Paths.get should create the FS correctly on the target platform
ex: Paths.get(modules.getPath(), "mod.a.jar");

Personally I stay away from using raw File.separator, instead have the APIs do the work for me.

-Removed all instances of File.separator


Kumar


> Hi Alan,
> Thank you for the review.
> My comments are inline and Webrev is updated here: 
> http://cr.openjdk.java.net/~rpatil/8167063/webrev.01/
>
> Change Summary:
> - Removed SecurityException handling
> - Updated the error message in launcher.properties
> - Removed loadModuleMainClass0 method and moved the code back into 
> original loadModuleMainClass
> - NoClassDefFoundError is replaced by its parent class LinkageError in 
> method loadMainClass
>
> Regards,
> Ramanand.
>
> -----Original Message-----
> From: Alan Bateman
> Sent: Friday, January 20, 2017 8:03 PM
> To: Ramanand Patil <ramanand.patil at oracle.com>; 
> core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 8167063: spurious message "A JNI error has occurred" 
> if start-class cannot be initialized
>
> On 20/01/2017 13:21, Ramanand Patil wrote:
>
>> Hi all,
>> Please review the following bug fix:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167063
>> Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.00/
>>
>> Handled the SecurityException and LinkageError which can be thrown from Class.forName(...) method used in LauncherHelper.java and added corresponding error messages to launcher.properties.
>> Though the reported bug is because of the LinkageError, Security exception is also handled to be safe from calling Class.forName method.
>>
> I see this changes loadMainClass to abort with resources that are keyed on java.launcher.cls.error6 and java.launcher.cls.error7 but they don't appear in the launcher.properties file. Does this work? I would assume MissingResourceException is thrown.
> Thanks for pointing this. I missed to add it to launcher.properties. But now I have changed error6 to point to java.launcher.cls.error1 and removed security exception handling.
>
> For java.launcher.module.error3 and java.launcher.module.error4 then "link" is likely to confuse people. Sure, there may be linkage errors but there are many linkage errors and I think would be a lot clearer if the message was "Unable to load main class {0} from module {1}\n\{2}".
> Updated the message as suggested.
>
> It's not clear to me that having a different message for security exceptions make sense, esp. when the exception is printed. So I think I would drop that.
> Yes, I agree to drop out the Security exceptions handling.
>
> Also loadModuleMainClass0 is unusual method name, we've mostly (not
> always) used the 0 suffix on native methods. In any case, it doesn't look like it is needed, the code was okay in loadModuleMainClass as it was.
> The method was added just to look the exception handling easier. I have removed the extra method and placed the code back into loadModuleMainClass.
>
> One final point is that is the nesting catching of LinkageError and SecurityException in loadMainClass, I assume you don't need the inner catch.
> I think both the catch blocks were needed, because the first(inner) catch was already inside catch.(This was same as NoClassDefFoundError catching twice in the same method). Now since NoClassDefFoundError is subclass of LinkageError, I have replaced it with LinkageError. And  I think still the same abort message holds good. Please let me know if this is ok.
>
> -Alan


From pavel.rappo at oracle.com  Wed Jan 25 11:05:49 2017
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 25 Jan 2017 11:05:49 +0000
Subject: RFR 8170116: Remove qualified exports from java.base to java.corba	
Message-ID: <3376D262-01E3-4A3C-A64A-210501BD8211@oracle.com>

Hello,

Could you please review the following change for [1]?

   http://cr.openjdk.java.net/~prappo/8170116/webrev.00/

Thanks,
-Pavel

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


From daniel.fuchs at oracle.com  Wed Jan 25 11:27:18 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 25 Jan 2017 11:27:18 +0000
Subject: RFR 8170116: Remove qualified exports from java.base to java.corba
In-Reply-To: <3376D262-01E3-4A3C-A64A-210501BD8211@oracle.com>
References: <3376D262-01E3-4A3C-A64A-210501BD8211@oracle.com>
Message-ID: <018d2c72-4925-4fd5-8e9f-61818aac7188@oracle.com>

Hi Pavel,

Looks good to me.
I might have kept the 'defaultPresentationManager' name though.
Even though it's global it feels like a better name than 'globalPM'.

best regards,

-- daniel

On 25/01/17 11:05, Pavel Rappo wrote:
> Hello,
>
> Could you please review the following change for [1]?
>
>    http://cr.openjdk.java.net/~prappo/8170116/webrev.00/
>
> Thanks,
> -Pavel
>
> --------------------------------------------------------------------------------
> [1] https://bugs.openjdk.java.net/browse/JDK-8170116
>


From amy.lu at oracle.com  Wed Jan 25 11:29:47 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 25 Jan 2017 19:29:47 +0800
Subject: JDK 9 RFR of JDK-8169903: Refactor spliterator traversing tests
	into a library
In-Reply-To: <39AF9B61-1680-4D3E-8523-EAC6DC8EB550@oracle.com>
References: <8f7822d7-e66c-8d53-89f4-9d9b7f9a713f@oracle.com>
	<e78193c5-565b-3034-1131-2fd1a0f94624@oracle.com>
	<39AF9B61-1680-4D3E-8523-EAC6DC8EB550@oracle.com>
Message-ID: <573cbb38-61d0-7f03-3918-fe0ee5a4f54b@oracle.com>

Thank you Paul for reviewing.

Webrev updated: http://cr.openjdk.java.net/~amlu/8169903/webrev.01/

Note that SpliteratorTestHelper.java now still under 
test/java/util/stream/bootlib/java.base but changed to "java.util" 
(instead of java.util.stream). It may be re-located to 
test/lib/testlibrary, together with other stream-based test libs, later 
in JDK-8085814.

Thanks,
Amy


On 1/20/17 3:22 AM, Paul Sandoz wrote:
>> On 19 Jan 2017, at 05:37, Amy Lu <amy.lu at oracle.com> wrote:
>>
>> This is test-only change, can still go into JDK 9?
>>
> Yes.
>
> It?s verbose but i would prefer if you can explicitly declare each test rather than having one test deferring to SpliteratorTestHelper.testSpliterator. So in effect the test methods are proxies to the equivalent methods on the helper. That way it?s easier to diagnose test failures.
>
> The expected contents (collection) has also been removed. It?s important in many cases to be able to pass this independently and not derive the expected result from traversing the spliterator, as that could mask bugs.
>
> There is no need to create separate classes for primitive tests (you only added explicit for int traversing and not long and double).
>
>
> Independently i wonder if test/java/util/stream/bootlib/java.base/java/util/stream/SpliteratorTestHelper.java is the right location. I know it?s used in Streams, but perhaps it and the provider should be placed within a library?
>
> Paul.
>
>> Thanks,
>> Amy
>>
>> On 1/19/17 9:34 PM, Amy Lu wrote:
>>> java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
>>> java/util/Spliterator/SpliteratorCollisions.java
>>>
>>> Test functions in above tests are almost duplicate with functions in java/util/stream/SpliteratorTestHelper.java. Test can reuse test functions from SpliteratorTestHelper, but with it?s own DataProvider.
>>>
>>> Please review the patch for refactoring spliterator traversing tests.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8169903
>>> webrev: http://cr.openjdk.java.net/~amlu/8169903/webrev.00/
>>>
>>> SpliteratorTestHelper.java has a minor update, added one small testcase that originally from SpliteratorCollisions.testForEach.
>>>
>>> The two skipped tests in SpliteratorCollisions.java are now enabled back, as mentioned bug has already been fixed.
>>> 256 /* skip this test until 8013649 is fixed
>>> ...
>>> 268 */
>>>
>>> This patch also brings back Integer.MAX_VALUE test data which requires big memory (and removed in JDK-8169838), in a separate test.
>>>
>>> Thanks,
>>> Amy


From Alan.Bateman at oracle.com  Wed Jan 25 12:28:46 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Jan 2017 12:28:46 +0000
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
In-Reply-To: <cdafe37b-7d8a-46a0-ac89-1c013764a030@default>
References: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>
	<07c4c8b9-695b-6ba8-2cf8-09423e467379@oracle.com>
	<18089cd3-4cfb-4e55-b02b-e11cb637daa9@default>
	<58867365.5070608@oracle.com>
	<cdafe37b-7d8a-46a0-ac89-1c013764a030@default>
Message-ID: <4e7039aa-2d18-c3df-0a5d-aab7663636f8@oracle.com>



On 25/01/2017 10:10, Ramanand Patil wrote:
> Hi Kumar,
> Thank you for the review and suggestions for the test case.
> Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.02/
>
I see Kumar is looking at the test, I'll stick with LauncherHelper.

The update to loadModuleMainClass looks okay now but I'm puzzled by the 
changes in loadMainClass. For starters  catching LinkageError and 
retrying the Class.forName looks fishy. I don't think you want that for 
errors like VerifyError or ClassFormatError.  In addition, it looks like 
the abort will now hide linkage errors where we used to get a helpful 
stack trace. I think what you are really need is to leave the original 
code was it was and just add a new catch block for LinkageError. Also 
java.launcher.cls.error1 or a new key cna be created so that the 
exception is printed (as it is done in loadModuleMainClass).

-Alan

From Alan.Bateman at oracle.com  Wed Jan 25 12:32:01 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Jan 2017 12:32:01 +0000
Subject: RFR 8170116: Remove qualified exports from java.base to java.corba
In-Reply-To: <3376D262-01E3-4A3C-A64A-210501BD8211@oracle.com>
References: <3376D262-01E3-4A3C-A64A-210501BD8211@oracle.com>
Message-ID: <ec6dd483-f952-97eb-6627-0f4d3e01891d@oracle.com>



On 25/01/2017 11:05, Pavel Rappo wrote:
> Hello,
>
> Could you please review the following change for [1]?
>
>     http://cr.openjdk.java.net/~prappo/8170116/webrev.00/
>
I agree with Daniel on the name.

Also the comment in the Bridge constructor says "Bridge.get() is always 
called in doPrivileged() blocks" which is at odds with the permission 
check in Bridge.get. That is, if Bridge.get is always called with 
privileges then the permission check is not needed.

-Alan.

From daniel.fuchs at oracle.com  Wed Jan 25 13:50:45 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 25 Jan 2017 13:50:45 +0000
Subject: RFR 8170116: Remove qualified exports from java.base to java.corba
In-Reply-To: <ec6dd483-f952-97eb-6627-0f4d3e01891d@oracle.com>
References: <3376D262-01E3-4A3C-A64A-210501BD8211@oracle.com>
	<ec6dd483-f952-97eb-6627-0f4d3e01891d@oracle.com>
Message-ID: <69bee9db-b034-395b-75ad-e550be020fbc@oracle.com>

On 25/01/17 12:32, Alan Bateman wrote:
>
>
> On 25/01/2017 11:05, Pavel Rappo wrote:
>> Hello,
>>
>> Could you please review the following change for [1]?
>>
>>     http://cr.openjdk.java.net/~prappo/8170116/webrev.00/
>>

Hi Alan,

> I agree with Daniel on the name.
>
> Also the comment in the Bridge constructor says "Bridge.get() is always
> called in doPrivileged() blocks" which is at odds with the permission
> check in Bridge.get. That is, if Bridge.get is always called with
> privileges then the permission check is not needed.

The comment was intended to explain that doPrivileged is not needed
in new Bridge() because the code that calls Bridge.get() (which in
turn creates new Bridge) uses doPrivileged to call Bridge.get()).
Otherwise creating the StackWalker in new Bridge might have caused
a new SecurityException to be propagated to user code at the time
bridge creation was triggered.

But maybe the comment should be removed if it's misleading.

cheers,

-- daniel

>
> -Alan.


From andrey.x.nazarov at oracle.com  Wed Jan 25 14:45:41 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Wed, 25 Jan 2017 17:45:41 +0300
Subject: RFR: 8075617, 8075616 Create tests to check wsgen, schemagen work with
	multi-version jar
Message-ID: <CBABED4B-B8A2-4A80-9BD2-8039A055F5AD@oracle.com>

Hi,

I?ve added sanity checks that wsgen and schemagen tools works with multi-release jar files.

Review http://cr.openjdk.java.net/~anazarov/8075617/webrev.00/webrev/

JBS: https://bugs.openjdk.java.net/browse/JDK-8075616 <https://bugs.openjdk.java.net/browse/JDK-8075616>, 
https://bugs.openjdk.java.net/browse/JDK-8075617 <https://bugs.openjdk.java.net/browse/JDK-8075617>

?Andrey

From Alan.Bateman at oracle.com  Wed Jan 25 15:03:45 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Jan 2017 15:03:45 +0000
Subject: RFR: 8075617, 8075616 Create tests to check wsgen, schemagen work
	with multi-version jar
In-Reply-To: <CBABED4B-B8A2-4A80-9BD2-8039A055F5AD@oracle.com>
References: <CBABED4B-B8A2-4A80-9BD2-8039A055F5AD@oracle.com>
Message-ID: <86914c18-9d41-6778-4a4d-66acff3442ac@oracle.com>

On 25/01/2017 14:45, Andrey Nazarov wrote:

> Hi,
>
> I?ve added sanity checks that wsgen and schemagen tools works with multi-release jar files.
>
> Review http://cr.openjdk.java.net/~anazarov/8075617/webrev.00/webrev/
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8075616 <https://bugs.openjdk.java.net/browse/JDK-8075616>,
> https://bugs.openjdk.java.net/browse/JDK-8075617 <https://bugs.openjdk.java.net/browse/JDK-8075617>
>
I'm not sure that test/tools/jar is a good place to put tests for the 
JAX-WS tools. Would you consider moving them to a location where we test 
these tests?

-Alan

From andrey.x.nazarov at oracle.com  Wed Jan 25 15:25:49 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Wed, 25 Jan 2017 18:25:49 +0300
Subject: RFR: 8075617, 8075616 Create tests to check wsgen, schemagen work
	with multi-version jar
In-Reply-To: <86914c18-9d41-6778-4a4d-66acff3442ac@oracle.com>
References: <CBABED4B-B8A2-4A80-9BD2-8039A055F5AD@oracle.com>
	<86914c18-9d41-6778-4a4d-66acff3442ac@oracle.com>
Message-ID: <FADC68EB-89AF-4CCA-AEE2-EBF55212D3FC@oracle.com>


> On 25 Jan 2017, at 18:03, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 25/01/2017 14:45, Andrey Nazarov wrote:
> 
>> Hi,
>> 
>> I?ve added sanity checks that wsgen and schemagen tools works with multi-release jar files.
>> 
>> Review http://cr.openjdk.java.net/~anazarov/8075617/webrev.00/webrev/
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8075616 <https://bugs.openjdk.java.net/browse/JDK-8075616>,
>> https://bugs.openjdk.java.net/browse/JDK-8075617 <https://bugs.openjdk.java.net/browse/JDK-8075617>
>> 
> I'm not sure that test/tools/jar is a good place to put tests for the JAX-WS tools. Would you consider moving them to a location where we test these tests?
What is the right location?
> 
> -Alan


From Alan.Bateman at oracle.com  Wed Jan 25 16:00:49 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Jan 2017 16:00:49 +0000
Subject: RFR: 8075617, 8075616 Create tests to check wsgen, schemagen work
	with multi-version jar
In-Reply-To: <FADC68EB-89AF-4CCA-AEE2-EBF55212D3FC@oracle.com>
References: <CBABED4B-B8A2-4A80-9BD2-8039A055F5AD@oracle.com>
	<86914c18-9d41-6778-4a4d-66acff3442ac@oracle.com>
	<FADC68EB-89AF-4CCA-AEE2-EBF55212D3FC@oracle.com>
Message-ID: <ff92bd6a-559e-6206-0e23-5d141a4441cf@oracle.com>

On 25/01/2017 15:25, Andrey Nazarov wrote:

> :
> What is the right location?
These tools are maintained in the upstream Metro project, I suspect the 
tests for these tools are located there too but I'm not sure. There are 
handful of JAXB and JAX-WS tests in the jdk repo but I don't think they 
directly test the tools. So I think you'll need a new location for 
these, assuming you really want these in the jdk repo.

-Alan

From kumar.x.srinivasan at oracle.com  Wed Jan 25 16:00:00 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 25 Jan 2017 08:00:00 -0800
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
In-Reply-To: <cdafe37b-7d8a-46a0-ac89-1c013764a030@default>
References: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>
	<07c4c8b9-695b-6ba8-2cf8-09423e467379@oracle.com>
	<18089cd3-4cfb-4e55-b02b-e11cb637daa9@default>
	<58867365.5070608@oracle.com>
	<cdafe37b-7d8a-46a0-ac89-1c013764a030@default>
Message-ID: <5888CB80.6050107@oracle.com>

  116         if (result.isOK()) {
  117             throw new Exception("Test Passed Unexpectedly!");
  118         } else if (result.contains("JNI error")) {
  119             result.testOutput.forEach(System.err::println);
  120             throw new Exception("Test Failed with JNI error!");
  121         }
  + 122  System.out.println("Test passes, failed with expected error message");

As a sanity I would add the above. This will make it clear to someone
trying to triage an error.

Kumar

On 1/25/2017 2:10 AM, Ramanand Patil wrote:
> Hi Kumar,
> Thank you for the review and suggestions for the test case.
> Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.02/
>
>
> Regards,
> Ramanand.
>
> -----Original Message-----
> From: Kumar Srinivasan
> Sent: Tuesday, January 24, 2017 2:50 AM
> To: Ramanand Patil <ramanand.patil at oracle.com>
> Cc: Alan Bateman <alan.bateman at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized
>
>
> Hi Ramanand,
> test/tools/launcher/LauncherMessageTest.java
>
> 1)
>
> 116         String[] commands = {"java", "--module-path", modules.getPath(),
> 117             "-m", "mod.b/pkgB.ClassB"};
>
> The execution PATH may or may not contain the JAVA_HOME_UNDER_TEST/bin, so the right "java" may not be picked up,  suggest using the TestHelper's javaCmd field that will be set correctly.
> Used TestHelper.javaCmd for instead of "java"
>
> 2)
>
>    122         if (!result.isOK() && result.contains("JNI error")) {
>    123             result.testOutput.forEach(System.err::println);
>    124             throw new RuntimeException("Test Failed with JNI error!");
>    125         } else {
>    126             System.out.println("Test Passed...");
>    127         }
>
> The problem with 122 if it the test returns back with non-zero code, it will still fail with "Test Failed with JNI error", I prefer it to be broken up and return back the right message ie. if the test returns with non-zero code say that.
> Changed the way test results were checked to include the check for unexpected failure when result is not non-zero.(i.e. when isOK() returns true).
> 3)
> Also usage of RuntimeException is over the top, you can simply throw an Exception and have the main throws Exception, jtreg will do the needful.
> Changed. Used an Exception instead of RuntimeException
>
> 4)
>
>    102         FileUtils.deleteFileWithRetry(Paths.get(modules.getPath() + File.separator + "mod.a.jar"));
>
> there are redundant use of File.separator, Paths.get should create the FS correctly on the target platform
> ex: Paths.get(modules.getPath(), "mod.a.jar");
>
> Personally I stay away from using raw File.separator, instead have the APIs do the work for me.
>
> -Removed all instances of File.separator
>
>
> Kumar
>
>
>> Hi Alan,
>> Thank you for the review.
>> My comments are inline and Webrev is updated here:
>> http://cr.openjdk.java.net/~rpatil/8167063/webrev.01/
>>
>> Change Summary:
>> - Removed SecurityException handling
>> - Updated the error message in launcher.properties
>> - Removed loadModuleMainClass0 method and moved the code back into
>> original loadModuleMainClass
>> - NoClassDefFoundError is replaced by its parent class LinkageError in
>> method loadMainClass
>>
>> Regards,
>> Ramanand.
>>
>> -----Original Message-----
>> From: Alan Bateman
>> Sent: Friday, January 20, 2017 8:03 PM
>> To: Ramanand Patil <ramanand.patil at oracle.com>;
>> core-libs-dev at openjdk.java.net
>> Subject: Re: RFR: 8167063: spurious message "A JNI error has occurred"
>> if start-class cannot be initialized
>>
>> On 20/01/2017 13:21, Ramanand Patil wrote:
>>
>>> Hi all,
>>> Please review the following bug fix:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167063
>>> Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.00/
>>>
>>> Handled the SecurityException and LinkageError which can be thrown from Class.forName(...) method used in LauncherHelper.java and added corresponding error messages to launcher.properties.
>>> Though the reported bug is because of the LinkageError, Security exception is also handled to be safe from calling Class.forName method.
>>>
>> I see this changes loadMainClass to abort with resources that are keyed on java.launcher.cls.error6 and java.launcher.cls.error7 but they don't appear in the launcher.properties file. Does this work? I would assume MissingResourceException is thrown.
>> Thanks for pointing this. I missed to add it to launcher.properties. But now I have changed error6 to point to java.launcher.cls.error1 and removed security exception handling.
>>
>> For java.launcher.module.error3 and java.launcher.module.error4 then "link" is likely to confuse people. Sure, there may be linkage errors but there are many linkage errors and I think would be a lot clearer if the message was "Unable to load main class {0} from module {1}\n\{2}".
>> Updated the message as suggested.
>>
>> It's not clear to me that having a different message for security exceptions make sense, esp. when the exception is printed. So I think I would drop that.
>> Yes, I agree to drop out the Security exceptions handling.
>>
>> Also loadModuleMainClass0 is unusual method name, we've mostly (not
>> always) used the 0 suffix on native methods. In any case, it doesn't look like it is needed, the code was okay in loadModuleMainClass as it was.
>> The method was added just to look the exception handling easier. I have removed the extra method and placed the code back into loadModuleMainClass.
>>
>> One final point is that is the nesting catching of LinkageError and SecurityException in loadMainClass, I assume you don't need the inner catch.
>> I think both the catch blocks were needed, because the first(inner) catch was already inside catch.(This was same as NoClassDefFoundError catching twice in the same method). Now since NoClassDefFoundError is subclass of LinkageError, I have replaced it with LinkageError. And  I think still the same abort message holds good. Please let me know if this is ok.
>>
>> -Alan


From andrey.x.nazarov at oracle.com  Wed Jan 25 16:04:55 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Wed, 25 Jan 2017 19:04:55 +0300
Subject: RFR: 8075617, 8075616 Create tests to check wsgen, schemagen work
	with multi-version jar
In-Reply-To: <ff92bd6a-559e-6206-0e23-5d141a4441cf@oracle.com>
References: <CBABED4B-B8A2-4A80-9BD2-8039A055F5AD@oracle.com>
	<86914c18-9d41-6778-4a4d-66acff3442ac@oracle.com>
	<FADC68EB-89AF-4CCA-AEE2-EBF55212D3FC@oracle.com>
	<ff92bd6a-559e-6206-0e23-5d141a4441cf@oracle.com>
Message-ID: <D0BAB791-CBE0-4BFA-928E-A7405860BE18@oracle.com>


> On 25 Jan 2017, at 19:00, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 25/01/2017 15:25, Andrey Nazarov wrote:
> 
>> :
>> What is the right location?
> These tools are maintained in the upstream Metro project, I suspect the tests for these tools are located there too but I'm not sure. There are handful of JAXB and JAX-WS tests in the jdk repo but I don't think they directly test the tools. So I think you'll need a new location for these, assuming you really want these in the jdk repo.
Is it Ok to use jdk/test/tools/jaxws ? Tools directory already contains tests for jjs for example.
> 
> -Alan


From rob.mckenna at oracle.com  Wed Jan 25 16:31:41 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 25 Jan 2017 16:31:41 +0000
Subject: [RFR] 8160768: Add capability to custom resolve host/domain names
	within the default JDNI LDAP provider
Message-ID: <20170125163141.GB3628@tecra>

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 henry.jen at oracle.com  Wed Jan 25 16:57:25 2017
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 25 Jan 2017 08:57:25 -0800
Subject: RFR: 8170832: Add a new launcher environment variable JAVA_OPTIONS
In-Reply-To: <CEDCF2D3-5EF5-4F06-8B21-32D40A9C34F4@oracle.com>
References: <E18D7570-2AE6-47BE-8143-4057376C1348@oracle.com>
	<CEDCF2D3-5EF5-4F06-8B21-32D40A9C34F4@oracle.com>
Message-ID: <2967BA40-4FE9-4085-9C56-94D3DE431EEE@oracle.com>


> On Jan 24, 2017, at 12:41 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> On Jan 24, 2017, at 10:20 AM, Henry Jen <henry.jen at oracle.com> wrote:
>> 
>> Hi,
>> 
>> Please review the webrev[1] that add support for JAVA_OPTIONS environment variable. The bug[2] describes how JAVA_OPTIONS works.
>> 
>> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8170832/4/webrev/
> 
> This looks quite good.  A couple of minor comments:
> 
> 503         // Must be after expansion so we can caught if main class specified @argfile
> 
> typo: s/caught/catch.  It?d be clear to simply say:
> // Check if Main class specified after argument checked.
> // This check must be done after expansion.
> 

Fixed.

>  42 #define JAVA_OPTIONS ?JAVA_OPTIONS"
> 
> I think java.h is the appropriate file to declare this instead of jli_util.h.
> 

Well, no disagreement. I moved it and add a separate entry in args.c.
The reason it was in jli_util.h is follows the _JAVA_LAUNCHER_DEBUG. and JAVA_OPTIONS is for launcher. It is used by args.c which include jli_util.h but not full java.h in standalone mode. 

> emessages.h
>  Would it be clearer to rename ARG_INFO to ARG_INFO_ENVVAR?
> 

Again, try o be consistent with existing style. Changed.

Cheers,
Henry


From paul.sandoz at oracle.com  Wed Jan 25 17:04:57 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Jan 2017 09:04:57 -0800
Subject: JDK 9 RFR of JDK-8169903: Refactor spliterator traversing tests
	into a library
In-Reply-To: <573cbb38-61d0-7f03-3918-fe0ee5a4f54b@oracle.com>
References: <8f7822d7-e66c-8d53-89f4-9d9b7f9a713f@oracle.com>
	<e78193c5-565b-3034-1131-2fd1a0f94624@oracle.com>
	<39AF9B61-1680-4D3E-8523-EAC6DC8EB550@oracle.com>
	<573cbb38-61d0-7f03-3918-fe0ee5a4f54b@oracle.com>
Message-ID: <2F67C7EC-0FC5-4E1B-B287-E1491B061926@oracle.com>

Hi Any,

Much better.

I suspect out of laziness when hacking i annotated the test methods with:

  @SuppressWarnings({"unchecked", "rawtypes?})

Can we remove those with an appropriate adjustment to the test method signatures?

SpliteratorTraversingAndSplittingTest
?

 897         Object[][] bitStreamTestcases = new Object[][] {
 898                 { "none", IntStream.empty().toArray() },
 899                 { "index 0", IntStream.of(0).toArray() },
 900                 { "index 255", IntStream.of(255).toArray() },
 901                 { "index 0 and 255", IntStream.of(0, 255).toArray() },
 902                 { "index Integer.MAX_VALUE", IntStream.of(Integer.MAX_VALUE).toArray() },
 903                 { "index Integer.MAX_VALUE - 1", IntStream.of(Integer.MAX_VALUE - 1).toArray() },
 904                 { "index 0 and Integer.MAX_VALUE", IntStream.of(0, Integer.MAX_VALUE).toArray() },
 905                 { "every bit", IntStream.range(0, 255).toArray() },
 906                 { "step 2", IntStream.range(0, 255).map(f -> f * 2).toArray() },
 907                 { "step 3", IntStream.range(0, 255).map(f -> f * 3).toArray() },
 908                 { "step 5", IntStream.range(0, 255).map(f -> f * 5).toArray() },
 909                 { "step 7", IntStream.range(0, 255).map(f -> f * 7).toArray() },
 910                 { "1, 10, 100, 1000", IntStream.of(1, 10, 100, 1000).toArray() },

We should be careful adding Integer.MAX_VALUE tests for BitStream as the can consume lots of memory.

My suggestion is not to add them to this test and instead consider, as a follow on issue, moving spliterator testing of BitSet to BitSetStreamTest, where we can better control large memory consuming cases.

Paul.

> On 25 Jan 2017, at 03:29, Amy Lu <amy.lu at oracle.com> wrote:
> 
> Thank you Paul for reviewing.
> 
> Webrev updated: http://cr.openjdk.java.net/~amlu/8169903/webrev.01/
> 
> Note that SpliteratorTestHelper.java now still under test/java/util/stream/bootlib/java.base but changed to "java.util" (instead of java.util.stream). It may be re-located to test/lib/testlibrary, together with other stream-based test libs, later in JDK-8085814.
> 
> Thanks,
> Amy
> 
> 
> On 1/20/17 3:22 AM, Paul Sandoz wrote:
>>> On 19 Jan 2017, at 05:37, Amy Lu <amy.lu at oracle.com> wrote:
>>> 
>>> This is test-only change, can still go into JDK 9?
>>> 
>> Yes.
>> 
>> It?s verbose but i would prefer if you can explicitly declare each test rather than having one test deferring to SpliteratorTestHelper.testSpliterator. So in effect the test methods are proxies to the equivalent methods on the helper. That way it?s easier to diagnose test failures.
>> 
>> The expected contents (collection) has also been removed. It?s important in many cases to be able to pass this independently and not derive the expected result from traversing the spliterator, as that could mask bugs.
>> 
>> There is no need to create separate classes for primitive tests (you only added explicit for int traversing and not long and double).
>> 
>> 
>> Independently i wonder if test/java/util/stream/bootlib/java.base/java/util/stream/SpliteratorTestHelper.java is the right location. I know it?s used in Streams, but perhaps it and the provider should be placed within a library?
>> 
>> Paul.
>> 
>>> Thanks,
>>> Amy
>>> 
>>> On 1/19/17 9:34 PM, Amy Lu wrote:
>>>> java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
>>>> java/util/Spliterator/SpliteratorCollisions.java
>>>> 
>>>> Test functions in above tests are almost duplicate with functions in java/util/stream/SpliteratorTestHelper.java. Test can reuse test functions from SpliteratorTestHelper, but with it?s own DataProvider.
>>>> 
>>>> Please review the patch for refactoring spliterator traversing tests.
>>>> 
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8169903
>>>> webrev: http://cr.openjdk.java.net/~amlu/8169903/webrev.00/
>>>> 
>>>> SpliteratorTestHelper.java has a minor update, added one small testcase that originally from SpliteratorCollisions.testForEach.
>>>> 
>>>> The two skipped tests in SpliteratorCollisions.java are now enabled back, as mentioned bug has already been fixed.
>>>> 256 /* skip this test until 8013649 is fixed
>>>> ...
>>>> 268 */
>>>> 
>>>> This patch also brings back Integer.MAX_VALUE test data which requires big memory (and removed in JDK-8169838), in a separate test.
>>>> 
>>>> Thanks,
>>>> Amy
> 


From rob.mckenna at oracle.com  Wed Jan 25 17:44:53 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 25 Jan 2017 17:44:53 +0000
Subject: [RFR] 8160768: Add capability to custom resolve host/domain
	names within the default JDNI LDAP provider
In-Reply-To: <20170125163141.GB3628@tecra>
References: <20170125163141.GB3628@tecra>
Message-ID: <20170125174453.GE3628@tecra>

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 daniel.fuchs at oracle.com  Wed Jan 25 17:50:22 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 25 Jan 2017 17:50:22 +0000
Subject: [RFR] 8160768: Add capability to custom resolve host/domain names
	within the default JDNI LDAP provider
In-Reply-To: <20170125174453.GE3628@tecra>
References: <20170125163141.GB3628@tecra> <20170125174453.GE3628@tecra>
Message-ID: <f81eb731-358e-a680-0788-05230af9ce07@oracle.com>

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 mandy.chung at oracle.com  Wed Jan 25 17:53:10 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 25 Jan 2017 09:53:10 -0800
Subject: RFR 8170116: Remove qualified exports from java.base to java.corba
In-Reply-To: <3376D262-01E3-4A3C-A64A-210501BD8211@oracle.com>
References: <3376D262-01E3-4A3C-A64A-210501BD8211@oracle.com>
Message-ID: <48771AAD-AD00-40FB-92D3-64A81F6111BA@oracle.com>


> On Jan 25, 2017, at 3:05 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> Hello,
> 
> Could you please review the following change for [1]?
> 
>   http://cr.openjdk.java.net/~prappo/8170116/webrev.00/

sun/corba/Bridge.java
  99         // Bridge.get() is always called in doPrivileged() blocks.

I agree that this comment can be removed and the javadoc of Bridge::get
already specifies the permissions required that is clear to me.

  Nit: line 130-132 should use /* */ comment as javadoc.

I?m happy to see this demonstrate a good use StackWalker to find the 
user loader.  This reminds that we should convert 
jdk.internal.misc.VM.latestUserDefinedLoader to use StackWalker and
remove the VM entry point.

I also agree to keep the defaultPresentationManager name.

Otherwise, looks good.

Mandy

From peter.levart at gmail.com  Wed Jan 25 17:59:39 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Jan 2017 18:59:39 +0100
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
	reflection
In-Reply-To: <9462D17E-1827-4B04-ACE2-AE2E1BE4CB78@oracle.com>
References: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>
	<1d8c06cf-ddba-ff49-bd61-2edd496efb48@oracle.com>
	<9462D17E-1827-4B04-ACE2-AE2E1BE4CB78@oracle.com>
Message-ID: <37cf537c-f777-d223-2706-4db3ba721991@gmail.com>

Hi Chris,

On 01/24/2017 04:07 PM, Chris Hegarty wrote:
> Peter,
>
>> On 2017-01-17 15:10, Peter Levart wrote:
>>> Hi,
>>>
>>> This is a preview of a patch that addresses the following issue:
>>>
>>>     https://bugs.openjdk.java.net/browse/JDK-8029019
> This very good work. I have not done a complete review, but what
> jumps out at me is that you have removed some of the validation
> code and checks from AnnotationInvocationHandler ( in one place
> there is an assert and a comment that ?good? data is expected.
> AnnotationInvocationHandler has shown up in many interesting
> places, I wonder if it is wise to remove these.

I don't know to what part of code you are referring. if it is the checks 
in the AnnotationInvocationHandler constructor then they have been moved 
to AnnotationType constructor. AnnotationParser always 
constructs/retrieves AnnotationType instance for the annotationClass 
object before it attempts to construct  AnnotationInvocationHandler for 
such annotationClass, so annotationClass is pre-validated. 
AnnotationInvocationHandler is a package-private class and its 
constructor is only invoked from AnnotationParser.annotationForMap() 
public factory method. This method is invoked from 3 places currently:

AnnotationParser.parseAnnotation2() which pre-validates the annotationClass
AnnotationsInheritanceOrderRedefinitionTest which is passing only javac 
compiled (pre-validated) annotationClasses to it
com.sun.tools.javac.model.AnnotationProxyMaker.generateAnnotation - this 
one is called from various other places so there's no guarantee that the 
annotationClass passed to it is validated.

So you have a point. I will include an unconditional call to 
AnnotationType.getInstance(annotationClass) in the 
AnnotationInvocationHandler constructor. This will only amount to an 
overhead of a volatile read when AnnotationType is already cached which 
it usually will be.

Regards, Peter

>
> -Chris.
>
>>> But it is also an attempt to clean-up failure reporting for invalid
>>> annotation types. Here's the 1st webrev:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/webrev.01/
>>>
>>>
>>> With this patch applied, running the following benchmark:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/AnnotationsBench.java
>>>
>>>
>>> Produces the following results:
>>>
>>> Original:
>>>
>>> Benchmark                                 Mode  Cnt Score     Error  Units
>>> AnnotationsBench.a1_PrimitiveMember       avgt   10 20.790 ?   1.317  ns/op
>>> AnnotationsBench.a2_ObjectMember          avgt   10 21.550 ?   0.580  ns/op
>>> AnnotationsBench.a3_PrimitiveArrayMember  avgt   10 28.314 ?   1.477  ns/op
>>> AnnotationsBench.a4_ObjectArrayMember     avgt   10 27.094 ?   0.574  ns/op
>>> AnnotationsBench.a5_AnnotationType        avgt   10 13.047 ?   0.983  ns/op
>>> AnnotationsBench.a6_HashCode              avgt   10 158.001 ?   9.347
>>> ns/op
>>> AnnotationsBench.a7_Equals                avgt   10 663.921 ?  27.256
>>> ns/op
>>> AnnotationsBench.a8_ToString              avgt   10 1772.901 ? 107.355
>>> ns/op
>>>
>>> Patched:
>>>
>>> Benchmark                                 Mode  Cnt Score    Error  Units
>>> AnnotationsBench.a1_PrimitiveMember       avgt   10 8.547 ?  0.100  ns/op
>>> AnnotationsBench.a2_ObjectMember          avgt   10 8.352 ?  0.340  ns/op
>>> AnnotationsBench.a3_PrimitiveArrayMember  avgt   10 17.526 ?  0.696  ns/op
>>> AnnotationsBench.a4_ObjectArrayMember     avgt   10 15.639 ?  0.116  ns/op
>>> AnnotationsBench.a5_AnnotationType        avgt   10 4.692 ?  0.154  ns/op
>>> AnnotationsBench.a6_HashCode              avgt   10 142.954 ?  7.460  ns/op
>>> AnnotationsBench.a7_Equals                avgt   10 184.535 ?  0.917  ns/op
>>> AnnotationsBench.a8_ToString              avgt   10 1806.685 ? 96.370
>>> ns/op
>>>
>>>
>>> Allocation rates are also reduced:
>>>
>>> Original:
>>>
>>> AnnotationsBench.a1_PrimitiveMember:?gc.alloc.rate.norm avgt   10
>>> 16.000 ?   0.001    B/op
>>> AnnotationsBench.a2_ObjectMember:?gc.alloc.rate.norm avgt   10    16.000
>>> ?   0.001    B/op
>>> AnnotationsBench.a3_PrimitiveArrayMember:?gc.alloc.rate.norm avgt
>>> 10    64.000 ?   0.001    B/op
>>> AnnotationsBench.a4_ObjectArrayMember:?gc.alloc.rate.norm avgt   10
>>> 48.000 ?   0.001    B/op
>>> AnnotationsBench.a5_AnnotationType:?gc.alloc.rate.norm avgt   10
>>> 16.000 ?   0.001    B/op
>>> AnnotationsBench.a6_HashCode:?gc.alloc.rate.norm avgt   10   128.000 ?
>>> 0.001    B/op
>>> AnnotationsBench.a7_Equals:?gc.alloc.rate.norm avgt   10   120.001 ?
>>> 0.001    B/op
>>> AnnotationsBench.a8_ToString:?gc.alloc.rate.norm avgt   10  5200.002 ?
>>> 0.001    B/op
>>>
>>> Patched:
>>>
>>> AnnotationsBench.a1_PrimitiveMember:?gc.alloc.rate.norm avgt   10    ?
>>> 10??              B/op
>>> AnnotationsBench.a2_ObjectMember:?gc.alloc.rate.norm avgt   10    ?
>>> 10??              B/op
>>> AnnotationsBench.a3_PrimitiveArrayMember:?gc.alloc.rate.norm avgt
>>> 10    48.000 ?   0.001    B/op
>>> AnnotationsBench.a4_ObjectArrayMember:?gc.alloc.rate.norm avgt   10
>>> 32.000 ?   0.001    B/op
>>> AnnotationsBench.a5_AnnotationType:?gc.alloc.rate.norm avgt   10    ?
>>> 10??              B/op
>>> AnnotationsBench.a6_HashCode:?gc.alloc.rate.norm avgt   10    64.000 ?
>>> 0.001    B/op
>>> AnnotationsBench.a7_Equals:?gc.alloc.rate.norm avgt   10    24.000 ?
>>> 0.001    B/op
>>> AnnotationsBench.a8_ToString:?gc.alloc.rate.norm avgt   10  5136.002 ?
>>> 0.001    B/op
>>>
>>>
>>> As for the failure reporting: requesting an annotation for invalid
>>> annotation type now always produces AnnotationFormatError. Previously,
>>> some invalid annotations were simply skipped, some produced
>>> AnnotationFormatError and for some of them, AnnotationFormatError was
>>> raised only when evaluating Annotation's equals() method.
>>>
>>> I would like to discuss this failure behavior more in-depth.
>>>
>>> Regards, Peter
>>>


From andrey.x.nazarov at oracle.com  Wed Jan 25 18:54:30 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Wed, 25 Jan 2017 21:54:30 +0300
Subject: RFR: 8173372 Add tests for multi-release module jar API validator
Message-ID: <386E1688-9264-47D3-A9AE-BABE00F1A254@oracle.com>

Hi,

I?ve added tests to check what MR Jar API validator handles changes in module-info.class

Review: http://cr.openjdk.java.net/~anazarov/8173372/webrev.01/webrev/
JBS: https://bugs.openjdk.java.net/browse/JDK-8173372


?Andrey

From peter.levart at gmail.com  Wed Jan 25 19:01:10 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 25 Jan 2017 20:01:10 +0100
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
	reflection
In-Reply-To: <1d8c06cf-ddba-ff49-bd61-2edd496efb48@oracle.com>
References: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>
	<1d8c06cf-ddba-ff49-bd61-2edd496efb48@oracle.com>
Message-ID: <bbe1f51f-ee62-4008-e2d2-6a06da8c09b3@gmail.com>

Hi Claes,

On 01/24/2017 03:34 PM, Claes Redestad wrote:
> Hi Peter,
>
> thanks for the thorough examination of this issue. 

Thanks for looking into this change...

> After going through
> the patch I do like what I see, but I have a few comments:
>
> AnnotationInvocationHandler:
> in invoke, cleaning up and replacing the explicit AssertionError should
> be fine, but perhaps convert it to an assert that the number of
> arguments is 1 when methodName is "equals" and 0 otherwise?

In the following part of code:

     public Object invoke(Object proxy, Method method, Object[] args) {

         String memberName = method.getName(); // guaranteed interned String
         Class<?> dtype = method.getDeclaringClass();

         if (dtype == Object.class ||  // equals/hashCode/toString
             dtype == Annotation.class // annotationType
             ) {
             if (memberName == "equals") return equalsImpl(proxy, args[0]);
             if (memberName == "hashCode") return hashCodeImpl();
             if (memberName == "annotationType") return type;
             if (memberName == "toString") return toStringImpl();
             throw new AssertionError("Invalid method: " + method);
         }

...in the if statement, when method's declaring class is either Object 
or Annotation, we have just a limited number of methods that are 
possible candidates and we can identify them just by their names 
(Method::getName returns interned string, so identity comparison is 
possible). For example: if method's name is "equals" and declaring class 
is either Object or Annotation, then we know that this method has a 
signature of Object::equals - we don't need to check - this is part of 
language spec.

The "throw new AssertionError("Invalid method: " + method)" is an 
unreachable statement until some new method is added to either Object or 
Annotation and at that time, if it ever comes to that, this code should 
fail and should be revised...

The assert you are talking about is meaningful only if inserted as 1st 
statement inside the if statement. Will add it.

>
> Adding @Stable is fine if that has a performance impact, but I think
> we might preserve clarity of intent if you kept the fields as final and
> kept using Unsafe to deserialize properly.

Ok, will make them final but keep @Stable.

>
> AnnotationSupport:
> I dislike that this code was already catching Throwable, and that
> you're now copying that approach.  Could the new the catch clause mimic
> the one that previously wrapped the entire method?

I think we can do it even better than that. See new webrev...

>
> AnnotationType:
> accessibleMembers might not need to be volatile.

AnnotationType.accessibleMembers() may be called concurrently from 
multiple threads (it is used by annotation's equals method when passed a 
foreign annotation and by AnnotationSupport.getValueArray() helper 
method used to access repeatable annotations in a foreign container 
annotation). What this method returns is a HashMap object which is not 
tolerable to unsafe publication (unlike String, for example). Volatile 
field is needed for safe publication of the HashMap instance.

>
> validateAnnotationMethod:
> the block: label and break block seems unnecessary. I'd not worry
> about optimizing for such invalid cases and simply run through all the
> checks and set valid = false multiple times if so be it.

I changed the method to a boolean-returning isValidAnnotationMethod() 
with multiple exit paths and moved throwing of AnnotationFormatError 
into AnnotationType constructor.

Here's all that applied together with comment from Chris:

http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/webrev.02/

plus more:

AnnotationInvocationHandler.equalsImpl()

- should check the number of values in both annotations and not the 
lengths of hash tables (hash table lengths are rounded to power of 2)
- exception handling when a foreign annotation throws an unchecked 
exception from it's member method - propagate it instead of returning 
"false" from equals

AnnotationInvocationHandler.asOneOfUs()

- enclose the Proxy.getInvocationHandler() in doPrivileged() if needed 
otherwise we can get SecurityException

AnnotationInvocationHandler.readObject()

- don't modify the Map instance read from stream as it might be shared 
or unmodifiable - clone it and modify it if necessary.

AnnotationParser:

- skip annotations for types that are not annotation types any more and 
propagate AnnotationFormatError for invalid annotation types.

AnnotationSupport.getValueArray()

- exception handling cleanup.

I just noticed this last thing will need another webrev and some 
discussion as handling of "oneOfUs" vs. "foreign" annotation is 
different currently. Should a RuntimeException (other than 
IncompleteAnnotationException) be propagated or wrapped with 
AnnotationFormatError? RuntimeException(s) are exceptions thrown by 
various ExceptionProxy(s) when retrieving annotation values that are 
somehow invalid.

Here's the diff between webrev.01 and 02 (without changes to the test):

http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/webrev.01to02/


Regards, Peter


>
> Thanks!
>
> /Claes
>
> On 2017-01-17 15:10, Peter Levart wrote:
>> Hi,
>>
>> This is a preview of a patch that addresses the following issue:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8029019
>>
>> But it is also an attempt to clean-up failure reporting for invalid
>> annotation types. Here's the 1st webrev:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/webrev.01/ 
>>
>>
>>
>> With this patch applied, running the following benchmark:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/AnnotationsBench.java 
>>
>>
>>
>> Produces the following results:
>>
>> Original:
>>
>> Benchmark                                 Mode  Cnt Score Error  Units
>> AnnotationsBench.a1_PrimitiveMember       avgt   10 20.790 ? 1.317  
>> ns/op
>> AnnotationsBench.a2_ObjectMember          avgt   10 21.550 ? 0.580  
>> ns/op
>> AnnotationsBench.a3_PrimitiveArrayMember  avgt   10 28.314 ? 1.477  
>> ns/op
>> AnnotationsBench.a4_ObjectArrayMember     avgt   10 27.094 ? 0.574  
>> ns/op
>> AnnotationsBench.a5_AnnotationType        avgt   10 13.047 ? 0.983  
>> ns/op
>> AnnotationsBench.a6_HashCode              avgt   10 158.001 ? 9.347
>> ns/op
>> AnnotationsBench.a7_Equals                avgt   10 663.921 ? 27.256
>> ns/op
>> AnnotationsBench.a8_ToString              avgt   10 1772.901 ? 107.355
>> ns/op
>>
>> Patched:
>>
>> Benchmark                                 Mode  Cnt Score Error  Units
>> AnnotationsBench.a1_PrimitiveMember       avgt   10 8.547 ? 0.100  ns/op
>> AnnotationsBench.a2_ObjectMember          avgt   10 8.352 ? 0.340  ns/op
>> AnnotationsBench.a3_PrimitiveArrayMember  avgt   10 17.526 ? 0.696  
>> ns/op
>> AnnotationsBench.a4_ObjectArrayMember     avgt   10 15.639 ? 0.116  
>> ns/op
>> AnnotationsBench.a5_AnnotationType        avgt   10 4.692 ? 0.154  ns/op
>> AnnotationsBench.a6_HashCode              avgt   10 142.954 ? 7.460  
>> ns/op
>> AnnotationsBench.a7_Equals                avgt   10 184.535 ? 0.917  
>> ns/op
>> AnnotationsBench.a8_ToString              avgt   10 1806.685 ? 96.370
>> ns/op
>>
>>
>> Allocation rates are also reduced:
>>
>> Original:
>>
>> AnnotationsBench.a1_PrimitiveMember:?gc.alloc.rate.norm avgt 10
>> 16.000 ?   0.001    B/op
>> AnnotationsBench.a2_ObjectMember:?gc.alloc.rate.norm avgt 10    16.000
>> ?   0.001    B/op
>> AnnotationsBench.a3_PrimitiveArrayMember:?gc.alloc.rate.norm avgt
>> 10    64.000 ?   0.001    B/op
>> AnnotationsBench.a4_ObjectArrayMember:?gc.alloc.rate.norm avgt 10
>> 48.000 ?   0.001    B/op
>> AnnotationsBench.a5_AnnotationType:?gc.alloc.rate.norm avgt   10
>> 16.000 ?   0.001    B/op
>> AnnotationsBench.a6_HashCode:?gc.alloc.rate.norm avgt   10 128.000 ?
>> 0.001    B/op
>> AnnotationsBench.a7_Equals:?gc.alloc.rate.norm avgt   10 120.001 ?
>> 0.001    B/op
>> AnnotationsBench.a8_ToString:?gc.alloc.rate.norm avgt   10 5200.002 ?
>> 0.001    B/op
>>
>> Patched:
>>
>> AnnotationsBench.a1_PrimitiveMember:?gc.alloc.rate.norm avgt 10    ?
>> 10??              B/op
>> AnnotationsBench.a2_ObjectMember:?gc.alloc.rate.norm avgt 10    ?
>> 10??              B/op
>> AnnotationsBench.a3_PrimitiveArrayMember:?gc.alloc.rate.norm avgt
>> 10    48.000 ?   0.001    B/op
>> AnnotationsBench.a4_ObjectArrayMember:?gc.alloc.rate.norm avgt 10
>> 32.000 ?   0.001    B/op
>> AnnotationsBench.a5_AnnotationType:?gc.alloc.rate.norm avgt 10    ?
>> 10??              B/op
>> AnnotationsBench.a6_HashCode:?gc.alloc.rate.norm avgt   10 64.000 ?
>> 0.001    B/op
>> AnnotationsBench.a7_Equals:?gc.alloc.rate.norm avgt   10 24.000 ?
>> 0.001    B/op
>> AnnotationsBench.a8_ToString:?gc.alloc.rate.norm avgt   10 5136.002 ?
>> 0.001    B/op
>>
>>
>> As for the failure reporting: requesting an annotation for invalid
>> annotation type now always produces AnnotationFormatError. Previously,
>> some invalid annotations were simply skipped, some produced
>> AnnotationFormatError and for some of them, AnnotationFormatError was
>> raised only when evaluating Annotation's equals() method.
>>
>> I would like to discuss this failure behavior more in-depth.
>>
>> Regards, Peter
>>


From paul.sandoz at oracle.com  Wed Jan 25 19:19:35 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 25 Jan 2017 11:19:35 -0800
Subject: RFR: 8173372 Add tests for multi-release module jar API validator
In-Reply-To: <386E1688-9264-47D3-A9AE-BABE00F1A254@oracle.com>
References: <386E1688-9264-47D3-A9AE-BABE00F1A254@oracle.com>
Message-ID: <03DA6876-2CCB-4BEB-9A47-8C09B8617FB7@oracle.com>


> On 25 Jan 2017, at 10:54, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
> 
> Hi,
> 
> I?ve added tests to check what MR Jar API validator handles changes in module-info.class
> 
> Review: http://cr.openjdk.java.net/~anazarov/8173372/webrev.01/webrev/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8173372
> 

Looks ok.


I think you can reduce some of the boiler plate by having before/after test methods:

Path root;
Path classes;

@BeforeMethod
void testInit(Method m) {
  root = Paths.get(method.getName());
  classes = root.resolve("classes");
}

@AfterMethod
void testCleanup() {
  FileUtils.deleteFileTreeWithRetry(root);
}


I dunno if your test methods really need to declare "throws Throwable?.

Paul.

From kumar.x.srinivasan at oracle.com  Wed Jan 25 19:32:49 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 25 Jan 2017 11:32:49 -0800
Subject: RFR: 8170832: Add a new launcher environment variable JAVA_OPTIONS
In-Reply-To: <E18D7570-2AE6-47BE-8143-4057376C1348@oracle.com>
References: <E18D7570-2AE6-47BE-8143-4057376C1348@oracle.com>
Message-ID: <5888FD61.8060400@oracle.com>


Hi Henry,

I was somewhat surprised to see changes to launcher_LANG.properties, I 
usually
make the change in the english/default locale and allow the L1ON team to 
make the
locale specific changes, but if you are confident of the changes, that 
is fine.

src/java.base/share/native/libjli/args.c

+        // Check if Main class specified after argument checked
+        // Must be after expansion so we can caught if main class specified @argfile


Is my interpretation accurate ? If so please reword it accordingly.
/*
  * Check if main-class is specified after argument being checked, it
  * must always appear after expansion,  as a  main-class specified in
  * an @argfile is not allowed, and it must be caught now.
  */

+        assert (*env == '\0' || isspace(*env));

asserts are not enable in product builds, is the intention only
for debug builds ? Should this be flagged as a warning or something
under tracing ?

src/java.base/windows/native/libjli/cmdtoargs.c

-    // iterate through rest of coammand line

+    // iterate through rest of command line


Thanks
Kumar



> Hi,
>
> Please review the webrev[1] that add support for JAVA_OPTIONS environment variable. The bug[2] describes how JAVA_OPTIONS works.
>
> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8170832/4/webrev/
> [2] https://bugs.openjdk.java.net/browse/JDK-8170832
>
> Cheers,
> Henry
>


From henry.jen at oracle.com  Wed Jan 25 20:14:38 2017
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 25 Jan 2017 12:14:38 -0800
Subject: RFR: 8170832: Add a new launcher environment variable JAVA_OPTIONS
In-Reply-To: <5888FD61.8060400@oracle.com>
References: <E18D7570-2AE6-47BE-8143-4057376C1348@oracle.com>
	<5888FD61.8060400@oracle.com>
Message-ID: <AFE7198C-85D6-462A-AFE8-FBA0F077990A@oracle.com>


> On Jan 25, 2017, at 11:32 AM, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
> 
> 
> Hi Henry,
> 
> I was somewhat surprised to see changes to launcher_LANG.properties, I usually
> make the change in the english/default locale and allow the L1ON team to make the
> locale specific changes, but if you are confident of the changes, that is fine.
> 
> src/java.base/share/native/libjli/args.c
> 
> +        // Check if Main class specified after argument checked
> +        // Must be after expansion so we can caught if main class specified @argfile
> 
> 
> Is my interpretation accurate ? If so please reword it accordingly.
> /*
> * Check if main-class is specified after argument being checked, it
> * must always appear after expansion,  as a  main-class specified in
> * an @argfile is not allowed, and it must be caught now.
> */

Not exactly, main-class or other terminal operation specified in the environment variable is not allowed, even if it is from @argfile.
However, @argfile directly on command line has no such limitations. I?ll update accordingly.

> 
> +        assert (*env == '\0' || isspace(*env));
> 
> asserts are not enable in product builds, is the intention only
> for debug builds ? Should this be flagged as a warning or something
> under tracing ?
> 

Yes, that?s what should happen if the code if implemented correctly regardless the input.

> src/java.base/windows/native/libjli/cmdtoargs.c
> 
> -    // iterate through rest of coammand line
> 
> +    // iterate through rest of command line
> 

Fixed.

Cheers,
Henry


From henry.jen at oracle.com  Wed Jan 25 20:58:45 2017
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 25 Jan 2017 12:58:45 -0800
Subject: Updated RFR: 8170832: Add a new launcher environment variable
	JAVA_OPTIONS
In-Reply-To: <AFE7198C-85D6-462A-AFE8-FBA0F077990A@oracle.com>
References: <E18D7570-2AE6-47BE-8143-4057376C1348@oracle.com>
	<5888FD61.8060400@oracle.com>
	<AFE7198C-85D6-462A-AFE8-FBA0F077990A@oracle.com>
Message-ID: <DF6CFEC8-B00C-40E5-9232-7266C6A34258@oracle.com>


> On Jan 25, 2017, at 12:14 PM, Henry Jen <henry.jen at oracle.com> wrote:
> 
> 
>> On Jan 25, 2017, at 11:32 AM, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
>> 
>> 
>> Hi Henry,
>> 
>> I was somewhat surprised to see changes to launcher_LANG.properties, I usually
>> make the change in the english/default locale and allow the L1ON team to make the
>> locale specific changes, but if you are confident of the changes, that is fine.

I just ordering the sentence, it has slim chance to screw up. :)
Anyhow, if L10N team is monitoring the chance, they should double check.

Updated webrev address feedbacks so far can be found at 
http://cr.openjdk.java.net/~henryjen/jdk9/8170832/5/webrev/

Cheers,
Henry


From kumar.x.srinivasan at oracle.com  Wed Jan 25 21:03:08 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 25 Jan 2017 13:03:08 -0800
Subject: Updated RFR: 8170832: Add a new launcher environment variable
	JAVA_OPTIONS
In-Reply-To: <DF6CFEC8-B00C-40E5-9232-7266C6A34258@oracle.com>
References: <E18D7570-2AE6-47BE-8143-4057376C1348@oracle.com>
	<5888FD61.8060400@oracle.com>
	<AFE7198C-85D6-462A-AFE8-FBA0F077990A@oracle.com>
	<DF6CFEC8-B00C-40E5-9232-7266C6A34258@oracle.com>
Message-ID: <5889128C.80207@oracle.com>


Thanks Henry, Looks good!.

Kumar

>> On Jan 25, 2017, at 12:14 PM, Henry Jen <henry.jen at oracle.com> wrote:
>>
>>
>>> On Jan 25, 2017, at 11:32 AM, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
>>>
>>>
>>> Hi Henry,
>>>
>>> I was somewhat surprised to see changes to launcher_LANG.properties, I usually
>>> make the change in the english/default locale and allow the L1ON team to make the
>>> locale specific changes, but if you are confident of the changes, that is fine.
> I just ordering the sentence, it has slim chance to screw up. :)
> Anyhow, if L10N team is monitoring the chance, they should double check.
>
> Updated webrev address feedbacks so far can be found at
> http://cr.openjdk.java.net/~henryjen/jdk9/8170832/5/webrev/
>
> Cheers,
> Henry
>


From henry.jen at oracle.com  Wed Jan 25 21:23:51 2017
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 25 Jan 2017 13:23:51 -0800
Subject: RFR: 8172309: classpath wildcards code does not support --class-path
Message-ID: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com>

Hi,

Please review the webrev[1], the fix is to ensure ?class-path and ?class-path= is processed correctly to expand wildcard. Changes are made in jdk repo. However, test case to verify the bug fix is in langtool repo.

Cheers,
Henry

[1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/
[2] https://bugs.openjdk.java.net/browse/JDK-8172309

From mandy.chung at oracle.com  Thu Jan 26 00:21:43 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 25 Jan 2017 16:21:43 -0800
Subject: Updated RFR: 8170832: Add a new launcher environment variable
	JAVA_OPTIONS
In-Reply-To: <DF6CFEC8-B00C-40E5-9232-7266C6A34258@oracle.com>
References: <E18D7570-2AE6-47BE-8143-4057376C1348@oracle.com>
	<5888FD61.8060400@oracle.com>
	<AFE7198C-85D6-462A-AFE8-FBA0F077990A@oracle.com>
	<DF6CFEC8-B00C-40E5-9232-7266C6A34258@oracle.com>
Message-ID: <546F4AEE-5B78-499B-B825-E7B2654E5760@oracle.com>


> On Jan 25, 2017, at 12:58 PM, Henry Jen <henry.jen at oracle.com> wrote:
> 
> Updated webrev address feedbacks so far can be found at 
> http://cr.openjdk.java.net/~henryjen/jdk9/8170832/5/webrev/

Looks good.

thanks
Mandy


From rob.mckenna at oracle.com  Thu Jan 26 04:03:27 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 26 Jan 2017 04:03:27 +0000
Subject: [RFR] 8160768: Add capability to custom resolve host/domain
	names within the default JDNI LDAP provider
In-Reply-To: <f81eb731-358e-a680-0788-05230af9ce07@oracle.com>
References: <20170125163141.GB3628@tecra> <20170125174453.GE3628@tecra>
	<f81eb731-358e-a680-0788-05230af9ce07@oracle.com>
Message-ID: <20170126040326.GA3544@vimes>

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 daniel.fuchs at oracle.com  Thu Jan 26 11:29:36 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 26 Jan 2017 11:29:36 +0000
Subject: [JAXP] RFR: 8173260: CatalogManager.catalogResolver should not fail
	when non-existing URI is passed to it
Message-ID: <178293d7-134d-0a8a-3abd-3b084bee84ff@oracle.com>

Hi,

Please find below a fix for

8173260: CatalogManager.catalogResolver should not fail
          when non-existing URI is passed to it
https://bugs.openjdk.java.net/browse/JDK-8173260

The specification for CatalogManager.catalogResolver and
CatalogManager.catalog says that invalid catalog entries
will be ignored.

However, this is not what happens when a catalog is created
with an URI that points to a file (or jar) which does not exist.
In that case, instead of ignoring the catalog entry,
an IllegalArgumentException is thrown, even if the URL itself is
valid.

This fix proposes to simply remove the special case that
the implementation makes for file or jar URLs.

test/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java
is updated to reflect this change.

http://cr.openjdk.java.net/~dfuchs/webrev_8173260/webrev.01/

best regards,

-- daniel

From Alan.Bateman at oracle.com  Thu Jan 26 11:35:07 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Jan 2017 11:35:07 +0000
Subject: [JAXP] RFR: 8173260: CatalogManager.catalogResolver should not
	fail when non-existing URI is passed to it
In-Reply-To: <178293d7-134d-0a8a-3abd-3b084bee84ff@oracle.com>
References: <178293d7-134d-0a8a-3abd-3b084bee84ff@oracle.com>
Message-ID: <67cd7085-f8d0-1ca7-52be-c8dcdfc3026d@oracle.com>

On 26/01/2017 11:29, Daniel Fuchs wrote:

> :
>
> This fix proposes to simply remove the special case that
> the implementation makes for file or jar URLs.
>
> test/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java
> is updated to reflect this change.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8173260/webrev.01/
I think this looks right, it's not clear why this was implemented to 
special case file URIs.

-Alan.

From andrey.x.nazarov at oracle.com  Thu Jan 26 11:56:14 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Thu, 26 Jan 2017 14:56:14 +0300
Subject: RFR: 8173372 Add tests for multi-release module jar API validator
In-Reply-To: <03DA6876-2CCB-4BEB-9A47-8C09B8617FB7@oracle.com>
References: <386E1688-9264-47D3-A9AE-BABE00F1A254@oracle.com>
	<03DA6876-2CCB-4BEB-9A47-8C09B8617FB7@oracle.com>
Message-ID: <499B8738-1ADA-4E10-9160-9E4167D750A8@oracle.com>

Thank you
> On 25 Jan 2017, at 22:19, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 
>> On 25 Jan 2017, at 10:54, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
>> 
>> Hi,
>> 
>> I?ve added tests to check what MR Jar API validator handles changes in module-info.class
>> 
>> Review: http://cr.openjdk.java.net/~anazarov/8173372/webrev.01/webrev/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8173372
>> 
> 
> Looks ok.
> 
> 
> I think you can reduce some of the boiler plate by having before/after test methods:
> 
> Path root;
> Path classes;
> 
> @BeforeMethod
> void testInit(Method m) {
>  root = Paths.get(method.getName());
>  classes = root.resolve("classes");
> }
> 
> @AfterMethod
> void testCleanup() {
>  FileUtils.deleteFileTreeWithRetry(root);
> }
> 
> 
> I dunno if your test methods really need to declare "throws Throwable?.
> 
> Paul.


From lance.andersen at oracle.com  Thu Jan 26 14:03:22 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 26 Jan 2017 09:03:22 -0500
Subject: [JAXP] RFR: 8173260: CatalogManager.catalogResolver should not
	fail when non-existing URI is passed to it
In-Reply-To: <178293d7-134d-0a8a-3abd-3b084bee84ff@oracle.com>
References: <178293d7-134d-0a8a-3abd-3b084bee84ff@oracle.com>
Message-ID: <BC459DD7-893E-43BF-81F2-A89B09025150@oracle.com>

+1
> On Jan 26, 2017, at 6:29 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a fix for
> 
> 8173260: CatalogManager.catalogResolver should not fail
>         when non-existing URI is passed to it
> https://bugs.openjdk.java.net/browse/JDK-8173260
> 
> The specification for CatalogManager.catalogResolver and
> CatalogManager.catalog says that invalid catalog entries
> will be ignored.
> 
> However, this is not what happens when a catalog is created
> with an URI that points to a file (or jar) which does not exist.
> In that case, instead of ignoring the catalog entry,
> an IllegalArgumentException is thrown, even if the URL itself is
> valid.
> 
> This fix proposes to simply remove the special case that
> the implementation makes for file or jar URLs.
> 
> test/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java
> is updated to reflect this change.
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8173260/webrev.01/
> 
> best regards,
> 
> -- daniel

 <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 andrey.x.nazarov at oracle.com  Thu Jan 26 14:25:17 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Thu, 26 Jan 2017 17:25:17 +0300
Subject: RFR: Problemlist tools/jar/multiRelease/ApiValidatorTest.java
Message-ID: <64862BA2-A26A-45B5-BF4F-149FF02D6539@oracle.com>


diff -r f5f50c8d8714 test/ProblemList.txt
--- a/test/ProblemList.txt	Thu Jan 26 14:32:41 2017 +0300
+++ b/test/ProblemList.txt	Thu Jan 26 17:17:02 2017 +0300
@@ -264,6 +264,8 @@

 tools/jlink/CustomPluginTest.java                               8172864 generic-all

+tools/jar/multiRelease/ApiValidatorTest.java                    8173396 generic-all
+
 ############################################################################

 # jdk_jdi

?Andrey

From paul.sandoz at oracle.com  Thu Jan 26 16:27:04 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 26 Jan 2017 08:27:04 -0800
Subject: RFR: Problemlist tools/jar/multiRelease/ApiValidatorTest.java
In-Reply-To: <64862BA2-A26A-45B5-BF4F-149FF02D6539@oracle.com>
References: <64862BA2-A26A-45B5-BF4F-149FF02D6539@oracle.com>
Message-ID: <78F0AA58-B733-44FB-AA49-EF3B76963D42@oracle.com>

Hi Andrey,

You need an issue for any change, even to the problem list. And can you provide an explanation?

Recently you updated ApiValidatorTest.java

  8173372 Add tests for multi-release module jar API validator

Did something happen between you writing/running this test locally and pushing?

Paul.

> On 26 Jan 2017, at 06:25, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
> 
> 
> diff -r f5f50c8d8714 test/ProblemList.txt
> --- a/test/ProblemList.txt	Thu Jan 26 14:32:41 2017 +0300
> +++ b/test/ProblemList.txt	Thu Jan 26 17:17:02 2017 +0300
> @@ -264,6 +264,8 @@
> 
> tools/jlink/CustomPluginTest.java                               8172864 generic-all
> 
> +tools/jar/multiRelease/ApiValidatorTest.java                    8173396 generic-all
> +
> ############################################################################
> 
> # jdk_jdi
> 
> ?Andrey


From andrey.x.nazarov at oracle.com  Thu Jan 26 16:41:40 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Thu, 26 Jan 2017 19:41:40 +0300
Subject: RFR: Problemlist tools/jar/multiRelease/ApiValidatorTest.java
In-Reply-To: <78F0AA58-B733-44FB-AA49-EF3B76963D42@oracle.com>
References: <64862BA2-A26A-45B5-BF4F-149FF02D6539@oracle.com>
	<78F0AA58-B733-44FB-AA49-EF3B76963D42@oracle.com>
Message-ID: <4E042695-616A-4703-8996-5FA57BF0ED64@oracle.com>

Hi, Paul

It tested agains a bit outdated java version. It was ok.
After push I've realised there is regression in product. https://bugs.openjdk.java.net/browse/JDK-8173396

Issue to problemlist https://bugs.openjdk.java.net/browse/JDK-8173395

?Andrey
> On 26 Jan 2017, at 19:27, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi Andrey,
> 
> You need an issue for any change, even to the problem list. And can you provide an explanation?
> 
> Recently you updated ApiValidatorTest.java
> 
>  8173372 Add tests for multi-release module jar API validator
> 
> Did something happen between you writing/running this test locally and pushing?
> 
> Paul.
> 
>> On 26 Jan 2017, at 06:25, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
>> 
>> 
>> diff -r f5f50c8d8714 test/ProblemList.txt
>> --- a/test/ProblemList.txt	Thu Jan 26 14:32:41 2017 +0300
>> +++ b/test/ProblemList.txt	Thu Jan 26 17:17:02 2017 +0300
>> @@ -264,6 +264,8 @@
>> 
>> tools/jlink/CustomPluginTest.java                               8172864 generic-all
>> 
>> +tools/jar/multiRelease/ApiValidatorTest.java                    8173396 generic-all
>> +
>> ############################################################################
>> 
>> # jdk_jdi
>> 
>> ?Andrey
> 


From andrey.x.nazarov at oracle.com  Thu Jan 26 16:57:47 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Thu, 26 Jan 2017 19:57:47 +0300
Subject: RFR: Problemlist tools/jar/multiRelease/ApiValidatorTest.java
In-Reply-To: <4E042695-616A-4703-8996-5FA57BF0ED64@oracle.com>
References: <64862BA2-A26A-45B5-BF4F-149FF02D6539@oracle.com>
	<78F0AA58-B733-44FB-AA49-EF3B76963D42@oracle.com>
	<4E042695-616A-4703-8996-5FA57BF0ED64@oracle.com>
Message-ID: <33D4F2FB-5FC9-48EA-B314-F4FE4425E7F3@oracle.com>

This commit leads to regression http://hg.openjdk.java.net/jdk9/dev/jdk/rev/dfba4c3eb1ac#l4.31
> On 26 Jan 2017, at 19:41, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
> 
> Hi, Paul
> 
> It tested agains a bit outdated java version. It was ok.
> After push I've realised there is regression in product. https://bugs.openjdk.java.net/browse/JDK-8173396
> 
> Issue to problemlist https://bugs.openjdk.java.net/browse/JDK-8173395
> 
> ?Andrey
>> On 26 Jan 2017, at 19:27, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>> Hi Andrey,
>> 
>> You need an issue for any change, even to the problem list. And can you provide an explanation?
>> 
>> Recently you updated ApiValidatorTest.java
>> 
>> 8173372 Add tests for multi-release module jar API validator
>> 
>> Did something happen between you writing/running this test locally and pushing?
>> 
>> Paul.
>> 
>>> On 26 Jan 2017, at 06:25, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
>>> 
>>> 
>>> diff -r f5f50c8d8714 test/ProblemList.txt
>>> --- a/test/ProblemList.txt	Thu Jan 26 14:32:41 2017 +0300
>>> +++ b/test/ProblemList.txt	Thu Jan 26 17:17:02 2017 +0300
>>> @@ -264,6 +264,8 @@
>>> 
>>> tools/jlink/CustomPluginTest.java                               8172864 generic-all
>>> 
>>> +tools/jar/multiRelease/ApiValidatorTest.java                    8173396 generic-all
>>> +
>>> ############################################################################
>>> 
>>> # jdk_jdi
>>> 
>>> ?Andrey
>> 
> 


From paul.sandoz at oracle.com  Thu Jan 26 17:37:23 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 26 Jan 2017 09:37:23 -0800
Subject: RFR: Problemlist tools/jar/multiRelease/ApiValidatorTest.java
In-Reply-To: <33D4F2FB-5FC9-48EA-B314-F4FE4425E7F3@oracle.com>
References: <64862BA2-A26A-45B5-BF4F-149FF02D6539@oracle.com>
	<78F0AA58-B733-44FB-AA49-EF3B76963D42@oracle.com>
	<4E042695-616A-4703-8996-5FA57BF0ED64@oracle.com>
	<33D4F2FB-5FC9-48EA-B314-F4FE4425E7F3@oracle.com>
Message-ID: <55A883CF-060A-4CD7-BB84-AF0D5E1B4A50@oracle.com>


> On 26 Jan 2017, at 08:57, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
> 
> This commit leads to regression http://hg.openjdk.java.net/jdk9/dev/jdk/rev/dfba4c3eb1ac#l4.31 <http://hg.openjdk.java.net/jdk9/dev/jdk/rev/dfba4c3eb1ac#l4.31>

Thanks for searching and finding this,
Paul.

>> On 26 Jan 2017, at 19:41, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
>> 
>> Hi, Paul
>> 
>> It tested agains a bit outdated java version. It was ok.
>> After push I've realised there is regression in product. https://bugs.openjdk.java.net/browse/JDK-8173396
>> 
>> Issue to problemlist https://bugs.openjdk.java.net/browse/JDK-8173395
>> 

From andrey.x.nazarov at oracle.com  Thu Jan 26 18:29:47 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Thu, 26 Jan 2017 21:29:47 +0300
Subject: RFR: 8075617, 8075616 Create tests to check wsgen, schemagen work
	with multi-version jar
In-Reply-To: <D0BAB791-CBE0-4BFA-928E-A7405860BE18@oracle.com>
References: <CBABED4B-B8A2-4A80-9BD2-8039A055F5AD@oracle.com>
	<86914c18-9d41-6778-4a4d-66acff3442ac@oracle.com>
	<FADC68EB-89AF-4CCA-AEE2-EBF55212D3FC@oracle.com>
	<ff92bd6a-559e-6206-0e23-5d141a4441cf@oracle.com>
	<D0BAB791-CBE0-4BFA-928E-A7405860BE18@oracle.com>
Message-ID: <75C6ACF3-28E8-4475-B871-049601D1FE79@oracle.com>

Hi
Move tests to new place. Please review.
http://cr.openjdk.java.net/~anazarov/8075617/webrev.01/webrev/ <http://cr.openjdk.java.net/~anazarov/8075617/webrev.01/webrev/>

?Andrey
> On 25 Jan 2017, at 19:04, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
> 
> 
>> On 25 Jan 2017, at 19:00, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> On 25/01/2017 15:25, Andrey Nazarov wrote:
>> 
>>> :
>>> What is the right location?
>> These tools are maintained in the upstream Metro project, I suspect the tests for these tools are located there too but I'm not sure. There are handful of JAXB and JAX-WS tests in the jdk repo but I don't think they directly test the tools. So I think you'll need a new location for these, assuming you really want these in the jdk repo.
> Is it Ok to use jdk/test/tools/jaxws ? Tools directory already contains tests for jjs for example.
>> 
>> -Alan
> 


From kumar.x.srinivasan at oracle.com  Thu Jan 26 22:31:10 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 26 Jan 2017 14:31:10 -0800
Subject: RFR: 8172309: classpath wildcards code does not support
	--class-path
In-Reply-To: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com>
References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com>
Message-ID: <588A78AE.9020101@oracle.com>


Hi Henry,

Looks ok to me. Thanks for making this change.

Kumar

> Hi,
>
> Please review the webrev[1], the fix is to ensure ?class-path and ?class-path= is processed correctly to expand wildcard. Changes are made in jdk repo. However, test case to verify the bug fix is in langtool repo.
>
> Cheers,
> Henry
>
> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/
> [2] https://bugs.openjdk.java.net/browse/JDK-8172309


From jonathan.gibbons at oracle.com  Fri Jan 27 00:09:25 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 26 Jan 2017 16:09:25 -0800
Subject: RFR: 8172309: classpath wildcards code does not support
	--class-path
In-Reply-To: <588A78AE.9020101@oracle.com>
References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com>
	<588A78AE.9020101@oracle.com>
Message-ID: <588A8FB5.5020601@oracle.com>

Henry,

You've changed old test cases into new test cases, thereby eliminating 
the old cases, which is not so good.

You should be adding new test cases, but changing old ones.

-- Jon


On 01/26/2017 02:31 PM, Kumar Srinivasan wrote:
>
> Hi Henry,
>
> Looks ok to me. Thanks for making this change.
>
> Kumar
>
>> Hi,
>>
>> Please review the webrev[1], the fix is to ensure ?class-path and 
>> ?class-path= is processed correctly to expand wildcard. Changes are 
>> made in jdk repo. However, test case to verify the bug fix is in 
>> langtool repo.
>>
>> Cheers,
>> Henry
>>
>> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8172309
>


From brent.christian at oracle.com  Fri Jan 27 01:07:09 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 26 Jan 2017 17:07:09 -0800
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are
	incorrect (updated)
In-Reply-To: <06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
References: <57B4C392.4060001@oracle.com>
	<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
	<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
	<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
Message-ID: <588A9D3D.1040200@oracle.com>

Hi,

Please review my updated approach for fixing 8156073 ("2-slot
LiveStackFrame locals (long and double) are incorrect") in the 
experimental portion of the StackWalker API, added in JDK 9.

Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/

(For reference, the earlier RFR thread is here:[1].)

We've concluded that we can't get enough primitive type info from the VM 
to use the current fine-grain *Primitive classes in LiveStackFrameInfo, 
so those classes have been removed for now.  I've simplified down to 
just a PrimitiveSlot32 for 32-bit VMs, and PrimitiveSlot64 for 64-bit VMs.

We also do not attempt to interpret a primitive's type based on the 
slot's contents, and instead return the slot's full contents for every 
primitive local.  This more accurately reflects the underlying layout of 
locals in the VM (versus the previous proposed 
LiveStackFrame.getLocals() behavior of having 64-bit behave like 32-bit 
by splitting long/double values into two slots).  On the 64-bit VM, this 
returns 64-bits even for primitive local variables smaller than 64-bits 
(int, etc).

The upshot is that we now return the entire value for longs/doubles on 
64-bit VMs.  (The current JDK 9 only reads the first 32-bits.)

I also now indicate in LiveStackFrameInfo.toString() if the frame is 
interpreted or compiled.

On the testing front:
In the interest of simplifying LiveStackFrame testing down into a single 
test file under jdk/test/, I chose not to add the additional test case 
from Fabio Tudone [2,3] (thanks, Fabio!), but instead incorporated some 
of those testing ideas into the existing test.  Testing is a bit relaxed 
versus the previously proposed test case; in particular it does not 
enforce endianness.

I also removed the more simplistic CountLocalSlots.java test, given that 
the updated LocalsAndOperands.java will now better cover testing -Xcomp. 
  On the hotspot side, I had to update the 8163014 regtest.

Automated test runs have looked fine so far.

Thanks,
-Brent

1. 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042979.html
2. 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041666.html
3. https://bugs.openjdk.java.net/browse/JDK-8158879



From henry.jen at oracle.com  Fri Jan 27 02:01:12 2017
From: henry.jen at oracle.com (Henry Jen)
Date: Thu, 26 Jan 2017 18:01:12 -0800
Subject: RFR: 8172309: classpath wildcards code does not support
	--class-path
In-Reply-To: <588A8FB5.5020601@oracle.com>
References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com>
	<588A78AE.9020101@oracle.com> <588A8FB5.5020601@oracle.com>
Message-ID: <A4E26709-1275-44E6-82EA-B92DBD7DFA37@oracle.com>

> On Jan 26, 2017, at 4:09 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> Henry,
> 
> You've changed old test cases into new test cases, thereby eliminating the old cases, which is not so good.
> 
> You should be adding new test cases, but changing old ones.
> 

I am not sure, I believe all wild-card cases still tested, just that we have different variety of calling -cp. Of course, it would be nice to test all cases with all 4 flavors of -cp, but I don?t think that?s necessary as I think the test coverage is the same.

Anyway, I could be wrong. If you feel strong about this, I can redo it. But that may takes more time to digest what the test cases are really for.

Cheers,
Henry


> -- Jon
> 
> 
> On 01/26/2017 02:31 PM, Kumar Srinivasan wrote:
>> 
>> Hi Henry,
>> 
>> Looks ok to me. Thanks for making this change.
>> 
>> Kumar
>> 
>>> Hi,
>>> 
>>> Please review the webrev[1], the fix is to ensure ?class-path and ?class-path= is processed correctly to expand wildcard. Changes are made in jdk repo. However, test case to verify the bug fix is in langtool repo.
>>> 
>>> Cheers,
>>> Henry
>>> 
>>> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8172309
>> 
> 


From xueming.shen at oracle.com  Fri Jan 27 06:58:11 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 26 Jan 2017 22:58:11 -0800
Subject: RFR JDK-8173396:Error message issue with jar tool API validator
Message-ID: <588AEF83.1090207@oracle.com>

Hi,

Please review the change for JDK-8173396.

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

The error message keys "error.versioned.xxxx" were renamed to 
error.validator.xxxx
in all resource properties files but several use site rename/change was 
missed in
method checkModuleDescriptor().

Sherman


From forax at univ-mlv.fr  Fri Jan 27 10:19:34 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 27 Jan 2017 11:19:34 +0100 (CET)
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double)
	are	incorrect (updated)
In-Reply-To: <588A9D3D.1040200@oracle.com>
References: <57B4C392.4060001@oracle.com>
	<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
	<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
	<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
	<588A9D3D.1040200@oracle.com>
Message-ID: <784291281.1854428.1485512374424.JavaMail.zimbra@u-pem.fr>

Hi Brent,
in LiveStackFrame, PrimitiveSlot.size() should be public.
The other solution is to see PrimitiveValue as a technical factorisation of code, not something users should know, so it should be a public class but a package-private abstract class and PrimitiveSlot32/PrimitiveSlot64 should be public (so you can try to make them value types in 10).

in LiveStackFrameInfo, the two flags MODE_* are not declared final.

cheers,
R?mi

----- Mail original -----
> De: "Brent Christian" <brent.christian at oracle.com>
> ?: "hotspot-dev" <hotspot-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Cc: "Fabio Tudone (fabio at paralleluniverse.co)" <fabio at paralleluniverse.co>
> Envoy?: Vendredi 27 Janvier 2017 02:07:09
> Objet: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are	incorrect (updated)

> Hi,
> 
> Please review my updated approach for fixing 8156073 ("2-slot
> LiveStackFrame locals (long and double) are incorrect") in the
> experimental portion of the StackWalker API, added in JDK 9.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
> 
> (For reference, the earlier RFR thread is here:[1].)
> 
> We've concluded that we can't get enough primitive type info from the VM
> to use the current fine-grain *Primitive classes in LiveStackFrameInfo,
> so those classes have been removed for now.  I've simplified down to
> just a PrimitiveSlot32 for 32-bit VMs, and PrimitiveSlot64 for 64-bit VMs.
> 
> We also do not attempt to interpret a primitive's type based on the
> slot's contents, and instead return the slot's full contents for every
> primitive local.  This more accurately reflects the underlying layout of
> locals in the VM (versus the previous proposed
> LiveStackFrame.getLocals() behavior of having 64-bit behave like 32-bit
> by splitting long/double values into two slots).  On the 64-bit VM, this
> returns 64-bits even for primitive local variables smaller than 64-bits
> (int, etc).
> 
> The upshot is that we now return the entire value for longs/doubles on
> 64-bit VMs.  (The current JDK 9 only reads the first 32-bits.)
> 
> I also now indicate in LiveStackFrameInfo.toString() if the frame is
> interpreted or compiled.
> 
> On the testing front:
> In the interest of simplifying LiveStackFrame testing down into a single
> test file under jdk/test/, I chose not to add the additional test case
> from Fabio Tudone [2,3] (thanks, Fabio!), but instead incorporated some
> of those testing ideas into the existing test.  Testing is a bit relaxed
> versus the previously proposed test case; in particular it does not
> enforce endianness.
> 
> I also removed the more simplistic CountLocalSlots.java test, given that
> the updated LocalsAndOperands.java will now better cover testing -Xcomp.
>  On the hotspot side, I had to update the 8163014 regtest.
> 
> Automated test runs have looked fine so far.
> 
> Thanks,
> -Brent
> 
> 1.
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042979.html
> 2.
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041666.html
> 3. https://bugs.openjdk.java.net/browse/JDK-8158879

From ramanand.patil at oracle.com  Fri Jan 27 12:52:00 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Fri, 27 Jan 2017 04:52:00 -0800 (PST)
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
In-Reply-To: <5888CB80.6050107@oracle.com>
References: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>
	<07c4c8b9-695b-6ba8-2cf8-09423e467379@oracle.com>
	<18089cd3-4cfb-4e55-b02b-e11cb637daa9@default>
	<58867365.5070608@oracle.com>
	<cdafe37b-7d8a-46a0-ac89-1c013764a030@default>
	<5888CB80.6050107@oracle.com>
Message-ID: <065eab06-3a3b-4a6a-8cbe-c892f5017ece@default>

Thank you Alan and Kumar for your review.
Here is the updated webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.03

Changes done:
1. LinkageError in method loadMainClass is handled separately and with a new message in launcher.properties
2. Test case updated to print the error message(even when test passes) and to print the final test result message as suggested by Kumar.


Regards,
Ramanand.

-----Original Message-----
From: Kumar Srinivasan 
Sent: Wednesday, January 25, 2017 9:30 PM
To: Ramanand Patil <ramanand.patil at oracle.com>
Cc: Alan Bateman <alan.bateman at oracle.com>; core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized

  116         if (result.isOK()) {
  117             throw new Exception("Test Passed Unexpectedly!");
  118         } else if (result.contains("JNI error")) {
  119             result.testOutput.forEach(System.err::println);
  120             throw new Exception("Test Failed with JNI error!");
  121         }
  + 122  System.out.println("Test passes, failed with expected error message");

As a sanity I would add the above. This will make it clear to someone trying to triage an error.

Kumar

On 1/25/2017 2:10 AM, Ramanand Patil wrote:
> Hi Kumar,
> Thank you for the review and suggestions for the test case.
> Here is the updated Webrev: 
> http://cr.openjdk.java.net/~rpatil/8167063/webrev.02/
>
>
> Regards,
> Ramanand.
>
> -----Original Message-----
> From: Kumar Srinivasan
> Sent: Tuesday, January 24, 2017 2:50 AM
> To: Ramanand Patil <ramanand.patil at oracle.com>
> Cc: Alan Bateman <alan.bateman at oracle.com>; core-libs-dev 
> <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: 8167063: spurious message "A JNI error has occurred" 
> if start-class cannot be initialized
>
>
> Hi Ramanand,
> test/tools/launcher/LauncherMessageTest.java
>
> 1)
>
> 116         String[] commands = {"java", "--module-path", modules.getPath(),
> 117             "-m", "mod.b/pkgB.ClassB"};
>
> The execution PATH may or may not contain the JAVA_HOME_UNDER_TEST/bin, so the right "java" may not be picked up,  suggest using the TestHelper's javaCmd field that will be set correctly.
> Used TestHelper.javaCmd for instead of "java"
>
> 2)
>
>    122         if (!result.isOK() && result.contains("JNI error")) {
>    123             result.testOutput.forEach(System.err::println);
>    124             throw new RuntimeException("Test Failed with JNI error!");
>    125         } else {
>    126             System.out.println("Test Passed...");
>    127         }
>
> The problem with 122 if it the test returns back with non-zero code, it will still fail with "Test Failed with JNI error", I prefer it to be broken up and return back the right message ie. if the test returns with non-zero code say that.
> Changed the way test results were checked to include the check for unexpected failure when result is not non-zero.(i.e. when isOK() returns true).
> 3)
> Also usage of RuntimeException is over the top, you can simply throw an Exception and have the main throws Exception, jtreg will do the needful.
> Changed. Used an Exception instead of RuntimeException
>
> 4)
>
>    102         FileUtils.deleteFileWithRetry(Paths.get(modules.getPath() + File.separator + "mod.a.jar"));
>
> there are redundant use of File.separator, Paths.get should create the 
> FS correctly on the target platform
> ex: Paths.get(modules.getPath(), "mod.a.jar");
>
> Personally I stay away from using raw File.separator, instead have the APIs do the work for me.
>
> -Removed all instances of File.separator
>
>
> Kumar
>
>
>> Hi Alan,
>> Thank you for the review.
>> My comments are inline and Webrev is updated here:
>> http://cr.openjdk.java.net/~rpatil/8167063/webrev.01/
>>
>> Change Summary:
>> - Removed SecurityException handling
>> - Updated the error message in launcher.properties
>> - Removed loadModuleMainClass0 method and moved the code back into 
>> original loadModuleMainClass
>> - NoClassDefFoundError is replaced by its parent class LinkageError 
>> in method loadMainClass
>>
>> Regards,
>> Ramanand.
>>
>> -----Original Message-----
>> From: Alan Bateman
>> Sent: Friday, January 20, 2017 8:03 PM
>> To: Ramanand Patil <ramanand.patil at oracle.com>; 
>> core-libs-dev at openjdk.java.net
>> Subject: Re: RFR: 8167063: spurious message "A JNI error has occurred"
>> if start-class cannot be initialized
>>
>> On 20/01/2017 13:21, Ramanand Patil wrote:
>>
>>> Hi all,
>>> Please review the following bug fix:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8167063
>>> Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.00/
>>>
>>> Handled the SecurityException and LinkageError which can be thrown from Class.forName(...) method used in LauncherHelper.java and added corresponding error messages to launcher.properties.
>>> Though the reported bug is because of the LinkageError, Security exception is also handled to be safe from calling Class.forName method.
>>>
>> I see this changes loadMainClass to abort with resources that are keyed on java.launcher.cls.error6 and java.launcher.cls.error7 but they don't appear in the launcher.properties file. Does this work? I would assume MissingResourceException is thrown.
>> Thanks for pointing this. I missed to add it to launcher.properties. But now I have changed error6 to point to java.launcher.cls.error1 and removed security exception handling.
>>
>> For java.launcher.module.error3 and java.launcher.module.error4 then "link" is likely to confuse people. Sure, there may be linkage errors but there are many linkage errors and I think would be a lot clearer if the message was "Unable to load main class {0} from module {1}\n\{2}".
>> Updated the message as suggested.
>>
>> It's not clear to me that having a different message for security exceptions make sense, esp. when the exception is printed. So I think I would drop that.
>> Yes, I agree to drop out the Security exceptions handling.
>>
>> Also loadModuleMainClass0 is unusual method name, we've mostly (not
>> always) used the 0 suffix on native methods. In any case, it doesn't look like it is needed, the code was okay in loadModuleMainClass as it was.
>> The method was added just to look the exception handling easier. I have removed the extra method and placed the code back into loadModuleMainClass.
>>
>> One final point is that is the nesting catching of LinkageError and SecurityException in loadMainClass, I assume you don't need the inner catch.
>> I think both the catch blocks were needed, because the first(inner) catch was already inside catch.(This was same as NoClassDefFoundError catching twice in the same method). Now since NoClassDefFoundError is subclass of LinkageError, I have replaced it with LinkageError. And  I think still the same abort message holds good. Please let me know if this is ok.
>>
>> -Alan


From mandy.chung at oracle.com  Fri Jan 27 16:26:56 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 27 Jan 2017 08:26:56 -0800
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are
	incorrect (updated)
In-Reply-To: <588A9D3D.1040200@oracle.com>
References: <57B4C392.4060001@oracle.com>
	<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
	<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
	<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
	<588A9D3D.1040200@oracle.com>
Message-ID: <CEA0DB3E-AC24-4B37-8252-9E95E54CA2B3@oracle.com>


> On Jan 26, 2017, at 5:07 PM, Brent Christian <brent.christian at oracle.com> wrote:
> 
> Hi,
> 
> Please review my updated approach for fixing 8156073 ("2-slot
> LiveStackFrame locals (long and double) are incorrect") in the experimental portion of the StackWalker API, added in JDK 9.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/

3734     element->int_field_put(_mode_offset, value);

hotspot code uses 2-space indentation

stackwalk.hpp
  line 96 - extra line can be removed.

I agree with Remi to make the MODE_* constants in LiveStackFrameInfo final and PrimitiveSlot::size() public.

Thanks for the good test and I want to take another look at it and get back to you.

Mandy

From mandy.chung at oracle.com  Fri Jan 27 16:44:12 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 27 Jan 2017 08:44:12 -0800
Subject: RFR JDK-8173396:Error message issue with jar tool API validator
In-Reply-To: <588AEF83.1090207@oracle.com>
References: <588AEF83.1090207@oracle.com>
Message-ID: <ECD39FB9-EA2C-41AD-A33C-351898062B1A@oracle.com>


> On Jan 26, 2017, at 10:58 PM, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi,
> 
> Please review the change for JDK-8173396.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8173396
> webrev: http://cr.openjdk.java.net/~sherman/8173396/webrev
> 
> The error message keys "error.versioned.xxxx" were renamed to error.validator.xxxx
> in all resource properties files but several use site rename/change was missed in
> method checkModuleDescriptor().
> 

The change looks okay.  This reminds me that this string-based keys are easy to miss if renamed.  javac generates the constant variables at build time that avoids this kind of regression but they are not in source which is its downside.  

Mandy

From brent.christian at oracle.com  Fri Jan 27 17:33:49 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 27 Jan 2017 09:33:49 -0800
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double)
	are incorrect (updated)
In-Reply-To: <CEA0DB3E-AC24-4B37-8252-9E95E54CA2B3@oracle.com>
References: <57B4C392.4060001@oracle.com>
	<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
	<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
	<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
	<588A9D3D.1040200@oracle.com>
	<CEA0DB3E-AC24-4B37-8252-9E95E54CA2B3@oracle.com>
Message-ID: <588B847D.9060609@oracle.com>

On 01/27/2017 08:26 AM, Mandy Chung wrote:
>> On Jan 26, 2017, at 5:07 PM, Brent Christian <brent.christian at oracle.com> wrote:
>>
>> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
>
> I agree with Remi to make the MODE_* constants in LiveStackFrameInfo final and PrimitiveSlot::size() public.

Thank you for the comments, Remi and Mandy.  Webrev updated in place.

> Thanks for the good test and I want to take another look at it and get back to you.

Sounds good.

Thanks,
-Brent



From paul.sandoz at oracle.com  Fri Jan 27 18:35:14 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Jan 2017 10:35:14 -0800
Subject: RFR JDK-8173396:Error message issue with jar tool API validator
In-Reply-To: <588AEF83.1090207@oracle.com>
References: <588AEF83.1090207@oracle.com>
Message-ID: <8AECFE04-7886-4851-A917-70453B95E669@oracle.com>

+1

Paul.

> On 26 Jan 2017, at 22:58, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi,
> 
> Please review the change for JDK-8173396.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8173396
> webrev: http://cr.openjdk.java.net/~sherman/8173396/webrev
> 
> The error message keys "error.versioned.xxxx" were renamed to error.validator.xxxx
> in all resource properties files but several use site rename/change was missed in
> method checkModuleDescriptor().
> 
> Sherman
> 


From brent.christian at oracle.com  Fri Jan 27 19:02:20 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 27 Jan 2017 11:02:20 -0800
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double)
	are incorrect (updated)
In-Reply-To: <588A9D3D.1040200@oracle.com>
References: <57B4C392.4060001@oracle.com>	<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>	<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>	<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
	<588A9D3D.1040200@oracle.com>
Message-ID: <588B993C.7020805@oracle.com>

On 01/26/2017 05:07 PM, Brent Christian wrote:
>
> I also removed the more simplistic CountLocalSlots.java test, given that
> the updated LocalsAndOperands.java will now better cover testing -Xcomp.

I also noticed that we no longer need the LocalsCrash.java test.  Removed.

-Brent


From henry.jen at oracle.com  Fri Jan 27 21:12:23 2017
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 27 Jan 2017 13:12:23 -0800
Subject: RFR: 8172309: classpath wildcards code does not support
	--class-path
In-Reply-To: <A4E26709-1275-44E6-82EA-B92DBD7DFA37@oracle.com>
References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com>
	<588A78AE.9020101@oracle.com> <588A8FB5.5020601@oracle.com>
	<A4E26709-1275-44E6-82EA-B92DBD7DFA37@oracle.com>
Message-ID: <30EF55B3-B321-4488-BFAD-1993E0F31A6C@oracle.com>

How about following patch instead for langtools repo?

diff -r ef142ac9824e test/tools/javac/Paths/wcMineField.sh
--- a/test/tools/javac/Paths/wcMineField.sh     Thu Jan 26 16:53:56 2017 -0800
+++ b/test/tools/javac/Paths/wcMineField.sh     Fri Jan 27 13:10:12 2017 -0800
@@ -26,7 +26,7 @@
 #
 # @test
 # @summary Test classpath wildcards for javac and java -classpath option.
-# @bug 6268383
+# @bug 6268383 8172309
 # @run shell/timeout=600 wcMineField.sh

 # To run this test manually, simply do ./wcMineField.sh
@@ -186,6 +186,8 @@
 Failure "$javac" ${TESTTOOLVMOPTS} -classpath "GooJar/*${PS}." Main1.java
 Success "$javac" ${TESTTOOLVMOPTS} -cp "GooJar/SubDir/*" Main1.java
 Success "$javac" ${TESTTOOLVMOPTS} -classpath "GooJar/SubDir/*" Main1.java
+Success "$javac" ${TESTTOOLVMOPTS} --class-path "GooJar/SubDir/*" Main1.java
+Success "$javac" ${TESTTOOLVMOPTS} --class-path="GooJar/SubDir/*" Main1.java
 #Same with launcher. Should not load jar in subdirectories unless specified
 Failure "$java" ${TESTVMOPTS}  -classpath "GooJar/*${PS}." Main1
 Success "$java" ${TESTVMOPTS}  -classpath "GooJar/SubDir/*${PS}." Main1

Cheers,
Henry


> On Jan 26, 2017, at 6:01 PM, Henry Jen <henry.jen at oracle.com> wrote:
> 
>> On Jan 26, 2017, at 4:09 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>> 
>> Henry,
>> 
>> You've changed old test cases into new test cases, thereby eliminating the old cases, which is not so good.
>> 
>> You should be adding new test cases, but changing old ones.
>> 
> 
> I am not sure, I believe all wild-card cases still tested, just that we have different variety of calling -cp. Of course, it would be nice to test all cases with all 4 flavors of -cp, but I don?t think that?s necessary as I think the test coverage is the same.
> 
> Anyway, I could be wrong. If you feel strong about this, I can redo it. But that may takes more time to digest what the test cases are really for.
> 
> Cheers,
> Henry
> 
> 
>> -- Jon
>> 
>> 
>> On 01/26/2017 02:31 PM, Kumar Srinivasan wrote:
>>> 
>>> Hi Henry,
>>> 
>>> Looks ok to me. Thanks for making this change.
>>> 
>>> Kumar
>>> 
>>>> Hi,
>>>> 
>>>> Please review the webrev[1], the fix is to ensure ?class-path and ?class-path= is processed correctly to expand wildcard. Changes are made in jdk repo. However, test case to verify the bug fix is in langtool repo.
>>>> 
>>>> Cheers,
>>>> Henry
>>>> 
>>>> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8172309
>>> 
>> 
> 


From paul.sandoz at oracle.com  Fri Jan 27 23:10:22 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 27 Jan 2017 15:10:22 -0800
Subject: RFR (JDK 10) 8172298: Reduce memory churn when linking VarHandles
	operations
Message-ID: <7C39CCC6-D0A2-4EBF-A3BE-D0787F91D6CD@oracle.com>

Hi,

Please review some small memory-based optimisations for VarHandle linkage:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8172298-varhandle-link-reduce-memory/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8172298-varhandle-link-reduce-memory/webrev/>

This will be pushed to the newly opened JDK 10 repo.

Thanks,
Paul.


From Alan.Bateman at oracle.com  Sat Jan 28 19:35:35 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 28 Jan 2017 19:35:35 +0000
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
In-Reply-To: <065eab06-3a3b-4a6a-8cbe-c892f5017ece@default>
References: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>
	<07c4c8b9-695b-6ba8-2cf8-09423e467379@oracle.com>
	<18089cd3-4cfb-4e55-b02b-e11cb637daa9@default>
	<58867365.5070608@oracle.com>
	<cdafe37b-7d8a-46a0-ac89-1c013764a030@default>
	<5888CB80.6050107@oracle.com>
	<065eab06-3a3b-4a6a-8cbe-c892f5017ece@default>
Message-ID: <357873c3-e37c-0c8f-8aa5-370ad4c680d7@oracle.com>

On 27/01/2017 12:52, Ramanand Patil wrote:

> Thank you Alan and Kumar for your review.
> Here is the updated webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.03
>
> Changes done:
> 1. LinkageError in method loadMainClass is handled separately and with a new message in launcher.properties
> 2. Test case updated to print the error message(even when test passes) and to print the final test result message as suggested by Kumar.
>
The updated LauncherHelper looks okay although you can drop the catching 
of LinkageError at L641 because it will be caught by the outer catch at 
L647.

-Alan.


From shade at redhat.com  Mon Jan 30 10:59:23 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 30 Jan 2017 11:59:23 +0100
Subject: RFR (JDK 10) 8172298: Reduce memory churn when linking VarHandles
	operations
In-Reply-To: <7C39CCC6-D0A2-4EBF-A3BE-D0787F91D6CD@oracle.com>
References: <7C39CCC6-D0A2-4EBF-A3BE-D0787F91D6CD@oracle.com>
Message-ID: <da7c296b-c81a-42cf-9bd8-b6191830cded@redhat.com>

On 01/28/2017 12:10 AM, Paul Sandoz wrote:
> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8172298-varhandle-link-reduce-memory/webrev/

Looks good, but I think the StringBuilder is inefficiently sized: it adds
(parameterCount() - 2) chars in the loop, skipping the first and and then two
after the loop. So the total number of chars is exactly (prefix +
parameterCount()), not +2?

Thanks,
-Aleksey


From ramanand.patil at oracle.com  Mon Jan 30 12:11:04 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 30 Jan 2017 04:11:04 -0800 (PST)
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
In-Reply-To: <357873c3-e37c-0c8f-8aa5-370ad4c680d7@oracle.com>
References: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>
	<07c4c8b9-695b-6ba8-2cf8-09423e467379@oracle.com>
	<18089cd3-4cfb-4e55-b02b-e11cb637daa9@default>
	<58867365.5070608@oracle.com>
	<cdafe37b-7d8a-46a0-ac89-1c013764a030@default>
	<5888CB80.6050107@oracle.com>
	<065eab06-3a3b-4a6a-8cbe-c892f5017ece@default>
	<357873c3-e37c-0c8f-8aa5-370ad4c680d7@oracle.com>
Message-ID: <a01a7f5f-7a48-4c58-a034-820adcacd322@default>

Thank you Alan.

I have eliminated the inner catch block for LinkageError. Here is the updated webrev: 
http://cr.openjdk.java.net/~rpatil/8167063/webrev.04


Regards,
Ramanand.
-----Original Message-----
From: Alan Bateman 
Sent: Sunday, January 29, 2017 1:06 AM
To: Ramanand Patil <ramanand.patil at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized

On 27/01/2017 12:52, Ramanand Patil wrote:

> Thank you Alan and Kumar for your review.
> Here is the updated webrev: 
> http://cr.openjdk.java.net/~rpatil/8167063/webrev.03
>
> Changes done:
> 1. LinkageError in method loadMainClass is handled separately and with 
> a new message in launcher.properties 2. Test case updated to print the error message(even when test passes) and to print the final test result message as suggested by Kumar.
>
The updated LauncherHelper looks okay although you can drop the catching of LinkageError at L641 because it will be caught by the outer catch at L647.

-Alan.


From Alan.Bateman at oracle.com  Mon Jan 30 13:05:58 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 30 Jan 2017 13:05:58 +0000
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
In-Reply-To: <a01a7f5f-7a48-4c58-a034-820adcacd322@default>
References: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>
	<07c4c8b9-695b-6ba8-2cf8-09423e467379@oracle.com>
	<18089cd3-4cfb-4e55-b02b-e11cb637daa9@default>
	<58867365.5070608@oracle.com>
	<cdafe37b-7d8a-46a0-ac89-1c013764a030@default>
	<5888CB80.6050107@oracle.com>
	<065eab06-3a3b-4a6a-8cbe-c892f5017ece@default>
	<357873c3-e37c-0c8f-8aa5-370ad4c680d7@oracle.com>
	<a01a7f5f-7a48-4c58-a034-820adcacd322@default>
Message-ID: <a59cadf9-7f50-01a3-6399-8e5faa98ecc9@oracle.com>

On 30/01/2017 12:11, Ramanand Patil wrote:

> Thank you Alan.
>
> I have eliminated the inner catch block for LinkageError. Here is the updated webrev:
> http://cr.openjdk.java.net/~rpatil/8167063/webrev.04
>
>
I think this looks right now.

-Alan

From christoph.langer at sap.com  Mon Jan 30 14:27:32 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 30 Jan 2017 14:27:32 +0000
Subject: [JAXP] RFR: 8173602: TESTBUG:
	javax/xml/jaxp/unittest/transform/TransformerTest.java needs
	refactoring
Message-ID: <7d392c5406a7476c9ffde144205d839e@derote13de46.global.corp.sap>

Hi,

please review a test fix for javax/xml/jaxp/unittest/transform/TransformerTest.java:
Bug: https://bugs.openjdk.java.net/browse/JDK-8173602
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8173602.0/

The main motivation for this refactoring is to remove the dependency to the JDK internal classes com.sun.org.apache.xml.internal.serialize.OutputFormat and com.sun.org.apache.xml.internal.serialize.XMLSerializer.

Generally, TransformerTest.java contains several subtests which do similar things (test XALAN transformations) but the implementations differ. I created a common template with helper methods which all tests take advantage of now. I also introduced data sources to some tests to make them more readable and adaptable.

Thanks
Christoph


From christoph.langer at sap.com  Mon Jan 30 14:52:17 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 30 Jan 2017 14:52:17 +0000
Subject: RFR (XS): 8173634: libjli/cmdtoargs.c does not compile with VS2010
Message-ID: <097d523560f347d3b2138d181acb7837@derote13de46.global.corp.sap>

Hi,

please review a tiny fix. The change for JDK-8170832 (Add a new launcher environment variable JAVA_OPTIONS) has introduced a build error when you build with Visual Studio 2010.

Yes, we know it is not officially supported for JDK9 - however, it's easy and clean to keep compatibility. :)

Bug: https://bugs.openjdk.java.net/browse/JDK-8173634
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8173634.0/

Thanks
Christoph


From Roger.Riggs at Oracle.com  Mon Jan 30 14:59:19 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 30 Jan 2017 09:59:19 -0500
Subject: RFR (XS): 8173634: libjli/cmdtoargs.c does not compile with VS2010
In-Reply-To: <097d523560f347d3b2138d181acb7837@derote13de46.global.corp.sap>
References: <097d523560f347d3b2138d181acb7837@derote13de46.global.corp.sap>
Message-ID: <9c5236a2-81af-d823-1149-d60007f12b34@Oracle.com>

Hi Christoph,

Looks fine,

Thanks, Roger


On 1/30/2017 9:52 AM, Langer, Christoph wrote:
> Hi,
>
> please review a tiny fix. The change for JDK-8170832 (Add a new launcher environment variable JAVA_OPTIONS) has introduced a build error when you build with Visual Studio 2010.
>
> Yes, we know it is not officially supported for JDK9 - however, it's easy and clean to keep compatibility. :)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173634
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8173634.0/
>
> Thanks
> Christoph
>


From christoph.langer at sap.com  Mon Jan 30 15:28:13 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 30 Jan 2017 15:28:13 +0000
Subject: Update: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
	namespace unaware StAX Input
Message-ID: <3f43563228ef4f7ca2eed6281698a17c@derote13de46.global.corp.sap>

Hi Joe,

I've updated my webrev for 8172974 after pulling out the refactoring of javax/xml/jaxp/unittest/transform/TransformerTest.java to Bug 8173602: http://cr.openjdk.java.net/~clanger/webrevs/8172974.1/

After exchanging some off-list mails with Lance and Daniel, we came to the conclusion that you should decide about this one when you are back. The changes are merely cleanups apart from com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.startElement(), which to me seem natural after 8169631, though.

Thanks,
Christoph

> -----Original Message-----
> From: Langer, Christoph
> Sent: Mittwoch, 18. Januar 2017 22:55
> To: 'huizhe wang' <huizhe.wang at oracle.com>; core-libs-dev at openjdk.java.net
> Subject: RE: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
> namespace unaware StAX Input
> 
> Hi Joe,
> 
> generally, you are right, XSLT requires namespace support. For parsing the
> stylesheet, it is definitely a hard requirement. Otherwise this would not make
> sense at all. For instance xsl directives are in the xsl namespace. That
> requirement is what the FAQ you are referencing [1] is talking about.
> 
> As for the InputSource which is to be processed, it is probably also not a right to
> use non namespace aware parsing. But still it's not forbidden. For instance, the
> JavaDoc for SAXSource [2] states this:
> "Note that XSLT requires namespace support. Attempting to transform an input
> source that is not generated with a namespace-aware parser may result in
> errors. Parsers can be made namespace aware by calling the
> SAXParserFactory.setNamespaceAware(boolean awareness) method."
> 
> So, I agree, we are in the error space here. But still I think the result of non
> namespace aware parsing should be the same for all types of input source. And
> at the moment it is the same for DOMSource and SAXSource but not for
> StAXSource. From that point of view I think my fix makes sense (along with the
> other cleanups).
> 
> Best regards
> Christoph
> 
> [1] https://xml.apache.org/xalan-j/faq.html#faq-N10207
> [2]
> https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/sax/SAXSource
> .html
> 
> 
> > -----Original Message-----
> > From: huizhe wang [mailto:huizhe.wang at oracle.com]
> > Sent: Mittwoch, 18. Januar 2017 22:12
> > To: Langer, Christoph <christoph.langer at sap.com>; core-libs-
> > dev at openjdk.java.net
> > Subject: Re: RFR 8172974 [JAXP] XALAN: Wrong result when transforming
> > namespace unaware StAX Input
> >
> > Hi Christoph,
> >
> > Xalan requires the underlying parser to be namespace aware. Please refer
> > to https://xml.apache.org/xalan-j/faq.html#faq-N10207
> >
> > Thanks,
> > Joe
> >
> > On 1/18/2017 8:26 AM, Langer, Christoph wrote:
> > > Hi,
> > >
> > > please review a change for JAXP.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172974
> > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8172974.0/
> > >
> > > When enhancing the test for https://bugs.openjdk.java.net/browse/JDK-
> > 8023653, I saw that there's still an issue with StAXInputSource which is not
> > namespace aware. This needs a small update in
> >
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dt
> > m/SAX2DTM2.java. Furthermore, I added the fixed warnings and formattings
> > from the proposal http://cr.openjdk.java.net/~clanger/webrevs/8023653.0/ to
> > this webrev, as 8023653 is an enhancement and might not go in in the near
> > future.
> > >
> > > I also enhanced the TransformerTest to utilize data providers now and test
> a
> > comprehensive matrix of XALAN input.
> > >
> > > Thanks in advance and Best regards
> > > Christoph
> > >


From chris.hegarty at oracle.com  Mon Jan 30 15:33:25 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 30 Jan 2017 15:33:25 +0000
Subject: RFR (XS): 8173634: libjli/cmdtoargs.c does not compile with VS2010
In-Reply-To: <9c5236a2-81af-d823-1149-d60007f12b34@Oracle.com>
References: <097d523560f347d3b2138d181acb7837@derote13de46.global.corp.sap>
	<9c5236a2-81af-d823-1149-d60007f12b34@Oracle.com>
Message-ID: <08779872-5cd3-08bb-3467-95a55c5480ea@oracle.com>

++1

I ran into this myself earlier today.

-Chris.

On 30/01/17 14:59, Roger Riggs wrote:
> Hi Christoph,
>
> Looks fine,
>
> Thanks, Roger
>
>
> On 1/30/2017 9:52 AM, Langer, Christoph wrote:
>> Hi,
>>
>> please review a tiny fix. The change for JDK-8170832 (Add a new
>> launcher environment variable JAVA_OPTIONS) has introduced a build
>> error when you build with Visual Studio 2010.
>>
>> Yes, we know it is not officially supported for JDK9 - however, it's
>> easy and clean to keep compatibility. :)
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173634
>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8173634.0/
>>
>> Thanks
>> Christoph
>>
>

From christoph.langer at sap.com  Mon Jan 30 15:38:30 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 30 Jan 2017 15:38:30 +0000
Subject: RFR (XS): 8173634: libjli/cmdtoargs.c does not compile with VS2010
In-Reply-To: <08779872-5cd3-08bb-3467-95a55c5480ea@oracle.com>
References: <097d523560f347d3b2138d181acb7837@derote13de46.global.corp.sap>
	<9c5236a2-81af-d823-1149-d60007f12b34@Oracle.com>
	<08779872-5cd3-08bb-3467-95a55c5480ea@oracle.com>
Message-ID: <79a467577b7c4a99991a85c23e25115c@derote13de46.global.corp.sap>

Thanks, Roger, Chris.

It's submitted: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/65a1441c9c80

Best
Christoph

> -----Original Message-----
> From: Chris Hegarty [mailto:chris.hegarty at oracle.com]
> Sent: Montag, 30. Januar 2017 16:33
> To: Langer, Christoph <christoph.langer at sap.com>; core-libs-
> dev at openjdk.java.net
> Subject: Re: RFR (XS): 8173634: libjli/cmdtoargs.c does not compile with VS2010
> 
> ++1
> 
> I ran into this myself earlier today.
> 
> -Chris.
> 
> On 30/01/17 14:59, Roger Riggs wrote:
> > Hi Christoph,
> >
> > Looks fine,
> >
> > Thanks, Roger
> >
> >
> > On 1/30/2017 9:52 AM, Langer, Christoph wrote:
> >> Hi,
> >>
> >> please review a tiny fix. The change for JDK-8170832 (Add a new
> >> launcher environment variable JAVA_OPTIONS) has introduced a build
> >> error when you build with Visual Studio 2010.
> >>
> >> Yes, we know it is not officially supported for JDK9 - however, it's
> >> easy and clean to keep compatibility. :)
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8173634
> >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8173634.0/
> >>
> >> Thanks
> >> Christoph
> >>
> >

From paul.sandoz at oracle.com  Mon Jan 30 19:48:46 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 30 Jan 2017 11:48:46 -0800
Subject: RFR (JDK 10) 8172298: Reduce memory churn when linking VarHandles
	operations
In-Reply-To: <da7c296b-c81a-42cf-9bd8-b6191830cded@redhat.com>
References: <7C39CCC6-D0A2-4EBF-A3BE-D0787F91D6CD@oracle.com>
	<da7c296b-c81a-42cf-9bd8-b6191830cded@redhat.com>
Message-ID: <48FEF7CE-C668-415F-B935-8F6758AE2C6B@oracle.com>


> On 30 Jan 2017, at 02:59, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> On 01/28/2017 12:10 AM, Paul Sandoz wrote:
>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8172298-varhandle-link-reduce-memory/webrev/
> 
> Looks good, but I think the StringBuilder is inefficiently sized: it adds
> (parameterCount() - 2) chars in the loop, skipping the first and and then two
> after the loop. So the total number of chars is exactly (prefix +
> parameterCount()), not +2?
> 

Ah yes, now that the guard method type is used, which has 2 additional parameters types not included in the mangled method name. Fixed.

Thanks,
Paul.

From naoto.sato at oracle.com  Mon Jan 30 21:27:21 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 30 Jan 2017 13:27:21 -0800
Subject: [9] RFR: 8173423: Wrong display name for supplemental Japanese era
Message-ID: <ca940fce-41ab-bf5a-fe70-cf7804a366fe@oracle.com>

Hello,

Please review the fix to the following bug:

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

The proposed fix is located at:

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

There is a functionality in Japanese Imperial Calendar to supplement a 
new era from system property. The code path from java.time did not 
retrieve the supplemental name before the fix, thus the era number "3" 
was displayed instead. The fix intends to retrieve the correct name, and 
return it to java.time formatters.

Naoto

From coleen.phillimore at oracle.com  Tue Jan 31 02:47:06 2017
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Jan 2017 21:47:06 -0500
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are
	incorrect (updated)
In-Reply-To: <75c5a7d6-7c61-2cd0-a3a4-e0d8330e8a23@oracle.com>
References: <57B4C392.4060001@oracle.com>
	<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
	<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
	<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
	<588A9D3D.1040200@oracle.com>
	<75c5a7d6-7c61-2cd0-a3a4-e0d8330e8a23@oracle.com>
Message-ID: <edc5fd74-2cd7-9bd6-d07a-b912bf2753d5@oracle.com>

Added core-libs-dev.
Coleen

On 1/30/17 5:52 PM, Coleen Phillimore wrote:
>
> Hi Brent,
>
> I think this looks more conservative and better.
>
> in
> http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/src/share/vm/prims/stackwalk.cpp.html 
>
>
>  287     int mode = 0;
>  288     if (_jvf->is_interpreted_frame()) { mode |= MODE_INTERPRETED; }
>  289     if (_jvf->is_compiled_frame())    { mode |= MODE_COMPILED;    }
>
> The mode can't be interpreted AND compiled so the OR doesn't make 
> sense here.  There may be other options though, so I wouldn't make 
> these the only cases.   It should be something more like:
>
>   if (_jvf->is_interpreted_frame()) {
>     mode = MODE_INTERPRETED;
>   else if (_jvf->is_compiled_frame()) {
>     mode = MODE_COMPILED;
>   }
>
> with no 'else' because it could be entry or runtime stub or new things 
> that we may eventually add, that you should probably not tell the API.
>
> Otherwise this seems fine.   I didn't see the update to test "On the 
> hotspot side, I had to update the 8163014 regtest. "
>
> Please make sure JPRT -testset hotspot works with this (or check it in 
> that way).
>
> Thanks,
> Coleen
>
> On 1/26/17 8:07 PM, Brent Christian wrote:
>> Hi,
>>
>> Please review my updated approach for fixing 8156073 ("2-slot
>> LiveStackFrame locals (long and double) are incorrect") in the 
>> experimental portion of the StackWalker API, added in JDK 9.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
>> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
>>
>> (For reference, the earlier RFR thread is here:[1].)
>>
>> We've concluded that we can't get enough primitive type info from the 
>> VM to use the current fine-grain *Primitive classes in 
>> LiveStackFrameInfo, so those classes have been removed for now. I've 
>> simplified down to just a PrimitiveSlot32 for 32-bit VMs, and 
>> PrimitiveSlot64 for 64-bit VMs.
>>
>> We also do not attempt to interpret a primitive's type based on the 
>> slot's contents, and instead return the slot's full contents for 
>> every primitive local.  This more accurately reflects the underlying 
>> layout of locals in the VM (versus the previous proposed 
>> LiveStackFrame.getLocals() behavior of having 64-bit behave like 
>> 32-bit by splitting long/double values into two slots).  On the 
>> 64-bit VM, this returns 64-bits even for primitive local variables 
>> smaller than 64-bits (int, etc).
>>
>> The upshot is that we now return the entire value for longs/doubles 
>> on 64-bit VMs.  (The current JDK 9 only reads the first 32-bits.)
>>
>> I also now indicate in LiveStackFrameInfo.toString() if the frame is 
>> interpreted or compiled.
>>
>> On the testing front:
>> In the interest of simplifying LiveStackFrame testing down into a 
>> single test file under jdk/test/, I chose not to add the additional 
>> test case from Fabio Tudone [2,3] (thanks, Fabio!), but instead 
>> incorporated some of those testing ideas into the existing test.  
>> Testing is a bit relaxed versus the previously proposed test case; in 
>> particular it does not enforce endianness.
>>
>> I also removed the more simplistic CountLocalSlots.java test, given 
>> that the updated LocalsAndOperands.java will now better cover testing 
>> -Xcomp.  On the hotspot side, I had to update the 8163014 regtest.
>>
>> Automated test runs have looked fine so far.
>>
>> Thanks,
>> -Brent
>>
>> 1. 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042979.html
>> 2. 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041666.html
>> 3. https://bugs.openjdk.java.net/browse/JDK-8158879
>>
>>
>


From christoph.langer at sap.com  Tue Jan 31 10:17:01 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 31 Jan 2017 10:17:01 +0000
Subject: Updated Webrev: [JAXP] RFR: 8173602: TESTBUG:
	javax/xml/jaxp/unittest/transform/TransformerTest.java needs
	refactoring
Message-ID: <744cc2b4a5e14229b9e25b33d9f044bc@derote13de46.global.corp.sap>

Hi,

I made a small update to the webrev (in place). I externalized class TransformerTestTemplate now to be able to use it in other tests besides TransformerTest.java.

Best regards
Christoph

From: Langer, Christoph
Sent: Montag, 30. Januar 2017 15:28
To: core-libs-dev at openjdk.java.net
Subject: [JAXP] RFR: 8173602: TESTBUG: javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring

Hi,

please review a test fix for javax/xml/jaxp/unittest/transform/TransformerTest.java:
Bug: https://bugs.openjdk.java.net/browse/JDK-8173602
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8173602.0/

The main motivation for this refactoring is to remove the dependency to the JDK internal classes com.sun.org.apache.xml.internal.serialize.OutputFormat and com.sun.org.apache.xml.internal.serialize.XMLSerializer.

Generally, TransformerTest.java contains several subtests which do similar things (test XALAN transformations) but the implementations differ. I created a common template with helper methods which all tests take advantage of now. I also introduced data sources to some tests to make them more readable and adaptable.

Thanks
Christoph


From andrey.x.nazarov at oracle.com  Tue Jan 31 13:05:03 2017
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Tue, 31 Jan 2017 16:05:03 +0300
Subject: RFR: 8075617, 8075616 Create tests to check wsgen, schemagen work
	with multi-version jar
In-Reply-To: <75C6ACF3-28E8-4475-B871-049601D1FE79@oracle.com>
References: <CBABED4B-B8A2-4A80-9BD2-8039A055F5AD@oracle.com>
	<86914c18-9d41-6778-4a4d-66acff3442ac@oracle.com>
	<FADC68EB-89AF-4CCA-AEE2-EBF55212D3FC@oracle.com>
	<ff92bd6a-559e-6206-0e23-5d141a4441cf@oracle.com>
	<D0BAB791-CBE0-4BFA-928E-A7405860BE18@oracle.com>
	<75C6ACF3-28E8-4475-B871-049601D1FE79@oracle.com>
Message-ID: <A26F3D5A-F5C6-4877-9FDB-DDC47AD2DD7A@oracle.com>

Hi,

Anyone please review and approve

?Andrey
> On 26 Jan 2017, at 21:29, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
> 
> Hi
> Move tests to new place. Please review.
> http://cr.openjdk.java.net/~anazarov/8075617/webrev.01/webrev/ <http://cr.openjdk.java.net/~anazarov/8075617/webrev.01/webrev/>
> 
> ?Andrey
>> On 25 Jan 2017, at 19:04, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
>> 
>> 
>>> On 25 Jan 2017, at 19:00, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> 
>>> On 25/01/2017 15:25, Andrey Nazarov wrote:
>>> 
>>>> :
>>>> What is the right location?
>>> These tools are maintained in the upstream Metro project, I suspect the tests for these tools are located there too but I'm not sure. There are handful of JAXB and JAX-WS tests in the jdk repo but I don't think they directly test the tools. So I think you'll need a new location for these, assuming you really want these in the jdk repo.
>> Is it Ok to use jdk/test/tools/jaxws ? Tools directory already contains tests for jjs for example.
>>> 
>>> -Alan
>> 
> 


From claes.redestad at oracle.com  Tue Jan 31 13:43:42 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 31 Jan 2017 14:43:42 +0100
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
	reflection
In-Reply-To: <bbe1f51f-ee62-4008-e2d2-6a06da8c09b3@gmail.com>
References: <431967d8-bdba-83e0-258c-6fe384630ff3@gmail.com>
	<1d8c06cf-ddba-ff49-bd61-2edd496efb48@oracle.com>
	<bbe1f51f-ee62-4008-e2d2-6a06da8c09b3@gmail.com>
Message-ID: <b7f9e9c9-1f06-7669-1250-dd5249c475c4@oracle.com>

Hi Peter,

On 01/25/2017 08:01 PM, Peter Levart wrote:
> Hi Claes,
>
> On 01/24/2017 03:34 PM, Claes Redestad wrote:
>> Hi Peter,
>>
>> thanks for the thorough examination of this issue. 
>
> Thanks for looking into this change...
>
>> After going through
>> the patch I do like what I see, but I have a few comments:
>>
>> AnnotationInvocationHandler:
>> in invoke, cleaning up and replacing the explicit AssertionError should
>> be fine, but perhaps convert it to an assert that the number of
>> arguments is 1 when methodName is "equals" and 0 otherwise?
>
> In the following part of code:
>
>     public Object invoke(Object proxy, Method method, Object[] args) {
>
>         String memberName = method.getName(); // guaranteed interned 
> String
>         Class<?> dtype = method.getDeclaringClass();
>
>         if (dtype == Object.class ||  // equals/hashCode/toString
>             dtype == Annotation.class // annotationType
>             ) {
>             if (memberName == "equals") return equalsImpl(proxy, 
> args[0]);
>             if (memberName == "hashCode") return hashCodeImpl();
>             if (memberName == "annotationType") return type;
>             if (memberName == "toString") return toStringImpl();
>             throw new AssertionError("Invalid method: " + method);
>         }
>
> ...in the if statement, when method's declaring class is either Object 
> or Annotation, we have just a limited number of methods that are 
> possible candidates and we can identify them just by their names 
> (Method::getName returns interned string, so identity comparison is 
> possible). For example: if method's name is "equals" and declaring 
> class is either Object or Annotation, then we know that this method 
> has a signature of Object::equals - we don't need to check - this is 
> part of language spec.
>
> The "throw new AssertionError("Invalid method: " + method)" is an 
> unreachable statement until some new method is added to either Object 
> or Annotation and at that time, if it ever comes to that, this code 
> should fail and should be revised...
>
> The assert you are talking about is meaningful only if inserted as 1st 
> statement inside the if statement. Will add it.

Yes, thanks!

>
>>
>> Adding @Stable is fine if that has a performance impact, but I think
>> we might preserve clarity of intent if you kept the fields as final and
>> kept using Unsafe to deserialize properly.
>
> Ok, will make them final but keep @Stable.

Good.

>
>>
>> AnnotationSupport:
>> I dislike that this code was already catching Throwable, and that
>> you're now copying that approach.  Could the new the catch clause mimic
>> the one that previously wrapped the entire method?
>
> I think we can do it even better than that. See new webrev...

Oh, right, since we're avoiding InvocationHandler::invoke we don't have to
catch Throwable here.

Tangent: could we theoretically respecify InvocationHandler to throw 
Exception
rather than Throwable (since RuntimeException and Error are always 
implicitly
thrown)?

>
>>
>> AnnotationType:
>> accessibleMembers might not need to be volatile.
>
> AnnotationType.accessibleMembers() may be called concurrently from 
> multiple threads (it is used by annotation's equals method when passed 
> a foreign annotation and by AnnotationSupport.getValueArray() helper 
> method used to access repeatable annotations in a foreign container 
> annotation). What this method returns is a HashMap object which is not 
> tolerable to unsafe publication (unlike String, for example). Volatile 
> field is needed for safe publication of the HashMap instance.

I stand corrected!

>
>>
>> validateAnnotationMethod:
>> the block: label and break block seems unnecessary. I'd not worry
>> about optimizing for such invalid cases and simply run through all the
>> checks and set valid = false multiple times if so be it.
>
> I changed the method to a boolean-returning isValidAnnotationMethod() 
> with multiple exit paths and moved throwing of AnnotationFormatError 
> into AnnotationType constructor.
>
> Here's all that applied together with comment from Chris:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/webrev.02/ 
>
>
> plus more:
>
> AnnotationInvocationHandler.equalsImpl()
>
> - should check the number of values in both annotations and not the 
> lengths of hash tables (hash table lengths are rounded to power of 2)
> - exception handling when a foreign annotation throws an unchecked 
> exception from it's member method - propagate it instead of returning 
> "false" from equals
>
> AnnotationInvocationHandler.asOneOfUs()
>
> - enclose the Proxy.getInvocationHandler() in doPrivileged() if needed 
> otherwise we can get SecurityException
>
> AnnotationInvocationHandler.readObject()
>
> - don't modify the Map instance read from stream as it might be shared 
> or unmodifiable - clone it and modify it if necessary.

Good - I had jotted down a note to ask about this in an early review draft.

>
> AnnotationParser:
>
> - skip annotations for types that are not annotation types any more 
> and propagate AnnotationFormatError for invalid annotation types.
>
> AnnotationSupport.getValueArray()
>
> - exception handling cleanup.
>
> I just noticed this last thing will need another webrev and some 
> discussion as handling of "oneOfUs" vs. "foreign" annotation is 
> different currently. Should a RuntimeException (other than 
> IncompleteAnnotationException) be propagated or wrapped with 
> AnnotationFormatError? RuntimeException(s) are exceptions thrown by 
> various ExceptionProxy(s) when retrieving annotation values that are 
> somehow invalid.
>
> Here's the diff between webrev.01 and 02 (without changes to the test):
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8029019_Annotations.optimization/webrev.01to02/ 
>

I think this all seems reasonable, but subtle behavior changes like this 
needs more scrutiny than I can provide.  I've discussed this offline 
with Joe and sadly concluded it's probably too much, too late for 9 at 
this point.

Hope you don't mind re-targetting this to JDK 10.

Thanks!

/Claes

From kumar.x.srinivasan at oracle.com  Tue Jan 31 16:22:44 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 31 Jan 2017 08:22:44 -0800
Subject: RFR: 8167063: spurious message "A JNI error has occurred" if
	start-class cannot be initialized
In-Reply-To: <a59cadf9-7f50-01a3-6399-8e5faa98ecc9@oracle.com>
References: <1b279d2c-e4e6-4bc2-b365-ed3ad5aa5629@default>
	<07c4c8b9-695b-6ba8-2cf8-09423e467379@oracle.com>
	<18089cd3-4cfb-4e55-b02b-e11cb637daa9@default>
	<58867365.5070608@oracle.com>
	<cdafe37b-7d8a-46a0-ac89-1c013764a030@default>
	<5888CB80.6050107@oracle.com>
	<065eab06-3a3b-4a6a-8cbe-c892f5017ece@default>
	<357873c3-e37c-0c8f-8aa5-370ad4c680d7@oracle.com>
	<a01a7f5f-7a48-4c58-a034-820adcacd322@default>
	<a59cadf9-7f50-01a3-6399-8e5faa98ecc9@oracle.com>
Message-ID: <6b43aba8-f880-1adb-4e52-46cb95b92c89@oracle.com>


Approved, please make sure you have run all the
jprt -testset pit tests.

Kumar

On 1/30/2017 5:05 AM, Alan Bateman wrote:
> On 30/01/2017 12:11, Ramanand Patil wrote:
>
>> Thank you Alan.
>>
>> I have eliminated the inner catch block for LinkageError. Here is the
>> updated webrev:
>> http://cr.openjdk.java.net/~rpatil/8167063/webrev.04
>>
>>
> I think this looks right now.
>
> -Alan

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From martinrb at google.com  Tue Jan 31 16:58:10 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 31 Jan 2017 08:58:10 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
Message-ID: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>

Another too-big too-scary wave for this phase of jdk9, but I still think it
should go in.  Or we can put into jdk10 first, then down-integrate into
jdk9 (when??).


http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/

---

concurrent-collections has spliterator bug fixes and fixes for rare but
serious performance problems in LinkedTransferQueue.
And it continues the optimization of bulk collection methods begun months
ago.

---

common-pool has a fix for unwanted ClassLoader retention via an
inaccessible thread context class loader.

This differs from Chris' approach of setting the internal TCCL to null.
Instead, it unifies the handling in the default FJTF and the innocuous FJTF
by simply setting the TCCL to the system class loader.  Except that the
innocuous TCCL cannot be reset by a task.

From spliterator at gmail.com  Tue Jan 31 17:08:49 2017
From: spliterator at gmail.com (Stefan Zobel)
Date: Tue, 31 Jan 2017 18:08:49 +0100
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
Message-ID: <CAPkkuScazbz5BcKBEucm=0VUQkC4Ti63b2p+o1bzUFKo3pjwNA@mail.gmail.com>

Hi Martin,

minor thing in CopyOnWriteArrayListTest.java, line 57


55  public static Test suite() {
56      class Implementation implements CollectionImplementation {
57          public Class<?> klazz() { return ArrayList.class; }

Shouldn't this be CopyOnWriteArrayList.class?


Regards,
Stefan

From martinrb at google.com  Tue Jan 31 17:20:02 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 31 Jan 2017 09:20:02 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <CAPkkuScazbz5BcKBEucm=0VUQkC4Ti63b2p+o1bzUFKo3pjwNA@mail.gmail.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<CAPkkuScazbz5BcKBEucm=0VUQkC4Ti63b2p+o1bzUFKo3pjwNA@mail.gmail.com>
Message-ID: <CA+kOe0_S6hzuFvKRfTCBPrswQM017W4dXwCT7+=mFhxMOOxPgQ@mail.gmail.com>

Thanks!  Well spotted!

On Tue, Jan 31, 2017 at 9:08 AM, Stefan Zobel <spliterator at gmail.com> wrote:

> Hi Martin,
>
> minor thing in CopyOnWriteArrayListTest.java, line 57
>
>
> 55  public static Test suite() {
> 56      class Implementation implements CollectionImplementation {
> 57          public Class<?> klazz() { return ArrayList.class; }
>
> Shouldn't this be CopyOnWriteArrayList.class?
>
>
> Regards,
> Stefan
>

From brent.christian at oracle.com  Tue Jan 31 18:19:24 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 31 Jan 2017 10:19:24 -0800
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double)
	are incorrect (updated)
In-Reply-To: <edc5fd74-2cd7-9bd6-d07a-b912bf2753d5@oracle.com>
References: <57B4C392.4060001@oracle.com>	<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>	<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>	<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>	<588A9D3D.1040200@oracle.com>	<75c5a7d6-7c61-2cd0-a3a4-e0d8330e8a23@oracle.com>
	<edc5fd74-2cd7-9bd6-d07a-b912bf2753d5@oracle.com>
Message-ID: <5890D52C.7010609@oracle.com>

> On 1/30/17 5:52 PM, Coleen Phillimore wrote:
>>
>> in
>> http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/src/share/vm/prims/stackwalk.cpp.html
>>
>>  287     int mode = 0;
>>  288     if (_jvf->is_interpreted_frame()) { mode |= MODE_INTERPRETED; }
>>  289     if (_jvf->is_compiled_frame())    { mode |= MODE_COMPILED;    }
>>
>> The mode can't be interpreted AND compiled so the OR doesn't make
>> sense here.  There may be other options though, so I wouldn't make
>> these the only cases.   It should be something more like:
>>
>>   if (_jvf->is_interpreted_frame()) {
>>     mode = MODE_INTERPRETED;
>>   else if (_jvf->is_compiled_frame()) {
>>     mode = MODE_COMPILED;
>>   }
>>
>> with no 'else' because it could be entry or runtime stub or new things
>> that we may eventually add, that you should probably not tell the API.

Thanks - makes sense.  Webrev updated in place.

>> Otherwise this seems fine.   I didn't see the update to test "On the
>> hotspot side, I had to update the 8163014 regtest. "

Ah, that's this:

http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/test/runtime/LocalLong/LocalLongHelper.java.sdiff.html

though the main @test file, .../LocalLong/LocalLongTest.java, didn't 
need any changes.

>> Please make sure JPRT -testset hotspot works with this (or check it in
>> that way).

Yes, that runs cleanly, and I do plan to push through hs.

Thanks for having a look, Coleen.

-Brent

>> On 1/26/17 8:07 PM, Brent Christian wrote:
>>> Hi,
>>>
>>> Please review my updated approach for fixing 8156073 ("2-slot
>>> LiveStackFrame locals (long and double) are incorrect") in the
>>> experimental portion of the StackWalker API, added in JDK 9.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
>>> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
>>>
>>> (For reference, the earlier RFR thread is here:[1].)
>>>
>>> We've concluded that we can't get enough primitive type info from the
>>> VM to use the current fine-grain *Primitive classes in
>>> LiveStackFrameInfo, so those classes have been removed for now. I've
>>> simplified down to just a PrimitiveSlot32 for 32-bit VMs, and
>>> PrimitiveSlot64 for 64-bit VMs.
>>>
>>> We also do not attempt to interpret a primitive's type based on the
>>> slot's contents, and instead return the slot's full contents for
>>> every primitive local.  This more accurately reflects the underlying
>>> layout of locals in the VM (versus the previous proposed
>>> LiveStackFrame.getLocals() behavior of having 64-bit behave like
>>> 32-bit by splitting long/double values into two slots).  On the
>>> 64-bit VM, this returns 64-bits even for primitive local variables
>>> smaller than 64-bits (int, etc).
>>>
>>> The upshot is that we now return the entire value for longs/doubles
>>> on 64-bit VMs.  (The current JDK 9 only reads the first 32-bits.)
>>>
>>> I also now indicate in LiveStackFrameInfo.toString() if the frame is
>>> interpreted or compiled.
>>>
>>> On the testing front:
>>> In the interest of simplifying LiveStackFrame testing down into a
>>> single test file under jdk/test/, I chose not to add the additional
>>> test case from Fabio Tudone [2,3] (thanks, Fabio!), but instead
>>> incorporated some of those testing ideas into the existing test.
>>> Testing is a bit relaxed versus the previously proposed test case; in
>>> particular it does not enforce endianness.
>>>
>>> I also removed the more simplistic CountLocalSlots.java test, given
>>> that the updated LocalsAndOperands.java will now better cover testing
>>> -Xcomp.  On the hotspot side, I had to update the 8163014 regtest.
>>>
>>> Automated test runs have looked fine so far.
>>>
>>> Thanks,
>>> -Brent
>>>
>>> 1.
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042979.html
>>>
>>> 2.
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041666.html
>>>
>>> 3. https://bugs.openjdk.java.net/browse/JDK-8158879
>>>
>>>
>>
>


From daniel.fuchs at oracle.com  Tue Jan 31 18:26:49 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 31 Jan 2017 18:26:49 +0000
Subject: RFR: 8173607: JMX RMI connector should be in its own module
Message-ID: <99aff7a4-ce4c-ad6c-031f-c994225b69df@oracle.com>

Hi,

Please find below a patch for:

8173607: JMX RMI connector should be in its own module
https://bugs.openjdk.java.net/browse/JDK-8173607

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05

This patch makes it possible to remove the requires transitive
java.rmi from the java.management module.

For convenience here is the HTML module-level API documentation
produced by javadoc for the new java.management.rmi module:

http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05/java.management.rmi-summary.html

The patch has some temporary hacks (mainly ConnectorBootstrap.java)
that we will be able to revert when
JDK-8173608 Separate JDK management agent from java.management module
is pushed.

The changes were mainly mechanical except for:

ConnectorBootstrap.java: see above
JMXConnectorFactory.java/JMXConnectorServerFactory.java:
    ServiceLoader is now used to load the default RMI Connector provider
    as a service. There should however be no observable behavior change
    to existing application.
ProxyRef.java, Unmarshal.java: are moved to a new
    com.sun.jmx.remote.internal.rmi package in the new module.
ClientNotifForwarder.java: is modified to no longer depend on
    java.rmi.UnmarshalException - NotSerializableException is used
    instead
RMIConnector.java: fetchNotif is updated to throw
    NotSerializableException instead of UnmarshalException
    The PRef serialization bytes are updated to accomodate the
    new ProxyRef package name.

Some further cleanup of java.base and java.rmi module-info.java
should become possible once JDK-8173608 is in (as well as moving
RMIExporter to java.management.rmi - which is not possible yet).

Further cleanup of @modules in tests might become possible as
well.

Note:
JCK tests for api/javax_management and api/java_lang/management
are passing with this change.

best regards,

-- daniel


From mandy.chung at oracle.com  Tue Jan 31 18:35:35 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 31 Jan 2017 10:35:35 -0800
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are
	incorrect (updated)
In-Reply-To: <CEA0DB3E-AC24-4B37-8252-9E95E54CA2B3@oracle.com>
References: <57B4C392.4060001@oracle.com>
	<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
	<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
	<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
	<588A9D3D.1040200@oracle.com>
	<CEA0DB3E-AC24-4B37-8252-9E95E54CA2B3@oracle.com>
Message-ID: <3E482CA5-F97F-464A-8E67-BB797174FB13@oracle.com>


> On Jan 27, 2017, at 8:26 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> 
>> On Jan 26, 2017, at 5:07 PM, Brent Christian <brent.christian at oracle.com> wrote:
>> 
>> Hi,
>> 
>> Please review my updated approach for fixing 8156073 ("2-slot
>> LiveStackFrame locals (long and double) are incorrect") in the experimental portion of the StackWalker API, added in JDK 9.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
>> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
> 
> :
> 
> Thanks for the good test and I want to take another look at it and get back to you.

I check the updated webrev and looks good.

The test looks good and it?s updated with my suggested formatting that I sent to you offline.  Thanks.

Mandy





From christoph.langer at sap.com  Tue Jan 31 19:02:34 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 31 Jan 2017 19:02:34 +0000
Subject: RFR - Update: 8168664 [JAXP] XALAN: xsl:element generates namespace
	prefixes if namespace is given as URI only
Message-ID: <dcceb6e6de034a748d881d2f3eb19e47@derote13de46.global.corp.sap>

Hi Joe,

evenutally I have updated my webrev for this issue: http://cr.openjdk.java.net/~clanger/webrevs/8168664.1/

I've implemented your suggestion to add a property "jdk.xml.generatePrefix" which is true by default. I also added a testcase which tests the correct behavior with "-Djdk.xml.generatePrefix=false".

Generally, I think namespace prefix generation at this place is not needed. Or would you know of or be able to construct a case where it is really required? If not, I rather think namespace generation at this place should be thrown out unconditionally. Maybe for JDK10? In case it is removed, it would render the test javax/xml/jaxp/unittest/transform/NamespacePrefixTest.java which was implemented recently by Alex for bug https://bugs.openjdk.java.net/browse/JDK-8167179 obsolete in its current form. However, the namespace generation function is still used some place for attribute namespaces.

For JDK9 I can imagine the change of this webrev going in - however, as we already discussed, you would have to do a ccc for me.

Thanks & Best regards
Christoph

From: Langer, Christoph
Sent: Dienstag, 25. Oktober 2016 15:39
To: core-libs-dev at openjdk.java.net
Subject: RFR (JAXP): 8168664 [JAXP] XALAN: xsl:element generates namespace prefixes if namespace is given as URI only

Hi JAXP experts,

please review a fix for a new issue regarding namespace handling in Xalan with xsl:element.

Bug: https://bugs.openjdk.java.net/browse/JDK-8168664
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8168664.0/

I'm not 100% sure if this is the right way to go or if it would break some correct behavior elsewhere. But I think the current behavior is either not correct or at least it is not required to generate new xsl namespace prefixes if the namespace comes in as URI only to an xsl:element node. The interpretative transformer from the Apache Xalan project will also produce the expected output, different to the compiled XSLTC here.

In the webrev, my changes to XslElement.java are only cosmetical/comments, the behavior does not change. In BasisLibrary.java I also took the opportunity to remove the $Id tag and the unused method "nodeList2IteratorUsingHandleFromNode".

If you think my change is good, I'll also add a test that runs the transformation which can be found in the bug...

Thanks & best regards
Christoph


From coleen.phillimore at oracle.com  Tue Jan 31 20:27:46 2017
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 31 Jan 2017 15:27:46 -0500
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are
	incorrect (updated)
In-Reply-To: <5890D52C.7010609@oracle.com>
References: <57B4C392.4060001@oracle.com>
	<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
	<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
	<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
	<588A9D3D.1040200@oracle.com>
	<75c5a7d6-7c61-2cd0-a3a4-e0d8330e8a23@oracle.com>
	<edc5fd74-2cd7-9bd6-d07a-b912bf2753d5@oracle.com>
	<5890D52C.7010609@oracle.com>
Message-ID: <3bd74b91-a34d-6506-6b90-7847ebd0bdf3@oracle.com>

Thanks Brent, looks good!
Coleen

On 1/31/17 1:19 PM, Brent Christian wrote:
>> On 1/30/17 5:52 PM, Coleen Phillimore wrote:
>>>
>>> in
>>> http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/src/share/vm/prims/stackwalk.cpp.html 
>>>
>>>
>>>  287     int mode = 0;
>>>  288     if (_jvf->is_interpreted_frame()) { mode |= 
>>> MODE_INTERPRETED; }
>>>  289     if (_jvf->is_compiled_frame())    { mode |= 
>>> MODE_COMPILED;    }
>>>
>>> The mode can't be interpreted AND compiled so the OR doesn't make
>>> sense here.  There may be other options though, so I wouldn't make
>>> these the only cases.   It should be something more like:
>>>
>>>   if (_jvf->is_interpreted_frame()) {
>>>     mode = MODE_INTERPRETED;
>>>   else if (_jvf->is_compiled_frame()) {
>>>     mode = MODE_COMPILED;
>>>   }
>>>
>>> with no 'else' because it could be entry or runtime stub or new things
>>> that we may eventually add, that you should probably not tell the API.
>
> Thanks - makes sense.  Webrev updated in place.
>
>>> Otherwise this seems fine.   I didn't see the update to test "On the
>>> hotspot side, I had to update the 8163014 regtest. "
>
> Ah, that's this:
>
> http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/test/runtime/LocalLong/LocalLongHelper.java.sdiff.html 
>
>
> though the main @test file, .../LocalLong/LocalLongTest.java, didn't 
> need any changes.
>
>>> Please make sure JPRT -testset hotspot works with this (or check it in
>>> that way).
>
> Yes, that runs cleanly, and I do plan to push through hs.
>
> Thanks for having a look, Coleen.
>
> -Brent
>
>>> On 1/26/17 8:07 PM, Brent Christian wrote:
>>>> Hi,
>>>>
>>>> Please review my updated approach for fixing 8156073 ("2-slot
>>>> LiveStackFrame locals (long and double) are incorrect") in the
>>>> experimental portion of the StackWalker API, added in JDK 9.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
>>>> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
>>>>
>>>> (For reference, the earlier RFR thread is here:[1].)
>>>>
>>>> We've concluded that we can't get enough primitive type info from the
>>>> VM to use the current fine-grain *Primitive classes in
>>>> LiveStackFrameInfo, so those classes have been removed for now. I've
>>>> simplified down to just a PrimitiveSlot32 for 32-bit VMs, and
>>>> PrimitiveSlot64 for 64-bit VMs.
>>>>
>>>> We also do not attempt to interpret a primitive's type based on the
>>>> slot's contents, and instead return the slot's full contents for
>>>> every primitive local.  This more accurately reflects the underlying
>>>> layout of locals in the VM (versus the previous proposed
>>>> LiveStackFrame.getLocals() behavior of having 64-bit behave like
>>>> 32-bit by splitting long/double values into two slots).  On the
>>>> 64-bit VM, this returns 64-bits even for primitive local variables
>>>> smaller than 64-bits (int, etc).
>>>>
>>>> The upshot is that we now return the entire value for longs/doubles
>>>> on 64-bit VMs.  (The current JDK 9 only reads the first 32-bits.)
>>>>
>>>> I also now indicate in LiveStackFrameInfo.toString() if the frame is
>>>> interpreted or compiled.
>>>>
>>>> On the testing front:
>>>> In the interest of simplifying LiveStackFrame testing down into a
>>>> single test file under jdk/test/, I chose not to add the additional
>>>> test case from Fabio Tudone [2,3] (thanks, Fabio!), but instead
>>>> incorporated some of those testing ideas into the existing test.
>>>> Testing is a bit relaxed versus the previously proposed test case; in
>>>> particular it does not enforce endianness.
>>>>
>>>> I also removed the more simplistic CountLocalSlots.java test, given
>>>> that the updated LocalsAndOperands.java will now better cover testing
>>>> -Xcomp.  On the hotspot side, I had to update the 8163014 regtest.
>>>>
>>>> Automated test runs have looked fine so far.
>>>>
>>>> Thanks,
>>>> -Brent
>>>>
>>>> 1.
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042979.html 
>>>>
>>>>
>>>> 2.
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041666.html 
>>>>
>>>>
>>>> 3. https://bugs.openjdk.java.net/browse/JDK-8158879
>>>>
>>>>
>>>
>>
>


From xueming.shen at oracle.com  Tue Jan 31 20:32:03 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 1 Feb 2017 04:32:03 +0800
Subject: <i18n dev> [9] RFR: 8173423: Wrong display name for supplemental
	Japanese era
In-Reply-To: <ca940fce-41ab-bf5a-fe70-cf7804a366fe@oracle.com>
References: <ca940fce-41ab-bf5a-fe70-cf7804a366fe@oracle.com>
Message-ID: <29B69144-B558-4194-BE15-3D8C01AB187C@oracle.com>

+1

On Jan 31, 2017, at 5:27 AM, Naoto Sato <naoto.sato at oracle.com> wrote:

Hello,

Please review the fix to the following bug:

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

The proposed fix is located at:

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

There is a functionality in Japanese Imperial Calendar to supplement a new era from system property. The code path from java.time did not retrieve the supplemental name before the fix, thus the era number "3" was displayed instead. The fix intends to retrieve the correct name, and return it to java.time formatters.

Naoto


From paul.sandoz at oracle.com  Tue Jan 31 20:32:09 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 31 Jan 2017 12:32:09 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
Message-ID: <2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>

ForkJoinPool
?

These changes will require a feature extension request and CCC.

Why does the default worker thread construction require the permission ?getClassLoader? but the innocuous worker thread construction does not? Both result in a call to getSystemLoader.

Unless there is some restriction in Thread?s constructor perhaps it is better to push the doPriv blocks to the special constructors of ForkJoinWorkerThread  that way there is less distance between the permissions and the actions?


ConcurrentLinkedDeque
?

1427                 if ((e = p.item) != null)
1428                     ((a != null) ? a : (a = new Object[n]))[i++] = e;

This is awfully hard to read. Is it really worth it to save an extra line or two?


ConcurrentLinkedQueue
?

 199         void appendRelaxed(Node<E> next) {

Recommend using ?appendPlain? (same in LinkedTransferQueue).


1057     static final VarHandle ITEM;
1058     static final VarHandle NEXT;

Suggest a comment as to why they are package private, due to access via a nested class. (Same in LinkedTransferQueue).


ConcurrentSkipListSet
?

  76  * <p>Bulk operations that add, remove, or examine multiple elements,
  77  * such as {@link #addAll}, {@link #removeIf} or {@link #forEach},
  78  * are <em>not</em> guaranteed to be performed atomically.
  79  * For example, a {@code forEach} traversal concurrent with an {@code
  80  * addAll} operation might observe only some of the added elements.

toArray was removed, and it?s not atomic. Same for many other cases.


ThreadPoolExecutor
?

 131     static void spinAwait(Supplier<Boolean> waitingForGodot) {
 132         for (int spins = 0;;) {
 133             if (waitingForGodot.get())
 134                 return;


:-) "Let's wait till we know exactly how we stand.?.


ThreadPoolExecutorSubclassTest
?

 690                 Callable<Boolean> task = new CheckedCallable<Boolean>() {

 756                 Callable<Boolean> task = new CheckedCallable<Boolean>() {


Diamond on the RHS.

Paul.





> On 31 Jan 2017, at 08:58, Martin Buchholz <martinrb at google.com> wrote:
> 
> Another too-big too-scary wave for this phase of jdk9, but I still think it should go in.  Or we can put into jdk10 first, then down-integrate into jdk9 (when??).
> 
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
> 
> ---
> 
> concurrent-collections has spliterator bug fixes and fixes for rare but serious performance problems in LinkedTransferQueue.
> And it continues the optimization of bulk collection methods begun months ago.
> 
> ---
> 
> common-pool has a fix for unwanted ClassLoader retention via an inaccessible thread context class loader.
> 
> This differs from Chris' approach of setting the internal TCCL to null.  Instead, it unifies the handling in the default FJTF and the innocuous FJTF by simply setting the TCCL to the system class loader.  Except that the innocuous TCCL cannot be reset by a task.
> 


From martinrb at google.com  Tue Jan 31 20:45:10 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 31 Jan 2017 12:45:10 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
Message-ID: <CA+kOe08ciSo=OKaAgqRiuyx_AM387K8LZCjjUbUzTsN6kA1=pA@mail.gmail.com>

On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz <paul.sandoz at oracle.com>
wrote:

>
> ?
>
>  690                 Callable<Boolean> task = new
> CheckedCallable<Boolean>() {
>
>  756                 Callable<Boolean> task = new
> CheckedCallable<Boolean>() {
>
>
> Diamond on the RHS.
>

Diamond compiles with jdk9 but fails with jdk8, and the CVS source files
are still tested with jdk8.

From lance.andersen at oracle.com  Tue Jan 31 21:45:24 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 31 Jan 2017 16:45:24 -0500
Subject: RFR: 8075617, 8075616 Create tests to check wsgen,
	schemagen work with multi-version jar
In-Reply-To: <A26F3D5A-F5C6-4877-9FDB-DDC47AD2DD7A@oracle.com>
References: <CBABED4B-B8A2-4A80-9BD2-8039A055F5AD@oracle.com>
	<86914c18-9d41-6778-4a4d-66acff3442ac@oracle.com>
	<FADC68EB-89AF-4CCA-AEE2-EBF55212D3FC@oracle.com>
	<ff92bd6a-559e-6206-0e23-5d141a4441cf@oracle.com>
	<D0BAB791-CBE0-4BFA-928E-A7405860BE18@oracle.com>
	<75C6ACF3-28E8-4475-B871-049601D1FE79@oracle.com>
	<A26F3D5A-F5C6-4877-9FDB-DDC47AD2DD7A@oracle.com>
Message-ID: <97E00806-D7A7-4A37-B445-64D7C1F8F7FD@oracle.com>

Hi Andrey,

The test looks reasonable.

Assuming Alan has blessed the location and we have run these on all platforms via JPRT, you should be good to go.

Best
Lance
> On Jan 31, 2017, at 8:05 AM, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
> 
> Hi,
> 
> Anyone please review and approve
> 
> ?Andrey
>> On 26 Jan 2017, at 21:29, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
>> 
>> Hi
>> Move tests to new place. Please review.
>> http://cr.openjdk.java.net/~anazarov/8075617/webrev.01/webrev/ <http://cr.openjdk.java.net/~anazarov/8075617/webrev.01/webrev/>
>> 
>> ?Andrey
>>> On 25 Jan 2017, at 19:04, Andrey Nazarov <andrey.x.nazarov at oracle.com> wrote:
>>> 
>>> 
>>>> On 25 Jan 2017, at 19:00, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>> 
>>>> On 25/01/2017 15:25, Andrey Nazarov wrote:
>>>> 
>>>>> :
>>>>> What is the right location?
>>>> These tools are maintained in the upstream Metro project, I suspect the tests for these tools are located there too but I'm not sure. There are handful of JAXB and JAX-WS tests in the jdk repo but I don't think they directly test the tools. So I think you'll need a new location for these, assuming you really want these in the jdk repo.
>>> Is it Ok to use jdk/test/tools/jaxws ? Tools directory already contains tests for jjs for example.
>>>> 
>>>> -Alan
>>> 
>> 
> 

 <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 jonathan.gibbons at oracle.com  Tue Jan 31 21:50:54 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 31 Jan 2017 13:50:54 -0800
Subject: RFR: 8172309: classpath wildcards code does not support
	--class-path
In-Reply-To: <30EF55B3-B321-4488-BFAD-1993E0F31A6C@oracle.com>
References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com>
	<588A78AE.9020101@oracle.com> <588A8FB5.5020601@oracle.com>
	<A4E26709-1275-44E6-82EA-B92DBD7DFA37@oracle.com>
	<30EF55B3-B321-4488-BFAD-1993E0F31A6C@oracle.com>
Message-ID: <589106BE.6010402@oracle.com>

OK

-- Jon

On 01/27/2017 01:12 PM, Henry Jen wrote:
> How about following patch instead for langtools repo?
>
> diff -r ef142ac9824e test/tools/javac/Paths/wcMineField.sh
> --- a/test/tools/javac/Paths/wcMineField.sh     Thu Jan 26 16:53:56 2017 -0800
> +++ b/test/tools/javac/Paths/wcMineField.sh     Fri Jan 27 13:10:12 2017 -0800
> @@ -26,7 +26,7 @@
>   #
>   # @test
>   # @summary Test classpath wildcards for javac and java -classpath option.
> -# @bug 6268383
> +# @bug 6268383 8172309
>   # @run shell/timeout=600 wcMineField.sh
>
>   # To run this test manually, simply do ./wcMineField.sh
> @@ -186,6 +186,8 @@
>   Failure "$javac" ${TESTTOOLVMOPTS} -classpath "GooJar/*${PS}." Main1.java
>   Success "$javac" ${TESTTOOLVMOPTS} -cp "GooJar/SubDir/*" Main1.java
>   Success "$javac" ${TESTTOOLVMOPTS} -classpath "GooJar/SubDir/*" Main1.java
> +Success "$javac" ${TESTTOOLVMOPTS} --class-path "GooJar/SubDir/*" Main1.java
> +Success "$javac" ${TESTTOOLVMOPTS} --class-path="GooJar/SubDir/*" Main1.java
>   #Same with launcher. Should not load jar in subdirectories unless specified
>   Failure "$java" ${TESTVMOPTS}  -classpath "GooJar/*${PS}." Main1
>   Success "$java" ${TESTVMOPTS}  -classpath "GooJar/SubDir/*${PS}." Main1
>
> Cheers,
> Henry
>
>
>> On Jan 26, 2017, at 6:01 PM, Henry Jen <henry.jen at oracle.com> wrote:
>>
>>> On Jan 26, 2017, at 4:09 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>>
>>> Henry,
>>>
>>> You've changed old test cases into new test cases, thereby eliminating the old cases, which is not so good.
>>>
>>> You should be adding new test cases, but changing old ones.
>>>
>> I am not sure, I believe all wild-card cases still tested, just that we have different variety of calling -cp. Of course, it would be nice to test all cases with all 4 flavors of -cp, but I don?t think that?s necessary as I think the test coverage is the same.
>>
>> Anyway, I could be wrong. If you feel strong about this, I can redo it. But that may takes more time to digest what the test cases are really for.
>>
>> Cheers,
>> Henry
>>
>>
>>> -- Jon
>>>
>>>
>>> On 01/26/2017 02:31 PM, Kumar Srinivasan wrote:
>>>> Hi Henry,
>>>>
>>>> Looks ok to me. Thanks for making this change.
>>>>
>>>> Kumar
>>>>
>>>>> Hi,
>>>>>
>>>>> Please review the webrev[1], the fix is to ensure ?class-path and ?class-path= is processed correctly to expand wildcard. Changes are made in jdk repo. However, test case to verify the bug fix is in langtool repo.
>>>>>
>>>>> Cheers,
>>>>> Henry
>>>>>
>>>>> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/
>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8172309


From martinrb at google.com  Tue Jan 31 22:00:08 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 31 Jan 2017 14:00:08 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
Message-ID: <CA+kOe08=bDPOb3q52p4tZU_4SkpbjKFtthHaV7XD5VF0r1LihQ@mail.gmail.com>

On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz <paul.sandoz at oracle.com>
wrote:

> ForkJoinPool
> ?
>
> These changes will require a feature extension request and CCC.
>
> Why does the default worker thread construction require the permission
> ?getClassLoader? but the innocuous worker thread construction does not?
> Both result in a call to getSystemLoader.
>
>
OK, added that permission for creating an innocuous thread.
Seems difficult to test.


> Unless there is some restriction in Thread?s constructor perhaps it is
> better to push the doPriv blocks to the special constructors of
> ForkJoinWorkerThread  that way there is less distance between the
> permissions and the actions?
>

I had the same thought, but that would introduce even more churn.

From martinrb at google.com  Tue Jan 31 22:18:06 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 31 Jan 2017 14:18:06 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
Message-ID: <CA+kOe08H_fAxsqxsZdUzyEVXZKH+-7MpMixWCqfWn_TOW6Y+2A@mail.gmail.com>

On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz <paul.sandoz at oracle.com>
wrote:

>
> ConcurrentLinkedDeque
> ?
>
> 1427                 if ((e = p.item) != null)
> 1428                     ((a != null) ? a : (a = new Object[n]))[i++] = e;
>
> This is awfully hard to read. Is it really worth it to save an extra line
> or two?
>

You're right.  Better style, better bytecode:

 Index: concurrent/ConcurrentLinkedDeque.java
===================================================================
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/ConcurrentLinkedDeque.java,v
retrieving revision 1.87
diff -u -U 1 -r1.87 ConcurrentLinkedDeque.java
--- concurrent/ConcurrentLinkedDeque.java 29 Dec 2016 23:08:16 -0000 1.87
+++ concurrent/ConcurrentLinkedDeque.java 31 Jan 2017 22:13:02 -0000
@@ -1397,4 +1397,7 @@
                 final E e;
-                if ((e = p.item) != null)
-                    ((a != null) ? a : (a = new Object[n]))[i++] = e;
+                if ((e = p.item) != null) {
+                    if (a == null)
+                        a = new Object[n];
+                    a[i++] = e;
+                }
                 if (p == (p = q))
Index: concurrent/ConcurrentLinkedQueue.java
===================================================================
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/ConcurrentLinkedQueue.java,v
retrieving revision 1.156
diff -u -U 1 -r1.156 ConcurrentLinkedQueue.java
--- concurrent/ConcurrentLinkedQueue.java 14 Jan 2017 06:50:52 -0000 1.156
+++ concurrent/ConcurrentLinkedQueue.java 31 Jan 2017 22:13:03 -0000
@@ -843,4 +843,7 @@
                 final E e;
-                if ((e = p.item) != null)
-                    ((a != null) ? a : (a = new Object[n]))[i++] = e;
+                if ((e = p.item) != null) {
+                    if (a == null)
+                        a = new Object[n];
+                    a[i++] = e;
+                }
                 if (p == (p = q))
Index: concurrent/LinkedTransferQueue.java
===================================================================
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/LinkedTransferQueue.java,v
retrieving revision 1.153
diff -u -U 1 -r1.153 LinkedTransferQueue.java
--- concurrent/LinkedTransferQueue.java 18 Jan 2017 23:40:58 -0000 1.153
+++ concurrent/LinkedTransferQueue.java 31 Jan 2017 22:13:03 -0000
@@ -1034,4 +1034,7 @@
                 if (p.isData) {
-                    if (item != null)
-                        ((a != null) ? a : (a = new Object[n]))[i++] =
item;
+                    if (item != null) {
+                        if (a == null)
+                            a = new Object[n];
+                        a[i++] = item;
+                    }
                 } else if (item == null) {

From martinrb at google.com  Tue Jan 31 22:41:56 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 31 Jan 2017 14:41:56 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
Message-ID: <CA+kOe08K9vROjnYPJBU587XLfW0x6q9o9UiwgRaYRgEzYq7v4w@mail.gmail.com>

On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz <paul.sandoz at oracle.com>
wrote:

>
> ?
>
>  131     static void spinAwait(Supplier<Boolean> waitingForGodot) {
>  132         for (int spins = 0;;) {
>  133             if (waitingForGodot.get())
>  134                 return;
>
>
> :-) "Let's wait till we know exactly how we stand.?.
>

You didn't ask for anything, but let's reclaim some vertical space without
loss of readability:

 Index: src/test/jtreg/util/concurrent/ThreadPoolExecutor/ConfigChanges.java
===================================================================
RCS file:
/export/home/jsr166/jsr166/jsr166/src/test/jtreg/util/concurrent/ThreadPoolExecutor/ConfigChanges.java,v
retrieving revision 1.11
diff -u -U 1 -r1.11 ConfigChanges.java
--- src/test/jtreg/util/concurrent/ThreadPoolExecutor/ConfigChanges.java 22
Dec 2016 00:22:22 -0000 1.11
+++ src/test/jtreg/util/concurrent/ThreadPoolExecutor/ConfigChanges.java 31
Jan 2017 22:39:48 -0000
@@ -131,5 +131,3 @@
     static void spinAwait(Supplier<Boolean> waitingForGodot) {
-        for (int spins = 0;;) {
-            if (waitingForGodot.get())
-                return;
+        for (int spins = 0; !waitingForGodot.get(); ) {
             if ((spins = (spins + 1) & 3) > 0) {
Index: src/test/jtreg/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java
===================================================================
RCS file:
/export/home/jsr166/jsr166/jsr166/src/test/jtreg/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java,v
retrieving revision 1.11
diff -u -U 1 -r1.11 ThrowingTasks.java
--- src/test/jtreg/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java 4
Jan 2017 04:46:19 -0000 1.11
+++ src/test/jtreg/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java 31
Jan 2017 22:39:48 -0000
@@ -174,5 +174,3 @@
     static void spinAwait(Supplier<Boolean> waitingForGodot) {
-        for (int spins = 0;;) {
-            if (waitingForGodot.get())
-                return;
+        for (int spins = 0; !waitingForGodot.get(); ) {
             if ((spins = (spins + 1) & 3) > 0) {

From martinrb at google.com  Tue Jan 31 22:55:00 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 31 Jan 2017 14:55:00 -0800
Subject: RFR: jsr166 jdk9 integration wave 14
In-Reply-To: <2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
References: <CA+kOe09x5GHbpXzBrQsFr3aPYpeebAHAtRUBZuDho7dxrYiY6g@mail.gmail.com>
	<2EAFB6CB-F9A3-409E-81EB-02DCAB5AB152@oracle.com>
Message-ID: <CA+kOe0-sN8sbQ9mW5saPeAtbQN7zsDaxk446BNWFdfQ6dMqKOQ@mail.gmail.com>

On Tue, Jan 31, 2017 at 12:32 PM, Paul Sandoz <paul.sandoz at oracle.com>
wrote:

>
> 1057     static final VarHandle ITEM;
> 1058     static final VarHandle NEXT;
>
> Suggest a comment as to why they are package private, due to access via a
> nested class. (Same in LinkedTransferQueue).
>
>
package private is almost always used for nestmates in j.u.c.; a comment
doesn't seem worthwhile.


>
> ConcurrentSkipListSet
> ?
>
>   76  * <p>Bulk operations that add, remove, or examine multiple elements,
>   77  * such as {@link #addAll}, {@link #removeIf} or {@link #forEach},
>   78  * are <em>not</em> guaranteed to be performed atomically.
>   79  * For example, a {@code forEach} traversal concurrent with an {@code
>   80  * addAll} operation might observe only some of the added elements.
>
> toArray was removed, and it?s not atomic. Same for many other cases.
>

We tried to maintain complete lists of non-atomic operations, but those
became stale as new methods got added to  superclasses/superintterfaces.
Even toString is non-atomic!  Give up or be pedantically exhaustive?

From martinrb at google.com  Tue Jan 31 23:13:50 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 31 Jan 2017 15:13:50 -0800
Subject: RFR: 8172309: classpath wildcards code does not support
	--class-path
In-Reply-To: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com>
References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com>
Message-ID: <CA+kOe0-Y5zNANPVC8Kdwx=jzpFwLSvcCbwj0QfXAUNk-Ywr4NQ@mail.gmail.com>

I would try to avoid having the wildcard code know about the various ways
of specifying classpath.  We now have 3 different classpath flags - can
they be canonicalized into one form before wildcard handling?

On Wed, Jan 25, 2017 at 1:23 PM, Henry Jen <henry.jen at oracle.com> wrote:

> Hi,
>
> Please review the webrev[1], the fix is to ensure ?class-path and
> ?class-path= is processed correctly to expand wildcard. Changes are made in
> jdk repo. However, test case to verify the bug fix is in langtool repo.
>
> Cheers,
> Henry
>
> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8172309/0/
> [2] https://bugs.openjdk.java.net/browse/JDK-8172309

From martinrb at google.com  Tue Jan 31 23:18:47 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 31 Jan 2017 15:18:47 -0800
Subject: RFR: 8172309: classpath wildcards code does not support
	--class-path
In-Reply-To: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com>
References: <7E5C9282-F3CE-4914-921A-DDF69D5245AD@oracle.com>
Message-ID: <CA+kOe0_DUUnC17Vkr7Xk0nRiJi6gwz7+WV0mExYqK+hhwnfUsg@mail.gmail.com>

Can we have tests in sets of threes, checking -cp, -classpath,
--class-path (and perhaps also CLASSPATH environment)


--- a/test/tools/launcher/ClassPathWildCard.sh
+++ b/test/tools/launcher/ClassPathWildCard.sh
@@ -125,7 +125,7 @@
   CheckFail TestA

   rm -f TestB${OUTEXT}
-  $JAVA${variant} -classpath JarDir/"*"$NOOP TestB || exit 1
+  $JAVA${variant} -cp JarDir/"*"$NOOP TestB || exit 1
   CheckFail TestB


@@ -134,11 +134,11 @@
   cp TestD/*.class JarDir

   rm -f TestC${OUTEXT}
-  $JAVA${variant} -classpath JarDir${PATHSEP}JarDir/"*"$NOOP TestC || exit 1
+  $JAVA${variant} --class-path JarDir${PATHSEP}JarDir/"*"$NOOP TestC || exit 1
   CheckFail TestC

   rm -f TestD${OUTEXT}
-  $JAVA${variant} -classpath JarDir${PATHSEP}JarDir/"*"$NOOP TestD || exit 1
+  $JAVA${variant} --class-path=JarDir${PATHSEP}JarDir/"*"$NOOP TestD || exit 1
   CheckFail TestD

From henry.jen at oracle.com  Tue Jan 31 23:40:13 2017
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 31 Jan 2017 15:40:13 -0800
Subject: RFR: 8171524: jar --help doesn't provide information that stdout and
	stdin can be used as output and input for tool
Message-ID: <52B6BACF-00BB-486C-ACD3-C80E3CECB799@oracle.com>

Hi,

Please review a trivial fix[1] for JDK-8171524.

The fix added a short paragraph about @argfile. Clarify stdin or stdout is used if ?file is omitted.

It also correct that -h, not -? is for the short option for ?help.

Cheers,
Henry

[1] http://cr.openjdk.java.net/~henryjen/jdk9/8171524/0/webrev/